[dhcwg] Please review version -07 of draft-ietf-dhc-dhcpv6-stateful-issues

[Marcin Siodelski <[e-mail]>]

Hi All,

The version -07 of the draft-ietf-dhc-dhcpv6-stateful-issues is now
available at:

http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-stateful-issues/

This version introduces numerous changes to the draft to address "New
issues" presented on IETF in Toronto:
http://www.ietf.org/proceedings/90/slides/slides-90-dhc-2.pdf. It also
addresses some issues raised on the mailing list. Thanks to Jinmei, Cong
and others for their interest and reviews.

In the new version we try to clarify the scope of this work - the
"Introduction" has been extended to state that the goal of this work is
to address the issues related to coexistence of IA_NA and IA_PD and we
get away from attempts to provide a generalized text for all existing IA
types (including IA_TA) and future IAs, as it is impossible to know how
they will look like.

The previous version of the draft provided a "unified" text (for
Renew/Rebind processing) which was intended to be used for the
RFC3315bis work. The new version removes the "unified" text to avoid
confusion that the draft is intended to provide generalized approach for
all IA types. Instead, the new text provides respective updates to
RFC3315 and RFC3633 for IA_NA and IA_PD processing in a single DHCP session.

The more detailed list of changes between version -06 and -07 is given
below.

1. The draft title has been changed from "Issues with multiple stateful
DHCPv6 options" to "Issues and Recommendations with Multiple DHCPv6
Stateful Options", as in fact the draft not only identifies the issues
but also proposes specific solutions.

2. The Introduction has been extended to clarify the scope of the draft
as mentioned above.

3. Use "stateful options" and "resources" where appropriate.

4. Provided the updates to relevant sections of RFC3315 to mandate that
the server MUST set the T1/T2 times to the same values across all IA
options sent to a client.

5. Removed the "unified" text (intended for RFC3315bis) from the
Renew/Rebind sections. The current text only provides respective updates
for RFC3315 and RFC3633.

6. With updated Renew/Rebind processing the server returns NoAddrsAvail
status code for the IA, when the server is configured to create new
bindings for the renewing clients but the binding cannot be created
(e.g. address pool exhausted or other reasons). If the server is not
configured (or updated) to create new bindings in the Renew/Rebind time,
the NoBinding is returned which falls back to the original behavior.

7. Reworked section 18.1.8. Receipt of Reply Message in RFC3315, mainly
to account for the NoAddrsAvail/NoPrefixAvail being returned by the
server in response to Renew/Rebind.

8. Updated 18.1.8 with a note that the client must use the shortest
T1/T2 time from the same IA across all IA options to facilitate the
renewal of all bindings at the same time.

9. Updated 18.1.8. with a note that client should follow the
retransmission procedure if it finds that the IA is not in the Reply
message from the server sent in response to Renew/Rebind. The original
text stated that the client should send Renew/Rebind if the IA is not
present in the server's response. This resulted in the Renew/Rebind storm.

9. Client SHOULD (relaxed from a MUST) initiate Confirm when it may have
moved to a new link as the client may have determined whether it moved
or not by other means. A reference to RFC6059 has been added.

Please provide your comments. Note that this work builds the ground for
the RFC3315bis, so your interest is important.

Marcin