This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
Modifications to the inet6num in the RIPE Database
- Previous message (by thread): Modifications to the inet6num in the RIPE Database
- Next message (by thread): Modifications to the inet6num in the RIPE Database
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Guy Davies
Guy.Davies at uk.uu.net
Tue Mar 16 15:25:54 CET 1999
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 at 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 at 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
- Previous message (by thread): Modifications to the inet6num in the RIPE Database
- Next message (by thread): Modifications to the inet6num in the RIPE Database
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]