IPv6 Netowrk Device Numbering BP

Sat Nov 3 11:19:18 UTC 2012

* Owen DeLong

> On Nov 2, 2012, at 02:52 , Tore Anderson 
> <tore.anderson at redpill-linpro.com> wrote:
> 
>> 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.
> 
> 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.

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.

> 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?

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.

>> 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.

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).

>> 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.

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.

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/