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

+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

-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon
Sent: Thursday, August 16, 2012 1:38 PM
To: dhc WG
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00

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?

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg