NAT64 and matching identities

Fred Baker (fred) fred at cisco.com
Tue Nov 19 22:56:32 UTC 2013


On Nov 19, 2013, at 8:36 AM, Andrew Sullivan <asullivan at dyn.com> wrote:

> On Mon, Nov 18, 2013 at 03:06:52PM -0500, Justin M. Streiner wrote:
>> Other IPv6 transition mechanisms appear to be no less thorny than
>> NAT64 for a variety of reasons.
> 
> Some of us who worked on the NAT64/DNS64 combination were content that
> it was a long way from the perfect solution.  The idea I at least had
> was to get something that mostly worked most of the time, and was
> simple enough that anyone could basically understand it.
> Nevertheless, I have to admit that it's a pig.
> 
> That piggishness was not something I wanted to get rid of.  I thought
> (and still think) that if the transition mechanisms are awful enough,
> it will encourage moving things to v6 for real so that we can get rid
> of the kludges.  Perhaps this is wishful thinking, however.  
> 
> In any case, I'm sorry to have contributed in some little way to this
> headache of yours.

Speaking as one of the co-authors of RFC 6052, 6144, and 6145...

I'm actually not sorry. The predecessor to RFCs 6052/6144/6145/6146/6147 was NAT-PT, which didn't work very well in part due to a nasty coupling (see RFC 4966). It's pretty straightforward to insert an IPv4 address into a specified IPv6 prefix (RFC 6052), and use that to statelessly translate between a IPv4 address and an RFC 6052 address (RFC 6145), or to statefully translate a random IPv6 address into an IPv4 space much in the way IPv4/IPv4 translation works (RFC 6146). What is hard is statefully translating from IPv4 to a generic IPv6 address - its hard to compress 128 bits of information into 32 bits. NAT-PT does it by having the DNS lookup temporarily assign an IPv4 address to the IPv6 device and inform the translator of the translation. http://tools.ietf.org/html/draft-anderson-siit-dc (which Tore didn't, to my knowledge, try to get turned into an RFC, although I'd be willing to discuss that with v6ops) does it by pre-assigning address pairs, enabling an IPv6-only domain to be accessed from an IPv4-only domain by a defined translation between the two for a small set of servers.

I'm all for helping people to transition. Where I get a little crazy is when the so-called transition tool makes them comfortable enough that they think they don't need to. What I expect to see in the IETF over the coming few years - and which I see in detail coming from several <nationality> competitors and their <nationality> network customers now - is a series of ideas of the form "but people with ancient IPv4-only hosts are having trouble with the IPv6 network; let's do this *temporary* patch to ease their pain". I submit that the best way to ease their pain is to upgrade their hosts. They will have to deal with it at some point.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20131119/b70700d3/attachment.sig>


More information about the NANOG mailing list