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

From: "Thirumalesh Bhat" <[email-masked]>
Date: Thu, 12 Jul 2001 16:37:39 -0700

Comments on Bernie's suggestions inline:

-----Original Message-----
From: Bernie Volz (EUD) [mailto:[email-masked]] 
Sent: Tuesday, July 10, 2001 6:56 AM
To: DHCPv6 discussion list
Subject: Discussion items for dhcpv6 -19 draft ...

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. 

            There is a need to have a limit on the length of DUID. If
the length of DUID is the option length the max length of DUID is 64K
bytes. This is going to put a burden on the server to store it and
compare it to the client's DUID every single time. I would say one octet
for DUID length should suffice.

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). 

            This is relevant if XID is used to check duplicate packets
on the client or server side. The chances of collision is somewhat
unlikely in the client if it keeps incrementing a counter.

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. 

            Secs field can also be used by a router to do load
balancing/fault tolerance. Eg: relay can forward the packet to a
different dhcp server if seconds field is non zero or above a certain
threshold. If there are other mechanisms to do it - this field may not
be needed.

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: "Bernie Volz (EUD)" <[email-masked]>
Date: Fri, 13 Jul 2001 08:33:06 -0500

OK. I was thinking that binding just referred to the DHID but it does say it includes that IAID (in section 6.2). So, we are hopefully OK.

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Friday, July 13, 2001 1:00 AM
To: DHCPv6 discussion list
Subject: Re: Discussion items for dhcpv6 -19 draft ... 

> OK. I'm happy if we add the IAIDs (and I'd also suggest the request
> type just to be safe). Then we can leave the XID as 16-bits.

Actually, I just checked, and it's already there.   The current draft
calls for entries in the cache to be indexed by {xid, binding}.
A binding includes both the IAID and the DUID.

			       _MelloN_