Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-03

[Sheng Jiang <[e-mail]>]

Hi, Bernie,

Thanks so much for your comments. They help a lot for improving the quality of this draft. I am making the correspondent changes. See replies in lines.

I also attached an ongoing version. It will only submit after the discussion get stable.

Best regards,

Sheng

>- An Advertise should NEVER assign anything. A Reply is the only thing 
>that can do that.
>
>       The DHCPv6 server assigns one or more prefixes to the host in
>       Advertise messages or in the Reply messages responding to the
>       prefix requests from the hosts.
>
>The assignment doesn't occur until the Reply (note also the "or"). This 
>is very bad and we should not be misleading people that all they need 
>is Solicit/Advertise.

Yes, you are right. I have removed assignment in advertise message.

>- This document still fails to clarify the on-link status of the PA 
>prefix (I would assume it is NOT on-link unless so advertised in an 
>RA). I haven't looked back at the stateless autoconfiguration document 
>to see if there is anything else that a RA Prefix Information Option 
>communicates that might also be missing
>- obviously the A (stateless) isn't need since it is implicit in the IA_PA.

I don't think PA should match all RA Prefix Information. On-link status is for the reachability, which IA_PA does not care. Different from draft-droms-dhc-dhcpv6-default-router, we don't want to replace ND reachability and routing functions. However, I have added the below text as explanation into the draft.

"Comparing with Prefix Information Option in ND, Section 4.6.2 of RFC4861, the IA_PA option does not provide L flag and A flag.  The A (autonomous address-configuration flag) isn't need obviously because the IA_PA is implicit for stateless address configuration. Because the IA_PA is only address relevant, it does not relevant to reachability or routing and the DHCPv6 server may not sure the on-link state. So L (on-Link) flag is not include. The DHCPv6 client should treat the prefix as same as L flag not set, which makes no statement about on-link or off-link properties of the prefix."

>- I would think it would improve things to move the 6. Applicability 
>section to earlier in the document (for example, after section 1).

Have done this.

>- I think this document needs to clarify what a host does if the same 
>prefix is communicated (for essentially stateless usage) via both RAs 
>and DHCPv6. For example, must it continue to renew it with the DHCP server.

I don't think this should be an issue. In principle, AI_PA and RA Prefix Information Option should NOT be used for the same prefix. Network operator should avoid this in network design. However, even this happens, it should not be harmful. Implementation can use any one of it and safely ignore another one. Why bother?

>- There probably needs to be some text regarding some considerations 
>for DHCP servers and clients. For example, if a IA_PA capable client 
>connects to a network, and the DHCP server is not IA_PA capable, the 
>Solicit will result in no or Advertises without IA_PAs. A client could 
>now continue Soliciting (with appropriate retransmissions) or it could 
>'failover' to doing IA_NA/IA_TA requests? Or perhaps just wait for 
>stateless (RS/RA) to either provide it stateless autoconfiguration or 
>indicate that it should do DHCP (with IA_NA/IA_TA)? Perhaps are reasons 
>for each of these behaviors. Or, there may be guidance about when to 
>use IA_PAs in Solicits and when not? For example, use it for 
>point-to-point interfaces only? Note that I'm not promoting one choice over another - that is for you (and the WG) to decide.

Personally, I believe this consideration is more implementer choices, rather than standard work. However, I have added the below text.

"If an IA_PA capable client connects to a network, and the DHCPv6 server is not IA_PA capable, the Solicit or Request message with IA_PA Option will result in no Reply, Reply without IA_PAs, or Reply with a Status Code containing UnspecFail. The client MAY decide the network does not support IA_PA immediately or after a period of soliciting (with limited retransmissions times). Then, it MAY 'failover' to IA_NA/IA_TA requests."

>- Perhaps not absolutely necessary (since I would hope it obvious), but 
>it may be useful to indicate that the PD_EXCLUDE (RFC 6603) option may 
>not be encapsulated in the IAPREFIX options that are encapsulated in an 
>IA_PD? (RFC
>6603 is pretty dependent on PD.)

Have added this statement into the draft.

Best regards,

Sheng