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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf