On Thu, 2006-05-25 at 10:43 -0700, Doug Barton wrote:
Marcos Sanz/Denic wrote:
P.S. Btw, if non-preferred IPv6 textual forms are accepted, will the output of e.g. whois deliver the original or the preferred form?
In my experience this is a good place to apply the principle, "Be liberal in what you accept, and conservative in what you send." It would be more convenient to users if you accepted many different forms of IPv6 address, and more convenient for consumers of the data if those addresses were canonicalized into the full form of the address as in section 2.2.1 of RFC 4291.
As RFC4291, 2.2.1 is not really a section, I assume you mean: 8<---------------------------------------------------- 2.2. Text Representation of Addresses There are three conventional forms for representing IPv6 addresses as text strings: 1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to four hexadecimal digits of the eight 16-bit pieces of the address. Examples: ABCD:EF01:2345:6789:ABCD:EF01:2345:6789 2001:DB8:0:0:8:800:200C:417A Note that it is not necessary to write the leading zeros in an individual field, but there must be at least one numeral in every field (except for the case described in 2.). ----------------------------------------------------->8 And thus when I submit "whois -h whois.ripe.net 2001:0db8:1234/64" it would return an inet6num with (the /48 exists, the /64 doesn't) : 2001:db8:1234::/48 Is that what you meant? From my point of view, what I do is *always* rewrite the addresses to the compressd form and in lowercase (caps are to screamish ;) Greets, Jeroen