nanog mailing list archives
Re: IPv6 Netowrk Device Numbering BP
From: Owen DeLong <owen () delong com>
Date: Fri, 2 Nov 2012 19:30:06 -0700
On Nov 2, 2012, at 02:52 , Tore Anderson <tore.anderson () redpill-linpro com> wrote:
* Owen DeLongYes, it was pointed out to me that for some silly reason passing understanding, that syntax is supported. It's absurd, but supported. Sigh Probably we should deprecate it as it really doesn't make sense to use it that way.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. 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.
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
Current thread:
- Re: IPv6 Netowrk Device Numbering BP, (continued)
- Re: IPv6 Netowrk Device Numbering BP Sander Steffann (Nov 01)
- Re: IPv6 Netowrk Device Numbering BP Joe Abley (Nov 01)
- Re: mail-abuse.org down? Alexander Maassen (Nov 04)
- Re: mail-abuse.org down? Suresh Ramasubramanian (Nov 04)
- Re: mail-abuse.org down? Tom Paseka (Nov 04)
- Re: IPv6 Netowrk Device Numbering BP Chip Marshall (Nov 01)
- Re: IPv6 Netowrk Device Numbering BP Owen DeLong (Nov 01)
- Re: IPv6 Netowrk Device Numbering BP Karl Auer (Nov 01)
- Re: IPv6 Netowrk Device Numbering BP Owen DeLong (Nov 01)
- Re: IPv6 Netowrk Device Numbering BP Tore Anderson (Nov 02)
- Re: IPv6 Netowrk Device Numbering BP Owen DeLong (Nov 02)
- Re: IPv6 Netowrk Device Numbering BP Tore Anderson (Nov 03)
- Re: IPv6 Netowrk Device Numbering BP Owen DeLong (Nov 03)
- Re: IPv6 Netowrk Device Numbering BP Tore Anderson (Nov 04)
- Re: IPv6 Netowrk Device Numbering BP Owen DeLong (Nov 04)
- Re: IPv6 Netowrk Device Numbering BP Tore Anderson (Nov 04)
- Re: IPv6 Netowrk Device Numbering BP Owen DeLong (Nov 04)
- Re: IPv6 Netowrk Device Numbering BP Tore Anderson (Nov 04)
- Re: IPv6 Netowrk Device Numbering BP Valdis . Kletnieks (Nov 01)