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

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Aug 2012 02:04:57 +0000

The authors have requested a working group last call for this draft.   The draft provides a mechanism whereby the DHCP server can indicate to the DHCP client which prefix it should use for autoconfiguration, for instance for CGA address generation.   This draft has been hanging around for a while, and could definitely use more eyes on it.   Please take the time to review it; if you think it's a good idea, please indicate your support for advancing the draft.   If you think it's a bad idea, please indicate that you do not support advancing it.   If you have comments, they would be very much appreciated.

We will determine consensus on August 27.

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Mon, 13 Aug 2012 04:20:45 +0000

I like the idea but I do have few comments:-.

1.) Abstract does not seems clear to me. 
This document introduce a procedure for configuring hosts' IPv6
   address which the prefix is assigned from a DHCPv6 server through
   DHCPv6 protocol while the interface identifiers are independently
   generated by the hosts.

2.) Section 1 . Introduction. Change "host-genarated" to "host-generated"
3.) Section 1 . Introduction. Change "separats" to "separates"
4.) Section 1 . Introduction. Change "ingerface identifiers" to "interface identifiers"
5.) Section 4.  This section talks about the new IA_PA option but does not explicitly say that this option needs to be inserted in SOLICIT message.

6.) As this procedure is indeed "state less" from the DHCPv6 perspective, why don't we want to use "Information-Request" message instead of SOLICIT from the host.?

7.) What should the host do after timers expire.? And is the DHCPv6 RECONFIGURE message supported for this option type. I think this should be clarified in the draft.

Thanks,
Gaurav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Monday, August 13, 2012 7:35 AM
To: dhc WG
Subject: [MARKETING] [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 13 Aug 2012 07:35:26 +0000

Hi, Gaurav,

Thanks for your carefully review. Reply in lines. With all your comments addressed, would you support this document forward?

>   DHCPv6 protocol while the interface identifiers are independently

Reworded: This document introduces a new DHCPv6 procedure to configure hosts' IPv6 addresses. In this new procedure, the prefix is advertised from a DHCPv6 server through DHCPv6 protocol while the interface identifiers are independently generated by the hosts.

>4.) Section 1 . Introduction. Change "ingerface identifiers" to "interface

All changed.

>5.) Section 4.  This section talks about the new IA_PA option but does not
>explicitly say that this option needs to be inserted in SOLICIT message.

Have added a sentence for this. However, this is only a MAY. "A host MAY include a Option Request Option in a Solicit or Request message to request a IA_PA explicitly." The prefix assignment could be in advertise model. It is not necessary that a host request a IA_PA.

>6.) As this procedure is indeed "state less" from the DHCPv6 perspective, why
>don't we want to use "Information-Request" message instead of SOLICIT
>from the host.?

Request message is possible, too. See the above new sentence.

>7.) What should the host do after timers expire.? And is the DHCPv6
>RECONFIGURE message supported for this option type. I think this should be
>clarified in the draft.

Have added two sentences in Section 4 to describe the potential follow up operation: 

When the host reaches T1 or T2 defined in Section 5.1, it SHOULD use the same message exchanges, as described in section 18, "DHCP Client-Initiated Configuration Exchange" of [RFC3315], to obtain or update prefix(es) from a DHCPv6 server.

A DHCPv6 server MAY initiatively send a reconfiguration message to the host, as described in section 19, "DHCP Server- Initiated Configuration Exchange" of [RFC3315], to cause prefix(es) information update.

Best regards,

Sheng

>The authors have requested a working group last call for this draft.   The
>draft provides a mechanism whereby the DHCP server can indicate to the
>DHCP client which prefix it should use for autoconfiguration, for instance for
>CGA address generation.   This draft has been hanging around for a while,
>and could definitely use more eyes on it.   Please take the time to review it;
>if you think it's a good idea, please indicate your support for advancing the
>draft.   If you think it's a bad idea, please indicate that you do not support
>advancing it.   If you have comments, they would be very much appreciated.
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 14 Aug 2012 07:58:36 +0000

Support advancing it. Few minor comments:

Section 3, first paragraph. It is not proper to say routers can "specify" the hosts should use DHCPv6 and/or stateless address configuration. In fact the RFC4862 doesn't clearly defined the hosts should interpret the M/O flags as prescriptive, but just advisory. In other word, it is not determined by the routers, but the hosts themselves. 

In last paragraph of section 4, what is the "address registration procedure"? Do you mean the procedure defined in draft-ietf-dhc-addr-registration ? If it is, it's better to add a reference.

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 14 Aug 2012 09:26:24 +0000

Hi, Bing,

Thanks for your support and comments. See my replies in lines.

Regards,

Sheng

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Liubing (Leo)
>Sent: Tuesday, August 14, 2012 3:59 PM
>To: Ted Lemon; dhc WG
>Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02
>
>Section 3, first paragraph. It is not proper to say routers can "specify" the
>hosts should use DHCPv6 and/or stateless address configuration. In fact the
>RFC4862 doesn't clearly defined the hosts should interpret the M/O flags as
>prescriptive, but just advisory. In other word, it is not determined by the
>routers, but the hosts themselves.

This sentence is almost the same with original sentence in RFC4862, including the word "specify". The object of "specify" is a "should", rather than "MUST". So, router is not determined the address configuration model. Router gives advices. This description is compatible with your understanding, I believe. 

>In last paragraph of section 4, what is the "address registration procedure"?
>Do you mean the procedure defined in draft-ietf-dhc-addr-registration ? If it is,
>it's better to add a reference.

Echo. Thanks.

Sheng

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Tue, 14 Aug 2012 10:26:49 +0000

Hi Sheng,

Please see inline.

Thanks,
Gaurav

-----Original Message-----
From: Sheng Jiang [mailto:[email-masked]] 
Sent: Monday, August 13, 2012 1:05 PM
To: Gaurav Halwasia (ghalwasi); Ted Lemon; dhc WG
Subject: RE: WGLC: draft-ietf-dhc-host-gen-id-02

Hi, Gaurav,

Thanks for your carefully review. Reply in lines. With all your comments addressed, would you support this document forward?
[Gaurav] Certainly. I support the document forward.

All changed.

>5.) Section 4.  This section talks about the new IA_PA option but does 
>not explicitly say that this option needs to be inserted in SOLICIT message.

Have added a sentence for this. However, this is only a MAY. "A host MAY include a Option Request Option in a Solicit or Request message to request a IA_PA explicitly." The prefix assignment could be in advertise model. It is not necessary that a host request a IA_PA.
[Gaurav] I don't understand this part completely. So you are saying that host can send "DHCP REQUEST" message as well instead of SOLICIT.? Can you please elaborate it in detail. 

>6.) As this procedure is indeed "state less" from the DHCPv6 
>perspective, why don't we want to use "Information-Request" message 
>instead of SOLICIT from the host.?

[Gaurav] I was referring to "Information-Request(11)" message not  "Request(3)"

>RECONFIGURE message supported for this option type. I think this should 
>be clarified in the draft.

Best regards,

Sheng

>Of Ted Lemon

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 15 Aug 2012 01:32:19 +0000

-----Original Message-----
From: Sheng Jiang 
Sent: Tuesday, August 14, 2012 5:26 PM
To: Liubing (Leo); Ted Lemon; dhc WG
Subject: RE: WGLC: draft-ietf-dhc-host-gen-id-02

Hi, Bing,

Regards,

Sheng

[Bing] That is what I mean. Thanks.

Echo. Thanks.

Sheng

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 15 Aug 2012 03:12:44 +0000

>Thanks for your carefully review. Reply in lines. With all your comments
>addressed, would you support this document forward?
>Reworded: This document introduces a new DHCPv6 procedure to configure
>hosts' IPv6 addresses. In this new procedure, the prefix is advertised from a
>DHCPv6 server through DHCPv6 protocol while the interface identifiers are
>independently generated by the hosts.
>
>Have added a sentence for this. However, this is only a MAY. "A host MAY
>include a Option Request Option in a Solicit or Request message to request a
>IA_PA explicitly." The prefix assignment could be in advertise model. It is not
>necessary that a host request a IA_PA.
>[Gaurav] I don't understand this part completely. So you are saying that host
>can send "DHCP REQUEST" message as well instead of SOLICIT.? Can you
>please elaborate it in detail.

<Sheng>Yes. After discovery a DHCPv6 server with solicit message, a host can use a Request message to request prefix assignment by include a IA_PA, instead of IA_NA or IA_TA. The server then return prefix information rather than address. In our understanding, this procedure is one way of address configuration, not other information.

Oops... With this, it seems we update RFC3315 a little bit. Maybe we should include an update header in the document.

The above sentence needs a little bit revise: "A host MAY include a Option Request Option in a Solicit or IA_PA in a Request message to request a prefix assignment explicitly."

When the prefix assignment in advertise model, even if a host does not request, DHCPv6 server can push it initiatively.

>[Gaurav] I was referring to "Information-Request(11)" message not

As explained above, we think this procedure is address associated. So, Request is more proper.

Sheng

>When the host reaches T1 or T2 defined in Section 5.1, it SHOULD use the
>same message exchanges, as described in section 18, "DHCP Client-Initiated
>Configuration Exchange" of [RFC3315], to obtain or update prefix(es) from a
>DHCPv6 server.
>
>A DHCPv6 server MAY initiatively send a reconfiguration message to the host,
>as described in section 19, "DHCP Server- Initiated Configuration Exchange"
>of [RFC3315], to cause prefix(es) information update.
>
>Best regards,
>
>Sheng
>
>>Thanks,
>>Gaurav
>>

---

From: Andre Kostur <[email-masked]>
Date: Tue, 14 Aug 2012 21:42:16 -0700

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.

--
Andre Kostur

---

From: "Fuyu (Eleven)" <[email-masked]>
Date: Wed, 15 Aug 2012 04:54:32 +0000

I am in favor of advancing this work.

BTW, some comments below
Section 4 part 1: This part describes that referring the IA_PD, a new IA_PA option is defined to insert into the DHCP message. 
And Section 5 the last sentence also describes that " However, the two options are different on the semantics and usage models." 
I think it need some more words to describe the difference between these two options in which scenario use IA_PD and in which scenario
use the IA_PA in this part.

Figure 1: I suggest to add message 4 (Request message) after the message 3 to confirm the usage of the new address as the whole 
configuration process. And I also think it is better to add the option name after the DHCP message in the figure 1. 

Some typo: Section 1 the last sentence: supports-support 
         Section 1 paragraph 4 the last sentence: separats->separates

Cheers 
Yu

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 15 Aug 2012 06:03:35 +0000

Hi, Andre,

Thanks for your reply. ORO in Solicit is support in the document. 

Request prefix assignment through solicit or request message happen in different scenarios: ORO in Solicit is for two message module. In four message module. Solicit is only used to discover DHCPv6. After that, Request message is used for information obtaining.

Regards,

Sheng

>From: Andre Kostur [mailto:[email-masked]]
>Sent: Wednesday, August 15, 2012 12:42 PM
>To: Sheng Jiang
>Cc: Gaurav Halwasia (ghalwasi); Ted Lemon; dhc WG
>> <Sheng>Yes. After discovery a DHCPv6 server with solicit message, a host
>can use a Request message to request prefix assignment by include a IA_PA,
>instead of IA_NA or IA_TA. The server then return prefix information rather
>than address. In our understanding, this procedure is one way of address
>configuration, not other information.
>>
>> Oops... With this, it seems we update RFC3315 a little bit. Maybe we should
>include an update header in the document.
>>
>> The above sentence needs a little bit revise: "A host MAY include a Option
>Request Option in a Solicit or IA_PA in a Request message to request a prefix
>assignment explicitly."
>>
>> When the prefix assignment in advertise model, even if a host does not
>request, DHCPv6 server can push it initiatively.
>>

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 15 Aug 2012 06:10:56 +0000

Hi, Yu,

Thanks your support and comments. Some replies in lines.

Regards,

Sheng

>Of Fuyu (Eleven)
>Sent: Wednesday, August 15, 2012 12:55 PM
>To: Ted Lemon
>Cc: dhc WG
>Section 4 part 1: This part describes that referring the IA_PD, a new IA_PA
>option is defined to insert into the DHCP message.
>And Section 5 the last sentence also describes that " However, the two
>options are different on the semantics and usage models."
>I think it need some more words to describe the difference between these
>two options in which scenario use IA_PD and in which scenario

Prefix delegation and Prefix assignment are quite different: IA_PD is actually used among routers. This has been described in third paragraph of introduction session.

>Figure 1: I suggest to add message 4 (Request message) after the message 3
>to confirm the usage of the new address as the whole
>configuration process.

We have stated this is out of scope and added a reference to I-D.ietf-dhc-addr-registration, which defines the address confirmation/registration process.

>And I also think it is better to add the option name
>after the DHCP message in the figure 1.

Added

>         Section 1 paragraph 4 the last sentence: separats->separates

Echo.

Sheng

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Aug 2012 13:11:33 +0000

On Aug 14, 2012, at 11:12 PM, Sheng Jiang wrote:
When the prefix assignment in advertise model, even if a host does not request, DHCPv6 server can push it initiatively.

It's hard to imagine a situation where this would be useful.   If the client doesn't already know about IA_PA, how is it going to know what to do when it gets one?   It seems to me that it would make more sense either to request an IA_PA in the ORO (in which case it would come in the advertise) or else just include an IA_PA in the Solicit.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Aug 2012 13:14:53 +0000

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.

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Wed, 15 Aug 2012 13:27:03 +0000

Hi Ted,
I agree. It's 'state-less' usage of DHCPv6 Protocol.

Also, may I am missing anything. Why do we think client using "Information-Request" message is inappropriate in this case in comparison to using SOLICIT.?

Thanks,
Gaurav

From: Ted Lemon [mailto:[email-masked]]
Sent: Wednesday, August 15, 2012 6:45 PM
To: Andre Kostur
Cc: Sheng Jiang; Gaurav Halwasia (ghalwasi); dhc WG
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02

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.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Aug 2012 14:00:09 +0000

On Aug 15, 2012, at 9:27 AM, Gaurav Halwasia (ghalwasi) wrote:
Also, may I am missing anything. Why do we think client using “Information-Request” message is inappropriate in this case in comparison to using SOLICIT.?

What would the source address be?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 15 Aug 2012 14:01:11 +0000

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: [email-masked] [mailto:[email-masked]] 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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Aug 2012 14:02:30 +0000

On Aug 15, 2012, at 10:00 AM, Ted Lemon wrote:
What would the source address be?

Actually, this was a dumb question.   The other answer is that the client has no way of knowing whether the network to which it is attaching supports this protocol, so it has to send a solicit with an IA_NA in case that's what the network administration supports.

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Wed, 15 Aug 2012 14:18:26 +0000

Ted,

Thanks, I get your point.

-Gaurav

From: Ted Lemon [mailto:[email-masked]]
Sent: Wednesday, August 15, 2012 7:33 PM
To: Gaurav Halwasia (ghalwasi)
Cc: dhc WG; Andre Kostur
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02

---

From: "Gaurav Halwasia (ghalwasi)" <[email-masked]>
Date: Wed, 15 Aug 2012 14:32:58 +0000

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: [email-masked] [mailto:[email-masked]] 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:

        0                   1                   2                   3

-          Bernie

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> 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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 15 Aug 2012 14:47:52 +0000

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

>From the document, I gather the issue is:

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,

Thanks,
Gaurav

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> 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:

        0                   1                   2                   3

-          Bernie

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 16 Aug 2012 00:18:31 +0000

Hi, Ted,

The scenario is just like RA broadcast prefix for stateless address configuration. The only different is broadcast though DHCPv6.

Sheng

From: Ted Lemon [mailto:[email-masked]]
Sent: Wednesday, August 15, 2012 9:12 PM
To: Sheng Jiang
Cc: Gaurav Halwasia (ghalwasi); dhc WG
Subject: Re: WGLC: draft-ietf-dhc-host-gen-id-02

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Aug 2012 00:40:04 +0000

On Aug 15, 2012, at 8:18 PM, Sheng Jiang wrote:
The scenario is just like RA broadcast prefix for stateless address configuration. The only different is broadcast though DHCPv6.

So why not use RA in this case?

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 16 Aug 2012 00:44:41 +0000

The assumption we take here is: this is a fully DHCPv6-managed network, SLACC through RA is not allowed.

From: Ted Lemon [mailto:[email-masked]]
Sent: Thursday, August 16, 2012 8:40 AM
To: Sheng Jiang
Cc: Gaurav Halwasia (ghalwasi); dhc WG
Subject: Re: WGLC: draft-ietf-dhc-host-gen-id-02

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 16 Aug 2012 00:49:59 +0000

Hi, Bernie,

Thanks for your comments. See my reply in lines.

Sheng

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

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

<Sheng> It is the existing NoPrefixAvail status code, defined in RFC 3633. I have just added an explicit explanation for this.

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

<Sheng> It is the assumption we take. I believe we had the WG consensus, by adopting as WG document. Because this only happens in a fully DHCPv6-managed network, does not impact any other network that use RA for SLACC, so I think discussion in DHC is enough.

Regards,

Sheng

---

From: Andre Kostur <[email-masked]>
Date: Wed, 15 Aug 2012 18:07:53 -0700

Leaving aside the issue of whether this "prefix announcement" should
be carried over DHCPv6, I wonder if trying to fit this into an
Identity Association isn't quite right since there is no identity to
be managed?   Perhaps a cleaner solution would be for the device to
ask for an IAPREFIX in an ORO in an Information-Request, and the
server can reply with an IAPREFIX (that isn't in any IA_* option).

Having said that, I'm with Ted in that I don't quite grasp why we're
trying to do this.  It the network is "fully DHCPv6-managed", wouldn't
that mean that the administrators would want to control the address
generation instead of leaving it up to the client to do with it as it
will?

On Wed, Aug 15, 2012 at 5:49 PM, Sheng Jiang <[email-masked]> wrote:
> 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)?
>
>
>
> <Sheng> It is the existing NoPrefixAvail status code, defined in RFC 3633.
> I have just added an explicit explanation for this.
>
>
>
>
>
> 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).
>
>
>
> <Sheng> It is the assumption we take. I believe we had the WG consensus,
> by adopting as WG document. Because this only happens in a fully
> DHCPv6-managed network, does not impact any other network that use RA for
> SLACC, so I think discussion in DHC is enough.

--
Andre Kostur

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 16 Aug 2012 02:58:39 +0000

What about the other things RAs provide? Such as the routers and on-link notification ... Are RAs active in these networks or not?

Also how is the client's assignment of addresses considered DHCPv6-managed?

How is this any different from stateless?

The only difference with this over normal stateless is that you could give each client its own prefix, whereas RAs are sent to all devices on the link. But I don't recall the document mentioning such a network (and in some cases where this might occur, usually there are tunnels involved and protocols such as ppp). And you would have to describe such a network and explain why RSs and RAs are insufficent or not usuable/pratical.

When the working group adopts a document to work on, that does not mean it will necessarily advance. Sometimes not all of the issues are well understood early in the process. There are other cases where it can take many years to work out the details and address the concerns before the document is ready. The process can be frustrating and demotivating. But the result is usually for the best.

Also, as CGAs are mentioned as one possible usage model, I think it would again be important to understand why the other works in this area (draft-ietf-dhc-cga-config-dhcpv6 and draft-ietf-dhc-secure-dhcpv6) are not appropriate or do not cover all of the requirements - and it might be worth considering working with those authors? Note also that in normal DHCPv6, clients may request explicit addresses and so using CGA addresses via DHCPv6 isn't impossible (some servers do require a range of addresses to be configured just like for v4, but I consider that approach to limit what v6 has to offer -- the server I work on does not have this restriction).

I can agree with you that the world isn't as simple as we would like - there are plenty of devices that only support stateless and this makes running a "fully" DHCPv6 managed network where you don't have total control of the devices that may connect impossible. But building more complexity and choices into DHCPv6 hardly seems like the a good approach to solving this since it will be even longer before all of the devices support these new configuration models - or some may chose not to implement DHCPv6 at all.

Anyway, if I haven't said it before or it isn't yet clear, I have serious objections to advancing this work in its current form and given its current motivation. If the rational for needing these capabilities and how they are used between clients, relays, and servers and the network are explained, I will be happy to remove my objections.

- Bernie

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 16 Aug 2012 03:48:00 +0000

Hi, Bernie and Andre

Thanks for your comments. Actually, we are quite open to discuss. The only reason we request WGLC is there is no any discussion for this draft for last 12 months and we have addressed all comments we received.

Since you have raised new discussion, we are happy to delay the process till all open issues get addressed. This is good for our work to be real mature. :)

See my reply in lines.

Sheng

>What about the other things RAs provide? Such as the routers and on-link
>notification ... Are RAs active in these networks or not?

This work does NOT replace neighbor discovery. RA is active in our target network. ND is mainly for reachability/routing purpose.

This work is to make the address configuration all by DHCPv6, rather than part by RA, part by DHCPv6. With the assumption that DHCPv6 takes over all address configuration, assigning 128-bit address is insufficient. Some host want to use self-generated address, CGA is only one example, others including EUI64 and privacy address.

This work is a generic prefix assignment/announcement mechanism. It is alternative of RA prefix assignment/announcement.

draft-ietf-dhc-secure-dhcpv6 is nothing to do with address configuration. It is AFTER CGA addresses generated, using them to protect DHCPv6 message exchanging.

draft-ietf-dhc-cga-config-dhcpv6 is specific CGA configuration. Since we separated prefix assignment to be this generic mechanism, that draft is only focusing on CGA approve process. However, if the discussion think prefix assignment is only meaningful for CGA, we have no problem to combine this back to CGA configuration draft.

Let's first discuss the requirement/problem first. We can come back to technical details later.

Regards,

Sheng

>The only difference with this over normal stateless is that you could give each
>client its own prefix, whereas RAs are sent to all devices on the link. But I
>don't recall the document mentioning such a network (and in some cases
>where this might occur, usually there are tunnels involved and protocols such
>as ppp). And you would have to describe such a network and explain why RSs
>and RAs are insufficent or not usuable/pratical.
>
>When the working group adopts a document to work on, that does not mean
>it will necessarily advance. Sometimes not all of the issues are well
>understood early in the process. There are other cases where it can take many
>years to work out the details and address the concerns before the document
>is ready. The process can be frustrating and demotivating. But the result is
>usually for the best.
>
>Also, as CGAs are mentioned as one possible usage model, I think it would
>again be important to understand why the other works in this area
>(draft-ietf-dhc-cga-config-dhcpv6 and draft-ietf-dhc-secure-dhcpv6) are not
>appropriate or do not cover all of the requirements - and it might be worth
>considering working with those authors? Note also that in normal DHCPv6,
>clients may request explicit addresses and so using CGA addresses via DHCPv6
>isn't impossible (some servers do require a range of addresses to be
>configured just like for v4, but I consider that approach to limit what v6 has to
>offer -- the server I work on does not have this restriction).
>
>I can agree with you that the world isn't as simple as we would like - there are
>plenty of devices that only support stateless and this makes running a "fully"
>DHCPv6 managed network where you don't have total control of the devices
>that may connect impossible. But building more complexity and choices into
>DHCPv6 hardly seems like the a good approach to solving this since it will be
>even longer before all of the devices support these new configuration models
>- or some may chose not to implement DHCPv6 at all.
>
>Anyway, if I haven't said it before or it isn't yet clear, I have serious objections
>to advancing this work in its current form and given its current motivation. If
>the rational for needing these capabilities and how they are used between
>clients, relays, and servers and the network are explained, I will be happy to
>remove my objections.
>
>- Bernie
>

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 16 Aug 2012 23:12:25 -0400

I support the concept behind this draft and think that the
requirements and text can be clarified to answer most objections.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 22 Aug 2012 02:05:21 +0000

The authors have submitted an updated 03 version of this draft according to the latest discussion on the mail list.

Among with minor modifications, the authors have largely rewritten the introduction/motivation section, hoping this would clarify the target scenarios.

http://tools.ietf.org/html/draft-ietf-dhc-host-gen-id-03

Discussion/review/comments are welcome.

Best regards,

Sheng

>Of Sheng Jiang
>Sent: Thursday, August 16, 2012 11:48 AM
>To: Bernie Volz (volz); Andre Kostur
>Cc: dhc WG; Ted Lemon
>Thanks for your comments. Actually, we are quite open to discuss. The only
>reason we request WGLC is there is no any discussion for this draft for last 12
>months and we have addressed all comments we received.
>
>Since you have raised new discussion, we are happy to delay the process till
>all open issues get addressed. This is good for our work to be real mature. :)
>
>See my reply in lines.
>
>Sheng
>
>This work does NOT replace neighbor discovery. RA is active in our target
>network. ND is mainly for reachability/routing purpose.
>
>This work is to make the address configuration all by DHCPv6, rather than part
>by RA, part by DHCPv6. With the assumption that DHCPv6 takes over all
>address configuration, assigning 128-bit address is insufficient. Some host
>want to use self-generated address, CGA is only one example, others
>including EUI64 and privacy address.
>
>This work is a generic prefix assignment/announcement mechanism. It is
>alternative of RA prefix assignment/announcement.
>
>
>draft-ietf-dhc-secure-dhcpv6 is nothing to do with address configuration. It is
>AFTER CGA addresses generated, using them to protect DHCPv6 message
>exchanging.
>
>draft-ietf-dhc-cga-config-dhcpv6 is specific CGA configuration. Since we
>separated prefix assignment to be this generic mechanism, that draft is only
>focusing on CGA approve process. However, if the discussion think prefix
>assignment is only meaningful for CGA, we have no problem to combine this
>back to CGA configuration draft.
>

---

From: Sheng Jiang <[email-masked]>
Date: Sat, 25 Aug 2012 05:56:44 +0000

Hi, Andre,

You are right that ORO is insufficient here. In the latest modification, we have removed ORO model. The client needs to include an IA_PA with IAID specified. There is no prefix announcement/advertise model in the current draft anymore.

Best regards,

Sheng