Re: Modifications to the inet6num in the RIPE Database
Hi David, Joao, et.al. <disclaimer> My question is going to prove complete ignorance when it comes to IPv6 address formats. So please bear with me :-) </disclaimer> => The two suggested changes are: => => - - addition of a "status" attribute with the following possible values: => TLA, NLA and SLA. => Syntax checks will be done so that: => TLA is only allowed if the prefix length is 3<x<=16 => NLA is only allowed if the prefix length is 16<x<=48 => SLA is only allowed if the prefix length is 48<x<=64 = =This is fine although, I am not entirely convinced that we really need =it. It's a bit redundant information. By definition something is a =TLA/NLA/SLA so you can just look at the 'inet6num:' field and you =already know what it is. Can't you just generate this field =automatically ?!? For the IPv4 case we do have a well-established format for external representation of addresses and prefixes, i.e. full dotted quad with /prefix-length. In the 6bone registry there's IPv6 prefixes with a "structured" external representation, like "3FFE::/16" or "5FBC:1000::/32". So my questioon is: is there an agreed algorithm to insert punctuation at the "appropriate" positions, and does the proposal/criticism for the semantic checks do have an influence on this formatting? Thanks, Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber@CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 --------------------------------------------------------------------------
Hi Wilfried, I am not yet too comfortable with writing IPv6 addresses myself. There is a standard which also has a couple of notes on how to avoid confusion that can arise from the :: thingy meaning all zeros up to the next part. However, I always have trouble with this and have to look it up so I will not try to explain it here (I am currently not at the office, so no book). We have adapted the syntax checks to take into account the different way of writing IPv6 addresses since the inet6num was introduced. May be Engin can elaborate on the cases, particularly when there can be ambiguity. None of the introduced changes constrain the standard but rather adapt to it. Regards, Joao "Wilfried Woeber, UniVie/ACOnet" <woeber@cc.univie.ac.at> writes: * Hi David, Joao, et.al. * * <disclaimer> * * My question is going to prove complete ignorance when it * comes to IPv6 address formats. So please bear with me :-) * * </disclaimer> * * => The two suggested changes are: * => * => - - addition of a "status" attribute with the following possible values: * => TLA, NLA and SLA. * => Syntax checks will be done so that: * => TLA is only allowed if the prefix length is 3<x<=16 * => NLA is only allowed if the prefix length is 16<x<=48 * => SLA is only allowed if the prefix length is 48<x<=64 * = * =This is fine although, I am not entirely convinced that we really need * =it. It's a bit redundant information. By definition something is a * =TLA/NLA/SLA so you can just look at the 'inet6num:' field and you * =already know what it is. Can't you just generate this field * =automatically ?!? * * For the IPv4 case we do have a well-established format for external * representation of addresses and prefixes, i.e. full dotted quad with * /prefix-length. * * In the 6bone registry there's IPv6 prefixes with a "structured" external * representation, like "3FFE::/16" or "5FBC:1000::/32". * * So my questioon is: is there an agreed algorithm to insert punctuation * at the "appropriate" positions, and does the proposal/criticism for the * semantic checks do have an influence on this formatting? * * Thanks, * Wilfried. * -------------------------------------------------------------------------- * Wilfried Woeber : e-mail: Woeber@CC.UniVie.ac.at * Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 * Vienna University : Fax: +43 1 4277 - 9 140 * Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 * A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 * -------------------------------------------------------------------------- *
Hi, The algorithm we use translates "5:0:0:78:0:0:0:0" into "5:0:0:78::" but not "5::78:0:0:0:0". Of course, both are legal, but we choose to double-colonize the last group of zeros, and all prefixes are normalized according to this and then put into the registry. But I don't know what 6bone registry does. The semantic checks do not have an influence on the formatting, nor the proposals about it. They can be implemented without touching the formatting. Best regards, Engin Gunduz RIPE NCC Joao Luis Silva Damas wrote:
Hi Wilfried, I am not yet too comfortable with writing IPv6 addresses myself. There is a standard which also has a couple of notes on how to avoid confusion that can arise from the :: thingy meaning all zeros up to the next part. However, I always have trouble with this and have to look it up so I will not try to explain it here (I am currently not at the office, so no book). We have adapted the syntax checks to take into account the different way of writing IPv6 addresses since the inet6num was introduced. May be Engin can elaborate on the cases, particularly when there can be ambiguity. None of the introduced changes constrain the standard but rather adapt to it.
Regards, Joao
"Wilfried Woeber, UniVie/ACOnet" <woeber@cc.univie.ac.at> writes: * Hi David, Joao, et.al. * * <disclaimer> * * My question is going to prove complete ignorance when it * comes to IPv6 address formats. So please bear with me :-) * * </disclaimer> * * => The two suggested changes are: * => * => - - addition of a "status" attribute with the following possible values: * => TLA, NLA and SLA. * => Syntax checks will be done so that: * => TLA is only allowed if the prefix length is 3<x<=16 * => NLA is only allowed if the prefix length is 16<x<=48 * => SLA is only allowed if the prefix length is 48<x<=64 * = * =This is fine although, I am not entirely convinced that we really need * =it. It's a bit redundant information. By definition something is a * =TLA/NLA/SLA so you can just look at the 'inet6num:' field and you * =already know what it is. Can't you just generate this field * =automatically ?!? * * For the IPv4 case we do have a well-established format for external * representation of addresses and prefixes, i.e. full dotted quad with * /prefix-length. * * In the 6bone registry there's IPv6 prefixes with a "structured" external * representation, like "3FFE::/16" or "5FBC:1000::/32". * * So my questioon is: is there an agreed algorithm to insert punctuation * at the "appropriate" positions, and does the proposal/criticism for the * semantic checks do have an influence on this formatting? * * Thanks, * Wilfried. * -------------------------------------------------------------------------- * Wilfried Woeber : e-mail: Woeber@CC.UniVie.ac.at * Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 * Vienna University : Fax: +43 1 4277 - 9 140 * Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 * A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 * -------------------------------------------------------------------------- *
Hi Wilfried, The syntax of IPv6 addresses confused the hell out of me for ages. It works like this. The address is written as 8 blocks of two bytes represented as 4 hex digits (with me so far?) Each block is separated by a single colon. Now for the special cases... Any leading zeroes in a single block of 4 hex digits can be omitted (hence, <blah>:00fe:<blah> would be reduced to just <blah>:fe:<blah>. Taken to the extreme case in a single block of four digits, if all four hex digits are zero, then it reduces to simply <blah>::<blah>. Take that one step further, if some sequential blocks of 4 hex digits are all zeroes, you can reduce _all_ those blocks to '::' so <blah>:0000:0000:<blah> also reduces to <blah>::<blah> Finally, you can only have one of these constructs per address. This is common sense really since, if you have 3ffe::aaaa::bbbb, you cannot tell how many zeroes are replaced with the first pair of colons and how many by the second. There is no convention (AFAIK) for which block would be written out in full. Personally, since I am lazy, I choose to write out the fewer number of zeroes (remembering that I only need one zero per block of 4 hex digits). So, some examples of IPv6 addresses are... 3ffe:1100:0:c00::/52 = Note the :0: because there is a :: later in the address 3ffe:1100:0:c04::1/64 3ffe:1100:0:c1c:60:3e59:4d90:8/64 Hope this helps. Regards, Guy "Wilfried Woeber, UniVie/ACOnet" wrote:
Hi David, Joao, et.al.
<disclaimer>
My question is going to prove complete ignorance when it comes to IPv6 address formats. So please bear with me :-)
</disclaimer>
=> The two suggested changes are: => => - - addition of a "status" attribute with the following possible values: => TLA, NLA and SLA. => Syntax checks will be done so that: => TLA is only allowed if the prefix length is 3<x<=16 => NLA is only allowed if the prefix length is 16<x<=48 => SLA is only allowed if the prefix length is 48<x<=64 = =This is fine although, I am not entirely convinced that we really need =it. It's a bit redundant information. By definition something is a =TLA/NLA/SLA so you can just look at the 'inet6num:' field and you =already know what it is. Can't you just generate this field =automatically ?!?
For the IPv4 case we do have a well-established format for external representation of addresses and prefixes, i.e. full dotted quad with /prefix-length.
In the 6bone registry there's IPv6 prefixes with a "structured" external representation, like "3FFE::/16" or "5FBC:1000::/32".
So my questioon is: is there an agreed algorithm to insert punctuation at the "appropriate" positions, and does the proposal/criticism for the semantic checks do have an influence on this formatting?
Thanks, Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber@CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 --------------------------------------------------------------------------
-- Guy Davies UUNET, An MCI WorldCom Company European Network Specialist 332 Science Park, Cambridge, CB4 4BZ, UK e: Guy.Davies@uk.uu.net t: +44 (1223) 250457 f: +44 (1223) 250412 PGP Key fingerprint = 8C 16 26 7A 86 90 E7 FB 23 8F E2 85 F1 81 F7 F8
participants (4)
-
Engin Gunduz -
Guy Davies -
Joao Luis Silva Damas -
Wilfried Woeber, UniVie/ACOnet