Re: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00

[Stephen Jacob <[e-mail]>]

This is actually extremely interesting to me. I believe there remains
even further confusion with the cited section. I will explain the
issues I ran into recently below the quoted context!

On Thu, May 24, 2012 at 02:29:52PM -0500, Bernie Volz (volz) wrote:
> Comments below (BV>).
...
> 1.)Section 3.1
> 
>    Replace Section 17.1.3
> <http://tools.ietf.org/html/draft-troan-dhc-dhcpv6-stateful-issues-00#se
> ction-17.1.3> : (existing errata)
>
>       The client MUST ignore any Advertise message that includes a  Status
>       Code option containing the value NoAddrsAvail, with the exception
>       that the client MAY display the associated status message to the
>       user.
>
>    With:
>
>       The client MUST ignore any IAs in an Advertise message that
>       includes a Status Code option containing the value NoAddrsAvail,
>       with the exception that the client MAY display the associated
>       status message to the user. An Advertise message without any IA
>       options MUST be ignored.
>
> Is this only applicable to IA_NA.? I guess in case client sends SOLICIT
> with both IA_NA and IA_PD. Then in that case I guess we should mention
> "NoPrefixAvail" as well.
>
> BV> It is applicable to IA_NA and IA_TA as those are the cases that end
> up with the Status Code option of NoAddsAvailable in the "main" part of
> the message - not in each IA_NA/IA_TA. (IA_PD puts the NoPrefixAvail
> Status Code option in the IA_PD itself. This is what we wish had been
> specified for IA_NA/IA_TA but was not.)

Now, here's where it gets even more convoluted:

(I don't know if deconfusing this convolutedness is in scope for this
draft, but I'd very much like any opinions/solutions from other
implementors even if it is not).

-----

As mentioned above, in RFC 3315, section 17.1.3, it says:

  "The client MUST ignore any Advertise message that includes a Status
   Code option containing the value NoAddrsAvail, with the exception
   that the client MAY display the associated status message to the
   user."

and in section 17.2.2 it says:

  "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."

In RFC 3633, section 11.2, it says:

  "If the delegating router will not assign any prefixes to any IA_PDs
   in a subsequent Request from the requesting router, the delegating
   router MUST send an Advertise message to the requesting router that
   includes the IA_PD with no prefixes in the IA_PD and a Status Code
   option in the IA_PD containing status code NoPrefixAvail ..."

This is different from IA_NA/IA_TA handling in that if you are not
going to grant leases on addresses (as opposed to prefixes), you can
omit the IA_NA/IA_TA options and just include Status Code NoAddrsAvail
at the top level.

RFC 3633 does not appear to say anything about status code in the top
level options (outside IA_PD options -- neither specifying any new
behaviour nor overriding/contradicting RFC 3315) other than in section
12.1 where it says:

  "Handling of Status Codes options in received Reply messages is
   described in section 18.1.8, "Receipt of Reply Messages" of RFC 3315.
   The NoPrefixAvail Status Code is handled in the same manner as the
   NoAddrsAvail Status Code."

... which by reference to RFC 3315 implies behaviour matching RFC 3315.
RFC 3315 section 18.1.8 does not explicitly address the use of the
Status Code option at the top level. One might assume that, then,
behaviour specified elsewhere in RFC 3315 would apply, but would that
be a correct assumption?

Reading between the lines, I might expect that since a DHCP server
MUST send IA_PD containing Status Code NoPrefixAvail when it is not
going to grant a lease on a prefix that:

 (a) that should supplant sending a Status Code at the top level, so
     one should omit Status Code in the top level options; or
 (b) another possibility is that one should also include Status Code
     at the top level, but with value NoPrefixAvail; or
 (c) one should, in fact, literally follow RFC 3315 and since no
     *addresses* will be offered, include Status Code at the top
     level with value NoAddrsAvail in spite of also including the
     IA_PD option with Status Code NoPrefixAvail.

The problem with option C is that ... let's say a Solicit contains
only an IA_PD (no IA_NA/IA_TA) and the DHCP server responds with a
valid prefix for the IA_PD option ... by a strict reading of RFC
3315 along side RFC 3633, since no *addresses* are being offered,
there should be a Status Code of NoAddrsAvail at the top level. I'm
nearly certain that that is not intended behaviour, since by a strict
reading of the two RFCs a DHCP client should then ignore the valid
IA_PD option.

What to do when the DHCP server receives IA_NA and IA_PD, does not
grant a lease on an address to the former and does grant a lease on
a prefix to the latter is even muddier. Logic suggests to me in that
case no top-level Status Code. Only one in the IA_NA option. Strict
reading of the RFCs does not *appear* to support this belief, however.

Since a compliant DHCP client must ignore messages containing Status
Code NoAddrAvail at the top level (RFC 3315), and due to the MUST on
inclusion of the IA_PD option (with Status Code NoPrefixAvail) (RFC
3633), I _suspect_ that the _intention_ is that implementations
should instead omit Status Code at the top level in this case, or
should use the value NoPrefixAvail (which seems redundant, with the
mandatory inclusion of IA_PD with its own Status Code option).

Our DHCP implementation does option C at present. I need to figure
out whether that is correct and, if not, change the implementation.

I expect this may be of interest to other implementors, too.

Regards,
Stephen
-- 
 Stephen Jacob | [e-mail] | [phone]
 Nominum, Inc. |  http://www.nominum.com/  | [phone]