About RIPE | Contact  | Search | Sitemap    
Homepage RIPE  
RIPE Community Mail Archives
search  
     
RIPE Navigation Ends
About RIPE Maillists
Maillists Archive
Global Lists
Non Active Lists
RIPE NCC Navigation Ends
Next Section
<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

Re: Modifications to the inet6num in the RIPE Database

  • To: "Wilfried Woeber, UniVie/ACOnet" < >
  • From: Guy Davies < >
  • Date: Tue, 16 Mar 1999 14:25:54 +0000
  • Cc:
  • Organization: UUNET

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@localhost
>   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@localhost  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





  • Post To The List:
<<< Chronological >>> Author    Subject <<< Threads >>>
 

Next Section
     About RIPE | Site Map | LIR Portal | About the RIPE NCC | Contact | © RIPE Community. All rights reserved.
RIPE.NET Homepage LIR Portal RIPE Community