Subject: [Dhcpv6bis] [dhcpv6bis] #123 (XML 3315): Clarify NotOnLink handling (18.1.8)

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Mon, 13 Oct 2014 16:17:49 -0000

#123: Clarify NotOnLink handling (18.1.8)

 Jinmei, during review of draft-ietf-dhc-dhcpv6-stateful-issues-07 raised
 an issue with the following text in RFC 3315, Section 18.1.8:

      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 17, and client-initiated
      configuration as described in section 18.

 The issue was:

   Does this mean, if the client has bindings of
   multiple IAs, it should (effectively) abandon all of the bindings
   and establish new bindings for all of the IAs starting from Solicit?
   If so, it makes sense to me, but it's not really clear from the
   text, and I suggest clarifying that point.

 Perhaps:

 1. The 18.1.8 text should indicate that the client must stop using the
 addresses (note that this doesn't apply to PD as PD requires use of
 Rebind, not Confirm). It may be worth clarify the NotOnLink status for all
 messages as Renew isn't directly covered in this text?

 2. In the Solicit section, we can clarify that when a client sends a
 Solicit, it MUST not be using any of the addresses or delegated prefixes
 for the bindings included in the Solicit.

-- 
----------------------------+-----------------
 Reporter:  [email-masked]  |      Owner:
     Type:  task            |     Status:  new
 Priority:  P1 blocker      |  Milestone:
Component:  XML 3315        |   Keywords:
----------------------------+-----------------

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/123>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>