[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

IPv6 Netowrk Device Numbering BP

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::" 
>>> is an example of a valid IPv6 address that maps to
>>> 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 on the far side of the SIIT gateway
>>> to your IPv6 server, it's much easier to open for 
>>> "64:ff9b::", 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

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