Subject: RE: questions on DHCPv6 -18 rev of draft

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Tue, 13 Mar 2001 11:13:13 -0600

See comments below (BV>).

-----Original Message-----
From: Vijay Bhaskar A K [mailto:[email-masked]]
Sent: Tuesday, March 13, 2001 10:23 AM
To: DHCPv6 discussion list
Subject: Re: questions on DHCPv6 -18 rev of draft

> "Bernie Volz (EUD)" wrote:
> 
> Some comments regarding your questions:
> 
> Fragmentation - This problem doesn't exist. The IPv6 layer will
> reassemble the packet. If the packet is multicast on the link, the
> other systems on that link in the destination multicast group will all
> reassemble the packet before processing it. So, whether it is a relay
> agent or a server doesn't matter. Also, if the relay is unicasting the
> packet to a server, same thing happens (it will be reassembled). This
> fragmentation is NOT something that the DHCP Client code does - but
> something that happens at the IPv6 layer. So, if the -18 text isn't
> clear about this, we need to fix it.

Yes. I think the draft has to make clear this.

> 
> DUID - How it is generated is still the $64,000 question. There have
> been some proposals in discussions.
> 
> All DHCP Clients Multicast - I agree, it should be link local. This
> hasn't yet been fully explored. It appears, from the -18 draft, that
> the server somehow communicates the client to tell it what Multicast
> group to join, but I think that has flaws in it. (I'm in the process
> of writing up some review comments as well in preparation for the
> conference call and this was one of my issues.)
> 

I feel that having All DHCP Clients Multicast address will be only an
additional overhead. Consider the following situation. 
1. Consider a site with links m,n,o,p. "p" has been renumbered.
2. The server will send the reconfigure-init message to the All DHCP
Client Site local multicast address. 
Since this is an site-scoped address, all the clients in links m,n,o,p
will respond with DHCP Request, flooding the network. But, the server
actually wanted the clients in link "p" to respond.

If we define All DHCP Client Multicast address as a link-local one,
then, how wiil the server sends the reconfigure-init message to the
clients in the links which are not directly connected to the server. 

BV> The DHCP Server needs to communicate through the relays. The DHCP Server
BV> must either be preconfigured with a list of the relays or could learn
BV> the relays (though that isn't as good if a server is starting cold as
BV> it can't trigger reconfigurations until it has learned of the relays).

I feel that, instead of defining a multicast address for this purpose,
if a range of multicast address of site-local scope is specified, then
the server can allocate one Reconfigure multicast address for one group.
(nodes belonging to one/two links can form a group). Thus, it prevents
other applications from using these multicast addresses. 

In the draft it is said that, Reconfigure-int MAY contain ORO option. In
case, if it is not there, what are the options that the client has to
send in the Request message? I feel that Reconfigure-init MUST contain
ORO option to specify the client the options/parameters that has been
changed. Then only, the client can request for those options.

BV> I think the client should always send a full Request regardless of
BV> what the ORO options are in the Reconfigure-Init. That way, it can be
BV> sure to get complete information.

> Solicit message - The client just sends whatever IA option(s) it would
> send with a Request. This allows the server to respond with what it
> would assign on receipt of the Request. And, yes this is very similar
> to the DHCP DISCOVER/OFFER. The reason is that the client may need
> this information to make a decision as to which Advertise it will
> accept.
> 
> Note that the specification (12.3.1) says: "all of the IAs MUST be
> empty" (when creating the Solicit).
> 
> I believe that the server should reply even if it can't honor all of
> the options in the ORO - the client can decide which to take based on
> what it receives (if it needs a particular option, it can discard the
> ones without it). That's what we do in DHCPv4.
> 
> If the server Advertises addresses, it should behave similar to
> DHCPv4's OFFER in that the server SHOULD not reassign these addresses
> for a short time to 'reserve' them for the client. But, it is only a
> SHOULD and not a MUST (the server may change the addresses in the
> REPLY).

The short time that the server 'reserve' the addresses needs to be
defined.

BV> Perhaps a default can be provided (I don't recall the DHCPv4 specification
BV> having this value). But I think it can also be left to the implementor (or
BV> as a configuration parameter on the server. This partially depends on how
BV> short you are on addresses (and with IPv6 that isn't likely to be an issue).

> 
> Note that when the Client constructs the Request "The list of
> addresses in each included IA MUST be empty." (13.3.1). Therefore,
> unless the server takes steps to 'reserve' the addresses, the client
> should have forgotten about them.
> 
> Request message (client wants more addresss) - If a client wants new
> addresses, it must use a new IA. This new DUID must be different than
> the previous. The DUID really is a client identifier/interface
> identifier/address request identifier. I think this has gotten lost in
> the draft text.

Why do we need the seperate IA for the getting new addresses. Is there
any specific reason for not sending the request for new addresses in the
same IA? 

BV> How does the server know the client wants more addresses? The num-addr
BV> field is supposed to reflect the number of addresses that follow (not
BV> the number that is requested) from my understanding.

> 
> The reason for sending *ALL* client requests via the multicast
> mechanism is such that if a relay agent is between the client and
> server IT WILL ALWAYS BE between the client and server. Therefore,
> things like the DHCPv4 Relay Agent options can always be inserted in
> the clients requests and the server always has complete information.
> This is actually a nice solution. There are also others (such as if
> there are failover partners, they can respond on behalf of each other
> if they know the target server is down). There is of course a cost,
> but it is rather low. One option we could consider (though at the lost
> of some potential features such as the failover one) is allowing a
> client to unicast to the server IF AND ONLY IF the server is on the
> link (ie, the server's address is a link-local). For in that case, no
> relay options would be added. But, I'm not in favor of this.

yes. this is ok. It will be better to use multicast instead of unicast.

> 
> Release message - A client can release one or many addresses (either
> in one or multiple IAs). It need not release all of the addresses in a
> single IA.
> 
> Sending deprecated address - I would expect that the server to do (b)
> - include both the old addresses (with lifetimes adjusted) and the
> new. However, it may also do (a) if the previous lifetimes given the
> client are still applicable and there is no need for the server to
> update them (since the client can use those addresses until the valid
> lifetime expires).

thanks for clarifying the doubts.
Vijay.

> 
> I'm sure I missed a few of your questions. Good comments.
> 
> - Bernie Volz
>   Ericsson
> 
> -----Original Message-----
> From: Vijay Bhaskar A K [mailto:[email-masked]]
> Sent: Monday, March 12, 2001 7:06 PM
> To: DHCPv6 discussion list
> Subject: questions on DHCPv6 -18 rev of draft
> 
> Hi,
> I have few questions regarding the -18 rev of DHCPv6 draft. I will be
> attending the design telecon. let me know your comments about these
> issues.
> Regrads,
> Vijay
> 
> questions
> ---------
> 
> * Since, in IPv6 routers won't handle the fragmentation. so, DHCPv6
> implmentation has to take care of the fragmentation.
> Assume the client has fragmented the packet in to two packets. The
> server will
> read the first packet correctly, since it is in proper packet format.
> Then, the second packet will be discarded, since it has only the
> remaining
> content of the previously sent packet.
> This is because, the server doesn't know that whether the packet
> recieved is
> correct one or the later part of the  prviously sent fragmented
> packet.
> Do we need to have an additional message type (or) a field speciying
> the
> "next fragment" for transmission of the fragemented packet?
> 
> * How DUID is generated? what is its format?
> 
> * I think we don't need site scoped "All DHCP Clients" multicast
> address
> for sending reconfigure messages. Since, renumbering of network takes
> place per link basis. This means we need to send Reconfigure message
> to
> only the nodes in a particular link, not to all the nodes in the site.
> 
> Thus, if we use All DHCP clients multicast address, most of the nodes
> will unecessarily receive the Reconfigure-init  message.
> 
> * There are some list of Generic Error values like
> AuthFailed,PoorlyFormed etc. are defined. But no where it is mentioned
> 
> how to return this error value. We need an option or a field for
> returning these generic error values. This option must be included in
> the base-spec.
> 
> * In solicit message, does the client need to send the number of IP
> address needed for the IA, in the IA option? I think it is better to
> send the requested number of IP address in the Ia option. If the
> client
> is asking "n" number of IP address and the server can offer only "m"
> IP-addresses (m<n), then the client can choose better server offering
> "n" IP address. This can become one criteria for selecting the server
> to
> send the DHCP Request message.
> 
> >The server MUST include options to Advertise message containing any
> address >that would be assigned to IAs contained in the Solicit
> message format.
> 
> 1. Is this similar to the DHCP OFFER in DHCPv4?
> 2. If the client has asked "n" IP address, does the server need to
> send
> "n" address in the IA? (or) need to send the just the prefix?
> 3. If the server does not have one or few of the requested
> configuration
> parameters asked by the client in ORO option, does the server need to
> send the only the configuration parameters it have and leave the other
> 
> options. (or) since it doesn't have some of the configuration
> parameters, will it tollaly ignore the Solicit and don't send reply?
> 4. If the server can offer only few IP-address (m) less than the
> requested number of IP-address (n), does the server needs to respond
> with the available number of IP-address (OR) doesn't send Advertise?
> 5. If the server is sending the "n" IP Addresses in IA option in
> Advertise message, it means that, these addresses should not be
> assigned
> to the other clients and is reserved for the client that has sent the
> Solicit?
> 
> Request message
> _______________
> 
> 1. assume, the client has asked 2 IP address first time. After some
> times, it needs another 3 IP-address in the same interface. This time,
> 
> does it need to send a fresh empty IA? or it can ask for another 3
> IP-address in the same IA?
> 
> a) If it has to send the fresh empty IA, how will the server maintain
> the record of these IAs, since the IA sent at the first time and sent
> next time will have the same DUID and subnet-prefix. Will the server
> treat these two as different or same IAs?
> 
> b) why empty IA is to be sent for requesting IP address?
> 
> c) what does exactly the empty IA mean? In other words, what are the
> fields to be filled in IA options for sending the empty IA.
> 
> (eg):- If the client is requesting 3 IP-address,
> I think these are fields which must be filled.
> (1) option-code
> (2) option-len
> (3) IA-DUID
> (4) num-addrs = 3
> 
> do the addr status, prefix length, IPv6 address, pref life time, val
> life time should be present or filled with zeros?
> 
> 2. If the client has sufficient scope to reach the server, then why
> can't it send the Request message directly? Why is it mentioned in the
> 
> draft that it should send the Request message to All DHCP Agents
> Address? This situtation holds for renew and rebind message also.
> 
> Release Message
> _______________
> 
> For sending DHCP Release message, does the client include addresses to
> 
> be released? (or) includes ONLY the address to be released?
> 
> Authentication Option
> _____________________
> 
> Why authentication option is to be included as the last option?
> If it is included as the first option, it will be easier to
> authenicate
> first and in case, if authentication fails, it can directly reject the
> 
> packet without processing further.
> 
> Sending deprecated address
> __________________________
> 
> Assume
> 1. A network renumbering for a particular link has occured. The prefix
> 
> 5ffe:: is changed to 3ffe::
> 2. An IA for a node in this link has following addresses, 5ffe::20 and
> 
> 5ffe::21
> 3. Now reconfiguration has been triggered and the server has sent the
> Reconfigure-init message to the client.
> 4. Client has responded with DHCP Request.
> 
> a) does the server has to delete the addresses 5ffe::20 and 5ffe::21
> from the IA and include 3ffe::20 and 3ffe:21 in the IA?
> (or)
> b) for graceful renumbering, it can add new IP-address 3ffe::20 and
> 3ffe:21 to the IA along with the orginal 5ffe addresses?
> In this case, i feel that the old prefix addresses (5ffe) should be
> made
> deprecated one with the prefered-lifetime = 0 and valid-lifetime =
> some
> grace period. I think this is a MUST one for renumbering.
> 
> _______________________
> 
> * In the draft, in one section(12.3.2) , it is mentioned that, client
> has to wait for ADV_MSG_TIMEOUT collecting the Advertise messages. In
> another section( WAIT collecting Advertise message. Since both the
> variable has different default values, which is to be used?

---

From: Vijay Bhaskar A K <[email-masked]>
Date: Wed, 14 Mar 2001 18:53:33 +0530

Hi Bernie,

see my comments below (VB>)

> BV> it can't trigger reconfigurations until it has learned of the

VB> There is no need of preconfiguring the server. It can record the
relay 
VB> information from the previous Relay-forward messages.

> BV> sure to get complete information.

VB> Assume, in future, we have defined 100 options. The client has to
send the 
VB> Request with all the 100 options asked? In case, only 2 parameters
has been 
VB> changed and the clients will be requesting for 100 configuration
parameters. 
VB> The message size will become very large. I think i we make the ORO
option in 
VB> Reconfigure-init as mandatory, we can prevent this.

> BV> short you are on addresses (and with IPv6 that isn't likely to be

VB> ok. i agree with this.
> BV> the number that is requested) from my understanding.

VB> This can be done very will the single IA. 
VB> Assume the IA has already 2 addresses. Now, the client wants another
3 
VB> addresses. For requesting another 3 addresses, send the same IA
option with 
VB> following. 
VB> 1. make num-addrs field as 5.
VB> 2. Include already existing 2 addresses in the IA option with filled
prefix
VB> length, IPv6 address and preferred lifetime and valid life time
values.
VB> 3. For the remaining 3 address newly asked, fill the prefix length,
IPv6
VB> address, pref-life time, valid-life time with zero and make the
corresponding VB> addr status to ADDR_REQUEST indicating, the client is
asking the address.

VB> This has some advantages also.
VB> 1. The DUID is need not to be generated for each and every request.
VB> 2. The server can maintain the list of IP-address it is managing for
a 
VB> particular interface of a node. This will minimize the number of
records 
VB> maintained.

-- 
____Vijay_Bhaskar_A_K____
______Inet_Services______
________HP_ISO___________
____Ph:_2251554_1424_____
___Pager:_9624_371137____