Federal Agencies Must Use IPv6 by 2008 295
MoiTominator writes "The White House Office of Management and Budget announced on Wednesday that all federal agencies must deploy IPv6 by June 2008. So far, Defense is the only agency which has made any progress toward implementing the new protocol." From the article: "While we know that IPv6 technologies are deployed throughout the government we do not know specifically which ones, how many there are, or precisely where they are located...For cost, the agencies must report on estimates for planning, infrastructure acquisition, training and risk mitigation."
Nice to see that... (Score:4, Insightful)
Re:Nice to see that... (Score:4, Interesting)
Basically, install an IPv6 stack on everything you can and use IPv6 ready software/hardware over IPv4. Eventually upstream people will see IPv6 all over the place using Toredo, and implement an IPv6 network.
My school runs on IPv6, along with a few others in the area, and our upstream provider is already implementing an IPv6 network for us.
Re:Nice to see that... (Score:2)
Its nice to see that government is implementing IPv6, but I'm more curious as to when it will be implemented by the private sector and widely used.
My guess, probably never.
Re:Nice to see that... (Score:2)
Everybody has their own citadel with their data servers up in pearly white towers. The only clear access to the information desk is across a gantry high above a wall of fire. As you walk across this gantry your every step is watched by a 50 eyed beholder...
Re:Nice to see that... (Score:3, Insightful)
NAT, dynamic DNS, and all the other "hacks" which resolved the problems in ways which were backward compatible. Between NAT, dynamic DNS, and application level protocols to negotiate ports, we don't have merely 4 billion IP addresses, we have 28147 trillion, and that, to misquote Bill Gates, should be enough for anyone.
I'm not saying IPv4 is going to last forever. Like anything else, it won't. But I'm pretty convinced that IPv6 won't be the next widely adopted protocol after IPv4. To (properly) quote D
Re:Nice to see that... (Score:3, Insightful)
You CAN have IPv4 and IPv6 on the same network. (Score:5, Insightful)
What is stopping the implementation of IPv6 are those pesky legacy devices, legacy operating systems (ie Windows) and legacy hardware accelerated routers, and the fact the Internet being as big as it is - it's basically impossible to do a clean switchover, and there ARE problems when combining the two systems - even though you can have both on the same network, they won't be interoperable (=really bad).
Of course IPv6 has been designed to work around these issues as well as possible, but there will be issues eg getting a IPv4 machine to connect to a IPv6 one. And NAT has been the easier-to-implement short-term-solution for home 'puters etc...
Re:You CAN have IPv4 and IPv6 on the same network. (Score:4, Informative)
IPv6 Preview for Windows 2000 [microsoft.com]
Advanced Networking Pack for Windows XP [microsoft.com]
FAQ About the IPv6 Protocol for Windows XP [microsoft.com]
Re:Nice to see that... (Score:3, Informative)
So please explain: if me and someone I'm trying to contact are both behind NAT, what number do I try to connect to if I want to directly connect to this computer, i.e. the whole damn point of the Internet?
Like has been said before, the people who think NAT is acceptable all want or have their own real IP addresses.
It will when major ISPs start supporting it (Score:3, Insightful)
Re:It will when major ISPs start supporting it (Score:3, Insightful)
And the major reason the vast majority of the big isps don't offer it is because there is no demand for it. Anyone offering a useful service on the web can afford a few bucks a month for a static IPv4 address, and I don't see that fact going away, ever. So what do you get by going with IPv6? AFAICT, nothing but incompatibility problems.
IPv6 would have been better than IPv4, if we were building the internet from scratch. But Beta is better than VHS too, and I don't know very many people with Beta casse
Re:It will when major ISPs start supporting it (Score:2)
But Beta is better than VHS too, and I don't know very many people with Beta cassette players.
Except that it's not. VHS had a longer capacity than Beta, and for most people being able to record more on a single tape was more important than a marginal difference in quality.
Re:Nice to see that... (Score:3, Insightful)
Re:Nice to see that... (Score:5, Insightful)
Now think about this: there's an entire class A subnet allocated to MIT. There's quite a few class A subnets allocated for various US governmental institutions. There's a whole one for Apple computer.
But, there's just one for the entire African continent. Some ISPs in countries besides the US cannot give their customers a real IP address! There are not enough to go round. The way they have been allocated is clearly skewed.
So yes, lots of people stand to gain by having more addresses. They just happen to be in some of the poorer nations.
Unless... (Score:3, Funny)
Re:Unless... (Score:2)
Re:Unless... (Score:2)
From the article:
Jawad Khaki, corporate vice president for Microsoft [said] Microsoft's next operating system, dubbed Longhorn, will be "fully IPv6-capable,"
Re:Unless... (Score:2)
Source [ipv6.org]
Re:Unless... (Score:2)
Re:Unless... (Score:2)
Progress in DoD (Score:5, Insightful)
This has appeared all along like a deliberate attempt to force a "technology refresh" that would be beneficial to major US networking companies than any real response to technical superiority of the IPv6 protocols.
If the technical merit were really there (many of the supposed IPv6 improvements have been backported to v4), my guess is a specific mandate wouldn't be necessary. Business would take care of it.
NAT (Score:5, Insightful)
Re:NAT (Score:4, Informative)
Nothing a simple firewall can't handle.
Re:NAT (Score:2)
NAT, as implemented by 95% of SOHO routing equipment is an inherrant protection system in that it prevents direct access to the machines connected behind them. In and of itself, NAT is a deny all, allow some mechanism which therefore offers a degree of protection that a simple 'this IP address belongs to this computer' routing setup can't offer. In that case the user must then also create a firewall ruleset
Re:NAT (Score:2)
In that case the user must then also create a firewall ruleset based on their network topology.
The default ruleset would merely do precisely what the NAT box does: Deny all incoming connections. The network topology in question is simple: One NIC connected to the outside world, another connected to a switch to which all of the interior computers are connected.
With respect to security, NAT offers nothing that a simple stateful firewall does not.
Re:NAT (Score:2)
Plug ADSL/Cable modem in one end, plug mom, dad, sis, and your computers in the other end. Instant security. Asking users to configure their own subnet and then create their own stateful firewall ("What's 'stateful'? What's a 'firewall'?") isn't realistic.
Re:NAT (Score:2)
Plug ADSL/Cable modem in one end, plug mom, dad, sis, and your computers in the other end. Instant security.
Yep. That's exactly what would happen given a $25 firewall box.
Asking users to configure their own subnet and then create their own stateful firewall ("What's 'stateful'? What's a 'firewall'?") isn't realistic.
Who asked them to configure anything? A small, off-the-shelf firewall box would do it all automatically. It would actually do *exactly* the same thing the NAT box does, except it c
Re:NAT (Score:3, Interesting)
Home users would buy a hardware firewall with routing and DHCP, plug it in, and get a home network that doesn't allow incoming connections by default.
Almost. The box wouldn't do DHCP, because it wouldn't know what IP addresses to hand out. DHCP service could be provided by the ISP, but since we're talking about IPv6, it's more likely that DHCP would simply disappear, and the machines would use autoconfiguration.
Re:NAT (Score:2)
And then you find out that company with 3000 machines to RDP into is using just about half of RFC1918 space and happens to be using the same portion of it that you are... doh!
Re:NAT (Score:2)
the biggest single nat problem is vpn tunneling. that a nat setup have to rewrite the source or destination part of the header can mess up or make invalid the tunnel if it require packet signing (ie, use private key to add a checksum for the header) fro
Re:NAT (Score:2)
Re:NAT (Score:3, Insightful)
If NAT goes out of style, the home router people will just focus more on delivering good firewalls, and a lot of people (probably inclu
Re:NAT (Score:2)
Re:NAT (Score:2)
The biggest problem I see with this attitude (not that I entirely disagree with it) is that it assumes NAT will go away in v6.
What's more likely, if IPv6 does catch on, is that NAT will be replaced by IPv4 to IPv6 tunnels.
But I seriously doubt this is going to happen. Redesigning everything from scratch is a software engineer's wet dream, but in the real world for a system to work it needs to be much more backward compatible than IPv6. It's like DJB said [cr.yp.to]: "The IPv6 designers made a fundamental concept
Re:NAT (Score:2)
We already have have about 2^48 IPv4 addresses for things using SVC records.
The real reason we ran out of IPv4 address is that cisco routers can't cope with a full routing table. Some how quadrupling the amount of memory the same routing table needs isn't going fix the problem.
Re:NAT (Score:3, Informative)
Re:NAT (Score:2)
I know the real world isn't as nice. I've been dealing with routing issues since the days of the uumaps collapsing and I've seen where IPv6 is headed.
Re:NAT (Score:2)
T
Re:NAT (Score:2)
I think those would be called NPT boxes (network protocol translation)...
Re:NAT (Score:2)
NAT doesn't have a security aspect. It just rewrites the addresses and ports on outbound packets and keeps track of them to rewrite the corresponding replies. If you don't have filter rules to back it up then any traffic can just flow right into your network. NAT doesn't cause packets to be dropped.
Re:NAT (Score:2)
A NAT router without special configuration has no way of accepting inward connections. So, by inserting an autoconfigured NAT box in front of a system you efficively have an autoconfigured firewall that only allows outbound connections.
This is like a filter that protects all your services that were intended for inside use only.
Re:NAT (Score:2)
Re:NAT (Score:2)
Re:NAT (Score:3, Informative)
Some people buy these devices as security devices, becasue incoming connections do not go through to their system by default...
Re:NAT (Score:3, Insightful)
In cases where hosts are already connected when the router is turned on, this means that whatever device requests an IP address first would get connections forwarded to it.
And in cases where there's only one PC connected, that's probably because people are using it as a firewall *because* it does not forward incoming connections. I know a few people that recommend this.
Re:NAT (Score:2)
My old Intel Express ISDN router do. By default it makes reverse mapping for all ports to the inside PC that triggered the outgoing link.
Re:NAT (Score:2)
So, you can connect to the sshd on my 10.0.0.31 box that is behind a public IP attached to a NAT'ing device? (No you can't any neither can anyone else without compromising the device performing the NAT'ing.) It causes packets that don't have a port redirection rule, to a private IP/port tuple, on the public interface to be dropped. It's a very crude version of a "deny all" rule that uses rewrite/redirection where a firewall would use "allow in" rules.
-Rusty
Well, IPv6 is nice (Score:2, Interesting)
Benefits of IPv6 (Score:5, Informative)
Page 46, CCNP Self-Study, Paquet Teare
Re:Benefits of IPv6 (Score:5, Informative)
The larger address space is meaningless as long as it's harder to get independently routeable IPv6 prefixes than it is for IPv4. IPv6 headers are not fixed-size, especially in enterprise environments, the extension headers make the IPv6 header variable-length, causing endless headaches with hardware-assisted forwarding. Quality of implementation of the transition mechanism often suck, and they introduce new security issues. IPsec for IPv6 is not widely available, in contrast to IPsec for IPv4 -- even though it is mandated by the RFCs.
Right now, IPv6 cannot deliver any of the new features it promises. It makes a lot of sense not to deploy it at this stage.
Re:Benefits of IPv6 (Score:2)
Look at it from an economic perspective: You have a limited resource imperfectly distributed. If some people who want/need the resource that can't get it, because its already been distributed, then you have an artificial shortage. While reclaiming and redistributing is a valid option, you should never ignore the option of increasing the amount of your limited resource.
Re:Benefits of IPv6 (Score:2)
Re:Benefits of IPv6 (Score:3, Insightful)
Yeah, because actually being able to have an address so people can connect to you over the Internet is a terrible thing... Better to have NAT where the Internet is only one-way, you can't provide anything, just be a mindless consumer of websites. And forget p2p, ftp, and all that crap. Oh and forget about the fact that corporations and universities in America each have as many addresses as the whole of Africa. As long as rich American
Likely future events... (Score:3, Interesting)
Re:Likely future events... (Score:3, Informative)
Re:Likely future events... (Score:2)
...and firewalls aren't the end all to security. (Thus, the sig.)
NAT is a capability of routers. It's not the only capability of routers, nor is it a necessary feature to enable when configuring them. (I'm talking about a full-featured router and other related devices, not a plug-and-go untweaked home model.)
Mac OSX has had great IPv6 for a while (10.2)! (Score:5, Informative)
http://evanjones.ca/macosx-ipv6.html [evanjones.ca]
And the feds moved back their deadline so many times that even 2008 will be pushed back.
Apple even had a demo of ipv6 in OS9 once, and a long while back was big on it.
Most people, who enjoy semi-anon IP addresses from defacto forced reissue taht I know are against IPv6 and see it for all its regretful faults, despite its wonderful goals and alleged benefits.
In an IPv6 world... there will be no more anononymity except at a WiFi cafe lacking video cameras.
Re:Mac OSX has had great IPv6 for a while (10.2)! (Score:3, Insightful)
And here shall commence the argument about whether or not anonymity on the Internet is a Good Thing or a Bad Thing.
Re:Mac OSX has had great IPv6 for a while (10.2)! (Score:5, Interesting)
The tin foil hat brigade is on the march, again.
If you want an "anonymous" IP address, there is nothing to prevent you from using a sooper-sekret random number instead of the interface's MAC. See RFC 3041 [ietf.org].
Re:Mac OSX has had great IPv6 for a while (10.2)! (Score:2)
In an IPv6 world... there will be no more anononymity except at a WiFi cafe lacking video cameras.
Hmm, I think just the opposite would be true. Now that every person on the planet can have a billion IP addresses, it'll be feasible to use a different IP address every single minute for the rest of your life. Yes, IPv6 makes it possible for even a dialup server to give out static IP addresses to everyone, but it doesn't require it.
This could have a big impact on sites like Slashdot which rely at least in
Re:Mac OSX has had great IPv6 for a while (10.2)! (Score:2)
What are these anonymous IP addresses you speak of? What about IPv6 makes the addresses less anonymous than IPv4?
To guarantee US adoption of IPv6... (Score:5, Funny)
NAT-PT for linux (Score:2, Interesting)
I don't think anyone wants go through the
pain of double stacks. So to run a ipv6
only network, and connect it with both
v4 and v6, you would need a v6tov4 nat
device (nat-pt). I haven't seen anyone
offering that, at least no linux based solution
(some *bsd might be able to do that, not sure).
Missing improvements (Score:5, Interesting)
A) A protocol between the ordinary level2 and IP(level3) (Could be named layer 2.5) that takes care of error-corrections via retransmissions. Not replacing TCP's error-correcting retransmissions, but in addition to those. The reason is that most lost packets are lost packets on a single link because of load issues and such, and not because a whole link falls and breaks a route. In those cases, it is very inefficient to retransmit the whole route, and to add a huge latency-overhead to the packet transmission.
B) Get rid of the silly "port" concept. Ports are just internal-computer addresses, and as such, should simply be part of the address itself. There should be no reason to distinguish between the network address and the host address and thus subnets were created, and that separation no longer exists. Just the same, there should be no reason to distinguish between net/host address an application addresses. Removing the "port" concept and placing it as part of the IP address itself has the following benefits:
I) UDP becomes redundant to IP itself, the whole protocol is about adding the port address and can be discarded.
II) DNS entries can point to applications and not hosts. This would allow www.server.com and www2.server.com to point to different webservers in the same computer. This would allow to discard the "virtual web hosts" feature. It would also allow to support multiple servers of any type (ftp, smtp, etc) on any host, all pointed by dns, without messing with the port supplied to the user.
III) An internal network can route the same application address to any host it chooses, easing the distribution of load. It would also not expose to the external world how applications are served on which hosts.
Anyhow, I look forward to seeing those features in IPv7.
Re:Missing improvements (Score:3, Interesting)
However, with B you certainly have a valid point!
How inconvenient it is that you cannot set an MX re
Re:Missing improvements (Score:3, Informative)
Re:Missing improvements (Score:2)
Having a larger address and using it with all protocols, instead of using the port concept only with certain protocols, would have been better.
Re:Missing improvements (Score:5, Insightful)
A) Look for MPLS and its future succesor GMPLS.
B) The port concept is a TCP/UDP layer issue, not an IP issue. You can use lots of IPv6 addresses for the same device (IPv6 permits explicitly that) and just one port if that is what you prefer. I personally don't see the improvement. IP addresses are assigned to devices (in the IPv6 paradigm), ports are assigned to application uses. I personally beleive it is much straightforward this arrangement that an IP derived solution. At least now, you now port 80 means (at least should) web access.
Re:Missing improvements (Score:2)
Anyone who ever wanted to run multiple copies of the same service on the same machine, or wanted to move applications that were once on the same machine to different machines, knows the advantage of that.
Re:Missing improvements (Score:3, Insightful)
Bring on the Vultures (Score:3, Insightful)
Consultant: Hey, buddy o'mine in the White House Budget office, lets do lunch.
WhiteHouse: OK
Consultant: You know, if you dont use IPv6, you're obsolete.
WhiteHouse: Really?
Consultant: Yep. You wouldn't want the (Commies|Al-Qaeda|Chinese|French) to be ahead of us, would you?
WhiteHouse: Hell no!
Consultant: Nobody is going to deploy IPv6 w/o a reason. It's hard to do.
WhiteHouse: Hmm, we need to do this, its a matter of Homeland Suck-your-ity. Can you help?
Consultant: Why sure, but you should make sure that only me and a few others are approved for this gig, you wouldn't want any incompatibilities, would you?
WhiteHouse: Damn straight, I think I'll have another Scotch.
Consultant: Go ahead, its on me. *evil cackle*
This is good news for Contractors (Score:4, Insightful)
Another GOSIP? (Score:5, Interesting)
GOSIP (Government OSI Profile, and the acronym was used separately by the US and UK) was a requirement to implement the OSI protocol stack by some date in the 1980s. It was a procurement requirement: Every system bought by the feds as of a certain date had to have OSI. Unless it got a waiver.
Some people took this to mean that the government would transition from TCP/IP to OSI by then. And this would lead the world to OSI. And so they invested heavily in OSI. (Remember DEC?) Come to think of it, the way the lead story is written here, you get the same impression, that by 2008 the feds really will be using IPv6.
But that's not what GOSIP meant. It meant that the equipment had to have OSI available, not that the government would actually use it. Having OSI was a checklist item. And eventually it got discarded, because nobody would actually use it; TCP/IP did the job well enough, and some of the early OSI implementations were, to be polite, a pile of crap. But a pile of crap still meets the checklist for an option that won't be used!
IPv6 is somewhat dumber, protocol-wise, than OSI. It has been around for well over a decade, solving non-problems with non-solutions, ignoring problems of the public Internet that developed since then, while promising higher overhead, obsolesence of equipment, difficult management and transtion, and more money for Cisco. So unless you're Cisco, there's no reason to go there. And nobody is going there.
Microsoft will meet the checkoff, as will other vendors, but I predict that in 2009, IPv6 will still see little use, even by the feds. Perhaps if we're lucky somebody will be talking about really fixing the problems in the current protocol stack, rather than going with a hack that was created for internal political reasons at IETF before the Internet was even open to the public.
The whole thing is absurd. (Score:3, Informative)
Here's the way things really should go. There are two possibilities, and they're not mutually exclusive.
1) For mobile devices:
Mobile devices should be addressed by a hardware address. This hardware address shouldn't be tied directly to the device, however, as mobile devices can be broken or lost easily. This is do-able right now with SIM cards. They have a SIM ID that could be used in place of an outdated phone number system. (Let's face it, POTS is ancient and crufty, and so are its numbering systems.) If you drop your cell phone and break it, move the SIM card to the new one.
One thing to watch out for here, though: All cell phones must use the same protocols, and all cell providers must use the same protocols. This ends their convenient lock-in semi-monopolies on their customers. This is a practice that isn't going to end without a fight.
2) Wired devices:
Wired devices should use an assigned address. IPv4-style 4-octet addresses are fine. But the arrangement needs to be a bit more logical. They need to be arranged in a hierarchy. From 0.0.0.2 to 255.255.255.255, every address should be valid. 0.0.0.0 should be reserved as a null address (duh) and 0.0.0.1 should be the localhost address (or "self" or "this" or "me"). Any other address can be a node. Any node can serve as a gateway to a COMPLETE subnet.
So if I want to reach grandma's wired VoIP phone, her number is "233.67.94.199::0.0.0.2". A phone keypad wouldn't have to be changed, as you could use * for . and # for
And there would, with only a two-level hierarchy, be more addresses than IPv6 offers(*). With more levels in that hierarchy, there would be no such thing as an address shortage. And to top it all off, I'm guessing the top-level routing equipment wouldn't have to be substantially changed. It's still just routing from one IPv4 address to another. The gateways would all have to change, though.
Notice another thing about this IPv4^n idea: Hierarchical NAT bypass. Notice how it resembles a C++ (and copycats) scope-resolution operator and how it resolves the scope of the actual device address and how it could easily be extended to multiple levels beyond what I've suggested.
(*)If you don't believe me, do the math:
IPv6:
2^128 = 3.402823669e38
IPv4^2 (IPv4-sqared)
32^32 = 1.461501637e48
IPv4^3 (x.x.x.x
32^32^32 = 1.461501637e1536
With those IPv4^n address spaces, you have to remember that you don't get quite that many addresses, as you lose 0.0.0.0 and 0.0.0.1 from each range and subrange. In IPv4^2, you lose 8-billion-something addresses - 2 main-range addresses plus 2 addresses from each of the 4-billion-something-minus-two subranges. That's a trivial loss in the scope of this scheme, and yet is almost twice as many addresses as we have available right now.
Re:What the hell? (Score:3, Insightful)
Re:Ugh (Score:2)
I beg to differ: NAT can do it, and well too (Score:3, Insightful)
Most surfers are considerably safer behind NAT anyway, as shielding incoming TCP connections on ports 135-139, 445 and 593 kills 9 out of 10 Windows remote exploits stone cold dead. Deploying technologies like uPNP in the ISP routers can negate the inability to accept incoming packets nmany
Re:I beg to differ: NAT can do it, and well too (Score:5, Informative)
Intelligent use of NAT can get a lot of users into one IP. 9 out of ten surfers only need outgoing-initialed connections (web surfing, email, instant messaging, IP-based broadcasting and legal music download software).
But if you want to do video conferencing or VOIP then you're screwed unless you go via proxy servers and give up speed and security.
In an ideal world yes, every device could be addressed by its own IP address, but in this world I don't want some cracker port-scanning my fridge and getting a backdoor through a butter overflow exploit.
It doesn't matter whether you use NAT or IPV6 . There's no reason why your fridge ith an IPV6 address should not sit behind your home firewall. At least, when you need to be able to open certain ports (at which point you're vunerable to buffer overflows regardless of the protovcol), you'll be able to do so using router rules rather than port mapping (which can only go so far). In both situations you'll have to buy an additional device -- an IPV6 router/firewall or a NAT based IPV4 router/firewall. There is no reason why an IPV6 router/firewall needs to be configured by default to permit all incoming connections.
Re:I beg to differ: NAT can do it, and well too (Score:2)
Actually there are hacks now available which can establish a direct UDP connection between two NATed clients without even using port forwarding. Basically you use a third party to exchange port numbers, and then you both send the initial transaction at the same time. You can even do it with TCP if you exchange some additional information.
Sounds interesting. I can't find any information on this
Re:I beg to differ: NAT can do it, and well too (Score:2)
Re:I beg to differ: NAT can do it, and well too (Score:2)
Re:I beg to differ: NAT can do it, and well too (Score:3, Insightful)
The solution to that is to disable the services running on those ports. It will have the same effect. uPNP shouldn't be necessary.
Why does your fridge have open ports unless you want to use them? If
Re:ATTENTION SLASHDOT READERS (Score:5, Funny)
Mothers and housewives?
Re:ATTENTION SLASHDOT READERS (Score:2, Interesting)
Re:Not ready for Prime Time (Score:4, Interesting)
IPv6 has such a large address pool to allow autoconfiguration of addresses for now and in the future. It basically redifines the whole issue of keeping up with who has which IPs. Just keep up with their network number and autoconfig the rest.
While the addresses may be 4 times the size and the header is twice the size, the header itself can be processed and delivered faster.
Re:Not ready for Prime Time (Score:2)
Re:Not ready for Prime Time (Score:5, Insightful)
1) You're thinking older Cisco equipment. But, the same argument could be made for any number of enterprise/carrier routing vendors. If you have a router/multilayer switch designed for IPv4, you're going to have to either upgrade it with IPv6 ASICs, or replace it completely. That's part of the price of transisition, and there's no way around that.
2) No one with any level of education in the matter says "We're running out of addresses." We're running out of address SPACE. Big difference. The huge class A and B networks issued to large US corporations and the military means those countries who got online later on are losing out. Case in point...I was on the redesign team at a USAF base that had two class B networks -- for 30,000 customers.
And NAT is only a stopgap. You end up with a massive number of interoperability problems when you start NATing. With IPv6, there simply isn't the need for it, and you remove those problems.
3) Memory and CPU performance hasn't been a major issue with most routers in a long time, especially BGP routers. Massive OSPF networks, yeah, the Dykstra algorithm hits hard, but there are other, less CPU-intensive options like IS-IS, or just design your network right from the ground up and summarize properly.
Again, the problem we're going to run into here is the specialized memory used for wire-speed packet switching. But, if you're doing wire-speed, you're going to have to replace the ASICs anyway, so the TCAM gets replaced too.
4) You're right, minimum MTU size in IPv4 networks is 576 bytes. But that's a difference of 3.5% versus 7%. Not a major issue -- especially since most MTUs are in the range of 1250-1500, or even higher in pure GigE networks.
The road to IPv6 will be bumpy, but the only issue you mentioned with any real weight is the first, and that's an easy one. You just throw money at it.
Where the problem is going to lie is in long-haul data transport, IPv4 interoperability, and legacy application support. The network's the easy part.
Re:Not ready for Prime Time (Score:3, Informative)
Re:Not ready for Prime Time (Score:4, Interesting)
Wrong. Recent IOS releases still have the same problems, they are also quite catastrophic from a usability point of view in comparison with the IPv4 features.
3) Memory and CPU performance hasn't been a major issue with most routers in a long time, especially BGP routers.
This is always an issue, as memory costs money. The global routing table has just passed the RAM barrier a few months ago for many routers; most Cisco routers holding that table now require 512MB minimum route memory. (of course it also depends on what else the router has running, but as a general rule, the mark was hit.)
Either way, IPv6 means more memory and resource requirements, which in turn means a lot of investment with no return. That's why IPv6 will only come when it has become absolutely necessary. Which will take a few years still. So no, it is not "ready for prime time".
Re:Not ready for Prime Time (Score:3, Interesting)
Thing is it'll never be absolutely necessary here in the US, at least not for a long time to come. Enough kludges have been developed for NAT that it's "good enough" for the time being, espeically to IT managers facing the hard choice between sticking with NAT or dumping a metric ass-ton (r
Re:Not ready for Prime Time (Score:2, Funny)
Re:Not ready for Prime Time (Score:2)
While the addresses itself gets longer, the routing tables will become easier. Because it can be consistent routing, i.e all that has 3ffe: goes in that direction, d4ae:f9821: goes in that
Re:Not ready for Prime Time (Score:2)
Re:Not ready for Prime Time (Score:2)
Re:Not ready for Prime Time (Score:2)
Re:Not ready for Prime Time (Score:2, Interesting)
Still, someone typing fast, who knows what he wants to say and has the foresight to spot something he wants to comment on in the mysterious future might pull this off.
Re:Not ready for Prime Time (Score:5, Insightful)
I see a lot of reasons to go IPv6, especially now China (1.3 billion people) and India (1 billion people) get connected.
Re:Not ready for Prime Time (Score:3, Interesting)
Re:Not ready for Prime Time (Score:2)
In the early days there even where theorists that proclaimed that "addresses are not routes" all the time.
I don't think it is going to work in IPv6...
Re:Not ready for Prime Time (Score:2)