Subject: [dhcwg] Rev of DHCPv6 spec

From: Ralph Droms <[email-masked]>
Date: Wed, 10 Oct 2001 22:01:31 -0400

I've finished another rev of the DHCPv6 spec (-20d), which is available at 
http://www.dhcp.org/dhcpv6.tty  I plan to submit this draft of the spec to 
the IETF for publication on 10/12.  The list of issues addressed by this 
draft is included below; these issues were discussed at the DHC WG meeting 
in London (8/2001).  The -20d draft does not include any changes related to 
IAs.  The changes related to IAs will appear in the next published rev of 
the draft.

- Ralph

=====
Issues from London addressed in this draft.

* Should addresses in an Advertise message be "real" addresses or
   "informational"; e.g., just prefixes?

   WG consensus: addresses in Advertise are the addresses the server
   will return in a subsequent Reply; client supplies those addresses
   to server in IA in Request message

* Servers will only assign complete addresses and not prefixes (e.g.,
   to be used by the client for stateless autoconfiguration)

   WG consensus: yes; prefix advertisement is handled through ND

* How and when does the client use DAD on addresses in Advertise and
   Reply messages?

   WG consensus: Client does DAD on addresses in Reply message and
   responds with Decline if addresses unacceptable (e.g., already in
   use)

* 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

   WG consensus: yes

* Add "NAK" function:

    If the server finds that the prefix on one or more IP addresses in
    any IA in the {Request, Confirm, Rebind} message is not a valid
    prefix for the link to which the client is connected, the server
    MUST send an NoPrefixMatch status in the IA status field for that
    IA in the DHCP Reply message.

   WG consensus: yes; indicate "NAK" through return of "NoPrefixMatch"
                 error code.  Add text allowing client to ignore
                 "NoPrefixMatch" from other servers if ACK received from
                 at least one server.

* Define DUID to be one of:
   - Link-layer address plus time
   - Vendor-assigned unique ID
   - Link-layer address
   - IMSI
   - IMEI

   WG consensus: yes; based on text submitted by Lemon with extensions
                 from subsequent WG discussion

   MODIFICATION: drop IMSI, IMEI

* Use IPsec for secure agent/server communication

   WG consensus: yes; add text to draft

* Add an "error code" option, to indicate errors not connected with a
   specific option

   WG consensus: yes; should allow inclusion of text message

* Tighten up language for unicasting Reconfigure-Init; in particular,
   the server may not have an appropriate address to use to send the
   message to the client.

   WG consensus: yes

* Reply to a Confirm should be a simple ACK/NAK without changing any
   values in options

   WG consensus: Discussion to be taken to mailing list
   Note: check to make sure there is text in the draft describing
   behavior if no response is heard to a Confirm

   FOLLOWUP:  Issue was not posted to mailing list.  Draft now defines
   Confirm to be simple ACK/NAK.

* Reply to Decline or Release should carry no options

   WG consensus: yes

* Restrict options in Decline or Release to IA with text to allow
   other options in the future

   WG consensus: no; this is an overspecification

* Server does not respond to Solicit when client wants addresses and
   server has no addresses

   WG consensus: Server should be allowed to respond

* Include only options specifically mentioned in the text in the
   DHCPv6 spec; move others to second doc or separate appendix

   WG consensus: anything we have consensus on stays; anything else
   gets punted to a separate draft.

* Add 'secs' field to fixed header

   WG consensus: if client retransmits, MUST send option called
   "milliseconds"

* Make the preference field an option

   WG consensus: yes

* Describe message transmission and retransmission in a separate
   section of the spec and reference that text throughout the remainder
   of the spec

   WG consensus: yes

* Discard the client unicast or recheck the entire spec for
   consistency in reference to message transmission

   WG consensus: yes, authors to fix spec

* Remove client link-local address from client message header.  Agent
   can then determine link-local from source (IP header) in client
   message and insert into agent->server message.  Server responds to
   source from IP header (whether agent or client).

   WG consensus: Yes

_______________________________________________
dhcwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/dhcwg

---

From: [email-masked]
Date: Sat, 13 Oct 2001 12:36:10 +0530

Ralph Droms <[email-masked]> on 10/12/2001 03:36:08 PM

Please respond to Ralph Droms <[email-masked]>

To:   Suresh Kodati/India/IBM@IBMIN
cc:   [email-masked], Suparna Bhattacharya/India/IBM@IBMIN, R
      Sharada/India/IBM@IBMIN
Subject:  Re: [dhcwg] Rev of DHCPv6 spec

>1./2. the unicast option is an administrative policy;

>3. I don't see any text in 16.1.1 that requires the
>client to check that the server is on the same link

I took the case of client and server on the same link as an example for the
first condition 16.1.1/16.1.3/16.1.6/16.1.8/ "If the client has a source
address that can be used by the server as a return address").

>In response to your last question, the use of unicast
>isn't dependent on whether the client and server
>are on the same link.  A client could use unicast to
>deliver DHCP messages to an off-link router.

>The draft doesn't specify how a server should react
>to a unicast message received from a client to which the
>server has not sent a unicast option.  I imagine the
>right thing to do is to allow the server to process
>such messages.

If the client can unicast the message without referring to receipt of
unicast option from the server, (and since the server doesn't mandate the
client to use unicast the messages to the server by sending unicast
option), How this option would be useful.

Is there any scenario that a client cannot unicast the
REQUEST/RENEW/RELEASE/DECLINE even after receipt of unicast option from the
server.

Isn't it is enough to leave it to the client to choose the
unicast/multicast based on the first condition ("If the client has a source
address that can be used by the server as a return address").

-Suresh

At 12:18 PM 10/12/2001 +0530, [email-masked] wrote:

>I would like to get clarification on when does a server send an unicast
>option,
>1. does the server send unicast option  whenever the client is on the same
>link (20.11 is not clear about it) (or)
>2. Is it an administrative policy that decides if the client can
>unicast/multicast of messages. If it is so, is there any example of the
>scenario where the server would not specify the option despite being on
the
>same link.
>3. why is the client required to check if the client and server are on the
>same link if  unicast option is already obtained from the server ( 16.1.1
)
>
>And also,
>  Is it not sufficient to have both client and server to be on the same
link
>to unicast client's message ?, if so what is the server response to
>client's unicast if it didn't send unicast option to the client and still
>gets messages unicast'ed to it.
>-suresh
>
>
>Ralph Droms <[email-masked]> on 10/11/2001 07:31:31 AM
>
>Please respond to Ralph Droms <[email-masked]>
>
>To:   [email-masked]
>cc:    (bcc: Suresh Kodati/India/IBM)
>Subject:  [dhcwg] Rev of DHCPv6 spec
>
>

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Sun, 14 Oct 2001 21:08:53 -0500

The reason for having the SERVER send the unicast option and tell the client that it is OK is to avoid some of the problems that exist today with client renewals that don't go through relay options (such as in cable modem systems). Since the client/server communicate directly (in DHCPv4), the relay can't add the relay-agent options to the client's messages. If this isn't in the -20 draft, perhaps we should add something about it (just so people in the future won't need to ask why).

I think that a client MUST NOT unicast a message unless it has received the unicast option from that server. (As Ralph indicated, I'm not sure it is required that a server MUST check that a message was multicast unless it told the client it was OK to use the unicast option; however, a server is free to drop those datagrams if it wishes. Hence, for a client to get service from all servers, it will need to honor the required behavior).

- Bernie Volz

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Saturday, October 13, 2001 3:06 AM
To: Ralph Droms
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dhcwg] Rev of DHCPv6 spec

-Suresh

the
)
link

---

From: [email-masked]
Date: Mon, 15 Oct 2001 18:00:38 +0530

Are there any conditions that the server has to check before sending an
unicast option, other than scope of the client's address. ( The draft talks
about "sufficient scope" only  20.11 in draft 20d).
If not,
     (a) Is there difference between the client verifying its scope to
reach the  server's address and server verifying the scope of the client
address to send the unicast option?.   if this is the case may i know what
are they. Does the example given by you (cable modem) considers this case?.

if yes:
     what are the other checks that the server has to perform.

If answer to (a) is "no difference", why does a client need to receive
"unicast option" from the server? instead of checking it at client's side.
-suresh

>The reason for having the SERVER send the unicast option and tell the
client that it is OK is to avoid some of the >problems that exist today
with client renewals that don't go through relay options (such as in cable
modem >systems). Since the client/server communicate directly (in DHCPv4),
the relay can't add the relay-agent options to >the client's messages. If
this isn't in the -20 draft, perhaps we should add something about it (just
so people in >the future won't need to ask why).
>
>I think that a client MUST NOT unicast a message unless it has received
the unicast option from that server. (As >Ralph indicated, I'm not sure it
is required that a server MUST check that a message was multicast unless it
told >the client it was OK to use the unicast option; however, a server is
free to drop those datagrams if it wishes. >Hence, for a client to get
service from all servers, it will need to honor the required behavior).
>Ralph Droms <[email-masked]> on 10/12/2001 03:36:08 PM>
>
>>client to check that the server is on the same link>
>
>

-Suresh

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Mon, 15 Oct 2001 08:56:10 -0500

I don't think the server is responsible for knowning all about the client - it can't. Therefore, the server simply sends the option as a matter of configuration policy (ie, no cable modems involved on those links and hence no reason why client can't unicast). It is up to the client to determine whether it CAN unicast.

So, to the server it is a matter of configuration.

To the client, it has to make the decision as to whether to unicast to the server. It can make this decision based on:
- Receipt of the option from the server
- Conditions of its addresses (does it have an address of sufficient scope). For example, if the server is on the same link, it can always unicast (using the link local). If the server is off-link, it can only unicast should it have an address available of sufficient scope (note that some links may have autoconfigured AND managed (DHCP) addresses).

I don't understand why this is such a big deal?

Please understand that multicasting for DHCPv6 is not like broadcasting. Only those hosts with an interest in that functionality (DHCP relays and servers) need to receive these packets.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, October 15, 2001 8:31 AM
To: Bernie Volz (EUD); Ralph Droms
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [dhcwg] Rev of DHCPv6 spec

if yes:

-Suresh

---

From: Ralph Droms <[email-masked]>
Date: Mon, 15 Oct 2001 10:45:23 -0400

The relevant text for Request messages in the -20d rev is:

    If the client has a source address that can be used by the server
    as a return address and the client has received a Client Unicast
    option (section 20.11) from the server, the client SHOULD unicast
    the Request message to the server.  Otherwise, the client sends
    the Request message to the All_DHCP_Agents multicast address.

To clarify and emphasize the requirement for multicast, I suggest the 
following text:

    If the client has a source address that can be used by the server
    as a return address and the client has received a Client Unicast
    option (section 20.11) from the server, the client SHOULD unicast
    the Request message to the server.  Otherwise, the client MUST send
    the Request message to the All_DHCP_Agents multicast address.

    DISCUSSION:

       Use of multicast and relay agents enables the inclusion of
       relay agent options in all messages sent by the client.  The
       server should enable the use of unicast only when relay
       agent options will not be used.

Is this replacement text sufficiently clear?

- Ralph

At 09:08 PM 10/14/2001 -0500, Bernie Volz (EUD) wrote:

>client that it is OK is to avoid some of the problems that exist today 
>modem systems). Since the client/server communicate directly (in DHCPv4), 
>the relay can't add the relay-agent options to the client's messages. If 
>this isn't in the -20 draft, perhaps we should add something about it 
>(just so people in the future won't need to ask why).
>
>the unicast option from that server. (As Ralph indicated, I'm not sure it 
>is required that a server MUST check that a message was multicast unless 
>it told the client it was OK to use the unicast option; however, a server 
>is free to drop those datagrams if it wishes. Hence, for a client to get 
>From: [email-masked] 
>[<mailto:[email-masked]>mailto:[email-masked]]
> ><http://www.dhcp.org/dhcpv6.tty>http://www.dhcp.org/dhcpv6.tty  I plan 
> to submit this draft of the spec to
><http://www1.ietf.org/mailman/listinfo/dhcwg>http://www1.ietf.org/mailman/listinfo/dhcwg 
>
>
>
>
><http://www1.ietf.org/mailman/listinfo/dhcwg>http://www1.ietf.org/mailman/listinfo/dhcwg 
>

---

From: "Thirumalesh Bhat" <[email-masked]>
Date: Mon, 15 Oct 2001 09:33:16 -0700

Some comments on the latest draft below:

a) Section 10.1 - DUIDs
	Do we have an upper limit on the DUID length? I thought we had a
prior thread regarding DUIDs where it was agreed that the upper limit on
DUID length will help the server implementation. 

b) Section 15.1.2 Creation of Solicit messages:
   Can the client send a solicit message without an IA. An example would
be for a client to check the servers that can provide the options it
needs.	
c) Section 15.1.3 Transmission of Solicit Messages:
The draft says "The client sends the Solicit message to the
All_Dhcp_Agents" multicast address". How would this work if the DHCP
Server is on the same segment as the client? Probably the DHCP server
should bind to "ALL_Dhcp_Agents" as well as "All_DHCP_Servers" address.

d) Section 15.1.4: Receipt of Advertise Messages:
Is there a recommendation on how long a client should wait to collect
response from all the responding servers or is this implementation
specific?

e) Section 15.2.2 - Creation and transmission of Advertise messages:
third paragraph:
What happens if the client doesn't send an IA - does the server ignore
the packet?

f) Section 16.1.5 
When a client receives AddrUnavail status should it create a new IA? I
would think that the client should create a new IA if it receives
NoPrefixMatch status back.

Not sure the reason for the use of "ConfNoMatch" status - I think the
other error codes can pretty much tell the client what to do. Same goes
for the error codes "RenwNoMatch", "RebdNoMatch".

g) Section 16.2.2 Receipt of confirm messages:

"If the server cannot determine if the info in the confirm message is
valid or invalid, the server MUST NOT send a reply to the client". 

This statement is a bit confusing. A server might be able to figure out
that the client request is not valid as far as it is confirmed but it
cant verify if it is invalid to other servers. 

May be the server should send its error message anyway and the client
should wait for a certain period of time ( as it does for advertise
messages ) to check if there is a server that can serve its needs.

h) Section 17.1.1 - Creation and transmission of reconfigure-init
messages.

Has the possibility of sending reconfigure-init to a relay been removed
so that the relay can unicast to the clients that it is aware of?

i) Section 20.1 - Format of DHCP Options.
We should be explicit in saying that the option code and option length
are in network byte order.

j) I feel that we should also add "Vendor class" and "User class"
options to the draft. I can prepare the text for these two options if
desired.

thx

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]] 
Sent: Wednesday, October 10, 2001 7:02 PM
To: [email-masked]
Subject: [dhcwg] Rev of DHCPv6 spec

I've finished another rev of the DHCPv6 spec (-20d), which is available
at 
http://www.dhcp.org/dhcpv6.tty  I plan to submit this draft of the spec
to 
the IETF for publication on 10/12.  The list of issues addressed by this

draft is included below; these issues were discussed at the DHC WG
meeting 
in London (8/2001).  The -20d draft does not include any changes related
to 
IAs.  The changes related to IAs will appear in the next published rev
of 
the draft.

- Ralph

=====

   WG consensus: yes

* Add "NAK" function:

   WG consensus: yes

   WG consensus: yes

   WG consensus: yes

   WG consensus: yes

   WG consensus: Yes

---

From: Ralph Droms <[email-masked]>
Date: Mon, 15 Oct 2001 13:36:46 -0400

Thanks for your review and feedback.  I haven't sent in the -20 rev to the 
IETF for publication, so I can still make some changes based on your 
comments.  I'll respond to your comments in line...

- Ralph

>DUID length will help the server implementation.

Yes - I think we put an upper limit of 256 bytes on a DUID.  I'll add that
restriction to the spec.

>be for a client to check the servers that can provide the options it

Yes - I'll make sure that it's clear that a client can send a Solicit
without IAs.

>should bind to "ALL_Dhcp_Agents" as well as "All_DHCP_Servers" address.

Turns out the naming of the of these multicast addresses is potentially
confusing; both servers and relay agents are members of the
All_DHCP_Agents multicast group:

       All_DHCP_Agents address:  FF02::1:2 This link-scoped multicast
                  address is used by clients to communicate with the
                  on-link agent(s) when they do not know the link-local
                  address(es) for those agents.  All agents (servers and
                  relays) are members of this multicast group.

>response from all the responding servers or is this implementation

The intention is that SOL_TIMEOUT defines the time during which the
client collects responses.  If that's not clear, we'll need to fix
the text:

    The client transmits the message according to section 13, using the
    following parameters:

       IRT   SOL_TIMEOUT

       MRT   SOL_MAX_RT

       MRC   0

       MRD   0

    The mechanism in section 13 is modified as follows for use in the
    transmission of Solicit messages.  The message exchange is not
    terminated by the receipt of an Advertise before SOL_TIMEOUT has
    elapsed.  Rather, the client collects Advertise messages until
    SOL_TIMEOUT has elapsed.  The first RT MUST be selected to be
    strictly greater than SOL_TIMEOUT by choosing RAND to be strictly
    greater than 0.

    A client MUST collect Advertise messages for SOL_TIMEOUT seconds,
    unless it receives an Advertise message with a preference value
    of 255.  The preference value is carried in the Preference option
    (section  20.5).  Any Solicit that does not include a Preference
    option is considered to have a preference value of 0.  If the client
    receives an Advertise message with a preference value of 255, then
    the client MAY act immediately on that Advertise message without
    waiting for any more additional Advertise messages.

>What happens if the client doesn't send an IA - does the server ignore

I guess the answer to this question is related to the answer to your
question (b).  If a client is allowed to send a Solicit with no IAs,
the text in 15.2.2 must be clarified to allow a server to respond with
an Advertise with no IAs.  The server can't generate IAs for the client;
all it can do is fill in IAs supplied by the client.

>NoPrefixMatch status back.

The client doesn't have to create a new IA; it just has to find a different
server that will agree to put addresses in the IA.

>for the error codes "RenwNoMatch", "RebdNoMatch".

The "*NoMatch" status codes are the analog of DHCPNAK in DHCPv4;
a mechanism through which the server can tell the client that
the client needs to recontact the server for new configuration
information.

>messages ) to check if there is a server that can serve its needs.

The spec presumes that the servers are all configured consistently,
so the presumption is the client won't get some ACK and some NAK
responses.  The text you quote allows for the fact that a server
may get a Confirm in which the addresses are appropriate for the
link from which the message was received, but the server doesn't
have a binding for the client to confirm that the addresses in
the IA have been specifically assigned to the client.

>so that the relay can unicast to the clients that it is aware of?

There is no mechanism through which a relay agent can forward a
reconfigure-init to multiple clients.

>are in network byte order.

OK.

>options to the draft. I can prepare the text for these two options if

OK, I'll accept your offer to write up text for "Vendor class" and
"User class".  Thanks!