Subject: Re: [Fwd: I-D Action:draft-kawamura-ipv6-text-representation-03.txt]

From: Роман Донченко <[email-masked]>
Date: Tue, 30 Jun 2009 19:48:44 +0400

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.

---

From: Aleksi Suhonen <[email-masked]>
Date: Mon, 06 Jul 2009 06:55:43 +0300

I agree with everything Роман Донченко wrote.

>> (i.e. 2001:db8:0:0:1:0:0:1), the former is usually shortened.

The wordings "can be used twice" and "is possible to use ..." are IMO 
misleading, since :: cannot be used twice.

Maybe you should use something like "when there are two or more 
alternative placings for ::"?

-- 
	Aleksi Suhonen

---

From: Seiichi Kawamura <[email-masked]>
Date: Thu, 09 Jul 2009 13:32:39 +0900

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.

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

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

> I believe is unnecessary complication. In short, I think ISATAP should be

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.

> * IPv4-compatible addresses (but not :: and ::1)

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

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Роман Донченко <[email-masked]>
Date: Fri, 17 Jul 2009 00:34:21 +0400

Hello,

Seiichi Kawamura <[email-masked]> писал(а) в своём письме Thu, 09

> Teredo was added after comments from Dave Thaler.

Teredo? I'm presuming you meant ISATAP.

> to addressess that are mentioned in RFC4291.

The problem is, the draft wants to define a canonical representation for
both humans and computers to follow, but those two have conflicting
requirements. On the one hand, computers want a simple algorithm that
depends only on the address being input, preferably an algorithm that
gives consistent output over a long period of time. On the other hand,
humans prefer representation which is most informative, and are usually
able to use external information to choose it. On the third hand, humans
and computers must interoperate (in particular, humans need to act on  
addresses that computers stringify), so one has to establish some kind of  
compromise.

A compromise may be to recommend the mixed form for currently known
addresses that end with an IPv4 address AND can be reliably distinguished
  from the rest (e.g. have a unique prefix). Then you can insert a paragraph
explaining why can't this be done for "nondeterministic" and future
addresses. That's inconsistent with existing implementations, though, and
I have a feeling that they will be reluctant to change. No easy solution,
it seems.

Roman.

---

From: Seiichi Kawamura <[email-masked]>
Date: Wed, 22 Jul 2009 18:52:51 +0900

Hi Roman

> Teredo? I'm presuming you meant ISATAP.

yes... I must have been asleep...sorry

> addresses that computers stringify), so one has to establish some kind
> of compromise.

This is a pretty nice summary of the case.
I agree.

> I have a feeling that they will be reluctant to change. No easy solution,

I have the same view as you here.
Its hard to fix past implementations, and that's not the goal here.
So it might be better if the draft took a more neutral standpoint
as you pointed out. I'll hopefully try to come up with a text
before the 6man meeting on Wednesday.

Regards,
Seiichi

Роман Донченко wrote:
> addresses that computers stringify), so one has to establish some kind
> of compromise.
>