Subject: Re: [netmod] ipv6 address normalization ??

From: David Partain <[email-masked]>
Date: Mon, 2 Mar 2009 15:01:58 +0100

On Thursday 05 February 2009 23.25.40 Per Hedeland wrote:
> On 2009-02-05 23:13, Juergen Schoenwaelder wrote:
> > On Thu, Feb 05, 2009 at 10:32:04PM +0100, Martin Bjorklund wrote:
> >> Juergen Schoenwaelder <[email-masked]> wrote:
> >>> On Tue, Dec 23, 2008 at 08:12:04PM +0100, Simon Leinen wrote:
> >>>> I would also add that the :: subsitution should only be applied to
> >>>> sequences of two or more all-zero chunks, i.e. you shouldn't compress
> >>>>
> >>>>   2000:0:2:3:4:5:6:7 => 2000::2:3:4:5:6:7
> >>>>
> >>>> This is a matter of taste and convention.  The existing inet_ntop()
> >>>> code that I checked doesn't compress a single zero.
> >>>
> >>> It seems the inet_ntop() code Paul Vixie wrote and which is part of
> >>> glibc (and I think also some BSD libcs) does compress a single
> >>> all-zero chunk. I would prefer to keep it this way. I am wondering
> >>> which code you checked...
> >>
> >> I tried this with glibc 2.8.90, and it did not compress a single
> >> zero.
> >
> > Hm. Wrong window. I stand corrected. The Paul Vixie code does indeed
> > not compress single all-zero chunks. The relevant line in his source
> > code is this:
> >
> >     if (best.base != -1 && best.len < 2)
> >         best.base = -1;
> >
> > But MacOS X does seem to always compress. Can someone check on Win32?
>
> Sorry, not me, but here are a few other data points:

[deleted]

So... to close this out... 

Jürgen, you haven't gotten a win32 datapoint, but do you have enough data to 
make a suggestion about what the right text should be?  

David

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 2 Mar 2009 15:29:44 +0100

On Mon, Mar 02, 2009 at 03:01:58PM +0100, David Partain wrote:
 
> J?rgen, you haven't gotten a win32 datapoint, but do you have enough
> data to make a suggestion about what the right text should be?

There have been split opinions and it is hard to read concensus. The
options:

a) Use the preferred form defined in 1. in section 2.2 or RFC 4291,
   (with supression of leading zeros), which means no compression of
   16-bit zeros. Since a Draft Standard RFC says this is the preferred
   format, there is a strong argument in place for choosing this
   option.

b) Use the popular CLI form with compressed zeros. Since existing
   inet_ntop() implementations obviously do slightly different things
   on different systems, we have to make up rules and since
   implementors can't rely on inet_ntop() always doing the right
   thing, you have to support your own function if your goal is
   portable code.

I personally meanwhile lean towards option a) since this is an easy to
defend format, it is easy to document, and it does not take more
effort to implement than option b).

Unless I hear objections, I will put this solution into the next
revision of the ID.

/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: David Partain <[email-masked]>
Date: Tue, 3 Mar 2009 10:03:28 +0100

> Unless I hear objections, I will put this solution into the next

Hi,

I think that option a makes good sense, especially given "it does not take 
more effort to implement than option b)".  I would, though, like others to 
chime in on this way forward.

Cheers,

David

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 03 Mar 2009 10:09:06 +0100

Hi David,

I support a) too, but you said "Unless I hear objections ...". :-)

Lada

David Partain píše v Út 03. 03. 2009 v 10:03 +0100:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C