Subject: Discussion items for dhcpv6 -19 draft ...

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Tue, 10 Jul 2001 08:56:01 -0500

Some discussion items from the DHCPv6 -19 draft for the Working Group to
consider:

1. I like the format of the option as per the -19 draft - in particular, the 
DUID-type. However, it seems as if the DUID len is either not necessary
(since it is just option-len - 2) OR making it one byte would be more than
sufficient (since we probably should set a reasonable upper limit of something
like 32 bytes for the DUID). I do like the fact that it is variable - so I
do NOT suggest we make it a fixed length field.

2. Should there be any recommendation (requirement) on the ordering of the 
DUID option? It might make server processing simplier and easier if the 
DUID is always required to be BEFORE any IA options (avoids needing to 
look ahead for it). Also, for relays and servers that will be load balancing,
finding this quickly means that relays can forward the message quicker and
servers can ignore the message sooner (if not in their load balancing range).

As it is required in every client message, making it first would be beneficial.
While it would be nice to make this a MUST, I would be happy with a SHOULD.

I guess one other option might be to make it part of the header, but I like it
better as an option.

3. Is the 16-bit Transaction ID really sufficient? I would like to understand
why reducing the number of bits from 32 (DHCPv4) to 16 is justified. A 1 out
of 65536 chance is a lot higher than a 1 out of 2^32 chance of a collision.
Especially if clients don't have stable storage to save the last transaction ID
(or don't want the 'cost' of using stable storage for this).

4. Is there any need for a 'secs' field? While the current specification is
really based on the assumption that (request)/Reply messages are exchanged
between client and one server, with the use of the anycast address or multicast
addresses for a "pool" of DHCP servers, having a 'secs' field does allow for
another member of the "pool" of servers to answer should the server assigned to
answer not be available. Note that servers could do this without a secs field,
but it does mean they need to save some state of these requests.

Note that perhaps with issue 3 and 4 a new header can be defined that
incorporates both a 32-bit transaction ID and a secs-like field?

- Bernie Volz
  Ericsson

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 Jul 2001 23:03:38 -0700

> 1. I like the format of the option as per the -19 draft - in
> particular, the DUID-type. However, it seems as if the DUID len is
> either not necessary (since it is just option-len - 2) OR making it
> one byte would be more than sufficient (since we probably should set
> a reasonable upper limit of something like 32 bytes for the DUID). I
> do like the fact that it is variable - so I do NOT suggest we make
> it a fixed length field.

Yup, I second the idea of getting rid of the DUID length field.

> servers can ignore the message sooner (if not in their load balancing range).

I don't think this is worth specifying.   The difference we're talking
about here is really minor compared to the overhead of, e.g., signing
packets or actually doing the hash on the identifier.

> I guess one other option might be to make it part of the header, but
> I like it better as an option.

Me too.   If you put it in the header, you have to choose a length for
it, and live with the choice later.

> 3. Is the 16-bit Transaction ID really sufficient? I would like to
> understand why reducing the number of bits from 32 (DHCPv4) to 16 is
> justified. A 1 out of 65536 chance is a lot higher than a 1 out of
> 2^32 chance of a collision.  Especially if clients don't have stable
> storage to save the last transaction ID (or don't want the 'cost' of
> using stable storage for this).

If the server is required to send back the DUID (and it probably
should be, IMHO) then sixteen bits should be fine.

> 4. Is there any need for a 'secs' field? While the current specification is

I think you're right about this - we probably do need a 'secs' field.
We haven't really talked about failover for DHCPv6 yet, but
failover+load balancing for DHCPv4 would be a real pain to implement
without the 'secs' field.

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Jul 2001 10:25:38 -0700

> using stable storage for this).

Hm, on second thought, here's the thing: the packet is being unicast
through the relay agent (or directly) to the client's link-local
address.   This is a completely different situation from DHCPv4, where
all responses to unconfigured clients were broadcast, and therefore
an XID collision was a real possibility.

So we don't have to consider statistical odds of a collision - as long
as the client doesn't use a transaction ID number for any transaction
that it remembers, there will never be a collision.

So there's no need for a 32-bit xid after all - 16 bits should be
plenty.

			       _MelloN_