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

["Bernie Volz (volz)" <[e-mail]>]

If a client requests both IA_NA and IA_PD, here is what our server
(Cisco Prime Network Registrar does):

- If neither are possible:
	- Top level option has Status Code with NoAddrsAvail
	- IA_PA has Status Code with NoPrefixAvail
- If only IA_NA possible:
	- IA_NA has binding information
	- IA_PD has Status Code with NoPrefixAvail
- If only IA_PD possible:
	- Top level option has Status Code with NoAddrsAvail
	- IA_PD has binding information

My read of RFC 3315 says that the above is correct with respect to
IA_NA/IA_TA. (Note that you can replace IA_NA with IA_TA in the above,
or add IA_TA.) BTW, you would NEVER include NoAddrsAvail if no
IA_NA/IA_TA options.

My read of RFC 3633 says that the above is correct with respect to
IA_PD.

A client should only treat a message with Status Code with NoAddrsAvail
to have "failed" with respect to IA_NA/IA_TA. Not, IA_PD. This is
exactly what we are suggesting the behavior to be in the draft.

While I agree that this Status Code difference is rather odd and I had
pushed for moving the Status Code with NoAddrsAvail into the IA_NA/TA
options at the time of RFC 3315, but it didn't happen. (Think of the
case where IA_NA and IA_TA are included but server only gives out IA_NA
... in this case, in Advertise IA_NA has bindings and IA_TA is empty.
That seemed a bit weird to me - if empty (no bindings) was OK, why did
we need a Status Code? And why only report the status if ALL IA_NA/IA_TA
fail? I think RFC 3633 got it right as to where the status should be.)

And, I think it too late to change this because it would likely break
many existing client implementations (such as those that only do
IA_NA/TA). We considered this when writing the ID, but felt it too
dangerous to existing implements to propose such a change (to move
NoAddrsAvail into IA_NA/IA_TA instead of at top level).

BTW: I can't say how well the above server implementation plays with all
clients because frankly it is likely not that usual for a client to
request IA_NA/TA and IA_PD and have a server that only supports one. I
can say we haven't heard of any complaints and the server is in use for
DHCPv6 in a lot of places.


You statement:

>Since a compliant DHCP client must ignore messages containing Status
Code NoAddrAvail at the top level (RFC 3315),

This is, IMHO, only with respect to the IA options specified in RFC
3315.

- Bernie

-----Original Message-----
From: Stephen Jacob [mailto:[e-mail]] 
Sent: Friday, May 25, 2012 2:38 AM
To: Bernie Volz (volz)
Cc: Gaurav Halwasia (ghalwasi); [e-mail]
Subject: Re: [dhcwg] Comments on
draft-troan-dhc-dhcpv6-stateful-issues-00

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 
> BV> 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]