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

[Ole Trøan <[e-mail]>]

Hemant,

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

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.

> 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?

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