Subject: Re: -16 rev of DHCPv6 spec

From: Jim Bound <[email-masked]>
Date: Fri, 01 Dec 2000 10:16:30 -0500

Hi Bernie,

Thanks for the careful read and great input.  I am traveling alot this
week again so can't respond in details but talking with Ralph and Mike
consistently.  But do want to suggest a response to one of your points.
Can discuss further on design tele conference next week.

>- In most of the message headers, there is the 16-byte client-link-local
>address. What about dropping the first 64-bits of this (the prefix)? It
>would save 8-bytes/packet. This is just a thought - there might be good
>reasons NOT to do this. But on the other hand, it would remove the need for
>servers/relays to validate that the prefix is the link local - instead, they
>pre-append the prefix when they need to use it as a link-local address. So,
>if we were to do this, we'd call this 64-bit field "interface ID" or
>something similar (at least based on RFC 2373 terminology).
>
>>From RFC 2373, it appears that link local doesn't really consume the full
>64-bits before the interface-id, instead only the first 10 bits are really
>specified (with the next 54-bits being zero, though it is not clear that is
>REQUIRED).
>
>   |   10     |
>   |  bits    |        54 bits          |          64 bits           |
>   +----------+-------------------------+----------------------------+
>   |1111111010|           0             |       interface ID         |
>   +----------+-------------------------+----------------------------+

If I understand what your suggesting?, we cannot do what you ask.  The
reason is that we cannot assume in any IETF protocol the "interface ID"
will always be 64bytes for all RFC 2373 prefixes.  I thought this to
some years ago as I wanted to only carry 64byte prefixes in our internal
OS inpcb structures for IPv6 in the kernel for fast lookups and for
host routing path search.  But, then I would have to have if-condition
construct for the Format-Prefix for IPv6 addresses.

See below from RFC 2373:

---------------------------
2.5.1 Interface Identifiers

   Interface identifiers in IPv6 unicast addresses are used to identify
  interfaces on a link.  They are required to be unique on that link.
   They may also be unique over a broader scope.  In many cases an
   interface's identifier will be the same as that interface's link-
   layer address.  The same interface identifier may be used on multiple
  interfaces on a single node.

   Note that the use of the same interface identifier on multiple
   interfaces of a single node does not affect the interface
   identifier's global uniqueness or each IPv6 addresses global
   uniqueness created using that interface identifier.

   In a number of the format prefixes (see section 2.4) Interface IDs
   are required to be 64 bits long and to be constructed in IEEE EUI-64
  format [EUI64].  EUI-64 based Interface identifiers may have global
   scope when a global token is available (e.g., IEEE 48bit MAC) or may
  have local scope where a global token is not available (e.g., serial
   links, tunnel end-points, etc.).  It is required that the "u" bit
   (universal/local bit in IEEE EUI-64 terminology) be inverted when
   forming the interface identifier from the EUI-64.  The "u" bit is set
  to one (1) to indicate global scope, and it is set to zero (0) to
   indicate local scope.  The first three octets in binary of an EUI-64
  identifier are as follows:

       0       0 0       1 1       2
      |0       7 8       5 6       3|
      +----+----+----+----+----+----+
      |cccc|ccug|cccc|cccc|cccc|cccc|
      +----+----+----+----+----+----+
-----------------------------------------------

The key is the sentence in the above paragraph first sentence "In a
number of format prefixes"......Not all IPv6 Format Prefixes will have
just 64byte interface ids.

Does this resolve your suggestion?

thanks
/jim

---

From: Stig Ven�s <[email-masked]>
Date: Fri, 8 Dec 2000 21:59:16 +0100

I've finally read the draft and have some comments as well.

On Tue, Nov 28, 2000 at 10:36:09AM -0500, Bernie Volz wrote:
> Ralph and others ... here's some comments on the -16 spec.
> 
> In general, this looks GREAT! Excellent job!

Yes

> - Section 22.2's diagram has a "pref. len". Yet this field is not defined
> anywhere in the list of fields. Was this an error in the diagram? Or was
> this to be the "prefix length"? If pref. len is prefix length, you might
> want to consider what to use as an abbreviation since then pref. could be
> "prefix" or "preferred" (as in preferred lifetime).

I think it must be prefix len, but I agree, the abbreviation is no good.

> - In section 10.3.3, there are several mentions of "advertising availability
> of IP address" ... how is this done (perhaps there will or is an option that
> will provide this information?). Also, if this capability DOES exist, isn't
> Ted's Discussion point in section 10.5.2 null and void?

My thought too. I think such an option is a good idea, but it requires
an option not specified in the draft as I understand it.

One more thing.

It says several places that an IA is identified by (prefix, UUID), why
isn't the UUID enough? The 64 bits UUID should be enough on it's own I
would think. There are also situations where I don't understand how the
server knows the prefix, I think things would be much simpler if the
UUID were enough on it's own. In order to do this, the IA UUID would
have to be decided by the server though, or one has to make sure two
clients won't use the same UUID in requests to the same server. If one
uses (prefix, UUID) the server must always know the prefix when it gets
an IA (don't think this is the case now), and one must also make sure
two clients won't try to use same (prefix, UUID) pair.

I haven't had time to think about all the details yet, my apologies if
I have missed something vital.

Stig

---

From: Ralph Droms <[email-masked]>
Date: Sun, 10 Dec 2000 19:18:14 -0500

> > In general, this looks GREAT! Excellent job!

Thanks...

> > anywhere in the list of fields.
>

The "prefix length" field was left out of the list of fields (editor's 
oversight).  I will label the field "prefix length" and add a description 
of the field to the list of fields.

>an option not specified in the draft as I understand it.

Sorry about the confusion.  We have confirmed (in the 12/5 meeting) that 
carrying addresses in the Advertise is the right thing to do.  The details 
are TBD.  I *imagine* the right thing to do is for the client to pass the 
IAs it needs configurations for in the Solicit.  The server can then fill 
in the IAs and return them to the client in the Advertise.

>isn't the UUID enough?

We also had this conversation during the 12/5 teleconference and will bring 
the discussion to the WG on Tuesday, 12/12.

- Ralph