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