He's discounting a technology that's designed to give you HDTV quality content because he thinks people want to store that content on their hard drives. How exactly is that content going to get from the distributor to your hard drive? Am I expected to download 50 gig of data? Even over an 8Mbps connection (which is far in excess of what _most_ people have these days) that's over 14 hours assuming I can saturate the connection. And most home-user connections are asymmetrical so peer2peer won't help nearly as much as you might think so the distributors will need stupid amounts of bandwidth. I don't think it's reasonable to make people wait 14 hours for something they would normally walk round the corner to the DVD shop for - instant gratification is a big deal in the retail sector.
This is a far cry from downloading sub-DVD quality content from ITMS - he's talking about HDTV content.
I don't doubt that in 5-10 years the average home-user will have enough bandwidth to make this feasable, but Blu-Ray is on sale *now* and it has 5-10 years to be useful.
Besides, I for one prefer to buy stuff on a physical medium that I can store how I want (on a shelf or ripped to my hard drive) - that's why I still buy CDs.
Colorado is testing conversion of electricity to H2 and then use the H2 to drive an internal combustion engine to drive a generator (how inefficient can you get).
What kind of efficiencies do you get using an internal combustian engine vs. fuel cell?
Unfortunately, (around here) the council keep building lots of very short (i.e. 20 metre) stretches of cycle lane that serve no purpose other than letting the council make the claim "we built 20 new cycle lanes!". When I was at college I used to cycle every day, but was knocked off enough times and had so many near-misses that frankly I'm scared to cycle on the roads these days - having cars fly past you at 50mph when you're wobbling up a steep hill at 10mph is no fun when they don't actually pull out to give you room (I've been clipped by car wing mirrors on a number of occasions - there's no way the car should be that close). However, as a driver I know the problems - at rush hour I _can't_ pull out to give the cyclists the space they should have because the traffic in the oncoming lane is non-stop.
I still maintain that a pedestrian walking around a blind bend and getting hit by a cyclist is going to come off no worse (probably better!) than a cyclist getting hit by a car. For one thing, in my experience the car that hits you isn't going to do the most damage - it's the one behind that you fall into the path of after being hit.
Because in Britain most things that might be marginally dangerous and/or interesting are banned. Such as cycling on the motorway.
Sorry, but having cyclists on the motorway would be a downright menace to drivers - its bad enough having cyclists on fast A-roads. Cyclists _shouldn't_ be on the roads any more than pedestrians should. Now I'm not taking an anti-cyclist stance here (I used to cycle a lot myself), I'm saying that there should be another prevision for cyclists rather than making them cycle on the roads. I'm not, on the whole, sure why having cycles on the road is considered better than having cyclists on the walkway - I rather suspect a pedestrian being hit by a cyclist doing 30mph is going to be in better shape than a cyclist being hit by a car doing 50mph.
In any case, most of the time there are non-motorway routes which would be better for a cyclist to take.
1. You still need port forwarding set up on your NAT to accept inbound calls 2. Since with NAT you only have a single global-scope address you can only have a single end-point for incoming calls (i.e. if you have multiple phones you would _have_ to run your own asterisk server inside your LAN) 3. Whilest it's a friendly protocol, it is not the industry standard (for good or bad, SIP has pretty much won as the standard with it's adoption into IMS, etc).
Well NAT is a huge pain in the arse for anything peer-to-peer - for example VoIP.
Lets take Skype (horrible system that it is) for example. You want to make a call:
1. Caller A places a call to caller B. This involves talking to the Skype directory server and ggiving caller A the IP address for caller B. 2. The system realises that caller B is behind a NAT so caller A can't start a connection to B... ok, no problem, we just get caller B to initiate the session instead. 3. Oh wait, A is also behind a NAT so B can't start a connection to A. 4. Lots of nasty NAT traversal hacks are tried to tick the NATs on both ends into allowing the traffic through. 5. Sometimes the NAT traversal works, lets assume in this case it doesn't. The only way to get traffic between A and B is to go via a third party server. 6. Another random Skype user's connection (which isn't using NAT) is hijacked - both A and B connect to this Skype user and use his connection to pass the traffic. This means that not only is it sucking the bandwidth and CPU time up on the third party's connection, but that connection may vanish at any instant and there is added latency caused by going via a connection of unknown quality.
Whereas without NAT that'd just be a case of A connecting to B and all would be good.
Also, being about to log into my video recorder from my cellphone and ask it to record something would be cool:)
At the risk of being pedantic, a x.x.x.255 address CAN BE a valid IP address in certain masks.
Ah, but this is where you're defeated again by Microsoft's broken IP stacks. Certainly under Win 95/98 era windows would refuse to talk to any address ending in.0 or.255, even though it had no way of knowing if it was really an invalid address (since you need to know the netmask to determine that). I've no idea if this is fixed in modern Windows, I suspect so since they now run a ripped off BSD stack, but if you want to be sure legacy Windows systems can't talk to you then use a.500 or.0 address.:)
I am curious to see what the working solution is to allow people to have their own internal addresses, such as NAT provides, in the case of IPv6.
There is no solution - IPv6 originally had site-local scope networks assigned but these have been withdrawn because the people up at the top think that site-local addresses are bad and everyone should have global scope addresses (I agree with this for networks that are Internet connected but I'm really not convinced that having no allocated addresses for completely isolated networks is a Good Thing).
In any case, changing the prefix of IPv6 networks is relatively easy, so migrating to a real global scope address when you connect to the Internet isn't much effort.
Also, are there still DNS servers that ignore the AAAA entry (IPv6 address entry)?
I've neither heard of nor come across this problem. In any case, you can always run your own DNS server (the assumption being that people who run broken DNS servers that can't cope with IPv6 are probably not running IPv6 networks:)
I can easily foresee a two-tier Internet, where there is IPV6 at some level "up there," but us unwashed masses will continue to get IPV4.
That's essentially what we have at the moment - if I hosted a server at a big datacentre (for example, if I shoved it on the AMIX network) then I'd get native IPv6 routing whereas over my home DSL I have to use 6to4 tunnelling.
Cisco sees IPV6 as an opportunity to sell more hardware
I'm not convinced that adoption of IPv6 will cause a huge increase in the amount of hardware Cisco is selling - all their kit has supported IPv6 natively for years already.
As long as IPv6 isn't required to get everywhere, they can save money by using smaller/fewer routers to do IPv4 work.
I think that rather depends on how much of the network is IPv6 only - if there's a large chunk that's only on IPv6 then refusing to support it would be like telling the customers "we've decided to not route any of your traffic to the US anymore because that's cheaper for us". Customers would be leaving them in droves - they don't need to understand _why_ parts of the internet are inaccessible, it will just become known that this ISP is crap because they have "firewalled" off part of the internet in the interests of cost saving.
My concern is the same thing happening with IPV6. Sure, there may be lots more addresses, but who's to say how efficiently they will be dispersed.
Have you any idea just how many 2^128 addresses is? Lets say you hand out/48 subnets - you've got 281 trillian of them to go around, and then each one of those subnets has 1.2 septillion individual addresses in it. Given that there's only about 6 billion people in the world it would take some mammouth mismanagement to allocate the whole lot.
What happens when ISP's still hand out only _one_ address per user?
Get a better ISP.
except that you've got worse support because people think NAT shouldn't exist anymore.
Well this is possibly a good point here - these days it's the norm for people to have more than one machine plugged into their internet connection (especially with modern games consoles, set top boxes, etc. having ethernet too). So they can't tell people they can only plug in a single machine like they did 5 years ago, and without any IPv6 NAT implementations around they don't have a lot of choice but to hand out subnets. It's also worth noting that the IPv6 auto-configuration system (built into the protocol) _requires_ the netmask to be/64 so it would cause hassle for everyone if you only got a single address. And besides, what's in it for the ISP? I get a/29 IPv4 subnet for free off my ISP because I asked for it - if there were plenty of IPv4 addresses then they'd be happy handing out/24's to anyone so it's not like they'd benefit from restricting the number of addresses available.
I know it would be technically monstrous to do, but I've always felt that IPv6 should've been null-terminated or something - some case where the max IP address length could be obscenely long
What's the point? IPv6 is already obscenely long. Doing variable length addresses would just increase the load on the backbone routers because they would have to have much more complex routing algorithms (I understand most of them use ASICs to do/48 netmask comparisons in hardware so that's _fast_).
Yes, and they do - a number of datacentres (AMIX springs to mind) run native ipv6 networks over the same cables as the ipv4 traffic. And for those of us who aren't so lucky, anyone with a global scope IPv4 address can use 6to4 tunnelling to connect to the v6 network. Turning on 6to4 is about a 5 second job under Fedora Core - you just set a couple of variables in the network config.
When do the root servers transfer over?
Some of them are on ipv6 already, although sadly I _still_ can't submit AAAA name server glue through OpenSRS.:(
If they can co-exist, what's the motivation for *everyone* to switch?
Well, obviously if you have no IPv6 address then you're not going to be able to contact someone who has no IPv4 address. The other way around is not entirely true since you can encode IPv4 addresses as IPv6 addresses and then send the traffic via a gateway (which essentially does NAT).
I think the motivation (for the West) is for peer-to-peer applications. For example, VoIP would be much more effective if you didn't go through a NAT.
What happens to smaller countries that don't have the resources to make hardware changes to keep up to date.
The developing world seems to be embracing IPv6 at the moment anyway to a much greater extent than the West. There are also probably very few hardware changes needed - most routers used in infrastructure will already support IPv6 (everyone except Microsoft has been shipping IPv6 capable kit for over 10 years, and even MS is now bundling a (crap) IPv6 stack in XP). And you can always tunnel IPv6 over IPv4 in places where you *really* can't do it natively.
This has been done. 192.88.99.1 is a magic address that should route towards the nearest 6to4 gateway.
Sadly, "nearest" isn't always "best". I had to override the gateway I use because the anycast one had round trip times of several seconds! What we need is for individual ISPs to provide gateways rather than bouncing traffic half way around the planet.
From TFA: Another debate occasionally resurfaces about reclaiming some of the early allocations to further extend the lifetime of IPv4. Hopefully this article has shown that the ROI for that approach is going to be extremely low. Discussions around the Internet community show there is an expectation that it will take several years of substantive negotiation (in multiple court systems around the globe) to retrieve any/8s. Then following that effort and expense, the likelihood of even getting back more than a few/8 blocks is very low. Following the allocation growth trend, after several years of litigation the result is likely to be just a few months of additional resource added to the pool--and possibly not even a whole month. All this assumes IANA does not completely run out before getting any back, because running out would result in pentup demand that could immediately exhaust any returns.
Actually, NAT is better because it provides address space isolation. If your organisation has 500 computers that all have a public IP address, it is harder for you to switch providers (500 IPs is too small to get your own address space for). When you switch your provider, you have to renumber all hosts, fix config files, fix DNS servers etc -- a royal pain in the ass. A NAT allows your to keep your internal structure exactly the same while you switch providers. That address isolation is very important for small-mid sized companies.
IPv6 supports network migration quite easilly. Basically the idea is that you change your prefix but leave the rest of the address the same. Since you had a clue when you set up the network (right?:), all your addressing is done through DNS and your machines are configured by DHCPv6 or the native IPv6 router discovery protocol (which is part of the IPv6 stack), so just changing the prefix on your router and in DNS will cause your entire network to migrate over to the new network automagically.
Mandatory support for ipsec is great.. except how many of us would use it?
Well, all those businesses that currently shell out rediculous amounts of money for VPN solutions I suppose. Things will get more interesting if DNSSEC (shoving X.509 certificates in DNS records) gets widespread and easier to use - at the moment it's horrendously complex to set up.
I think in the long run it'd be nice to use IPSEC with DNSSEC instead of SSL, etc. There are some advantages - for one thing, once the keys have been negotiated between 2 hosts then that's it (until they expire), no having to renegotiate the encryption for every connection with the associated multiple round trips needed. Of course it'll cause firewall administrators a headache since they can nolonger filter packets by port number.
Weaker how? If you can't address a node, how can you attack it?
Well, ignoring the fact that there _are_ ways to defeat NAT (although they usually require cooperation from hosts behind the NAT anyway), one notable weakness is that you're relying on your ISP to get things right, and relying on someone else's cluefulness is always bad.
What I mean by that is, given a network like:
PC (192.168.0.1) ------ (192.168.0.254) Router (1.2.3.4) ------- ISP
Assuming 1.2.3.4 is a global scope address and 192.168.0.0/24 is site-local. The router is doing NAT, all well and good. However, if the ISP somehow ends up routing traffic destined to 192.168.0.1 to your router (for exacmple, a routing cockup on their end) then most consumer grade routers will just let it right through because they don't explicitly block incoming traffic.
Admittedly it's unlikely this would happen, and only nodes reasonably close to you would be able to take advantage of the routing. However, I still maintain that trusting a third party as part of your network security is a Bad Thing.
but I don't see how it's less secure than the complicated (and thus fallible) filtering rules in a "real" firewall.
Firewall rules don't have to be especially complex - a firewall that does the same job as a NAT (security wise) but provides protection from the above problem is simply a connection tracker configured to drop incoming connections. Infact, since a NAT is basically a connection tracker with some more stuff shoved ontop it could be argued that the NAT is more complex and thus more fallible.
Of course they can run side by side, but why turn it on now when it isn't absolutly necessary? We can still use IPv4 until it reaches critical mass.
Well you have to have some kind of overlap period. If you just suddenly tell people "you're not getting an IPv4 address, but here have this shiny new IPv6 address instead" when very few people are actually on the v6 network then you'll get lots of angry people. The way to do it is to hand out both v4 and v6 addresses side by side so by the time you can't hand out anymore v4 addresses everyone's using v6 anyway. (And yes, I'm aware that it's possible to do some translation between v4 and v6 but it's nowhere near as versatile as the real thing).
but I'll bet reclaiming old absurdly huge allocations of IP space could push this out beyond 10-12 years
TFA does talk about reclaiming old IP allocations and concludes the return is not worth the investment. It also seems the Microsoft IP stacks cause problems (as usual) by not allowing people to use the experimental networks, which means those can't be reassigned.
I remember reading a while ago that NAT actually turned out to be better than IPv6 by virtue of it "solving" the limited number of addresses problem and simultaneously providing a defence against simple hacking attempts by hiding your real IP address.
NAT in itself doesn't provide any extra security - the connection tracking needed by NAT is what provides the security (and you can do this equally well without using NAT). I wrote an article on this subject a while back.
Whiles NAT does to some extent "solve" the limited number of addresses problem, it also creates many more problems. The Internet was designed to be peer to peer but NAT turns it into a client/server model. Whilest client/server works fine for "traditional" applications such as web surfing, it's a major stumbling block for peer to peer services such as VoIP, which have to employ various hacks to trick NATs into letting the peer-to-peer traffic through (with varying degrees of success). The likes of Skype are designed to hijack the connections of random Skype users who don't have NAT and use them to route traffic between peers who do have NAT when the NAT traversal hacks fail.
Everyone is just waiting to push the big red button and turn on the support
Why do you need to wait to turn it on? IPv4 and v6 can run side by side. I've been running v6 for a few years using 6to4 tunnelling to provide connectivity since my ISP doesn't do native IPv6... infact I haven't seen *any* ISP (in the UK) offering IPv6 connectivity over DSL. Just providing a 6to4 anycast gateway on their core network would be a start.
Oh, I see, you don't even know what a virus is. No wonder Mac users think they are invincible.
Strictly speaking, a virus is a lump of code that embeds itself in a legitimate executable. When that application is executed, the viral code is loaded into memory and modifies other legitimate executable files, embedding itself in them too. Usually the infected executable works as you would expect and the viral code isn't noticable until the payload kicks in. A simple method of embedding a virus is to just append it to the end of the executable and insert a jump at the start of the program to execute the viral code before starting the legitimate application.
Under a Unix OS a virus can't spread very far unless it's executed as root since most of the executables on the system aren't writable by non-root users. And if the sysadmin wants to be more paranoid, he can mount all the filesystems the normal users have write access to as noexec. Root accounts are usually only used where absolutely necessary so the window of opportunity for huge infection is small. Also, since most stuff executes as non-root, the viral payload should only be able to damage a single user's data.
I'm fairly sure there hasn't been an actual virus written in a good few years.
Most of what the media call "viruses" are really trojans or worms (or a hibred of the two).
Trojans rely on user-stupidity and the tradition of doing most things as non-root limits the window of opportunity and the damage they can do.
Worms rely on security holes in services - Windows has a history of having more known and unpatched security holes than other operating systems. I'm afraid the "Microsoft is only targetted because there are more Microsoft systems out there" doesn't pull much weight when you compare IIS and Apache security problems - there are way more Apache servers than IIS servers out there yes IIS has a much worse security record.
I'm happy that Microsoft is starting to address the security problems but they have a long way to go - much of their software is fundamentally flawed and I despare every time I see Microsoft talking about a new malware scanner they're working on, etc. The anti-malware companies have no choice but to produce band-aid solutions to deal with the security holes, but MS is in the position of being able to fix the fundamental problems instead of producing utilities to work around them.
A good analagy would be a double-glazing company that knows full well that a slight breeze in the wrong direction will cause the windows to break because of a design flaw, but rather than fixing the flaw they just ship the windows with a free board to nail over them when it happens (with the possibility that they might start charging for that bit of wood in the future).
So whilest I'll admit that Unix type operating systems _do_ have security weaknesses, they're nowhere near as bad as Microsoft's effort.
Old -> legacy -> entrenchment... The only escape is when cost(refractoring_to_new) cost(maintaining_old)... Which is starting to happen in the case of COBOL due to the aging of that generation...
Entrenchment is certainly there (and I'm the first to admit that I'm fairly entrenched in coding C), but in my experience, smart people with the right kind of attitudes can frequently relearn stuff *when there is a reason to*. E.g. 5 years ago I didn't know PHP, now I can program in it fluently. A year ago I didn't know XSLT. 7 years ago I didn't know how to use CSS or Javascript. These are all things which I have learnt because I have seen a significant advantage in using them. Meanwhile, I haven't bothered to learn C++ or Java because they don't do anything (for me) significantly better than C.
And who in their right minds lets any mission critical server auto-patch itself, regardless of operating system. That's just utter madness!
That rather depends on your set up. At my old job I was managing a customer's global network. They had a central colocation and redundent servers. So for example, 3 web-accellerator servers with the load balanced across them using LVS. If a server completely broke (i.e. a service stopped answering connections) it would automatically be taken out of the LVS configuration. If the server was still accepting connections but not performing as expected then clearly the automatic systems weren't going to work, but it could be taken out of service within seconds manually. So the servers were auto-patched at staggered times of the week (e.g. monday, wednesday, friday) and if an update broke anything (none ever did) then I could've taken the affected server offline and postponed the updates of the other servers until the problem had been resolved. This seemed like a good solution since it lead to very fast patching with very minimal risk and effort since any problems could simply be taken out of service while they were fixed with no effect to the end-user.
Although I agree that if you haven't designed your network sensibly with redundent systems then auto-patching is probably a very bad thing (but it's a hell of a lot better than not patching at all).
Slashdot Mirror
He's discounting a technology that's designed to give you HDTV quality content because he thinks people want to store that content on their hard drives. How exactly is that content going to get from the distributor to your hard drive? Am I expected to download 50 gig of data? Even over an 8Mbps connection (which is far in excess of what _most_ people have these days) that's over 14 hours assuming I can saturate the connection. And most home-user connections are asymmetrical so peer2peer won't help nearly as much as you might think so the distributors will need stupid amounts of bandwidth. I don't think it's reasonable to make people wait 14 hours for something they would normally walk round the corner to the DVD shop for - instant gratification is a big deal in the retail sector.
This is a far cry from downloading sub-DVD quality content from ITMS - he's talking about HDTV content.
I don't doubt that in 5-10 years the average home-user will have enough bandwidth to make this feasable, but Blu-Ray is on sale *now* and it has 5-10 years to be useful.
Besides, I for one prefer to buy stuff on a physical medium that I can store how I want (on a shelf or ripped to my hard drive) - that's why I still buy CDs.
Colorado is testing conversion of electricity to H2 and then use the H2 to drive an internal combustion engine to drive a generator (how inefficient can you get).
What kind of efficiencies do you get using an internal combustian engine vs. fuel cell?
Unfortunately, (around here) the council keep building lots of very short (i.e. 20 metre) stretches of cycle lane that serve no purpose other than letting the council make the claim "we built 20 new cycle lanes!". When I was at college I used to cycle every day, but was knocked off enough times and had so many near-misses that frankly I'm scared to cycle on the roads these days - having cars fly past you at 50mph when you're wobbling up a steep hill at 10mph is no fun when they don't actually pull out to give you room (I've been clipped by car wing mirrors on a number of occasions - there's no way the car should be that close). However, as a driver I know the problems - at rush hour I _can't_ pull out to give the cyclists the space they should have because the traffic in the oncoming lane is non-stop.
I still maintain that a pedestrian walking around a blind bend and getting hit by a cyclist is going to come off no worse (probably better!) than a cyclist getting hit by a car. For one thing, in my experience the car that hits you isn't going to do the most damage - it's the one behind that you fall into the path of after being hit.
Because in Britain most things that might be marginally dangerous and/or interesting are banned. Such as cycling on the motorway.
Sorry, but having cyclists on the motorway would be a downright menace to drivers - its bad enough having cyclists on fast A-roads. Cyclists _shouldn't_ be on the roads any more than pedestrians should. Now I'm not taking an anti-cyclist stance here (I used to cycle a lot myself), I'm saying that there should be another prevision for cyclists rather than making them cycle on the roads. I'm not, on the whole, sure why having cycles on the road is considered better than having cyclists on the walkway - I rather suspect a pedestrian being hit by a cyclist doing 30mph is going to be in better shape than a cyclist being hit by a car doing 50mph.
In any case, most of the time there are non-motorway routes which would be better for a cyclist to take.
1. You still need port forwarding set up on your NAT to accept inbound calls
2. Since with NAT you only have a single global-scope address you can only have a single end-point for incoming calls (i.e. if you have multiple phones you would _have_ to run your own asterisk server inside your LAN)
3. Whilest it's a friendly protocol, it is not the industry standard (for good or bad, SIP has pretty much won as the standard with it's adoption into IMS, etc).
what are the benefits to the average end-user?
:)
Well NAT is a huge pain in the arse for anything peer-to-peer - for example VoIP.
Lets take Skype (horrible system that it is) for example. You want to make a call:
1. Caller A places a call to caller B. This involves talking to the Skype directory server and ggiving caller A the IP address for caller B.
2. The system realises that caller B is behind a NAT so caller A can't start a connection to B... ok, no problem, we just get caller B to initiate the session instead.
3. Oh wait, A is also behind a NAT so B can't start a connection to A.
4. Lots of nasty NAT traversal hacks are tried to tick the NATs on both ends into allowing the traffic through.
5. Sometimes the NAT traversal works, lets assume in this case it doesn't. The only way to get traffic between A and B is to go via a third party server.
6. Another random Skype user's connection (which isn't using NAT) is hijacked - both A and B connect to this Skype user and use his connection to pass the traffic. This means that not only is it sucking the bandwidth and CPU time up on the third party's connection, but that connection may vanish at any instant and there is added latency caused by going via a connection of unknown quality.
Whereas without NAT that'd just be a case of A connecting to B and all would be good.
Also, being about to log into my video recorder from my cellphone and ask it to record something would be cool
At the risk of being pedantic, a x.x.x.255 address CAN BE a valid IP address in certain masks.
.0 or .255, even though it had no way of knowing if it was really an invalid address (since you need to know the netmask to determine that). I've no idea if this is fixed in modern Windows, I suspect so since they now run a ripped off BSD stack, but if you want to be sure legacy Windows systems can't talk to you then use a .500 or .0 address. :)
Ah, but this is where you're defeated again by Microsoft's broken IP stacks. Certainly under Win 95/98 era windows would refuse to talk to any address ending in
I am curious to see what the working solution is to allow people to have their own internal addresses, such as NAT provides, in the case of IPv6.
:)
There is no solution - IPv6 originally had site-local scope networks assigned but these have been withdrawn because the people up at the top think that site-local addresses are bad and everyone should have global scope addresses (I agree with this for networks that are Internet connected but I'm really not convinced that having no allocated addresses for completely isolated networks is a Good Thing).
In any case, changing the prefix of IPv6 networks is relatively easy, so migrating to a real global scope address when you connect to the Internet isn't much effort.
Also, are there still DNS servers that ignore the AAAA entry (IPv6 address entry)?
I've neither heard of nor come across this problem. In any case, you can always run your own DNS server (the assumption being that people who run broken DNS servers that can't cope with IPv6 are probably not running IPv6 networks
I can easily foresee a two-tier Internet, where there is IPV6 at some level "up there," but us unwashed masses will continue to get IPV4.
That's essentially what we have at the moment - if I hosted a server at a big datacentre (for example, if I shoved it on the AMIX network) then I'd get native IPv6 routing whereas over my home DSL I have to use 6to4 tunnelling.
Cisco sees IPV6 as an opportunity to sell more hardware
I'm not convinced that adoption of IPv6 will cause a huge increase in the amount of hardware Cisco is selling - all their kit has supported IPv6 natively for years already.
As long as IPv6 isn't required to get everywhere, they can save money by using smaller/fewer routers to do IPv4 work.
I think that rather depends on how much of the network is IPv6 only - if there's a large chunk that's only on IPv6 then refusing to support it would be like telling the customers "we've decided to not route any of your traffic to the US anymore because that's cheaper for us". Customers would be leaving them in droves - they don't need to understand _why_ parts of the internet are inaccessible, it will just become known that this ISP is crap because they have "firewalled" off part of the internet in the interests of cost saving.
My concern is the same thing happening with IPV6. Sure, there may be lots more addresses, but who's to say how efficiently they will be dispersed.
/48 subnets - you've got 281 trillian of them to go around, and then each one of those subnets has 1.2 septillion individual addresses in it. Given that there's only about 6 billion people in the world it would take some mammouth mismanagement to allocate the whole lot.
/64 so it would cause hassle for everyone if you only got a single address. /29 IPv4 subnet for free off my ISP because I asked for it - if there were plenty of IPv4 addresses then they'd be happy handing out /24's to anyone so it's not like they'd benefit from restricting the number of addresses available.
/48 netmask comparisons in hardware so that's _fast_).
Have you any idea just how many 2^128 addresses is? Lets say you hand out
What happens when ISP's still hand out only _one_ address per user?
Get a better ISP.
except that you've got worse support because people think NAT shouldn't exist anymore.
Well this is possibly a good point here - these days it's the norm for people to have more than one machine plugged into their internet connection (especially with modern games consoles, set top boxes, etc. having ethernet too). So they can't tell people they can only plug in a single machine like they did 5 years ago, and without any IPv6 NAT implementations around they don't have a lot of choice but to hand out subnets. It's also worth noting that the IPv6 auto-configuration system (built into the protocol) _requires_ the netmask to be
And besides, what's in it for the ISP? I get a
I know it would be technically monstrous to do, but I've always felt that IPv6 should've been null-terminated or something - some case where the max IP address length could be obscenely long
What's the point? IPv6 is already obscenely long. Doing variable length addresses would just increase the load on the backbone routers because they would have to have much more complex routing algorithms (I understand most of them use ASICs to do
Can IPv4 and IPv6 coexist?
:(
Yes, and they do - a number of datacentres (AMIX springs to mind) run native ipv6 networks over the same cables as the ipv4 traffic. And for those of us who aren't so lucky, anyone with a global scope IPv4 address can use 6to4 tunnelling to connect to the v6 network. Turning on 6to4 is about a 5 second job under Fedora Core - you just set a couple of variables in the network config.
When do the root servers transfer over?
Some of them are on ipv6 already, although sadly I _still_ can't submit AAAA name server glue through OpenSRS.
If they can co-exist, what's the motivation for *everyone* to switch?
Well, obviously if you have no IPv6 address then you're not going to be able to contact someone who has no IPv4 address. The other way around is not entirely true since you can encode IPv4 addresses as IPv6 addresses and then send the traffic via a gateway (which essentially does NAT).
I think the motivation (for the West) is for peer-to-peer applications. For example, VoIP would be much more effective if you didn't go through a NAT.
What happens to smaller countries that don't have the resources to make hardware changes to keep up to date.
The developing world seems to be embracing IPv6 at the moment anyway to a much greater extent than the West. There are also probably very few hardware changes needed - most routers used in infrastructure will already support IPv6 (everyone except Microsoft has been shipping IPv6 capable kit for over 10 years, and even MS is now bundling a (crap) IPv6 stack in XP). And you can always tunnel IPv6 over IPv4 in places where you *really* can't do it natively.
This has been done. 192.88.99.1 is a magic address that should route towards the nearest 6to4 gateway.
Sadly, "nearest" isn't always "best". I had to override the gateway I use because the anycast one had round trip times of several seconds! What we need is for individual ISPs to provide gateways rather than bouncing traffic half way around the planet.
Isn't worth it to whom?
/8s. Then following that effort and expense, the likelihood of even getting back more than a few /8 blocks is very low. Following the allocation growth trend, after several years of litigation the result is likely to be just a few months of additional resource added to the pool--and possibly not even a whole month. All this assumes IANA does not completely run out before getting any back, because running out would result in pentup demand that could immediately exhaust any returns.
From TFA: Another debate occasionally resurfaces about reclaiming some of the early allocations to further extend the lifetime of IPv4. Hopefully this article has shown that the ROI for that approach is going to be extremely low. Discussions around the Internet community show there is an expectation that it will take several years of substantive negotiation (in multiple court systems around the globe) to retrieve any
Actually, NAT is better because it provides address space isolation. If your organisation has 500 computers that all have a public IP address, it is harder for you to switch providers (500 IPs is too small to get your own address space for). When you switch your provider, you have to renumber all hosts, fix config files, fix DNS servers etc -- a royal pain in the ass. A NAT allows your to keep your internal structure exactly the same while you switch providers. That address isolation is very important for small-mid sized companies.
:), all your addressing is done through DNS and your machines are configured by DHCPv6 or the native IPv6 router discovery protocol (which is part of the IPv6 stack), so just changing the prefix on your router and in DNS will cause your entire network to migrate over to the new network automagically.
IPv6 supports network migration quite easilly. Basically the idea is that you change your prefix but leave the rest of the address the same. Since you had a clue when you set up the network (right?
Mandatory support for ipsec is great.. except how many of us would use it?
Well, all those businesses that currently shell out rediculous amounts of money for VPN solutions I suppose. Things will get more interesting if DNSSEC (shoving X.509 certificates in DNS records) gets widespread and easier to use - at the moment it's horrendously complex to set up.
I think in the long run it'd be nice to use IPSEC with DNSSEC instead of SSL, etc. There are some advantages - for one thing, once the keys have been negotiated between 2 hosts then that's it (until they expire), no having to renegotiate the encryption for every connection with the associated multiple round trips needed. Of course it'll cause firewall administrators a headache since they can nolonger filter packets by port number.
Weaker how? If you can't address a node, how can you attack it?
Well, ignoring the fact that there _are_ ways to defeat NAT (although they usually require cooperation from hosts behind the NAT anyway), one notable weakness is that you're relying on your ISP to get things right, and relying on someone else's cluefulness is always bad.
What I mean by that is, given a network like:
PC (192.168.0.1) ------ (192.168.0.254) Router (1.2.3.4) ------- ISP
Assuming 1.2.3.4 is a global scope address and 192.168.0.0/24 is site-local. The router is doing NAT, all well and good. However, if the ISP somehow ends up routing traffic destined to 192.168.0.1 to your router (for exacmple, a routing cockup on their end) then most consumer grade routers will just let it right through because they don't explicitly block incoming traffic.
Admittedly it's unlikely this would happen, and only nodes reasonably close to you would be able to take advantage of the routing. However, I still maintain that trusting a third party as part of your network security is a Bad Thing.
but I don't see how it's less secure than the complicated (and thus fallible) filtering rules in a "real" firewall.
Firewall rules don't have to be especially complex - a firewall that does the same job as a NAT (security wise) but provides protection from the above problem is simply a connection tracker configured to drop incoming connections. Infact, since a NAT is basically a connection tracker with some more stuff shoved ontop it could be argued that the NAT is more complex and thus more fallible.
All I know is that if, once my broadband ISP serves up IPv6, they want to charge me extra for a static IP, I'll be pissed.
/48 and /64 subnets.
What kind of freaky ISP charges for IP addresses? I get a subnet of 8 IPv4 addresses for free.
In any case, IPv6 addresses won't be handed out singley - they'll be handed out in
Of course they can run side by side, but why turn it on now when it isn't absolutly necessary? We can still use IPv4 until it reaches critical mass.
Well you have to have some kind of overlap period. If you just suddenly tell people "you're not getting an IPv4 address, but here have this shiny new IPv6 address instead" when very few people are actually on the v6 network then you'll get lots of angry people. The way to do it is to hand out both v4 and v6 addresses side by side so by the time you can't hand out anymore v4 addresses everyone's using v6 anyway. (And yes, I'm aware that it's possible to do some translation between v4 and v6 but it's nowhere near as versatile as the real thing).
but I'll bet reclaiming old absurdly huge allocations of IP space could push this out beyond 10-12 years
TFA does talk about reclaiming old IP allocations and concludes the return is not worth the investment. It also seems the Microsoft IP stacks cause problems (as usual) by not allowing people to use the experimental networks, which means those can't be reassigned.
I remember reading a while ago that NAT actually turned out to be better than IPv6 by virtue of it "solving" the limited number of addresses problem and simultaneously providing a defence against simple hacking attempts by hiding your real IP address.
NAT in itself doesn't provide any extra security - the connection tracking needed by NAT is what provides the security (and you can do this equally well without using NAT). I wrote an article on this subject a while back.
Whiles NAT does to some extent "solve" the limited number of addresses problem, it also creates many more problems. The Internet was designed to be peer to peer but NAT turns it into a client/server model. Whilest client/server works fine for "traditional" applications such as web surfing, it's a major stumbling block for peer to peer services such as VoIP, which have to employ various hacks to trick NATs into letting the peer-to-peer traffic through (with varying degrees of success). The likes of Skype are designed to hijack the connections of random Skype users who don't have NAT and use them to route traffic between peers who do have NAT when the NAT traversal hacks fail.
Everyone is just waiting to push the big red button and turn on the support
Why do you need to wait to turn it on? IPv4 and v6 can run side by side. I've been running v6 for a few years using 6to4 tunnelling to provide connectivity since my ISP doesn't do native IPv6... infact I haven't seen *any* ISP (in the UK) offering IPv6 connectivity over DSL. Just providing a 6to4 anycast gateway on their core network would be a start.
Oh, I see, you don't even know what a virus is. No wonder Mac users think they are invincible.
Strictly speaking, a virus is a lump of code that embeds itself in a legitimate executable. When that application is executed, the viral code is loaded into memory and modifies other legitimate executable files, embedding itself in them too. Usually the infected executable works as you would expect and the viral code isn't noticable until the payload kicks in. A simple method of embedding a virus is to just append it to the end of the executable and insert a jump at the start of the program to execute the viral code before starting the legitimate application.
Under a Unix OS a virus can't spread very far unless it's executed as root since most of the executables on the system aren't writable by non-root users. And if the sysadmin wants to be more paranoid, he can mount all the filesystems the normal users have write access to as noexec. Root accounts are usually only used where absolutely necessary so the window of opportunity for huge infection is small. Also, since most stuff executes as non-root, the viral payload should only be able to damage a single user's data.
I'm fairly sure there hasn't been an actual virus written in a good few years.
Most of what the media call "viruses" are really trojans or worms (or a hibred of the two).
Trojans rely on user-stupidity and the tradition of doing most things as non-root limits the window of opportunity and the damage they can do.
Worms rely on security holes in services - Windows has a history of having more known and unpatched security holes than other operating systems. I'm afraid the "Microsoft is only targetted because there are more Microsoft systems out there" doesn't pull much weight when you compare IIS and Apache security problems - there are way more Apache servers than IIS servers out there yes IIS has a much worse security record.
I'm happy that Microsoft is starting to address the security problems but they have a long way to go - much of their software is fundamentally flawed and I despare every time I see Microsoft talking about a new malware scanner they're working on, etc. The anti-malware companies have no choice but to produce band-aid solutions to deal with the security holes, but MS is in the position of being able to fix the fundamental problems instead of producing utilities to work around them.
A good analagy would be a double-glazing company that knows full well that a slight breeze in the wrong direction will cause the windows to break because of a design flaw, but rather than fixing the flaw they just ship the windows with a free board to nail over them when it happens (with the possibility that they might start charging for that bit of wood in the future).
So whilest I'll admit that Unix type operating systems _do_ have security weaknesses, they're nowhere near as bad as Microsoft's effort.
Old -> legacy -> entrenchment... The only escape is when cost(refractoring_to_new) cost(maintaining_old)... Which is starting to happen in the case of COBOL due to the aging of that generation...
Entrenchment is certainly there (and I'm the first to admit that I'm fairly entrenched in coding C), but in my experience, smart people with the right kind of attitudes can frequently relearn stuff *when there is a reason to*. E.g. 5 years ago I didn't know PHP, now I can program in it fluently. A year ago I didn't know XSLT. 7 years ago I didn't know how to use CSS or Javascript. These are all things which I have learnt because I have seen a significant advantage in using them. Meanwhile, I haven't bothered to learn C++ or Java because they don't do anything (for me) significantly better than C.
And who in their right minds lets any mission critical server auto-patch itself, regardless of operating system. That's just utter madness!
That rather depends on your set up. At my old job I was managing a customer's global network. They had a central colocation and redundent servers. So for example, 3 web-accellerator servers with the load balanced across them using LVS. If a server completely broke (i.e. a service stopped answering connections) it would automatically be taken out of the LVS configuration. If the server was still accepting connections but not performing as expected then clearly the automatic systems weren't going to work, but it could be taken out of service within seconds manually. So the servers were auto-patched at staggered times of the week (e.g. monday, wednesday, friday) and if an update broke anything (none ever did) then I could've taken the affected server offline and postponed the updates of the other servers until the problem had been resolved. This seemed like a good solution since it lead to very fast patching with very minimal risk and effort since any problems could simply be taken out of service while they were fixed with no effect to the end-user.
Although I agree that if you haven't designed your network sensibly with redundent systems then auto-patching is probably a very bad thing (but it's a hell of a lot better than not patching at all).