[166919] in North American Network Operators' Group
Re: NAT64 and matching identities
daemon@ATHENA.MIT.EDU (Fred Baker (fred))
Tue Nov 19 17:56:45 2013
From: "Fred Baker (fred)" <fred@cisco.com>
To: Andrew Sullivan <asullivan@dyn.com>
Date: Tue, 19 Nov 2013 22:56:32 +0000
In-Reply-To: <20131119163649.GC5265@dyn.com>
Cc: "<nanog@nanog.org>" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--Apple-Mail=_FA61F465-B872-46D4-B304-3833C47283FD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
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.
>=20
> 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.
>=20
> 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. =20
>=20
> 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.
--Apple-Mail=_FA61F465-B872-46D4-B304-3833C47283FD
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iD8DBQFSi+ydbjEdbHIsm0MRAoHFAJsE7qLQDBPvXYl/7MgIP5ke6Em/+QCgy07o
IEer38zvG/5NGdwg0MYEOw4=
=PylZ
-----END PGP SIGNATURE-----
--Apple-Mail=_FA61F465-B872-46D4-B304-3833C47283FD--
