IPv6 Netowrk Device Numbering BP

Sat Nov 3 16:48:24 UTC 2012

On Nov 3, 2012, at 04:19 , Tore Anderson <tore.anderson at redpill-linpro.com> wrote:

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

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

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

What do you get from SIIT that you don't get from dual stack in a
datacenter?

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

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