Tony Thigpen said:
>Maybe the IPv6 thing is really a non-issue? Our mainframes
are behind
>routers that can do the IPv6 conversion.
So what if our machine only has
>a short address,
with the router doing the conversion, the other end
>thinks we are IPv6 without out us really being IPv6.
>Or, do I misunderstand the whole thing?
No, it's really a big deal.
There are two major issues:
First, the NAT-PM (both address and port semantics translation) approach you mention breaks two of the fundamental pieces of IPv6 (in IPv6, TLS encryption and endpoint authentication support are required features), so you really can't rely on it being acceptable long-term. If we immediately start finding ways of circumventing these important features, we lose a major advantage of IPv6 right out of the box. NAT-PM is explicitly a temporary transition strategy and is deprecated for long-term use.
The other issue is in the semantics for connections between server and client applications with differing IP versions -- how does a IPv4-only client specify a connection to a IPv6-only server? Where does the IPv4-only client put the remaining 96 bits of a IPv6 address? Going the other way, the IPv6 FF80: local IPv4 provider prefix is only valid for IPv4 addresses on the same local subnet, so how does the IPv6 client specify a remote IPv4 address, possibly in a different provider prefix space?
The answer is that "it can't" -- without either the application becoming IPv6-aware, or inserting a IPv4-to-IPv6 application-level proxy between the two and modifying the application -- and the application protocol -- to support the proxy... for every possible application that needs to support connections to both host types. This isn't supportable -- the applications have to acquire IPv6 awareness to survive and be interoperable.
Also, are you sure the router is doing IPv6-to-IPv4 NAT? -- NAT in IPv6 isn't just fixing up the addresses like NAT in IPv4, but there's a whole lot of other stuff going on in IPv6 that is impossible to adduce from just the IPv4 stream (cf encryption and endpoint auth support discussed above, among other goodies). Most IPv6-aware routers are operating two separate stacks in the same box, and you're seeing the benefit of multiprotocol routing on the same interfaces. A lot of the mainstream commodity routers also implement tunneled IPv6 over a IPv4 TCP connection to something like the 6bone (essentially treating the IPv4 TCP connection as a virtual link, and the IPv6 packets as data payload).
With the push from the US and other national governments to implement IPv6 by December 2008, and the dramatic increase in the number of IP-aware devices (like VoIP cell phones, net-aware iPods, etc), IPv6 will be a production reality in the global Internet by December 2008 -- if not long before then. It already is a fact of life in China and Europe, and is already present natively in z/OS, AIX, and Linux. We can't avoid it in VM if we want to stay in the game -- it is a required prerequisite for US government IT purchases *now*.
Right now, the VM TCPIP stack can receive and process IPv6 packets, but none of the applications supplied with the stack (client or server) can make use of the IPv6 support in the stack. If government agencies -- or companies that do business with government agencies or have to supply data to such agencies over the network -- can't acquire or use VM because it doesn't comply with the native-IPv6 mandate....game over.
-- db
