On 8 Oct 2010, at 23:51, Dave Cridland wrote:
On Fri Oct 8 16:14:02 2010, Phillip Hallam-Baker wrote:
If the application is going to use the AA record it has to have an IPv4.1
stack. This causes it to emit IPv4 packets where the first four bytes are
sent in the IPv4 header and the remaining four bytes are sent as a header
option.
Can't one then use a DNS lookup which tells it a tunnel endpoint for an
IPv6-in-IPv4 tunnel, and provide transparent IPv6 at both ends? This could be
implemented entirely at the network edge, eliminating the need for special
stacks at the endpoints.
I think this should be possible, today, with 6to4 and NAT64/46 in combination
without any changes for the IPv4 host at all. 6to4 has the nice property that
it is instantly compatible with every other 6to4 user, without any kind
intermediate choke points (assuming that the non-tunneled IPv4 Internet remains
reasonably flat and NAT-free, of course). Sooner or later you're going to need
IPv6 on the wire, though, because your IPv4-only hosts aren't capable of
encoding more bits into their packets than they know how (address and port).
Besides that, quite a few apps do not fair well with NAT64, but I suppose if
we're dead-set on keeping it alive, then we had better get to work fixing
those. Should work for any DNS-addressible resource running over straight
TCP/UDP without any payload modifications. We just need some spare addresses
to implement our NAT state table, no DNSSec and minimal caching, and a strong
stomach.
Just FTR, I'm not advocating this direction. I really think we're worrying
about the wrong problem - it isn't really the end nodes where the IPv6 is
lacking, it's the blasted middleboxes. Having said that, I just got an Epson
Photo Stylus PX710W which is IPv4 only, unfortunately.
Cheers,
Sabahattin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf