-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Roman,
Appologies for the lateness of my reply, and thanks for the many helpful comments. I'll try to incorporate the editorial fixes as much as possible. The following comments are mostly about the technical part. > The draft seems to downplay the importance of the mixed hex-decimal > representation form. It's only briefly mentioned in Section 5 as a special > encoding for certain classes of addresses. I believe this to go against Thank you. It was not my intension to downplay its importance. Let me think about this one. > I agree that IPv4-mapped addresses should canonically be represented with > the mixed notation. I also implicitly agree that IPv4-compatible (::/96) > addresses should NOT, since they're deprecated and conflict with :: and > ::1. Perhaps there should be a note in the draft about that. the earlier versions of the draft had a notation about this, but was removed because we had some comments on this list saying if its deprecated, then its not much meaningful to have in the document. I don't really have a strong feeling about this though. > The rest is more controversial. While ISATAP addresses obviously make more > sense in mixed notation, they can't be reliably identified without > additional information, since they can have arbitrary prefixes. This makes > the specification impossible to implement for a generic inet_ntop-like > routine. While you can say that addresses should be represented in mixed > notation if they are known to be ISATAP addresses (by some other means), > this makes the definition of canonicity depend on external factors, which > I believe is unnecessary complication. In short, I think ISATAP should be > removed from the list. Teredo was added after comments from Dave Thaler. IMHO, specifying what type of addresses does not have strong meaning in this context. Rather, as an informational document, it would be informative to operators what address can do mixed notation. But just as you say in a different part of your mail, we never know what comes up in the future. My feeling about this is, if there's many people that think this is out of place, we can just go back to pointing to addressess that are mentioned in RFC4291. > Afraid not; I don't have a FreeBSD handy, but inspection of the code > (http://svn.freebsd.org/viewvc/base/release/7.0.0/lib/libc/inet/inet_ntop.c?revision=176506&view=markup) > > tells me that mixed notation is used for: > > * IPv4-compatible addresses (but not :: and ::1) > * IPv4-mapped addresses thank you. we did know that embedded addresses were not comforming with inet_ntop but we forgot to mention this. I will refine this text. Regards, Seiichi > Greetings, > > I want to offer a couple of comments/suggestions for this draft. > > -------------------- > Editorial. > -------------------- > >> A Recommendation for IPv6 Address Text Representation > > Given that the focus of the draft is on defining a canonical > representation format, I think it would be useful to put the word > "canonical" in the title. With a title like, e.g. "Canonical > Representation of IPv6 Addresses", one will be able to find the RFC by > searching titles for, say, canonical+IPv6. > >> It is expected that the canonical format is followed by >> humans and systems when generating an address to represent as text, > > This wording is misleading, IMHO; the draft concerns representation, not > generation of addresses. I suggest "by humans and systems when > representing addresses in text," instead. > >> 4.2. "::" Usage >> 4.2.1. shorten as much as possible >> 4.2.2. One 16 bit 0 Field >> 4.2.3. When "::" Can Be Used Twice > > IMHO, the subdivision of 4.2 isn't justified. 4.2.1 and 4.2.2 contain only > one sentence each. Plus, it's inconsistent with Section 2.2, which it > parallels. > >> When cases where it is possible to use "::" in two or more different >> sections of an address, implementation to shorten the side with >> longer 16 bit 0 fields are more common (i.e. latter is shortened in >> 2001:0:0:1:0:0:0:1). When the length of 16 bit 0 fields are equal >> (i.e. 2001:db8:0:0:1:0:0:1), the former is usually shortened. > > 16-bit 0 fields are always 16 bits long. 8=] I'd say "to shorten the > longest 16-bit 0 field sequence" instead. > > Also, since this section is defining the canonical format, I'd reword those > sentences to tell what the implementations should do, not what they > currently do. E.g.: > > ~ > In cases where it is possible to use "::" in two or more different > sections of an address, implementations are to shorten the longest 16-bit > 0 field sequence (e.g. latter is shortened in 2001:0:0:1:0:0:0:1). When > there are several sequences of maximum length (e.g. 2001:db8:0:0:1:0:0:1), > the first SHOULD be shortened. This is consistent with existing > implementation practice. > ~ > >> 7. Conclusion >> The recommended format of text representing an IPv6 address is >> summarized as follows. > > I think this section can be replaced/augmented with some pseudocode. The > canonical representation algorithm is complicated enough. > > -------------------- > Technical. > -------------------- > >> [no quote here 8=]] > > The draft seems to downplay the importance of the mixed hex-decimal > representation form. It's only briefly mentioned in Section 5 as a special > encoding for certain classes of addresses. I believe this to go against > RFC 4291, which defines that form as an equivalent alternative which can > be used with any address (but is "more convenient when dealing with a > mixed environment of IPv4 and IPv6 nodes"). As such, I propose to remove > Section 5, distributing its contents over the rest of the draft: > > * add some examples to Section 1, e.g.: > - 2001:db8:0:0:1:0:0.0.0.1 > - 2001:DB8::1:0:0.0.0.1 > * describe the form in Section 2. Example: > > ~ > 2.4. Mixed notation. > > The last four octets are allowed to be written in the dotted decimal > notation, as if they were an IPv4 address. This can increase legibility of > addresses used by several v4-to-v6 transition mechanisms, such as > IPv4-mapped, IPv4-translated [RFC2765] and ISATAP [RFC5214] addresses. For > example, the following addresses are equivalent: > > 2001:db8:aaaa:bbbb:0:0:c000:201 > 2001:db8:aaaa:bbbb:0:0:192.0.2.1 > > The other concerns of Section 2 still apply to the hexadecimal part of the > address. Thus, the address above can also be expressed in other ways: > > 2001:0db8:aaaa:bbbb:0000:0000:192.0.2.1 > 2001:DB8:AAAA:BBBB:0:0:192.0.2.1 > 2001:db8:aaaa:bbbb::0:c000:201 > 2001:db8:aaaa:bbbb::c000:201 > ~ > > * Possibly insert examples of confusion related to mixed notation in > Section 3. An easy way I see is to replace the addresses in 3.1.2 with > 2001:db8::192.0.2.1 and 2001:db8::c000:201, which looks plausible in the > context. > > * Insert Section 4.4 defining where this form is to be used. I don't > supply example text here since I think it warrants additional discussion. > See below. > > * Summarize in Section 7. > >> IPv4-Mapped IPv6 addresses, ISATAP [RFC5214], and IPv4-translated >> addresses [RFC2765] have IPv4 addresses embedded in the low-order 32 >> bits of the address. These addresses have special representation >> that may combine hexadecimal and decimal notations. In cases where >> there is a choice of whether to express the address as fully >> hexadecimal or hexadecimal and decimal combined, decimal notations >> should be used. > > Barring that there's always a choice, there are further issues. > > I agree that IPv4-mapped addresses should canonically be represented with > the mixed notation. I also implicitly agree that IPv4-compatible (::/96) > addresses should NOT, since they're deprecated and conflict with :: and > ::1. Perhaps there should be a note in the draft about that. > > The rest is more controversial. While ISATAP addresses obviously make more > sense in mixed notation, they can't be reliably identified without > additional information, since they can have arbitrary prefixes. This makes > the specification impossible to implement for a generic inet_ntop-like > routine. While you can say that addresses should be represented in mixed > notation if they are known to be ISATAP addresses (by some other means), > this makes the definition of canonicity depend on external factors, which > I believe is unnecessary complication. In short, I think ISATAP should be > removed from the list. > > IPv4-translated addresses are fine in this regard, but I want to raise the > question of what happens in the future. RFCs are rarely updated. It's > possible that after this draft becomes an RFC new transition mechanisms > will surface, which could use mixed notation as the canonical > representation. However, this document will still mandate the fully > hexadecimal form. I don't see a clean way to resolve this, short of > creating a new IANA registry, but you can add a paragraph to the above, > like: > > ~ > Implementations MAY use the mixed notation for any future address classes > which are known to contain an IPv4 address in the last four octets. This > is to aid the users of future transition mechanisms. > ~ > >> We recommend that developers use display routines that conform to >> these rules. For example, the usage of getnameinfo() with flags >> argument NI_NUMERICHOST in FreeBSD 7.0 will give a conforming output. > > Afraid not; I don't have a FreeBSD handy, but inspection of the code > (http://svn.freebsd.org/viewvc/base/release/7.0.0/lib/libc/inet/inet_ntop.c?revision=176506&view=markup) > > tells me that mixed notation is used for: > > * IPv4-compatible addresses (but not :: and ::1) > * IPv4-mapped addresses > > Which is not what the draft recommends. > > Regards, > Roman Donchenko. > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) iD8DBQFKVXLncrhTYfxyMkIRAqvmAJ4x3ELedu04m0Q+DGXOEcPSTwVD0ACfWHKy hsrD51fsICgVNBr8Qbf+/bA= =0imH -----END PGP SIGNATURE----- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
