zero suppression vs compression in addresses

Ted Mittelstaedt tedm at
Mon May 18 19:09:04 CEST 2009


> -----Original Message-----
> From: at 
> [ at] On 
> Behalf Of Gert Doering
> Sent: Sunday, May 17, 2009 8:31 AM
> To: michael.dillon at
> Cc: ipv6-ops at
> Subject: Re: zero suppression vs compression in addresses
> Hi,
> On Sun, May 17, 2009 at 03:45:09PM +0100, michael.dillon at wrote:
> > The point is that the text representation of IPv6 addresses 
> might be 
> > about to change, so if you are writing code to read IPv6 
> text format 
> > addresses, you probably want to accept the format defined in this 
> > draft. Unless of course, there is some fundamental flaw in 
> which case 
> > you might want to communicate that to the author of the draft.
> The whole point of this draw is the *output* format of an 
> IPv6 address (and it's using fairly weak language, like 
> "should" instead of "SHOULD", at that).
> Input parsers need to understand every possible 
> representation, as long as it's syntactically correct. 

Only for automated or script-fed input, if it's a webform your
presenting to a user to input the IP address, you can always
stick with making the user enter the "long-form" of the address,

HaCi for example accepts the shortened IPv6 then expands it and
displays it as long-form when it's displaying the tree.  I can
see lots of potential for trouble if the RFC changes the logic and
people are copying and pasting addresses from configs to the HaCi input
form from a device using different parser rules to display addresses
in a shortened form.


More information about the ipv6-ops mailing list