[157684] in North American Network Operators' Group
Re: IPv6 Netowrk Device Numbering BP
daemon@ATHENA.MIT.EDU (Owen DeLong)
Fri Nov 2 22:31:26 2012
From: Owen DeLong <owen@delong.com>
In-Reply-To: <509397D6.7020009@redpill-linpro.com>
Date: Fri, 2 Nov 2012 19:30:06 -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 2, 2012, at 02:52 , Tore Anderson =
<tore.anderson@redpill-linpro.com> wrote:
> * Owen DeLong
>=20
>> Yes, it was pointed out to me that for some silly reason passing
>> understanding, that syntax is supported. It's absurd, but supported.
>> Sigh
>>=20
>> Probably we should deprecate it as it really doesn't make sense to=20
>> use it that way.
>=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" 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...
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?
2. As a destination specifier (in which case the system most likely =
got the address
as a binary return from DNS64 and doesn't present it 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.
Sure, there's the third possibility that an end-user is hand-typing 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?
> 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 "64:ff9b::192.0.2.33", and it =
will
> also make your ACL much more readable to the next guy that comes along
> than if you had used "64:ff9b::c000:221".
SIIT is a really bad idea. Codifying it into a firewall only makes =
things worse.
>=20
> Also see RFC 6052 section 2.4.
RFC's contain all kinds of embodiments and documentation of bad ideas =
that
should have been deprecated long ago.
Use of this notation for parsing rather than as an output-only format is =
just
another example.
Yes, once upon a time, lumping lots of V4-ness into IPv6 to try and =
create
some impression of backwards compatibility seemed like a good idea.
A couple of decades of experimentation and operational experience has
now taught us that it doesn't work out as well as one might have hoped.
Time to move on.
Owen
