Subject: Re: [netmod] ipv6 address representation

From: Seiichi Kawamura <[email-masked]>
Date: Tue, 31 Mar 2009 11:21:57 +0900

Hi

Juergen, thanks for introducing the draft to the working group
and also for the many helpful comments.

Just a quick example of how multiple representations are painful.
If there was some trouble on the network, a traceroute would
be done to detect where the packet was being dropped.
Your favorite operating system(Windows, BSD) will return an address like
2001:db8:1::10
and we operators will copy that address from the terminal
and seach for it on whatever systems that we use to managage
IP addresses, router configurations, SNMP data, etc.
Depending on the flavors of those systems, a search (or grep) might
return a no match just because it has 2001:db8:1:0:0:0:0:10.
Think if network diagrams were written on Excel(which I see
very often) and try seaching for an address there.

- From what I've experienced, the "preferred way" noted in RFC4291
sec 2.2 item 1 is rarely used. BTW, I'm a network
operator at an ISP/Data Center.

Thanks
Seiichi Kawamura
NEC BIGLOBE, Ltd.

=================================
Hi,

I just saw this document:

http://www.ietf.org/internet-drafts/draft-kawamura-ipv6-text-representation-00.txt

While this document is not perfect and the suggestion to use
inet_ntop() does not work since we know this function is not fully
defined and different implementations produce different results, I
believe the authors do have a point in spelling out that multiple
different representations are operationally not really a feature.

/js

- --
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 31 Mar 2009 08:00:20 +0200

On Tue, Mar 31, 2009 at 04:21:57AM +0200, Seiichi Kawamura wrote:

[...]
 
> sec 2.2 item 1 is rarely used. BTW, I'm a network operator at an
> ISP/Data Center.

So what is your suggestion? Note that the format produced by
inet_ntop() implementations seems to differ slightly on some
platforms:

http://www.ietf.org/mail-archive/web/netmod/current/msg02047.html

Note that the list is pretty incomplete yet and we felt is it not our
task to define how inet_ntop() should behave.

What do you plan to do with your document? Has it been discussed
somewhere at the last IETF? If your plan is to write down how an
interoperable compressed format is constructed and you plan to push
this through one of the IPv6 WGs, I guess we would be happy to pick up
the compressed format. But note that we like to wrap up our work soon
and so this would have to move relatively fast.

/js

--