On Nov 3, 2012, at 04:19 , Tore Anderson <tore.ander...@redpill-linpro.com> wrote:
> * Owen DeLong > >> On Nov 2, 2012, at 02:52 , Tore Anderson >> <tore.ander...@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
