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

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 24 May 2012 14:29:52 -0500

Hi and thanks for reading and commenting!

Comments below (BV>).

-          Bernie

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Gaurav Halwasia (ghalwasi)
Sent: Thursday, May 24, 2012 11:03 AM
To: [email-masked]
Subject: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00

I have read this informational draft and I have couple of comments so
far.

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.)
 
2.) Section 3.6
   Proposed solution: the client should keep a single session with the
   server.  The client should continue with the IA_ options received,
   while continuing to request the other IA options in subsequent
   messages to the server.  That means continue to include the empty
   unanswered IAs in subsequent Renew and Rebind messages.
 
I believe, it is possible that a particular server is willing to offer
only a subset of IA_'s which has been requested. In that case, what's
the use of including the other IA_ in the subsequent renew/rebind. As in
this case server will anyway only renew only one IA_. ? Are we
suggesting that a client at any given point of time should only be
talking to one server after the advertise is accepted.
 
BV> What harm is there in continuing to include this in the subsequent
operations? If the server's policy prohibits returning addresses or
delegated prefixes for these other IA types, there is no harm. The main
assumption is that clients are in a single administrative domain and
thus talking to another server will be unlikely to help (except of
course in the case of misconfiguration, but better that the issue is
detected early and dealt with).
 
-          Bernie

---

From: Stephen Jacob <[email-masked]>
Date: Thu, 24 May 2012 23:37:47 -0700

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!

> Comments below (BV>).
...
>       The client MUST ignore any Advertise message that includes a  Status

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 | [email-masked] | +1 650 381 6051
 Nominum, Inc. |  http://www.nominum.com/  | +1 650 381 6000

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Fri, 25 May 2012 13:40:08 +0530

Thanks Bernie for clarification.
 
<snip>

</snip>

[Gaurav] I don't see any harm in including not assigned IA_'s in
subsequent renew and rebind.  I wanted to clarify that with this text,
we implicitly mean that client can only be associated with one server at
a time.  So we are saying that we can not have a deployment where 2
dhcpv6 servers (one doing IA_NA and other doing IA_PD) can be present.
Also what if client first did IA_NA and at any later point of time it
wants to do IA_PD. 

1.       Does it need to wait for the next renew time to get expired
before it can ask IA_PD along.? 

2.       So are we saying that it should not send SOLICIT for IA_PD
anytime in between.? If we are still allowing SOLICIT, should it only
accept ADVERTISE from the server (which initially gave IA_NA) 

Thanks,

Gaurav

From: Bernie Volz (volz) 
Sent: Friday, May 25, 2012 1:00 AM
To: Gaurav Halwasia (ghalwasi); [email-masked]
Subject: RE: [dhcwg] Comments on
draft-troan-dhc-dhcpv6-stateful-issues-00

Comments below (BV>).

-          Bernie

1.)Section 3.1

   Replace Section 17.1.3

   With:

 
 
2.) Section 3.6

 
-          Bernie

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 25 May 2012 05:29:03 -0500

BTW - we really should be referencing
draft-ietf-dhc-dhcpv6-stateful-issues-00. I hope that is the draft that
you looked at.

> I wanted to clarify that with this text, we implicitly mean that
client can only be associated with one server at a time. 

We are pretty much saying that, per interface, a client is associated
with one server. There isn't anything to prohibit multiple servers, but
without some additional work (which I mentioned at the DHC WG meeting in
Paris) to support multiple administrative domains, it is not possible
for a client to know whether it is in ONE or MULTIPLE administrative
domains. And, in probably 99.9% of the cases, it is in a SINGLE
administrative domain. So, let's make sure that things work well in that
environment before worrying about the 0.1% (perhaps I should have said
99% and 1% based on the recent "Occupy" movements).

Yes. Best practice is that it should renew early and renew what it has
and also ask for the IA_PD. But, the client may also "restart" by doing
a Solicit (for IA_NA and IA_PD) - I think the renew is best though. The
only negative with starting with the Renew is that you don't really want
to wait until T2 to find another server if the original server is down.
So we might want to think some more about whether the retransmission
rules should be different.

No - we are not disallowing this. We are saying that Renew is OK to get
new bindings. If client sends Solicit, it can accept whatever
Advertisement it likes (per the "rules" in RFC 3315/3633). 

We might need an additional section in the draft to specify this
behavior.

-          Bernie

From: Gaurav Halwasia (ghalwasi) 
Sent: Friday, May 25, 2012 4:10 AM
To: Bernie Volz (volz); [email-masked]'
Subject: RE: [dhcwg] Comments on
draft-troan-dhc-dhcpv6-stateful-issues-00

<snip>

</snip>

Thanks,

Gaurav

From: Bernie Volz (volz) 

Comments below (BV>).

-          Bernie

1.)Section 3.1

   Replace Section 17.1.3

   With:

 
 
2.) Section 3.6

 
-          Bernie

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 25 May 2012 05:45:20 -0500

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.

>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:[email-masked]] 
Sent: Friday, May 25, 2012 2:38 AM
To: Bernie Volz (volz)
Cc: Gaurav Halwasia (ghalwasi); [email-masked]
Subject: Re: [dhcwg] Comments on

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!

...
Status
> 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.)

-----

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.

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

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.

Regards,
Stephen
--
 Stephen Jacob | [email-masked] | +1 650 381 6051  Nominum,
Inc. |  http://www.nominum.com/  | +1 650 381 6000