Subject: DHCPv6 -19 Draft Comments

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Mon, 16 Jul 2001 13:03:19 -0500

Ralph, et al:

In some further internal discussions and reviews, here are some other issues to address in the revision to the DHCPv6 -19 draft:

1. In Section 14.3.1 (Creation and sending of Request messages), there is no mention of using any of the "information" supplied by a server in the Advertise message (in response to a Solicit). In DHCPv4, the client sent information received in the Offer. We probably should be explicit about this and perhaps even suggest that the information received by a client in an Advertise is basically for information purposes only to help it determine whether this server will offer it what it needs. Perhaps the addresses assigned in the Advertise should even just be prefixes (interface portion all 0's)?

If instead we want the server to assign "real" addresses, should something be said about how long those should be valid and whether the server should attempt to assign those same addresses to the client in a subsequent Request/Reply exchange for the IA? Perhaps we could punt and say this is a server implementation issue (whether it assigns real addresses and whether those are held for some (short) time for the client)?

NOTE: If real addresses are returned, perhaps a client might even initiate DAD during the Request/Reply in which case it can do these two items in parallel (though this would be somewhat tricky since it would not want to Decline the addresses before receiving the Reply).

Also, while checking the draft regarding this issue, I noticed:
- Section 13.4.2 (Creation and sending of Advertise messages) does not even say anything about the ORO option that a client might have specified. Shouldn't we indicate that the Advertise message SHOULD include options for all OROs that were included in the Solicit if the server is willing/capable of offering a value for that option?

- Section 14.3.1 (Creation and sending of Request messages) the first sentence says "If a client has no valid IPv6 addresses of sufficient scope to communicate with a DHCP server, ..." Huh? Even if it *DOES* have an address of sufficient scope, we don't want the client sending messages directly to the server. This must be some old text that should be dropped.

2. In Section 14.3.1, we should perhaps explicitly indicate that the client should add an ORO option (it now says "The client adds any appropriate options" ... but in many cases that just means an ORO option with appropriate options specified in that option.

3. During the WG / Design Team (I forget which, if not both) we did discuss designing a "quick" handshake for allowing a client to assign an address. I would assume we'd define a new option that the client could use to communicate to the server that it is doing this. Would we use Solicit/Advertise or Request/Reply for this (in many ways, Request/Reply seems like a better mechanism - the Request could simply leave the "server address" field as all 0's and that could even be the flag to the server). Perhaps we decided to defer this for now and do it later?

4. At another time we also discussed using the server to just advertise prefixes and allowing the client to generate the addresses? What about adding a "P" bit (next to the "T"-temporary bit) to indicate that this is a prefix from which the client should generate an address (or simply allowing it to do so if the link-identifier field is all 0's).

> Bernie Volz
> Chief Technical Officer - DNS & DHCP Development Unit
> Ericsson, Inc.
> Tel: +1-508-875-3162
> Fax: +1-508-875-3018
> Mobile: +1-617-513-9060
> mailto:[email-masked]
> 
>

---

From: Jim Bound <[email-masked]>
Date: Mon, 16 Jul 2001 22:48:51 -0400 (EDT)

On Mon, 16 Jul 2001, Bernie Volz (EUD) wrote:

wordwrap of 72 chars and using plain text with ms would be nice...

> Ralph, et al: 
> 
> In some further internal discussions and reviews, here are some other
> issues to address in the revision to the DHCPv6 -19 draft: 
> 
> 1. In Section 14.3.1 (Creation and sending of Request messages), there
> is no mention of using any of the "information" supplied by a server in
> the Advertise message (in response to a Solicit). In DHCPv4, the client
> sent information received in the Offer. We probably should be explicit
> about this and perhaps even suggest that the information received by a
> client in an Advertise is basically for information purposes only to
> help it determine whether this server will offer it what it needs.
> Perhaps the addresses assigned in the Advertise should even just be
> prefixes (interface portion all 0's)? 

This is implementable for now.  Client can get options.  Options are
defined.

But we easy fix.

We want to permit future extensions so we need to be careful here and not
over specify.

> 
> If instead we want the server to assign "real" addresses, should
> something be said about how long those should be valid and whether the
> server should attempt to assign those same addresses to the client in a
> subsequent Request/Reply exchange for the IA? Perhaps we could punt and
> say this is a server implementation issue (whether it assigns real
> addresses and whether those are held for some (short) time for the
> client)? 

This is the default if we don't say.  Its up to the server.

> 
> NOTE: If real addresses are returned, perhaps a client might even
> initiate DAD during the Request/Reply in which case it can do these two
> items in parallel (though this would be somewhat tricky since it would
> not want to Decline the addresses before receiving the Reply). 

If the clients chooses to do DAD it should be done before Request.

> 
> Also, while checking the draft regarding this issue, I noticed:  -
> Section 13.4.2 (Creation and sending of Advertise messages) does not
> even say anything about the ORO option that a client might have
> specified. Shouldn't we indicate that the Advertise message SHOULD
> include options for all OROs that were included in the Solicit if the
> server is willing/capable of offering a value for that option? 

Yes it should this can be added in easily.

> 
> - Section 14.3.1 (Creation and sending of Request messages) the first
> sentence says "If a client has no valid IPv6 addresses of sufficient
> scope to communicate with a DHCP server, ..." Huh? Even if it *DOES*
> have an address of sufficient scope, we don't want the client sending
> messages directly to the server. This must be some old text that should
> be dropped. 

We now permit the unicast option so we still need this health warning.
but in context of the new option.

> 
> 2. In Section 14.3.1, we should perhaps explicitly indicate that the
> client should add an ORO option (it now says "The client adds any
> appropriate options" ... but in many cases that just means an ORO option
> with appropriate options specified in that option. 

The word "appropriate" is correct.  It can be an ORO or IA.

> 
> 3. During the WG / Design Team (I forget which, if not both) we did
> discuss designing a "quick" handshake for allowing a client to assign an
> address. I would assume we'd define a new option that the client could
> use to communicate to the server that it is doing this. Would we use
> Solicit/Advertise or Request/Reply for this (in many ways, Request/Reply
> seems like a better mechanism - the Request could simply leave the
> "server address" field as all 0's and that could even be the flag to the
> server). Perhaps we decided to defer this for now and do it later? 

My recollection is that we the end result was the design team and then at 
the IETF the WG does not want to permit this behavior????
 
> 4. At another time we also discussed using the server to just advertise
> prefixes and allowing the client to generate the addresses? What about
> adding a "P" bit (next to the "T"-temporary bit) to indicate that this
> is a prefix from which the client should generate an address (or simply
> allowing it to do so if the link-identifier field is all 0's). 

We decided in San Diego and Minneapolis to not do this behavior at this
time in the WG.  So we verified it twice.  We may want to reserve a prefix
bit though if all feel it worthwhile.

/jim

---

From: "Vijay Bhaskar A K" <[email-masked]>
Date: Thu, 19 Jul 2001 07:17:08 +0530

DHCPv6 -19 Draft Comments
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On
Behalf Of Bernie Volz (EUD)
  Sent: Monday, July 16, 2001 11:33 PM
  To: DHCPv6 discussion list
  Subject: DHCPv6 -19 Draft Comments

  Ralph, et al:

  1. In Section 14.3.1 (Creation and sending of Request messages), there is
no mention of using any of the "information" supplied by a server in the
Advertise message (in response to a Solicit). In DHCPv4, the client sent
information received in the Offer. We probably should be explicit about this
and perhaps even suggest that the information received by a client in an
Advertise is basically for information purposes only to help it determine
whether this server will offer it what it needs. Perhaps the addresses
assigned in the Advertise should even just be prefixes (interface portion
all 0's)?

  [Vijay Bhaskar A K] *****

  I think, sending the prefix instead of real addresses in the SOLICIT
message is a nice idea. Becaues, for the IP address, we need some knob for
the expiration of the "offered" addresses and at the same time, the client
will be able to select the server who is giving address of its scope. It can
find out that, whether the server is capable of giving the number of address
it has asked. I feel that, we have to specifically say that, the server MUST
send the IA option filled with prefixes, if it has that free pool of those
many addresses. Otherwise, what will happen, if the server's preference
value is 255 and it don't have the free pool of addresses to be assigned.

  If instead we want the server to assign "real" addresses, should something
be said about how long those should be valid and whether the server should
attempt to assign those same addresses to the client in a subsequent
Request/Reply exchange for the IA? Perhaps we could punt and say this is a
server implementation issue (whether it assigns real addresses and whether
those are held for some (short) time for the client)?

  NOTE: If real addresses are returned, perhaps a client might even initiate
DAD during the Request/Reply in which case it can do these two items in
parallel (though this would be somewhat tricky since it would not want to
Decline the addresses before receiving the Reply).

  Also, while checking the draft regarding this issue, I noticed:
  - Section 13.4.2 (Creation and sending of Advertise messages) does not
even say anything about the ORO option that a client might have specified.
Shouldn't we indicate that the Advertise message SHOULD include options for
all OROs that were included in the Solicit if the server is willing/capable
of offering a value for that option?

  - Section 14.3.1 (Creation and sending of Request messages) the first
sentence says "If a client has no valid IPv6 addresses of sufficient scope
to communicate with a DHCP server, ..." Huh? Even if it *DOES* have an
address of sufficient scope, we don't want the client sending messages
directly to the server. This must be some old text that should be dropped.

  3. During the WG / Design Team (I forget which, if not both) we did
discuss designing a "quick" handshake for allowing a client to assign an
address. I would assume we'd define a new option that the client could use
to communicate to the server that it is doing this. Would we use
Solicit/Advertise or Request/Reply for this (in many ways, Request/Reply
seems like a better mechanism - the Request could simply leave the "server
address" field as all 0's and that could even be the flag to the server).
Perhaps we decided to defer this for now and do it later?

  4. At another time we also discussed using the server to just advertise
prefixes and allowing the client to generate the addresses? What about
adding a "P" bit (next to the "T"-temporary bit) to indicate that this is a
prefix from which the client should generate an address (or simply allowing
it to do so if the link-identifier field is all 0's).

  Willl there be lease for these kind of addresses or these are same as the
address formed by the stateful autoconf with infinite leases?

  Bernie Volz

---

From: Jim Bound <[email-masked]>
Date: Thu, 19 Jul 2001 01:06:34 -0400 (EDT)

yes ralph and I need to parse this... geeeezzz I am glad for all this
great discussion but we are up against nasty deadline.

/jim