Brian,
Yes, we have in some cases to test whether the address is "global in
scope" or not; such tests are mandated for example in the behavior of
Shipworm routers. This points us to section 2.4 of the addressing spec,
which reads:
The type of an IPv6 address is identified by the high-order bits of
the address, as follows:
Address type Binary prefix IPv6 notation Section
------------ ------------- ------------- -------
Unspecified 00...0 (128 bits) ::/128 2.5.2
Loopback 00...1 (128 bits) ::1/128 2.5.3
Multicast 11111111 FF00::/8 2.7
Link-local unicast 1111111010 FE80::/10 2.5.6
Site-local unicast 1111111011 FEC0::/10 2.5.6
Global unicast (everything else)
So, when I implement the test, I am going to check whether the address
matches ::/127, FF00::/8, or FF80/9, and if yes recognize a non local
scope. What I should specifically not do is check whether the address
matches 2000::/3, and if not recognize a non local scope! In short,
looking for an inexistent format prefix would drive a programming error.
-- Christian Huitema
> -----Original Message-----
> From: Brian E Carpenter [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 07, 2001 11:49 AM
> To: Erik Nordmark
> Cc: Bob Hinden; [EMAIL PROTECTED]
> Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture"
>
> Well, I miswrote slightly - the fact is that an implementation has to
> first check if the address is any of the non-global-unicast cases, and
> that
> involves doing a sequence of matches which involve the bits
> Formerly Known as the Format Prefix (not just 3 of them of course).
> I think the new text makes this harder to understand. It doesn't
> change
> what implementors should do.
>
> Feel free to ignore my comment if nobody else has the same reaction.
>
> Brian
>
> Erik Nordmark wrote:
> >
> > > I also think that abolishing the term "format prefix" is
> obfuscation. The
> > > fact is that the leading bits of an address *are* a format prefix
> and
> > > implementors *will* look at those bits before processing an
> address. Why
> > > obscure that fact?
> >
> > Brian,
> > It is exactly this that we want to avoid - implementors thinking
> that they
> > need to inspect the first 3 bits of the addresses.
> > There is no need to do this and we need to reduce the probability
> that
> > implementors hard-code any knowledge of any leading 3 bit
> combinations
> > since it will make it harder to use the other 15/16th of the address
> space
> > in the future.
> >
> > Erik
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page: http://playground.sun.com/ipng
> FTP archive: ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [EMAIL PROTECTED]
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
