[157696] in North American Network Operators' Group
Re: IPv6 Netowrk Device Numbering BP
daemon@ATHENA.MIT.EDU (Owen DeLong)
Sat Nov 3 12:51:32 2012
From: Owen DeLong <owen@delong.com>
In-Reply-To: <5094FDB6.2000905@redpill-linpro.com>
Date: Sat, 3 Nov 2012 09:48:24 -0700
To: Tore Anderson <tore.anderson@redpill-linpro.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Nov 3, 2012, at 04:19 , Tore Anderson =
<tore.anderson@redpill-linpro.com> wrote:
> * Owen DeLong
>=20
>> On Nov 2, 2012, at 02:52 , Tore Anderson=20
>> <tore.anderson@redpill-linpro.com> wrote:
>>=20
>>> It absolutely does make sense, especially in the case of IPv4/IPv6
>>> translation. For example, when using NAT64, "64:ff9b::192.0.2.33"=20
>>> is an example of a valid IPv6 address that maps to 192.0.2.33.
>>> Much easier to relate to for a human than "64:ff9b::c000:221" is.
>>=20
>> But there are two situations where you'd use that for NAT64...
>>=20
>> 1. Presentation of electronic information to the end user, where
>> it's virtually impossible for the system to know whether that's a
>> NAT64 address representing an IPv4 remote end or an IPv6 address, so,
>> how do you know when to represent it that way to the end user?
>>=20
>> 2. As a destination specifier (in which case the system most likely=20=
>> got the address as a binary return from DNS64 and doesn't present it=20=
>> to the end user prior to sending the request off to the remote
>> server and even if it did, again, doesn't likely have a way to know
>> when to use that notation.
>=20
> There's also the case of when including NAT64 support directly into an
> application. Not all applications use DNS, and therefore cannot use
> DNS64 either, e.g., applications that are passing around IP literals =
in
> their payload (p2p stuff like BitTorrent and Skype comes to mind).
> However, by discovering the NAT64 prefix in some other way (see
> draft-ietf-behave-nat64-discovery-heuristic), they can construct a
> usable destination specifier by simple string concatenation. It's
> wouldn't be the only way to do it, but it's certainly simple and easy =
to
> understand approach.
>=20
But if the application is doing the construction, then it's doing it =
with
binary and not with a string representation of the address. The binary
128 bits don't change. We're talking about the format of a string =
representing
those 128 bit.
>> Sure, there's the third possibility that an end-user is hand-typing=20=
>> an IPv6-encoded IPv4 address to go through a translator, but, I
>> think for a variety of reasons, that behavior should be relatively
>> strongly discouraged, no?
>=20
> That wouldn't be a end-user friendly application, no. However, for
> network operators, dealing with IP literals is common when debugging =
or
> other stuff. I frequently use the dotted quad syntax when working on =
our
> NAT64 installation, and find it very convenient.
>=20
Fair point.
>>> Similarly, when using SIIT, the same syntax may be used in firewall
>>> rules or ACLs. So if you want to open, say, the SSH port from a
>>> trusted IPv4 address 192.0.2.33 on the far side of the SIIT gateway
>>> to your IPv6 server, it's much easier to open for=20
>>> "64:ff9b::192.0.2.33", and it will also make your ACL much more=20
>>> readable to the next guy that comes along than if you had used=20
>>> "64:ff9b::c000:221".
>>=20
>> SIIT is a really bad idea.
>=20
> I disagree. In my opinion, SIIT is perfectly suited for data centres.
> But let's not take that discussion here - I'll be submitting a draft
> about the use case to the IETF in a few days, and I hope you'll read =
it
> and participate in the discussion on the v6ops or sunset4 list (not =
yet
> sure which one it'll be).
What do you get from SIIT that you don't get from dual stack in a
datacenter?
>=20
>>> Also see RFC 6052 section 2.4.
>>=20
>> RFC's contain all kinds of embodiments and documentation of bad
>> ideas that should have been deprecated long ago.
>=20
> Certainly. There is, however, a mechanism for deprecating RFCs. Either
> you can move them to Historic status, or you can obsolete them by
> writing new ones. You, or anyone else who don't like the ::0.0.0.0
> syntax, is free to do so. Until that happens, though, it will remain
> part of the standard and you cannot reject it out of hand just because
> you don't like it.
Fair point, however, I can certainly discourage its use. Frankly, lots =
of
stuff from RFCs gets rejected out of hand by various implementers all
the time.
Owen
