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

["Bernie Volz (volz)" <[e-mail]>]

I'd really like to understand exactly what the problem/requirement here is?

>From the document, I gather the issue is:

   Up to now, there is no mechanism that allows host self-generated
   addresses to be used in the DHCPv6-managed network.

But why does the host care what its address is? And if it needs multiple addresses, DHCPv6 already provides a mechanism for this (IA_NAs with unique IAIDs).

Later there is some mention of CGAs and there was a separate draft being worked on for that, draft-ietf-dhc-cga-config-dhcpv6-02? So, if CGAs are the goal, isn't that document perhaps the better one to one forward (perhaps with changes if there are some additional items to be accommodated).

And, there's also temporary addresses mentioned - but why aren't IA_TAs appropriate?

Also, why is the RS/RA mechanism that a host could use NOT appropriate? There is no mention of this?

And, RS/RA and prefix information communicate more information such as whether the prefix is on-link or not, which is NOT information that is provided by this mechanism - what does the host assume?


-          Bernie

From: Gaurav Halwasia (ghalwasi)
Sent: Wednesday, August 15, 2012 10:33 AM
To: Bernie Volz (volz); Ted Lemon; Andre Kostur
Cc: dhc WG
Subject: RE: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02

Bernie,

> Another issue that should be addressed in the document is what a client should send when it connects to a network. How does >it know that the server supports IA_PA and that it should be used, instead of the traditional IA_NA? Should a client request >both? Does it send some kind of probe (Solicit with IA_PA [perhaps only in the ORO]) - and what does it do if it doesn't get any >response; try again for IA_NA.

I see your point which you are making. Further, draft says following:-

   Up to now, there is no mechanism that allows host self-generated
   addresses to be used in the DHCPv6-managed network.

So, what about continuing with IA_NA itself but perhaps including host generated "Interface-identifier" (as a new sub-option) as a hint in IA_NA option which server *might* want to use while assigning the IPv6 address. ?

Thanks,
Gaurav


From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]<mailto:[mailto:[e-mail]]> On Behalf Of Bernie Volz (volz)
Sent: Wednesday, August 15, 2012 7:31 PM
To: Ted Lemon; Andre Kostur
Cc: dhc WG
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02

Ted:

If that is the case, why is there an IAID in the option (see below)? Shouldn't that be removed?? If we have an IAID, then the client MUST provide this option. If there is no IAID, then it may be possible to just put the option in the ORO. However, I'd personally prefer we stick with the IA_NA/IA_TA/IA_PD conventions and require this to be supplied by the client. If the server doesn't understand the option, it won't send it back in the Advertise/Reply.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         OPTION_IA_PA          |         option-length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         IAID (4 octets)                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              T1                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              T2                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       .                                                               .
       .                          IA_PA-options                        .
       .                                                               .
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


I'd also suggest the following be clarified (section 4, bullet 2):


       If there is not a proper prefix available, a status-

       code is returned to the host and the procedure is terminated.

What status code and where is this status code returned. Let's hope it follows the IA_PD conventions (especially if we keep the IAID in the IA_PA). There is no new status code requested, do apparently it is one of the existing codes (RFC 3315/3633)?


This work also seems to be to replacing Router Solicitation/Router Advertisement messages to advertise the prefixes (for stateless autoconfiguration). Do we really want this. And, might not this be something to discuss in a slightly wider IETF audience. Perhaps it has already been (I haven't followed this work that closely).


Another issue that should be addressed in the document is what a client should send when it connects to a network. How does it know that the server supports IA_PA and that it should be used, instead of the traditional IA_NA? Should a client request both? Does it send some kind of probe (Solicit with IA_PA [perhaps only in the ORO]) - and what does it do if it doesn't get any response; try again for IA_NA.

Personally, I do NOT think this work is ready and needs more clarity.


-          Bernie

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]<mailto:[mailto:[e-mail]]> On Behalf Of Ted Lemon
Sent: Wednesday, August 15, 2012 9:15 AM
To: Andre Kostur
Cc: dhc WG
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02

On Aug 15, 2012, at 12:42 AM, Andre Kostur wrote:
I think that if the device wants a PA, it should supply an IA_PA in
its Solicit.  The device needs to specify an IAID.  An ORO is
insufficient.

The prefix is not necessarily specific to an individual client-it's not a prefix delegation.   So I don't think an IAID is necessary at all.