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

["Gaurav Halwasia (ghalwasi)" <[e-mail]>]

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