Slashdot Mirror
Federal Agencies Must Use IPv6 by 2008
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."
What other industry is so stupid as to work for free?
Mothers and housewives?
Obviously you only read trade mags and know nothing about networking:
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.
Page 46, CCNP Self-Study, Paquet Teare
Mac OSX has had great IPv6 for a while (10.2)
http://evanjones.ca/macosx-ipv6.html
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.
..Just declare it part of the metric system. Or is that the other way round?
Don't trust anyone under thirty.
IPv6, to me, was a bit of a disappointment because it lacks two features that I find important:
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.
NAT will not allow you to do easy VOIP or video-conferencing.
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.