Re: NAT64 and matching identities

["Fred Baker (fred)" <fred () cisco com>]

On Nov 19, 2013, at 8:36 AM, Andrew Sullivan <asullivan () 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.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail