Subject: Re: [dhcwg] Gen-ART review of draft-ietf-v6ops-ipv6-cpe-router-06

From: Ole Troan <[email-masked]>
Date: Mon, 2 Aug 2010 14:32:19 +0200

Bernie,

> Ole, my personal opinion is that this is fine (wrt to DHCPv6).

thank you very much for thorough comments. looks like we need some small adjustments to the CPE router draft.

> However, WPD-7 is technically incorrect ...
> 
> From RFC 3315, section 17.2.2 (Advertise processing):
> 
>   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.
> 
> And, WPD-7 reads:
> 
>   WPD-7:  If the IPv6 CE router requests both an IA_NA and an IA_PD in
>           DHCPv6, it MUST accept an IA_PD in DHCPv6 Advertise/Reply
>           messages, even if the message does not contain any addresses
>           (IA_NA options with status code equal to NoAddrsAvail).
> 
> So, the server's Advertise response would be an IA_PD option (with an
> IAPREFIX) and a Status Code option of NoAddrsAvail. There will be no
> IA_NA options. At least, that's the way I would interpret this.

but section 18.2.1, paragraph 6 and 18.1.8 seem to indicate that the status code is encapsulated in the IA_NA option.
I think in any case RFC3315 section 17.1.3 needs to be changed. as I read that to mean that the whole Advertise message MUST be dropped.

so assuming we get an update or errata to 3315/3633, what should the CPE router draft say?
just:?

WPD-7: If the IPv6 CE router requests both an IA_NA and an IA_PD in DHCPv6, it MUST accept an IA_PD DHCPv6 Advertise/Reply
               messages, even if the message does not contain any addresses.

> 
> This is also an edge case as it depends on how literally you interpret
> section 17.2.2 ... this implies that no other options are returned (such
> as those from the ORO) and what about IA_PD? But, my interpretation is
> that this 17.2.2 applies only if there are no IA_PD options - if there
> are, the server should continue processing the request and return the
> IA_PD plus any client request options (except of course if the IA_PD
> fails to assign any prefixes).
> 
> The server I work on handles this and returns no IA_NA, Status Code of
> NoAddrsAvail, and IA_PD for the Advertise. 

right, so I read it to mean that a server would always have to return the IA_* but empty and with a status code.

> Now, another way to interpret section 17.2.2 is to change "will not
> assign any addresses" to "will not assign any addresses or delegate any
> prefixes", in which case the response would be a bit different ... but,
> that doesn't make much sense as the NoAddrsAvail status code only
> applies to addresses.

agree. a server and a client should be able to support any combination of IAs be it addresses or prefixes or something else.
and handle the cases where a server can only give address or only prefixes, even though the client has asked for both.

the slightly more interesting cases happen if you have two servers, one advertising addresses, the other prefixes. how should a client behave? is this something we need to standardise?

> Note that for the Request, the Reply would be as written in WPD-7 as
> section 18.2.1 of RFC 3315 reads:
> 
>   If the server cannot assign any addresses to an IA in the message
>   from the client, the server MUST include the IA in the Reply message
>   with no addresses in the IA and a Status Code option in the IA
>   containing status code NoAddrsAvail.
> 
> However, in most cases the Request would likely never contain the IA_NA
> because the Advertise told the client addresses are not available.

ah, I see. so the status code would be presented differently between Request and Advertise?
isn't that a bit awkward? ;-)

> I'm not sure why the RFC 3315 behavior was designed to be different
> between Solicit/Advertise and Request/Reply and how the Advertise
> behavior was meant to interact with PD. 
> 
> Perhaps this is something to work out and then issue an Errata (for RFC
> 3315)? 

I think so. and also for rfc3633.
the dhc working group is doing a 2 week review of the CPE router draft, so I expect and hope we will have all this issues ironed out as a result of that review.

cheers,
Ole

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 2 Aug 2010 09:40:07 -0500

Ole:

Yes, might be safer for WPD-7 to be less explicitly about exactly what
is returned in the response.

I guess there are 4 possibilities here:
1. No address allocated nor prefix delegated
2. Address allocated and prefix delegated
3. Address allocated, no prefix delegated
4. No address allocated, but prefix delegated.

And, then you have the multiple server situation you described (where
one returns 3 and the other 4).

And, there's also the case where the (single) server can't handle both
address allocation and prefix delegation, but that might just end up
looking like 3 or 4.

I guess that a really good client might handle them as follows:
1. Retry periodically (with exponential backoff ...)
2. Easy case as this is exactly what the client wants.
3. Use the address and repeat DHCP for the IA_PD only.
4. Use the prefix and repeat DHCP for the IA_NA only.

A client is 'done' with DHCP when it has both an address and a prefix.
The address might also come from RAs, in which case the client can stop
DHCP for the address if the M bit is not set in the RA and it is
unsuccessful.

Another option for the client is to treat the IA_NA and IA_PD requests
independently (which is really what the 'good client' above is all about
except that it tries to request both in a single Solicit initially). I'm
not sure that this is so bad - yes, it costs a few more packets (4) but
may make for a simpler implementation and easier to test. (Of course,
that ignores the issue with receiving different 'other information'
options, but I don't even think that is so bad as the option usage is
somewhat different for the address allocation vs prefix delegation and
thus might actually argue for splitting the two requests).

I have no issue with trying to clarify RFC 3315 (and perhaps 3633) with
an Errata. But I'm not sure that necessarily solves the problem if we do
make 'changes' as there are existing (server) implementations in the
field already.

- Bernie

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Monday, August 02, 2010 8:32 AM
To: Bernie Volz (volz)
Cc: Dhcwg Group; [email-masked]; Francis Dupont
Subject: Re: [dhcwg] Gen-ART review of
draft-ietf-v6ops-ipv6-cpe-router-06

Bernie,

> Ole, my personal opinion is that this is fine (wrt to DHCPv6).

thank you very much for thorough comments. looks like we need some small
adjustments to the CPE router draft.

> IA_NA options. At least, that's the way I would interpret this.

but section 18.2.1, paragraph 6 and 18.1.8 seem to indicate that the
status code is encapsulated in the IA_NA option.
I think in any case RFC3315 section 17.1.3 needs to be changed. as I
read that to mean that the whole Advertise message MUST be dropped.

so assuming we get an update or errata to 3315/3633, what should the CPE
router draft say?
just:?

WPD-7: If the IPv6 CE router requests both an IA_NA and an IA_PD in
DHCPv6, it MUST accept an IA_PD DHCPv6 Advertise/Reply
               messages, even if the message does not contain any
addresses.

> NoAddrsAvail, and IA_PD for the Advertise. 

right, so I read it to mean that a server would always have to return
the IA_* but empty and with a status code.

> that doesn't make much sense as the NoAddrsAvail status code only

agree. a server and a client should be able to support any combination
of IAs be it addresses or prefixes or something else.
and handle the cases where a server can only give address or only
prefixes, even though the client has asked for both.

the slightly more interesting cases happen if you have two servers, one
advertising addresses, the other prefixes. how should a client behave?
is this something we need to standardise?

> because the Advertise told the client addresses are not available.

ah, I see. so the status code would be presented differently between
Request and Advertise?
isn't that a bit awkward? ;-)

I think so. and also for rfc3633.
the dhc working group is doing a 2 week review of the CPE router draft,
so I expect and hope we will have all this issues ironed out as a result
of that review.

cheers,
Ole

---

From: "MULTACH, JEFF (ATTLABS)" <[email-masked]>
Date: Tue, 3 Aug 2010 09:34:17 -0400

> ...
> an Errata. But I'm not sure that necessarily solves the ...

But for those who are in the development of DHCP server requirements, it
would be nice to have clarification.

Between policy options statements which allow you not respond to
requests, and lack of clarity on how a server is to respond in these
cases, one is left to their own decision on requirements.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Bernie Volz (volz)
Sent: Monday, August 02, 2010 9:40 AM
To: Ole Troan
Cc: Dhcwg Group; [email-masked]; Francis Dupont
Subject: Re: [dhcwg] Gen-ART review of
draft-ietf-v6ops-ipv6-cpe-router-06

Ole:

- Bernie

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Monday, August 02, 2010 8:32 AM
To: Bernie Volz (volz)
Cc: Dhcwg Group; [email-masked]; Francis Dupont
Subject: Re: [dhcwg] Gen-ART review of

Bernie,

cheers,
Ole
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 3 Aug 2010 09:37:24 -0500

Well, if it was up to me, I'd say the server does what RFC 3315 says in
17.2.2 with respect to the address (IA_NA/IA_TA) processing and that if
there are one or more IA_PDs, the server will in addition process the
IA_PD(s) as per RFC 3633. If there are NO addresses and prefixes
delegated, the server will not return any 'other information' options
(thus the response is minimal and contains the Status Code Option with
NoAddrsAvail and the IA_PD's with Status Code Option NoPrefixAvail). If
at least one address or one prefix is delegated, the server returns the
'other information' options (i.e., completes processing as normal to
produce a full response).

Thus the Advertise response for a Solicit with IA_NA/IA_TA(s) and
IA_PD(s) would contain:
1. If no addresses or prefixes delegated: basic (error) response with
Status Code Option NoAddrsAvail and IA_PD(s) with encapsulated Status
Code Option of NoPrefixAvail.
2. If just addresses available, and no prefixes: full response with
IA_NA(s) and IA_PD(s) with encapsulated Status Code Option of
NoPrefixAvail.
3. If just prefixes available, and no addresses: full response with
Status Code Option NoAddrsAvail and IA_PDs with delegated prefix.

I do recall discussing this at one of the Comcast sponsored DHCPv6
Bakeoff events, but can't find anything about the discussion and
conclusion in the emails related to that event nor in the presentations
made to the DHC WG. I think my suggestion above was what we thought the
intended responses should be (as that is what ended up in our server
implementation, Cisco Network Registrar), but I could easily be
misremembering (either that it was discussed or what the consensus might
have been).

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of MULTACH, JEFF (ATTLABS)
Sent: Tuesday, August 03, 2010 9:34 AM
To: Bernie Volz (volz); Ole Troan
Cc: Dhcwg Group; [email-masked]; Francis Dupont
Subject: Re: [dhcwg] Gen-ART review of
draft-ietf-v6ops-ipv6-cpe-router-06

-----Original Message-----

Ole:

- Bernie

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Monday, August 02, 2010 8:32 AM
To: Bernie Volz (volz)
Cc: Dhcwg Group; [email-masked]; Francis Dupont
Subject: Re: [dhcwg] Gen-ART review of

Bernie,

cheers,
Ole

---

From: Francis Dupont <[email-masked]>
Date: Fri, 06 Aug 2010 16:23:24 +0200

Putting my gen-art reviewer hat on, this proves there are unresolved
issues about DHCPv6 usage in the IPv6 CPE router draft.
So my only question (which should receive a yes) is whether to solve
these issues is in the scope of the DHC WG...

Regards

[email-masked]

PS: without the hat IMHO the combination of address (RFC 3315), PD
(RFC 3633) and stateless (RFC 3736) is clearly underspecified.
Now we have a real world context where this combination makes sense
so the DHC WG should produce a document specifying all the details
(and the IPv6 CPE router draft should just refer to it).

---

From: Fred Baker <[email-masked]>
Date: Fri, 6 Aug 2010 17:21:10 +0200

Question for you. I believe you are in v6ops and didn't raise the point during the time that the document was in review there. Would it be appropriate to address the matter in the -bis version of the document that the WG is now working on, or does it need to be addressed in this one?

As the DHC working group is chartered, I suspect that they would be tasked with helping 6man or v6ops with what are perceived as "their" issues, but not to take the task on themselves.

> (and the IPv6 CPE router draft should just refer to it).

http://www.ipinc.net/IPv4.GIF

---

From: Ole Troan <[email-masked]>
Date: Fri, 6 Aug 2010 18:08:56 +0200

Franics,

> these issues is in the scope of the DHC WG...

I should perhaps not have taken all these issues into a single email, as only  the issue which has relevance to the IPv6 CPE router draft is the clarification in 3315/3633 that an IA should be ignored in advertise messages, not the whole message.

and even that point is something I'd like to wait for the DHC WG review to conclude on before we decide if any work needs to be done or not.

> (and the IPv6 CPE router draft should just refer to it).

I'm not sure I agree with you.
what issues are you thinking of? with regards to the Basic IPv6 CE router specification, e.g the issue of 6rd & DHCPV6 or "donut" delegations are out of scope.

cheers,
Ole

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 6 Aug 2010 11:59:30 -0500

I don't come to that conclusion. If the cpe-router draft is updated to
remove the incorrect information, which is just deleting "(IA_NA options
with status code equal to NoAddrsAvail)", it is clean and correct.

This does leave the open issue as to exactly how RFC 3315/RFC 3633
interact in this case, but that exists whether the cpe-router draft
moves forward or not.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, August 06, 2010 10:23 AM
To: Bernie Volz (volz)
Cc: Ole Troan; Dhcwg Group; [email-masked]
Subject: Re: [dhcwg] Gen-ART review of

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sat, 07 Aug 2010 19:22:59 +0200

In your previous mail you wrote:

   Question for you. I believe you are in v6ops and didn't raise the point
   during the time that the document was in review there.

=> and I am afraid I wouldn't raise it during the IETF last call too
if I wasn't designed as the gen-art reviewer...

   Would it be appropriate to address the matter in the -bis version
   of the document that the WG is now working on, or does it need to
   be addressed in this one?
   
=> in this one. BTW I don't believe the document is wrong, it just
relies on something which was not enough studied by the DHC WG
(as I explained to Ole I consulted a DHCP expert before sending
the review report).

   As the DHC working group is chartered, I suspect that they would be
   tasked with helping 6man or v6ops with what are perceived as "their"
   issues, but not to take the task on themselves.
   
=> if this becomes an issue the IESG should help (but looking at the
DHC WG mailing-list IMHO the DHC WG won't stay inactive...)

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Sat, 07 Aug 2010 19:30:27 +0200

Formally you are right: the only thing we can require is a review
by the DHC WG. Now IMHO it won't be enough and there is some work to do.

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Sat, 07 Aug 2010 19:38:48 +0200

=> is there a consensus about this?

=> this raises another question: does the publication of the cpe-router
draft add constraint to a 3315/3633 interaction document, i.e., a
solution should have to be consistent?

Note if answers are yes and no then a revised cpe-router draft could
move forward ASAP.

Thanks