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

[Роман Донченко <DXDragon at yandex.ru>]

Hello,

Seiichi Kawamura <kawamucho at mesh.ad.jp> писал(а) в своём письме Thu, 09
Jul 2009 08:32:39 +0400:

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

Teredo? I'm presuming you meant ISATAP.

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

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.