Subject: [dhcwg] draft-ietf-dhc-dhcpv6-stateful-issues - Section 4.2. Placement of Status Codes

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 25 May 2014 13:43:26 +0000

Rob Shakir from BT recently raised (to the authors) the issue of the placement of status codes for Advertise messages based on some operational experience. A few of us (Ole Troan, Marcin Siodelski, and Tomek Mrugalski) discussed this via email. After our discussion, we are taking the conclusion to the mailing list for feedback - please read and provide your feedback (concerns/objections or support for the change).

Some Background:

The original reason for keeping the RFC 3315 Advertise behavior with respect to IA_NA/IA_TA requests and NoAddrsAvail status code option  was to avoid backwards compatibility issues (i.e., with existing clients). However, during this discussion it turns out that there are already servers in the field that, strictly speaking, weren't following RFC 3315 Advertise behavior and only returning the NoAddrsAvail Status Code option encapsulated in the IA_* option (not at the global scope). Because at least some of these servers are freely and widely available, we assume that if there had been issues, someone would have reported the problem.

Proposed Change:

Thus, we are planning to update the next revision of draft-ietf-dhc-dhcpv6-stateful-issues to change section 4.2, Placement of Status Codes, which will change RFC 3315 behavior and have the NoAddrsAvail status in Advertise messages move into the IA_* options rather than being a global scope option (i.e., follow how a Reply is formatted with respect to Status Code options).

More Detailed Information:

The possible Advertise responses when IA_NA and IA_PD are requested and one or the other or both are not available are (ignoring other errors or issues):

1. IA_NA - no addresses available, IA_PD - no prefix available

                A. Global scope status code with NoAddrsAvail, no IA_NA option, IA_PD with status code of NoPrefixAvail

                B. IA_NA with status code of NoAddrsAvail, IA_PD with status code of NoPrefixAvail

                C. (b) but also with global scope status code with NoAddrsAvail

2. IA_NA - no addresses available, IA_PD - assigned

                A. Global scope status code with NoAddrsAvail, no IA_NA option, IA_PD with prefix

                B. IA_NA with status code of NoAddrsAvail, IA_PD with prefix

                C. (b) but also with global scope status code with NoAddrsAvail

3. IA_NA - assigned, IA_PD - no prefix available

                A. IA_NA with address, IA_PD with status code of NoPrefixAvail

Note that if an IA_PD is not included, there are still 3 possible responses for just IA_NA:

                A. Global scope status code with NoAddrsAvail, no IA_NA option

                B. IA_NA with status code of NoAddrsAvail

                C. (b) but also with global scope status code with NoAddrsAvail

In all cases, if multiple IA_NA, multiple IA_PD, and multiple IA_TA options are present, just extend appropriately.

And, we are, in all cases, recommending that form B. in the above is used.

Proposed Revised Section 4.2 Text:

The revised 4.2 text might thus end up being (the first 2 paragraphs are exactly what is currently in the document, the rest of the section will be replaced):

++ START OF REVISED SECTION 4.2:

4.2. Placement of Status Code

In Reply messages IA specific status codes (i.e., NoAddrsAvail, NotOnlink, NoBinding, NoPrefixAvail) are encapsulated in the IA option.  In Advertisement messages the Status Code option with the NoAddrsAvail code is in the "global" scope.  That makes sense when the failure case is fatal.  With the introduction of multiple IA option types, there might be a case where a server is not willing to offer addresses, but might be willing to offer other stateful option types.

While a Status Code option is implicitly bound to a specific type of IA, e.g. NoPrefixAvail is only applicable to IA_PD and NoAddrsAvail is only applicable to IA_NA/IA_TA, it may be problematic to make this assumption for all status codes.  Ideally the Status Code option should be encapsulated in the IA option for all DHCP messages.  This makes Advertisement messages equal to Reply messages.

However, how a server formats the Advertise message when addresses are not available has been a point of some confusion and implementations seem to vary.

Therefore, the Proposed solution is:

Clients MUST be prepared to handle each of the following Advertise messages formats when there are no addresses available (even when no IA_PD was in the Solicit):

1. Advertise containing just a global scope status code option (of NoAddrsAvail) and no IA_NAs/IA_TAs.

2. Advertise containing the IA_NAs and/or IA_TAs with encapsulated status code option (of NoAddrsAvail) and no global scope status code option.

3. Advertise containing a global scope status code option (of NoAddrsAvail) and IA_NAs and/or IA_TAs with a status code option (of NoAddrsAvail).

Servers MUST use the encapsulated status code option (of NoAddrsAvail) in an IA_NA/IA_TA and not a global scope status code option (of NoAddrsAvail) when no addresses will be assigned (2 in the above list). This means that the Advertise response matches the Reply response with respect to the handling of the NoAddrsAvail status.

Replace the following paragraph in RFC 3315, section 17.2.2:

   If the server will not assign any addresses to any IAs in a

   subsequent Request from the client, the server MUST send an Advertise

   message to the client that includes only a Status Code option with

   code NoAddrsAvail and a status message for the user, a Server

   Identifier option with the server's DUID, and a Client Identifier

   option with the client's DUID.

With:

   If the server will not assign any addresses to an IA in a

   subsequent Request from the client, the server MUST include

   the IA in the Advertise message with no addresses in the IA

   and a Status Code option in the IA containing status code

   NoAddrsAvail.

END OF SECTION 4.2 --

** ACTION NEEDED FROM YOU:

Does anyone have any concerns or objections regarding this change?

- Bernie