Subject: Re: IPv6 Addr/Prefix clarification

From: Steve Deering <[email-masked]>
Date: Thu, 7 Feb 2002 16:49:59 -0800

At 11:02 AM -0500 1/23/02, Keith Moore wrote:
> > 1) Is it safe to assume that all IPv6 prefixes will be between 16 and 64 bits
> > long?
>
>no.  because nothing requires a site to use the lower 64 bits as an 
>interface ID - a site is free to subnet that space if it wishes.

Actually, there *is* something that requires a site to use the lower 64
bits as an interface ID: the IPv6 address architecture spec.  RFC-2373
says on the top of page 7:

      (2) The format prefixes 001 through 111, except for Multicast
          Addresses (1111 1111), are all required to have to have 64-bit
          interface identifiers in EUI-64 format.

That wording has been revised in the most recent version of that spec,
draft-ietf-ipngwg-addr-arch-v3-07.txt, removing the reference to
"format prefixes" and introducing the term "Modified EUI-64 format" to
distinguish the format we use in which we invert the value of one of
the bits from the real EUI-64 format, but still saying the same
thing (on the bottom of page 8):

   For all unicast addresses, except those that start with binary value
   000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format.

Note that there is an exception for addresses beginning with binary 000,
which is where we have put things like the embedded NSAP addresses and
several of the many forms of IPv6 addresses with embedded IPv4 addresses,
which obviously don't have 64-bit interface IDs.

So, in answer to Irina's question "Is it safe to assume that all IPv6
prefixes will be between 16 and 64 bits long?" the answer is no:
prefixes starting with 000 may well be longer than 64 bits.  (Prefixes
may also be shorter than 16 bits, since we have also removed the TLA,
NLA notions from the updated address architecture, those properly being
in the realm of address assignment policy, not architecture.)

If Keith and kre want to ignore the requirement for 64-bit interface
IDs, and can find implementations that will satisfy that desire, fine.
But if they choose to use prefixes longer than /70, they'll have the
additional operational headache of ensuring that the "u" bit which
indicates whether or not the interface ID is globally unique is correctly
set to zero, even though that bit now falls within the subnet (or
higher-level) field of the address.  Doesn't seem worth the hassle,
and the need for longer prefixes for address conservation is not
persuasive, to me.

When I get asked about what assumptions can be made about unicast prefix
lengths (e.g., by people designing route look-up implementations), I
tell them that they should be prepared to handle any prefix length,
but that it will probably be OK if prefixes between 65 and 127, inclusive,
are handled in a slower path (i.e., if you can't build the fully-general
mechanism at an acceptable cost, you probably won't get burned if you
optimize for prefixes between 0 and 64, plus 128 (for "host routes")).

Steve

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Mon, 11 Feb 2002 11:21:54 +0700

Date:        Thu, 7 Feb 2002 16:49:59 -0800
    From:        Steve Deering <[email-masked]>
    Message-ID:  <v04220801b888c8d632ef@[10.34.255.54]>

  | Actually, there *is* something that requires a site to use the lower 64
  | bits as an interface ID: the IPv6 address architecture spec.  RFC-2373
  | says on the top of page 7:

That is a mistake.  Requiring this for the addresses that we're currently
allocating is a mistake of its own, pretending that we know how addresses
are to be allocated forever into the future is just plain insane.

Just look backwards a little - when IPv6 was first designed (even the
first versions with 128 bit addresses - the SIPP stuff), the interface
identifier was a 48 bit MAC address (or at least that's what we were
assuming that would be enough for everything).

Then we found out that the rest of the world had moved on, and this new
thing called the EUI-64 was to be the new standard for future network
technologies.   So we changed.

We have to retain the flexibility to change again, when the rest of the
world invents some other new format of link level identification.  It
makes no sense to pretend that we own that specification, and that we
are not going to allow anything other than an EUI-64 (or something that
can be converted into one) to ever be used.

What's more, there's nothing at all in IPv6 as we know it now that depends
upon this - apart from auto-configuration of addresses, which is a very
much link dependent activity (relies upon the link supporting multicast
so addresses can be verified, lookups can be done, ...).  Some potential
new medium won't necessarily support this (and point to point links certainly
don't need anything nearly so complex).

Of course, it does no real harm to have statements like this in the spec
(and having such things makes it easier to deal with organisations which
would prefer to be more miserly than we would like in the allocation of
numbers) - provided that no-one starts building code that actually depends
upon this never being changed into the future.

We can easily change the spec as soon as it becomes apparent that a change
is needed - provided that no-one has relied upon it too heavily.   That's
what I am requesting - that implementors simply ignore all these pretend to
be boundaries, except where they are actually important for something.

  | If Keith and kre want to ignore the requirement for 64-bit interface
  | IDs, and can find implementations that will satisfy that desire, fine.
  | But if they choose to use prefixes longer than /70, they'll have the
  | additional operational headache of ensuring that the "u" bit which

Huh?   Thanks all the same, but unless that 'u' bit ever actually gets a
use that matters, I don't think I'll care too much.   Nothing (certainly
not anything outside my local network) has any business at all caring in
the slightest what the internal format of my "interface identifiers" is.

Sure - when I'm doing something like allocating some static addresses (or
some randomly assigned ones) and mixing those with ones that are 
auto-configured that bit helps avoid unnecessary collisions, so it is
useful to have.    Beyond that it is a waste of space (that is, if it
wasn't already in the EUI-64 format, we wouldn't be inventing it for IPv6).

  | indicates whether or not the interface ID is globally unique is correctly

Since absolutely nothing cares if the interface ID is globally unique
or not, this cannot really matter.   What's more, since we allow addresses
with 'u' == 0, nothing can really ever demand that we have globally unique
addresses.  That is, it simply isn't possible to retro-fit 8+8 onto IPv6
as we have it now, there are already too many non-unique "interface IDs"
for there to be any chance of that at all.

  | When I get asked about what assumptions can be made about unicast prefix
  | lengths (e.g., by people designing route look-up implementations), I
  | tell them that they should be prepared to handle any prefix length,
  | but that it will probably be OK if prefixes between 65 and 127, inclusive,
  | are handled in a slower path (i.e., if you can't build the fully-general
  | mechanism at an acceptable cost, you probably won't get burned if you
  | optimize for prefixes between 0 and 64, plus 128 (for "host routes")).

I have no particular problem with that - though I'd expect that where people
will optimise will also be determined by their target market.   For some, host
routes (/128) won't be worth optimising either.  For some, perhaps only prefixes
up to /48 will need to be handled really quickly.   For others, everything
between 0 and /128 is likely to be equally important.   All this just results
in situating different implementations into different market niches.

kre

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 Jan 2002 11:02:40 -0500

---

From: [email-masked] (Irina Dayal)
Date: Wed, 23 Jan 2002 09:33:08 -0500

I am new here so please excuse the trivial questions. I did trawl the archives but could not find a definitive answer.

1) Is it safe to assume that all IPv6 prefixes will be between 16 and 64 bits long?  The current allocation of IPv6 prefixes seems to require Aggregatable Global Unicast Addresses, which restricts the prefixes to this range.

2) Is it possible for two hosts with the same interface ID (lower 64 bits) to have different prefixes (upper 64 bits) in their addresses?  The v6 standards indicate that the interface ID does not always have global scope, so the answer appears to be yes. 

Thank you for reading...

Irina
-- 

__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

---

From: Francis Dupont <[email-masked]>
Date: Wed, 23 Jan 2002 16:58:07 +0100

In your previous mail you wrote:

   1) Is it safe to assume that all IPv6 prefixes will be between 16
  and 64 bits long?  The current allocation of IPv6 prefixes seems to
  require Aggregatable Global Unicast Addresses, which restricts the
  prefixes to this range.
   
=> if this seems to be safe today you may *not* assume this will
remain safe in the future, conclusion: this is not safe.

   2) Is it possible for two hosts with the same interface ID (lower
  64 bits) to have different prefixes (upper 64 bits) in their
  addresses?  The v6 standards indicate that the interface ID does not
  always have global scope, so the answer appears to be yes.
   
=> yes, I know at least 10 boxes with the 1 interface ID and near
the same number with 2. But I believe there are hundreds or thousands...
(BTW only a small fraction of them are hosts (i.e. not routers))

Regards

[email-masked]