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

Reply via email to