Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00

From: Ted Lemon <[email-masked]>
Date: Fri, 10 Aug 2012 03:14:53 +0000

The authors have requested a working group last call.   The document describes some problems that exist in the way DHCP clients handle multiple stateful options, and proposes a solution that unifies the client state machine to accommodate these issues.

This document could use additional review, so please take the time to read it over and comment on it if you have any comments.   If you are in favor of advancing the document, please say so.   If you oppose advancing it, please say so, and say why.   We will evaluate the consensus based on these responses on August 24.

Thanks!

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Mon, 13 Aug 2012 02:57:45 +0000

I support this document.

Thanks,
Gaurav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Friday, August 10, 2012 8:45 AM
To: dhc WG
Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00

Thanks!

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Aug 2012 16:21:29 +0000

Not wearing my chair hat, I support what this draft is trying to do.   However, the draft makes a decision to unify the state machines of the IA_NA and IA_PD maintenance process.   We've had some discussions about this with customers, and one question that came up was whether it might make sense to have different DHCP servers answering IA_NA and IA_PD requests.   Obviously this is not possible if the transaction can't be split.

Have the authors considered this issue?   Any opinions on the topic?

The reason for the potential separation is that in some cases the business logic involved in delegating prefixes may be different than the logic used to allocate addresses.   Keeping the two functions separate enables significant additional flexibility when provisioning CPE devices.   This draft, if it were to progress in its current state, would rule out any such flexibility.   This is not an absolute deal breaker for me, but I wanted to raise the issue and see if anybody else has thought about this.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Aug 2012 17:37:51 +0000

One other question about this draft: it proposes extending the Confirm message to stateful options other than IA_NA.   Presumably, the option we're most interested in is IA_PD, but how would a DHCP server without access to the client binding state know that a PD was valid?   Are we talking about a scenario like Leaf Yeh's prefix pool option, whether the server simply validates that the proposed prefixes are within the pool that is assigned to the specific PE router?

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Thu, 16 Aug 2012 17:54:12 +0000

Why MUST the client ignore an Advertise message with no bindings?
What if stateful and stateless options are carried in the same message?
Does this mean the stateless options will be ignored just because the
stateful 
Options failed?

In general, I think this draft addresses an important problem that needs
to be 
solved urgently.  We need to think through carefully the consequences of
the proposed 
solutions, however.

- Wes

On 8/9/12 11:14 PM, "Ted Lemon" <[email-masked]> wrote:

>The authors have requested a working group last call.   The document
>describes some problems that exist in the way DHCP clients handle
>multiple stateful options, and proposes a solution that unifies the
>client state machine to accommodate these issues.
>
>This document could use additional review, so please take the time to
>read it over and comment on it if you have any comments.   If you are in
>favor of advancing the document, please say so.   If you oppose advancing
>it, please say so, and say why.   We will evaluate the consensus based on
>these responses on August 24.
>
>Thanks!
>

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 17 Aug 2012 15:46:55 +0000

+1 to Wes' comment that this document is addressing a very important problem space and the solutions are needed urgently.  However, more thought is required for the solutions.

In regards to section 4.4, if the server only checks the network configuration to reply to a Confirm message, how is it possible for most network configurations that the server determines an IA_PD is on-link?   I suspect that is why RFC 3633 prohibited use of the Confirm for the IA_PD.  In any case this document should explain why did RFC 3633 have a restriction on using the Confirm for the IA_PD.  Or does network configuration include looking up the prefix pool configured on the server for allocation?  In contrast, to make an on-link determination for an IA_NA IA_Address, all the server has to do is match (longest-prefix match) all IPv6 addresses configured on the machine that the server is running on.  These addresses are clearly network configuration. 

Section 4.1:  

# In relation to the first paragraph the document is addressing the fact that one server replies with, say, an IA_NA, while another server replies back with only the IA_PD.   Then why in section 4.7 the case of section 4.1 is deemed out of scope?   I also do not understand what does "equal" in section 4.7 mean.  Does it mean each server replies with all IAs that the deployment needs?
# In relation to the text in the last paragraph of section 4.1, if the client does not restart the Solicit retransmissions timers, what does the client do?

# Other comment:  Shouldn't the header of the document have an Updates tag to signify this document updates RFC 3315?

Thanks,

Hemant

---

From: Ole Trøan <[email-masked]>
Date: Mon, 20 Aug 2012 11:02:01 +0200

Ted,

> The reason for the potential separation is that in some cases the business logic involved in delegating prefixes may be different than the logic used to allocate addresses.   Keeping the two functi…

yes, we have talked about this issue. this draft clarifies correct protocol behaviour when multiple stateful options are present. I suppose it implicitly recommends one single DHCP session for multiple stateful options, but I don't think the text prohibits using multiple sessions either. that would be a choice the client could make, given the set of ADVERTISE messages received.

could we go forward with this draft that clarifies how multiple stateful options work in a single session, and with the general assumption that a client will choose one DHCP server and that server is authoritative?

then have separate specifications for how clients should behave in a multi-domain / separate session scenario if there is interest for that?

cheers,
Ole

---

From: Ole Trøan <[email-masked]>
Date: Mon, 20 Aug 2012 11:04:22 +0200

Ted,

> One other question about this draft: it proposes extending the Confirm message to stateful options other than IA_NA.   Presumably, the option we're most interested in is IA_PD, but how would a DHCP…

the server may have enough information, be it configured or having the binding. if so there is no harm in using confirm, and it has a lower overhead than Renew. I wasn't thinking of this in the context of the prefix pool option.

cheers,
Ole

---

From: Ole Trøan <[email-masked]>
Date: Mon, 20 Aug 2012 11:06:17 +0200

Wes,

> solved urgently.  We need to think through carefully the consequences of

how much do you want the protocol to change? that's how a client behaves today.
a client could fall-back to "stateless" DHCP, if it couldn't find any servers that would reply to its request for an address. is that a change we want to make?

cheers,
Ole

---

From: Ole Trøan <[email-masked]>
Date: Mon, 20 Aug 2012 11:13:15 +0200

Hemant,

> In regards to section 4.4, if the server only checks the network configuration to reply to a Confirm message, how is it possible for most network configurations that the server determines an IA_PD…

right, either the server has the binding, or the server has configuration that it can look up in, to verify if the client has moved or not. if it has no information it MUST not reply.

> # In relation to the first paragraph the document is addressing the fact that one server replies with, say, an IA_NA, while another server replies back with only the IA_PD.   Then why in section 4.…

the assumption in 3315/3633 is that a client is connected to a single administrative dhc domain on an interface.
scenarios where a client finds two DHCP servers, that are administered by two different entities, are outside of the scope of 3315/3633 and therefore also outside the scope of this update. there is as far as I know separate work in progress on this.

> # In relation to the text in the last paragraph of section 4.1, if the client does not restart the Solicit retransmissions timers, what does the client do?

continues with the timers it has.
otherwise as the text says, a received advertise with a consequent restart of solicit timers would result in a solicit storm.

> # Other comment:  Shouldn't the header of the document have an Updates tag to signify this document updates RFC 3315?

good point. both 3315 and 3633.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Aug 2012 12:39:10 +0000

On Aug 20, 2012, at 11:02 AM, Ole Trøan <[email-masked]<mailto:[email-masked]>> wrote:
could we go forward with this draft that clarifies how multiple stateful options work in a single session, and with the general assumption that a client will choose one DHCP server and that server is authoritative?

My concern is that if you do so, it will essentially result in clients standardizing on whatever behavior you specify, and so whether we write another standard or not, it will not be available in practice.

---

From: Ole Trøan <[email-masked]>
Date: Mon, 20 Aug 2012 14:44:31 +0200

Ted,

> My concern is that if you do so, it will essentially result in clients standardizing on whatever behavior you specify, and so whether we write another standard or not, it will not be available in p…

to turn the question around.
is there anyone who thinks that we should _not_ make multiple stateful options work in a single DHCP session?

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Aug 2012 17:15:25 +0000

> is there anyone who thinks that we should _not_ make multiple stateful options work in a single DHCP session?

That's certainly not what I am getting at!  :)