At least VM is better off than VSE. We don't even have a low-level IPv6
access routine to the hardware yet. So, neither stack product can even
start coding IPv6 support. :-(
Tony Thigpen
-----Original Message -----
From: David Boyes
Sent: 03/29/2006 10:15 PM
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
