Subject: [Dhcpv6bis] Review request - ticket #140

From: Marcin Siodelski <[email-masked]>
Date: Mon, 19 Oct 2015 18:20:59 +0200

Hi,

I was working on ticket
http://trac.tools.ietf.org/group/dhcpv6bis/ticket/140 aiming to put this
change in before the draft submission cut off today. But, I realized
that this change may be a bit tricky and thus may require a review
before I actually merge it to the document.

Please read the text below and indicate any issues you see. It would be
great to see responses today like: "Yes, it is fabulous, let's put it in
as is". But, I don't actually count on it very much. :-)

Marcin

---- Your review starts here ----

19.1.8.  Receipt of Reply Messages

   Upon the receipt of a valid Reply message in response to a Solicit
   (with a Rapid Commit option), Request, Confirm, Renew, Rebind, or
   Information-request message, the client extracts the configuration
   information contained in the Reply.  The client MUST process the
   information received in the Reply message from the server in the
   following order:

   -  Process any IA options in the Reply message.

   -  Process SOL_MAX_RT and INF_MAX_RT options as described in
      Section 23.23 and Section 23.24 respectively.

   -  Process top-level status code in the Reply message.

   The client SHOULD perform duplicate address detection [RFC4862] on
   each of the received addresses in any IAs, on which it has not
   performed duplicate address detection during processing of any of the
   previous Reply messages from the server.  The client performs the
   duplicate address detection before using the received addresses for
   the traffic.  If any of the addresses are found to be in use on the
   link, the client sends a Decline message to the server for those
   addresses as described in Section 19.1.7.

   If the Reply was received in response to a Solicit (with a Rapid
   Commit option), Request, Renew, or Rebind message, the client updates
   the information it has recorded about IAs from the IA options
   contained in the Reply message:

   -  Record T1 and T2 times.

   -  Add any new leases in the IA option to the IA as recorded by the
      client.

   -  Update lifetimes for any leases in the IA option that the client
      already has recorded in the IA.

   -  Discard any leases from the IA, as recorded by the client, that
      have a valid lifetime of 0 in the IA Address or IA Prefix option.

   -  Leave unchanged any information about leases the client has
      recorded in the IA but that were not included in the IA from the
      server.

   Management of the specific configuration information is detailed in
   the definition of each option in Section 23.

   The client examines the status code in each IA individually.  If the
   client receives a NoAddrsAvail and/or NoPrefixAvail status code, the
   client has received no usable addresses and/or delegated prefixes in
   the IA.

   If the client can operate with the addresses and prefixes obtained
   from the server, the client uses the addresses, delegated prefixes,
   and other information from any IAs that do not contain a Status Code
   option with the NoAddrsAvail or NoPrefixAvail status code.  The
   client MAY include the IAs for which it received the NoAddrsAvail or
   NoPrefixAvail status code, with no addresses or prefixes, in
   subsequent Renew and Rebind messages sent to the server, to retry
   obtaining the addresses or prefixes for these IAs.

   If the Reply message contains any IAs, but the client finds no usable
   addresses and/or delegated prefixes in any of these IAs, the client
   may either try another server (perhaps restarting the DHCP server
   discovery process) or use the Information-request message to obtain
   other configuration information only.

   Whenever a client restarts the DHCP server discovery process or
   selects an alternate server, as described in Section 18.1.3, the
   client SHOULD stop using all the addresses and delegated prefixes for
   which it has the bindings and try to obtain all required leases from
   the new server.  This facilitates the client using a single state
   machine for all bindings.

   When the client receives a Reply message in response to a Renew or
   Rebind message, the client:

   -  sends a Request message if any of the IAs in the Reply message
      contains the NoBinding status code.  The client places IA options
      in this message for only those IAs for which the server returned
      the NoBinding status code in the Reply message.  The client
      continues to use other bindings for which the server did not
      return an error.

   -  sends a Renew/Rebind if any of the IAs are not in the Reply
      message, but in this case the client MUST limit the rate at which
      it sends these messages, to avoid the Renew/Rebind storm.

   -  otherwise accepts the information in the IA.

   When the requesting router receives a valid Reply message, for each
   IA_PD the delegating router assigns a subnet from each of the
   delegated prefixes to each of the links to which the associated
   interfaces are attached.

   When the client receives a valid Reply message in response to a
   Release message, the client considers the Release event completed,
   regardless of the Status Code option(s) returned by the server.

   When the client receives a valid Reply message in response to a
   Decline message, the client considers the Decline event completed,
   regardless of the Status Code option(s) returned by the server.

   When the client receives a NotOnLink status from the server in
   response to a Confirm message, the client performs DHCP server
   solicitation, as described in Section 18, and client-initiated
   configuration, as described in Section 19.  If the client receives
   any Reply messages that do not indicate a NotOnLink status, the
   client can use the addresses in the IA and ignore any messages that
   indicate a NotOnLink status.

   When the client receives a NotOnLink status from the server in
   response to a Solicit (with a Rapid Commit option) or a Request, the
   client can either re-issue the message without specifying any
   addresses or restart the DHCP server discovery process (see
   Section 18).

   If the client receives a Reply message with a status code containing
   UnspecFail, the server is indicating that it was unable to process
   the message due to an unspecified failure condition.  If the client
   retransmits the original message to the same server to retry the
   desired operation, the client MUST limit the rate at which it
   retransmits the message and limit the duration of the time during
   which it retransmits the message (see Section 14.1).

   When the client receives a Reply message with a Status Code option
   with the value UseMulticast, the client records the receipt of the
   message and sends subsequent messages to the server through the
   interface on which the message was received using multicast.  The
   client resends the original message using multicast.

   The client MAY choose to report any status code or message from the
   Status Code option in the Reply message.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 19 Oct 2015 17:32:04 +0000

I think it would be best to wait.

While a quick read doesn't turn up major concerns, I think there are some things that we could clean up.

Also, the deadline is fast approaching (now only 7 or so hours to go), that I think it best to submit 'as is'.

- Bernie

-----Original Message-----
From: Dhcpv6bis [mailto:[email-masked]] On Behalf Of Marcin Siodelski
Sent: Monday, October 19, 2015 12:21 PM
To: [email-masked]
Subject: [Dhcpv6bis] Review request - ticket #140

Hi,

I was working on ticket
http://trac.tools.ietf.org/group/dhcpv6bis/ticket/140 aiming to put this change in before the draft submission cut off today. But, I realized that this change may be a bit tricky and thus may require a review before I actually merge it to the document.

Please read the text below and indicate any issues you see. It would be great to see responses today like: "Yes, it is fabulous, let's put it in as is". But, I don't actually count on it very much. :-)

Marcin

---- Your review starts here ----

_______________________________________________
Dhcpv6bis mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcpv6bis

---

From: Marcin Siodelski <[email-masked]>
Date: Mon, 19 Oct 2015 20:17:33 +0200

Ok, I am also inclined to not commit this change in rush. Tomek, from my
perspective you're welcome to publish the doc as is.

Marcin

---

From: Tomek Mrugalski <[email-masked]>
Date: Mon, 19 Oct 2015 20:29:42 +0200

Ok, I'm on to it.