Subject: [dhcwg] DHCPv6 NoAddrAvailable

From: David Miles <[email-masked]>
Date: Fri, 5 Oct 2012 16:55:57 -0600

I have run across two different implementations of DHCPv6 server wrt NoAddrAvail/NoPrefixAvail and was hoping to get some thoughts what is best practice and what is non-compliant.

In my case, IA_NA and IA_PD are present in the solicit. The responses are:

Server A:-
Advertise
Client-Id
Server-Id
Status Code: NoPrefixAvail
Status Code: NoAddrAvail

Server B:-
Advertise
Client-Id
Server-Id
IA_NA
   Status Code: NoAddrAvail
IA_PD
   Status Code: NoPrefixAvail

IMO a client should be able to handle both cases (as server B is a superset of existing RFC requirements), but a server MUST send like A according to the RFC (I think?) when there are no addresses at all to offer.

And to be interesting, I assume that if there were addresses available but no prefixes, the Server B example (but with valid IA_NA) is the correct approach?

Thoughts?

d

---

From: Stephen Jacob <[email-masked]>
Date: Fri, 5 Oct 2012 17:21:20 -0700

On Fri, Oct 05, 2012 at 04:55:57PM -0600, David Miles wrote:
> I have run across two different implementations of DHCPv6 server wrt
> NoAddrAvail/NoPrefixAvail and was hoping to get some thoughts what is
> best practice and what is non-compliant.
> 
> IMO a client should be able to handle both cases (as server B is a
> superset of existing RFC requirements), but a server MUST send like A
> according to the RFC (I think?) when there are no addresses at all to
> offer.
> 
> And to be interesting, I assume that if there were addresses available
> but no prefixes, the Server B example (but with valid IA_NA) is the
> correct approach?
> 
> Thoughts?

Ole and Bernie have been attempting to fix this case up a bit in
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-stateful-issues/

That said, it's an annoying problem. Prior to considering IA_PD, it
seemed to make sense to have a NoAddrsAvail at the top-level when not
returning any bindings, so you didn't have to include multiple IA
options which just said NoAddrsAvail.

Unfortunately, it turned out to be a decision which has not worked out
well with the addition of IA_PD into the mix. Since you cannot both
indicate successful prefix assignment and unsuccessful address
assignment with one status code at the top level, and since RFC 3315
says you MUST include a status of NoAddsAvail if you don't assign any
addresses ... it has been a bit of a mess.

Server A is acting in a way that most closely fits the standards, but
Server B is doing the thing that would be least confusing.

Bernie and Ole's draft at least removes the contradictions and
confusion, but I wish we could hit reset and do it right (status codes
only in IA options).

Hopefully draft-ietf-dhc-dhcpv6-stateful-issues answers the question
of what one should do adequately.

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 6 Oct 2012 02:28:16 +0000

Actually, the correct answer should be:

Server C:-
Advertise
Client-Id
Server-Id
IA_PD
    Status Code: NoPrefixAvail
Status Code: NoAddrsAvail

You can change the order of the options, but RFC 3315 is pretty clear that the NoAddrsAvail should be a 'top' level status code in this case. The text in RFC 3315 is in 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.

RFC 3633 is clear that the NoPrefixAvail is in the IA_PD option.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Jacob
Sent: Friday, October 05, 2012 8:21 PM
To: David Miles
Cc: [email-masked]
Subject: Re: [dhcwg] DHCPv6 NoAddrAvailable

Regards,
Stephen
-- 
 Stephen Jacob | [email-masked] | +1 650 381 6051
 Nominum, Inc. |  http://www.nominum.com/  | +1 650 381 6000
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: David Miles <[email-masked]>
Date: Sat, 6 Oct 2012 11:01:42 -0600

> Status Code: NoAddrsAvail
Bernie,  

thanks for the example. So in the mixed case (some IA have addresses/prefixes and others don't) and trying to remain compliant with section 18.1.8:

The client examines the status code in each IA individually. If the status code is NoAddrsAvail, the client has received no usable addresses in the IA and may choose to try obtaining addresses for the IA from another server.

It suggests that when there is a multiple IA combination with differing levels of success, then the status code must always be in the IA?

By putting the Status Code NoAddrAvailable at the 'top' level then the text of 17.1.3 [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.],  it seems a server MUST NOT put a status code at the top level unless all IA have NoAddrAvail and NoPrefixesAvail. In the cases where there are mixed results the status codes should be within the appropriate IA?

Perhaps this is where the confusion is, as it is not explicit that an Advertise in which IA have mixed results/status codes should employ those status codes at the IA level. I appreciate it wasn't my question, but I wanted to be sure this corner case didn't change any of the suggested best practice work Øle and you are working on.

cheers again

d

---

From: David Miles <[email-masked]>
Date: Sat, 6 Oct 2012 11:05:36 -0600

Bernie,

my apologies,

in reading 4.2 of draft-ietf-dhc-dhcpv6-stateful-issues-01 makes some proposal that seems reasonable.

Additional text applicable to the Requesting Router may be useful to be clear that a RR should not ignore a Advertise with a Status Code 'NoAddrAvail' at the top level, but should instead examine for a IA_PD and any Status Code of NoPrefixAvail there before ignoring the Advertise message.

Sorry mate
,
d

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 6 Oct 2012 19:54:38 +0000

The stateful-issues draft doesn't address this - we said it was to remain the same. Though I guess the question is what does it 'the same' mean. My interpretation of RFC 3315 is apparently different than others.

I wish RFC 3315 had said to put the status code in IA_* status codes regardless of whether it applies to all or just one individually (I argued for this at the time but lost out) but it didn't and I think it is a matter of interpretation as to what should happen in the case of mixed IA_NA/IA_PD.

Perhaps clients already deal with this case as there appear to be 3 servers that behave differently and that means that clients will work regardless of where the options are??

If there is sufficient consensus, it would be great to add to the stateful-issues draft that RFC 3315 is changed to put the NoAddrsAvail status code in the IA_* itself and not in the top level option.

- Bernie

-----Original Message-----
From: David Miles [mailto:[email-masked]] 
Sent: Saturday, October 06, 2012 1:02 PM
To: Bernie Volz (volz)
Cc: Stephen Jacob; [email-masked]
Subject: Re: [dhcwg] DHCPv6 NoAddrAvailable

Bernie,  

cheers again

d

---

From: David Miles <[email-masked]>
Date: Mon, 8 Oct 2012 10:03:32 -0600

> I wish RFC 3315 had said to put the status code in IA_* status codes regardless of whether it applies to all or just one individually (I argued for this at the time but lost out) but it didn't and…
I too would see that as the most ideal implementation, as right now it seems a requesting router must treat any 'top' level NoAddrAvail as only an indicator for the IA_NA and not for PD. Regardless of the approach taken, I think clarifying text is worthwhile. 
 
> Perhaps clients already deal with this case as there appear to be 3 servers that behave differently and that means that clients will work regardless of where the options are??

Well, my problem is right now the client isn't dealing with some of the servers. If a vendor is going to make changes to get interop working I'd like to suggest the "right" way as well as including these 3 other ways so that it may be compatible. Any of the ISC guys able to shed light on how ISC dhcpd would handle these situations for another point of ref?
> If there is sufficient consensus, it would be great to add to the stateful-issues draft that RFC 3315 is changed to put the NoAddrsAvail status code in the IA_* itself and not in the top level opti…
I would place my vote there, agreeing with your earlier statement that it was written when the IA_NA/TA were the only IA types, now we have IA_PD (and perhaps more later) it seems more extensible to put NoAddrAvail in the IA itself. Putting NoAddrAvailable at the top-level to indicate that there are no addresses and prefixes seems wrong (as i don't think NoAddrAvail should imply no prefixes as well). 
I'd suggest text along the lines of: 
- A server generating an Advertise MUST put any status codes under the appropriate IA
- A client MUST check each present IA. Any IA_NA/TA that have a status code of NoAddrAvailable and any IA_PD that have a status code of NoPrefixesAvailable must be ignored (and no request sent for that IA). If all IA were unavail then the client MUST ignore the Advertise.
- In the absence of any IA and the presence of a status-code of NoAddrAvail the client MUST ignore the Advertise.

---

From: Stephen Jacob <[email-masked]>
Date: Mon, 8 Oct 2012 11:11:20 -0700

On Sat, Oct 06, 2012 at 07:54:38PM +0000, Bernie Volz (volz) wrote:
> If there is sufficient consensus, it would be great to add to the
> stateful-issues draft that RFC 3315 is changed to put the NoAddrsAvail
> status code in the IA_* itself and not in the top level option.

I think I've already made it clear that I'd like this. :)

Perhaps a backwards-compatible way to go might be that servers:

	- MUST put the NoAddrsAvail status code in the IA_* itself, and
	- SHOULD put the NoAddrsAvail status code at the top level

The latter for backwards compatibility with clients that expect it to be
there. Clients complying to the new standard could ignore the top level,
with ambiguity removed by each IA_* having a status associated with it.

Would that be an acceptable solution?

Regards,
Stephen

---

From: Ted Lemon <[email-masked]>
Date: Mon, 8 Oct 2012 18:42:25 +0000

> Would that be an acceptable solution?

Seems like a kludge—maybe it's necessary, but it's worth examining.   What's the downside to not sending NoAddrsAvail in the global scope?

---

From: Timothy Winters <[email-masked]>
Date: Mon, 8 Oct 2012 20:46:00 -0400

Hi Ted,
	We've seen DHCP Clients not properly handle the status code in the IA_NA option.    Basically older clients that are only looking for it in the global scope and regrettable accept the IA_NA when the status code NoAddrsAvail is in the IA_NA.   We not seen this behavior for the IA_PD, but that behavior was clearly defined in 3633.

Regards,
Tim

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 9 Oct 2012 00:51:27 +0000

That's a bit of useful information. I think the USG DHCPv6 tests must test this behavior for clients and servers? Though not sure whether they test what happens at the client if the wrong answer is given by the server? And, not sure how many implementations have had that testing.

I'm much more in favor of documenting the existing behavior and living with it (as I think that breaks fewer things). It isn't optimum, but in the end it really doesn't matter as long as implementers understand what is expected. And today that isn't as clear as it needs to be.

Perhaps the stateful issues draft can expand on this and clarify the server's answer (using the example of what the returned message should look like).

- Bernie

-----Original Message-----
From: Timothy Winters [mailto:[email-masked]] 
Sent: Monday, October 08, 2012 8:46 PM
To: Ted Lemon
Cc: Stephen Jacob; [email-masked]; Bernie Volz (volz)
Subject: Re: [dhcwg] DHCPv6 NoAddrAvailable

Hi Ted,

Regards,
Tim

On Oct 8, 2012, at 2:42 PM, Ted Lemon <[email-masked]> wrote:

> Seems like a kludge-maybe it's necessary, but it's worth examining.   What's the downside to not sending NoAddrsAvail in the global scope?
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Oct 2012 01:37:06 +0000

> Perhaps the stateful issues draft can expand on this and clarify the server's answer (using the example of what the returned message should look like).

That sounds right.   It's not how we would have done it if we'd anticipated prefix delegation when we did 3315, but that's water under the bridge.

---

From: David Miles <[email-masked]>
Date: Mon, 8 Oct 2012 22:27:13 -0600

So back to status code for the IA_NA at 'top' level and IA_PD in the IA itself? 

I do think we need to some clarifying text so that be no suggestion that a client can just look at the IA_NA at the top level without checking for any IA_PD (provided the client is also a RR), and that an status code of NoAddrAvailable at the top level refers only to IA_NA/TA.

d

On Monday, October 8, 2012 at 7:37 PM, Ted Lemon wrote: 
> On Oct 8, 2012, at 8:51 PM, "Bernie Volz (volz)" <[email-masked] (mailto:[email-masked])>
> wrote:
> That sounds right. It's not how we would have done it if we'd anticipated prefix delegation when we did 3315, but that's water under the bridge

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Tue, 9 Oct 2012 04:45:29 +0000

What about if we say:-

1.) Server MUST put the status-code within IA_* if both NA and PD are requested in same DHCPv6 message.  
2.) Server can put status-code within IA_NA if only IA_NA is requested DHCPv6 Message. (This will take care of backward compatibility) (behave as per rfc 3315)

Thanks,
Gaurav