http://blog.gmane.org/gmane.ietf.dhc hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.dhc/11304 <pre>If a client requests both IA_NA and IA_PD, here is what our server (Cisco Prime Network Registrar does): - If neither are possible: - Top level option has Status Code with NoAddrsAvail - IA_PA has Status Code with NoPrefixAvail - If only IA_NA possible: - IA_NA has binding information - IA_PD has Status Code with NoPrefixAvail - If only IA_PD possible: - Top level option has Status Code with NoAddrsAvail - IA_PD has binding information My read of RFC 3315 says that the above is correct with respect to IA_NA/IA_TA. (Note that you can replace IA_NA with IA_TA in the above, or add IA_TA.) BTW, you would NEVER include NoAddrsAvail if no IA_NA/IA_TA options. My read of RFC 3633 says that the above is correct with respect to IA_PD. A client should only treat a message with Status Code with NoAddrsAvail to have "failed" with respect to IA_NA/IA_TA. Not, IA_PD. This is exactly what we are suggesting the behavior to be in the draft. While I agree that this Status Code difference is rather odd and I had pushed for moving the Status Code with NoAddrsAvail into the IA_NA/TA options at the time of RFC 3315, but it didn't happen. (Think of the case where IA_NA and IA_TA are included but server only gives out IA_NA ... in this case, in Advertise IA_NA has bindings and IA_TA is empty. That seemed a bit weird to me - if empty (no bindings) was OK, why did we need a Status Code? And why only report the status if ALL IA_NA/IA_TA fail? I think RFC 3633 got it right as to where the status should be.) And, I think it too late to change this because it would likely break many existing client implementations (such as those that only do IA_NA/TA). We considered this when writing the ID, but felt it too dangerous to existing implements to propose such a change (to move NoAddrsAvail into IA_NA/IA_TA instead of at top level). BTW: I can't say how well the above server implementation plays with all clients because frankly it is likely not that usual for a client to request IA_NA/TA and IA_PD and have a server that only supports one. I can say we haven't heard of any complaints and the server is in use for DHCPv6 in a lot of places. You statement: Code NoAddrAvail at the top level (RFC 3315), This is, IMHO, only with respect to the IA options specified in RFC 3315. - Bernie -----Original Message----- From: Stephen Jacob [mailto:Stephen.Jacob&lt; at &gt;nominum.com] Sent: Friday, May 25, 2012 2:38 AM To: Bernie Volz (volz) Cc: Gaurav Halwasia (ghalwasi); dhcwg&lt; at &gt;ietf.org Subject: Re: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00 This is actually extremely interesting to me. I believe there remains even further confusion with the cited section. I will explain the issues I ran into recently below the quoted context! On Thu, May 24, 2012 at 02:29:52PM -0500, Bernie Volz (volz) wrote: ... Status exception Now, here's where it gets even more convoluted: (I don't know if deconfusing this convolutedness is in scope for this draft, but I'd very much like any opinions/solutions from other implementors even if it is not). ----- As mentioned above, in RFC 3315, section 17.1.3, it says: "The client MUST ignore any Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user." and in section 17.2.2 it says: "If the server will not assign any addresses to any IAs in a subsequent Request from the client, the server MUST send an Advertise message to the client that includes only a Status Code option with code NoAddrsAvail and a status message for the user, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID." In RFC 3633, section 11.2, it says: "If the delegating router will not assign any prefixes to any IA_PDs in a subsequent Request from the requesting router, the delegating router MUST send an Advertise message to the requesting router that includes the IA_PD with no prefixes in the IA_PD and a Status Code option in the IA_PD containing status code NoPrefixAvail ..." This is different from IA_NA/IA_TA handling in that if you are not going to grant leases on addresses (as opposed to prefixes), you can omit the IA_NA/IA_TA options and just include Status Code NoAddrsAvail at the top level. RFC 3633 does not appear to say anything about status code in the top level options (outside IA_PD options -- neither specifying any new behaviour nor overriding/contradicting RFC 3315) other than in section 12.1 where it says: "Handling of Status Codes options in received Reply messages is described in section 18.1.8, "Receipt of Reply Messages" of RFC 3315. The NoPrefixAvail Status Code is handled in the same manner as the NoAddrsAvail Status Code." ... which by reference to RFC 3315 implies behaviour matching RFC 3315. RFC 3315 section 18.1.8 does not explicitly address the use of the Status Code option at the top level. One might assume that, then, behaviour specified elsewhere in RFC 3315 would apply, but would that be a correct assumption? Reading between the lines, I might expect that since a DHCP server MUST send IA_PD containing Status Code NoPrefixAvail when it is not going to grant a lease on a prefix that: (a) that should supplant sending a Status Code at the top level, so one should omit Status Code in the top level options; or (b) another possibility is that one should also include Status Code at the top level, but with value NoPrefixAvail; or (c) one should, in fact, literally follow RFC 3315 and since no *addresses* will be offered, include Status Code at the top level with value NoAddrsAvail in spite of also including the IA_PD option with Status Code NoPrefixAvail. The problem with option C is that ... let's say a Solicit contains only an IA_PD (no IA_NA/IA_TA) and the DHCP server responds with a valid prefix for the IA_PD option ... by a strict reading of RFC 3315 along side RFC 3633, since no *addresses* are being offered, there should be a Status Code of NoAddrsAvail at the top level. I'm nearly certain that that is not intended behaviour, since by a strict reading of the two RFCs a DHCP client should then ignore the valid IA_PD option. What to do when the DHCP server receives IA_NA and IA_PD, does not grant a lease on an address to the former and does grant a lease on a prefix to the latter is even muddier. Logic suggests to me in that case no top-level Status Code. Only one in the IA_NA option. Strict reading of the RFCs does not *appear* to support this belief, however. Since a compliant DHCP client must ignore messages containing Status Code NoAddrAvail at the top level (RFC 3315), and due to the MUST on inclusion of the IA_PD option (with Status Code NoPrefixAvail) (RFC 3633), I _suspect_ that the _intention_ is that implementations should instead omit Status Code at the top level in this case, or should use the value NoPrefixAvail (which seems redundant, with the mandatory inclusion of IA_PD with its own Status Code option). Our DHCP implementation does option C at present. I need to figure out whether that is correct and, if not, change the implementation. I expect this may be of interest to other implementors, too. Regards, Stephen -- Stephen Jacob | Stephen.Jacob&lt; at &gt;nominum.com | +1 650 381 6051 Nominum, Inc. | http://www.nominum.com/ | +1 650 381 6000 </pre> Bernie Volz (volz 2012-05-25T10:45:20 http://permalink.gmane.org/gmane.ietf.dhc/11303 <pre>BTW - we really should be referencing draft-ietf-dhc-dhcpv6-stateful-issues-00. I hope that is the draft that you looked at. client can only be associated with one server at a time. We are pretty much saying that, per interface, a client is associated with one server. There isn't anything to prohibit multiple servers, but without some additional work (which I mentioned at the DHC WG meeting in Paris) to support multiple administrative domains, it is not possible for a client to know whether it is in ONE or MULTIPLE administrative domains. And, in probably 99.9% of the cases, it is in a SINGLE administrative domain. So, let's make sure that things work well in that environment before worrying about the 0.1% (perhaps I should have said 99% and 1% based on the recent "Occupy" movements). 1. Does it need to wait for the next renew time to get expired before it can ask IA_PD along.? Yes. Best practice is that it should renew early and renew what it has and also ask for the IA_PD. But, the client may also "restart" by doing a Solicit (for IA_NA and IA_PD) - I think the renew is best though. The only negative with starting with the Renew is that you don't really want to wait until T2 to find another server if the original server is down. So we might want to think some more about whether the retransmission rules should be different. 2. So are we saying that it should not send SOLICIT for IA_PD anytime in between.? If we are still allowing SOLICIT, should it only accept ADVERTISE from the server (which initially gave IA_NA) No - we are not disallowing this. We are saying that Renew is OK to get new bindings. If client sends Solicit, it can accept whatever Advertisement it likes (per the "rules" in RFC 3315/3633). We might need an additional section in the draft to specify this behavior. - Bernie From: Gaurav Halwasia (ghalwasi) Sent: Friday, May 25, 2012 4:10 AM To: Bernie Volz (volz); 'dhcwg&lt; at &gt;ietf.org' Subject: RE: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00 Thanks Bernie for clarification. &lt;snip&gt; I believe, it is possible that a particular server is willing to offer only a subset of IA_'s which has been requested. In that case, what's the use of including the other IA_ in the subsequent renew/rebind. As in this case server will anyway only renew only one IA_. ? Are we suggesting that a client at any given point of time should only be talking to one server after the advertise is accepted. BV&gt; What harm is there in continuing to include this in the subsequent operations? If the server's policy prohibits returning addresses or delegated prefixes for these other IA types, there is no harm. The main assumption is that clients are in a single administrative domain and thus talking to another server will be unlikely to help (except of course in the case of misconfiguration, but better that the issue is detected early and dealt with). &lt;/snip&gt; [Gaurav] I don't see any harm in including not assigned IA_'s in subsequent renew and rebind. I wanted to clarify that with this text, we implicitly mean that client can only be associated with one server at a time. So we are saying that we can not have a deployment where 2 dhcpv6 servers (one doing IA_NA and other doing IA_PD) can be present. Also what if client first did IA_NA and at any later point of time it wants to do IA_PD. 1. Does it need to wait for the next renew time to get expired before it can ask IA_PD along.? 2. So are we saying that it should not send SOLICIT for IA_PD anytime in between.? If we are still allowing SOLICIT, should it only accept ADVERTISE from the server (which initially gave IA_NA) Thanks, Gaurav From: Bernie Volz (volz) Sent: Friday, May 25, 2012 1:00 AM To: Gaurav Halwasia (ghalwasi); dhcwg&lt; at &gt;ietf.org Subject: RE: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00 Hi and thanks for reading and commenting! Comments below (BV&gt;). - Bernie From: dhcwg-bounces&lt; at &gt;ietf.org [mailto:dhcwg-bounces&lt; at &gt;ietf.org] On Behalf Of Gaurav Halwasia (ghalwasi) Sent: Thursday, May 24, 2012 11:03 AM To: dhcwg&lt; at &gt;ietf.org Subject: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00 I have read this informational draft and I have couple of comments so far. 1.)Section 3.1 Replace Section 17.1.3 &lt;http://tools.ietf.org/html/draft-troan-dhc-dhcpv6-stateful-issues-00#se ction-17.1.3&gt; : (existing errata) The client MUST ignore any Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user. With: The client MUST ignore any IAs in an Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user. An Advertise message without any IA options MUST be ignored. Is this only applicable to IA_NA.? I guess in case client sends SOLICIT with both IA_NA and IA_PD. Then in that case I guess we should mention "NoPrefixAvail" as well. BV&gt; It is applicable to IA_NA and IA_TA as those are the cases that end up with the Status Code option of NoAddsAvailable in the "main" part of the message - not in each IA_NA/IA_TA. (IA_PD puts the NoPrefixAvail Status Code option in the IA_PD itself. This is what we wish had been specified for IA_NA/IA_TA but was not.) 2.) Section 3.6 Proposed solution: the client should keep a single session with the server. The client should continue with the IA_ options received, while continuing to request the other IA options in subsequent messages to the server. That means continue to include the empty unanswered IAs in subsequent Renew and Rebind messages. I believe, it is possible that a particular server is willing to offer only a subset of IA_'s which has been requested. In that case, what's the use of including the other IA_ in the subsequent renew/rebind. As in this case server will anyway only renew only one IA_. ? Are we suggesting that a client at any given point of time should only be talking to one server after the advertise is accepted. BV&gt; What harm is there in continuing to include this in the subsequent operations? If the server's policy prohibits returning addresses or delegated prefixes for these other IA types, there is no harm. The main assumption is that clients are in a single administrative domain and thus talking to another server will be unlikely to help (except of course in the case of misconfiguration, but better that the issue is detected early and dealt with). - Bernie _______________________________________________ dhcwg mailing list dhcwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dhcwg </pre> Bernie Volz (volz 2012-05-25T10:29:03 http://permalink.gmane.org/gmane.ietf.dhc/11302 <pre>Thanks Bernie for clarification. &lt;snip&gt; I believe, it is possible that a particular server is willing to offer only a subset of IA_'s which has been requested. In that case, what's the use of including the other IA_ in the subsequent renew/rebind. As in this case server will anyway only renew only one IA_. ? Are we suggesting that a client at any given point of time should only be talking to one server after the advertise is accepted. BV&gt; What harm is there in continuing to include this in the subsequent operations? If the server's policy prohibits returning addresses or delegated prefixes for these other IA types, there is no harm. The main assumption is that clients are in a single administrative domain and thus talking to another server will be unlikely to help (except of course in the case of misconfiguration, but better that the issue is detected early and dealt with). &lt;/snip&gt; [Gaurav] I don't see any harm in including not assigned IA_'s in subsequent renew and rebind. I wanted to clarify that with this text, we implicitly mean that client can only be associated with one server at a time. So we are saying that we can not have a deployment where 2 dhcpv6 servers (one doing IA_NA and other doing IA_PD) can be present. Also what if client first did IA_NA and at any later point of time it wants to do IA_PD. 1. Does it need to wait for the next renew time to get expired before it can ask IA_PD along.? 2. So are we saying that it should not send SOLICIT for IA_PD anytime in between.? If we are still allowing SOLICIT, should it only accept ADVERTISE from the server (which initially gave IA_NA) Thanks, Gaurav From: Bernie Volz (volz) Sent: Friday, May 25, 2012 1:00 AM To: Gaurav Halwasia (ghalwasi); dhcwg&lt; at &gt;ietf.org Subject: RE: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00 Hi and thanks for reading and commenting! Comments below (BV&gt;). - Bernie From: dhcwg-bounces&lt; at &gt;ietf.org [mailto:dhcwg-bounces&lt; at &gt;ietf.org] On Behalf Of Gaurav Halwasia (ghalwasi) Sent: Thursday, May 24, 2012 11:03 AM To: dhcwg&lt; at &gt;ietf.org Subject: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00 I have read this informational draft and I have couple of comments so far. 1.)Section 3.1 Replace Section 17.1.3 &lt;http://tools.ietf.org/html/draft-troan-dhc-dhcpv6-stateful-issues-00#se ction-17.1.3&gt; : (existing errata) The client MUST ignore any Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user. With: The client MUST ignore any IAs in an Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user. An Advertise message without any IA options MUST be ignored. Is this only applicable to IA_NA.? I guess in case client sends SOLICIT with both IA_NA and IA_PD. Then in that case I guess we should mention "NoPrefixAvail" as well. BV&gt; It is applicable to IA_NA and IA_TA as those are the cases that end up with the Status Code option of NoAddsAvailable in the "main" part of the message - not in each IA_NA/IA_TA. (IA_PD puts the NoPrefixAvail Status Code option in the IA_PD itself. This is what we wish had been specified for IA_NA/IA_TA but was not.) 2.) Section 3.6 Proposed solution: the client should keep a single session with the server. The client should continue with the IA_ options received, while continuing to request the other IA options in subsequent messages to the server. That means continue to include the empty unanswered IAs in subsequent Renew and Rebind messages. I believe, it is possible that a particular server is willing to offer only a subset of IA_'s which has been requested. In that case, what's the use of including the other IA_ in the subsequent renew/rebind. As in this case server will anyway only renew only one IA_. ? Are we suggesting that a client at any given point of time should only be talking to one server after the advertise is accepted. BV&gt; What harm is there in continuing to include this in the subsequent operations? If the server's policy prohibits returning addresses or delegated prefixes for these other IA types, there is no harm. The main assumption is that clients are in a single administrative domain and thus talking to another server will be unlikely to help (except of course in the case of misconfiguration, but better that the issue is detected early and dealt with). - Bernie _______________________________________________ dhcwg mailing list dhcwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dhcwg </pre> Gaurav Halwasia (ghalwasi 2012-05-25T08:10:08 http://permalink.gmane.org/gmane.ietf.dhc/11301 <pre>This is actually extremely interesting to me. I believe there remains even further confusion with the cited section. I will explain the issues I ran into recently below the quoted context! On Thu, May 24, 2012 at 02:29:52PM -0500, Bernie Volz (volz) wrote: ... Now, here's where it gets even more convoluted: (I don't know if deconfusing this convolutedness is in scope for this draft, but I'd very much like any opinions/solutions from other implementors even if it is not). ----- As mentioned above, in RFC 3315, section 17.1.3, it says: "The client MUST ignore any Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user." and in section 17.2.2 it says: "If the server will not assign any addresses to any IAs in a subsequent Request from the client, the server MUST send an Advertise message to the client that includes only a Status Code option with code NoAddrsAvail and a status message for the user, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID." In RFC 3633, section 11.2, it says: "If the delegating router will not assign any prefixes to any IA_PDs in a subsequent Request from the requesting router, the delegating router MUST send an Advertise message to the requesting router that includes the IA_PD with no prefixes in the IA_PD and a Status Code option in the IA_PD containing status code NoPrefixAvail ..." This is different from IA_NA/IA_TA handling in that if you are not going to grant leases on addresses (as opposed to prefixes), you can omit the IA_NA/IA_TA options and just include Status Code NoAddrsAvail at the top level. RFC 3633 does not appear to say anything about status code in the top level options (outside IA_PD options -- neither specifying any new behaviour nor overriding/contradicting RFC 3315) other than in section 12.1 where it says: "Handling of Status Codes options in received Reply messages is described in section 18.1.8, "Receipt of Reply Messages" of RFC 3315. The NoPrefixAvail Status Code is handled in the same manner as the NoAddrsAvail Status Code." ... which by reference to RFC 3315 implies behaviour matching RFC 3315. RFC 3315 section 18.1.8 does not explicitly address the use of the Status Code option at the top level. One might assume that, then, behaviour specified elsewhere in RFC 3315 would apply, but would that be a correct assumption? Reading between the lines, I might expect that since a DHCP server MUST send IA_PD containing Status Code NoPrefixAvail when it is not going to grant a lease on a prefix that: (a) that should supplant sending a Status Code at the top level, so one should omit Status Code in the top level options; or (b) another possibility is that one should also include Status Code at the top level, but with value NoPrefixAvail; or (c) one should, in fact, literally follow RFC 3315 and since no *addresses* will be offered, include Status Code at the top level with value NoAddrsAvail in spite of also including the IA_PD option with Status Code NoPrefixAvail. The problem with option C is that ... let's say a Solicit contains only an IA_PD (no IA_NA/IA_TA) and the DHCP server responds with a valid prefix for the IA_PD option ... by a strict reading of RFC 3315 along side RFC 3633, since no *addresses* are being offered, there should be a Status Code of NoAddrsAvail at the top level. I'm nearly certain that that is not intended behaviour, since by a strict reading of the two RFCs a DHCP client should then ignore the valid IA_PD option. What to do when the DHCP server receives IA_NA and IA_PD, does not grant a lease on an address to the former and does grant a lease on a prefix to the latter is even muddier. Logic suggests to me in that case no top-level Status Code. Only one in the IA_NA option. Strict reading of the RFCs does not *appear* to support this belief, however. Since a compliant DHCP client must ignore messages containing Status Code NoAddrAvail at the top level (RFC 3315), and due to the MUST on inclusion of the IA_PD option (with Status Code NoPrefixAvail) (RFC 3633), I _suspect_ that the _intention_ is that implementations should instead omit Status Code at the top level in this case, or should use the value NoPrefixAvail (which seems redundant, with the mandatory inclusion of IA_PD with its own Status Code option). Our DHCP implementation does option C at present. I need to figure out whether that is correct and, if not, change the implementation. I expect this may be of interest to other implementors, too. Regards, Stephen </pre> Stephen Jacob 2012-05-25T06:37:47 http://permalink.gmane.org/gmane.ietf.dhc/11300 <pre>I would say no. By changing from DHCPv6 Enabled to Static, it should no longer be doing DHCP. On Thu, May 24, 2012 at 11:40 AM, a r pradeep &lt;pradeepar&lt; at &gt;gmail.com&gt; wrote: </pre> Andre Kostur 2012-05-25T01:20:52 http://permalink.gmane.org/gmane.ietf.dhc/11299 <pre>Hello All Had a question on RFC 3315, Section 18.1.2 Creation and Transmission of Confirm messages When a client changes its configuration from dhcpv6 enabled to static, is this considered as moving to new link and is the client required to send out a Confirm message ? Thanks pradeep _______________________________________________ dhcwg mailing list dhcwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dhcwg </pre> a r pradeep 2012-05-24T18:40:32 http://permalink.gmane.org/gmane.ietf.dhc/11298 <pre>Hi and thanks for reading and commenting! Comments below (BV&gt;). - Bernie From: dhcwg-bounces&lt; at &gt;ietf.org [mailto:dhcwg-bounces&lt; at &gt;ietf.org] On Behalf Of Gaurav Halwasia (ghalwasi) Sent: Thursday, May 24, 2012 11:03 AM To: dhcwg&lt; at &gt;ietf.org Subject: [dhcwg] Comments on draft-troan-dhc-dhcpv6-stateful-issues-00 I have read this informational draft and I have couple of comments so far. 1.)Section 3.1 Replace Section 17.1.3 &lt;http://tools.ietf.org/html/draft-troan-dhc-dhcpv6-stateful-issues-00#se ction-17.1.3&gt; : (existing errata) The client MUST ignore any Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user. With: The client MUST ignore any IAs in an Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user. An Advertise message without any IA options MUST be ignored. Is this only applicable to IA_NA.? I guess in case client sends SOLICIT with both IA_NA and IA_PD. Then in that case I guess we should mention "NoPrefixAvail" as well. BV&gt; It is applicable to IA_NA and IA_TA as those are the cases that end up with the Status Code option of NoAddsAvailable in the "main" part of the message - not in each IA_NA/IA_TA. (IA_PD puts the NoPrefixAvail Status Code option in the IA_PD itself. This is what we wish had been specified for IA_NA/IA_TA but was not.) 2.) Section 3.6 Proposed solution: the client should keep a single session with the server. The client should continue with the IA_ options received, while continuing to request the other IA options in subsequent messages to the server. That means continue to include the empty unanswered IAs in subsequent Renew and Rebind messages. I believe, it is possible that a particular server is willing to offer only a subset of IA_'s which has been requested. In that case, what's the use of including the other IA_ in the subsequent renew/rebind. As in this case server will anyway only renew only one IA_. ? Are we suggesting that a client at any given point of time should only be talking to one server after the advertise is accepted. BV&gt; What harm is there in continuing to include this in the subsequent operations? If the server's policy prohibits returning addresses or delegated prefixes for these other IA types, there is no harm. The main assumption is that clients are in a single administrative domain and thus talking to another server will be unlikely to help (except of course in the case of misconfiguration, but better that the issue is detected early and dealt with). - Bernie _______________________________________________ dhcwg mailing list dhcwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dhcwg </pre> Bernie Volz (volz 2012-05-24T19:29:52 http://permalink.gmane.org/gmane.ietf.dhc/11297 <pre>I have read this informational draft and I have couple of comments so far. 1.)Section 3.1 Replace Section 17.1.3 &lt;http://tools.ietf.org/html/draft-troan-dhc-dhcpv6-stateful-issues-00#se ction-17.1.3&gt; : (existing errata) The client MUST ignore any Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user. With: The client MUST ignore any IAs in an Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message to the user. An Advertise message without any IA options MUST be ignored. Is this only applicable to IA_NA.? I guess in case client sends SOLICIT with both IA_NA and IA_PD. Then in that case I guess we should mention "NoPrefixAvail" as well. 2.) Section 3.6 Proposed solution: the client should keep a single session with the server. The client should continue with the IA_ options received, while continuing to request the other IA options in subsequent messages to the server. That means continue to include the empty unanswered IAs in subsequent Renew and Rebind messages. I believe, it is possible that a particular server is willing to offer only a subset of IA_'s which has been requested. In that case, what's the use of including the other IA_ in the subsequent renew/rebind. As in this case server will anyway only renew only one IA_. ? Are we suggesting that a client at any given point of time should only be talking to one server after the advertise is accepted. _______________________________________________ dhcwg mailing list dhcwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dhcwg </pre> Gaurav Halwasia (ghalwasi 2012-05-24T15:03:25 http://permalink.gmane.org/gmane.ietf.dhc/11296 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Prefix Assignment in DHCPv6 Author(s) : Sheng Jiang Frank Xia Behcet Sarikaya Filename : draft-ietf-dhc-host-gen-id-02.txt Pages : 10 Date : 2012-05-22 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. The method is applicable to Cryptographically Generated Addresses (CGA), and other IPv6 addresses with host-generated interface identifiers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-host-gen-id-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-host-gen-id-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-host-gen-id/ </pre> internet-drafts< at >ietf.org 2012-05-23T01:01:43 http://permalink.gmane.org/gmane.ietf.dhc/11292 <pre>Folks, We have published a new IETF I-D entitled: "DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers". It is analogous to the RA-Guard (RFC 6105) mechanism currently employed for mitigating RA-based attacks. The I-D is available at: &lt;http://tools.ietf.org/id/draft-gont-opsec-dhcpv6-shield-00.txt&gt; I'm not sure in which wg I'd be pursuing this effort (v6ops, opsec, or dhcwg). If there's interest in this wg, it could be done here. However, in any case discussion of this document within dhcwg would be welcome. Thanks! Best regards, Fernando -------- Original Message -------- Subject: New Version Notification for draft-gont-opsec-dhcpv6-shield-00.txt Date: Thu, 17 May 2012 22:26:10 -0700 From: internet-drafts&lt; at &gt;ietf.org To: fgont&lt; at &gt;si6networks.com A new version of I-D, draft-gont-opsec-dhcpv6-shield-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Filename: draft-gont-opsec-dhcpv6-shield Revision: 00 Title: DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers Creation date: 2012-05-18 WG ID: Individual Submission Number of pages: 12 Abstract: This document specifies a mechanism for protecting hosts connected to a broadcast network against rogue DHCPv6 servers. The aforementioned mechanism is based on DHCPv6 packet-filtering at the layer-2 device on which the packets are received. The aforementioned mechanism has been widely deployed in IPv4 networks ("DHCP snooping"), and hence it is desirable that similar functionality be provided for IPv6 networks. The IETF Secretariat </pre> Fernando Gont 2012-05-18T23:33:56 http://permalink.gmane.org/gmane.ietf.dhc/11290 <pre> A new Request for Comments is now available in online RFC libraries. RFC 6603 Title: Prefix Exclude Option for DHCPv6-based Prefix Delegation Author: J. Korhonen, Ed., T. Savolainen, S. Krishnan, O. Troan Status: Standards Track Stream: IETF Date: May 2012 Mailbox: jouni.nospam&lt; at &gt;gmail.com, teemu.savolainen&lt; at &gt;nokia.com, suresh.krishnan&lt; at &gt;ericsson.com, ot&lt; at &gt;cisco.com Pages: 10 Characters: 19485 Updates: RFC3633 I-D Tag: draft-ietf-dhc-pd-exclude-04.txt URL: http://www.rfc-editor.org/rfc/rfc6603.txt This specification defines an optional mechanism to allow exclusion of one specific prefix from a delegated prefix set when using DHCPv6-based prefix delegation. The new mechanism updates RFC 3633. [STANDARDS-TRACK] This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor&lt; at &gt;rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC </pre> rfc-editor< at >rfc-editor.org 2012-05-15T22:17:55 http://permalink.gmane.org/gmane.ietf.dhc/11289 <pre>I think the draft is in a good shape. Support to move forward Many thanks Gang 2012/5/7, Ted Lemon &lt;Ted.Lemon&lt; at &gt;nominum.com&gt;: </pre> GangChen 2012-05-13T01:08:50 http://permalink.gmane.org/gmane.ietf.dhc/11288 <pre>The IESG has approved the following document: - 'Description of Cisco Systems' Subnet Allocation Option for DHCPv4' (draft-ietf-dhc-subnet-alloc-13.txt) as Informational RFC This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Ralph Droms and Brian Haberman. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dhc-subnet-alloc/ Technical Summary This document defines a new DHCP option which is passed between the DHCP Client and the DHCP Server to request dynamic allocation of a subnet, give specifications of subnet(s) allocated, and report usage statistics. This memo documents the current usage of the option in agreement with [RFC3942], which declares that any pre-existing usages of option numbers in the range 128 - 223 should be documented and the working group will try to officially assign those numbers to those options. Working Group Summary There was nothing controversial about this document. There was consensus in the working group to include the following text in the document: At the time when RFC 3942 came out, Cisco Systems had already deployed products which made use of option number 220. In RFC 3942, section 4, procedure 2, it is clearly stated, "Vendors that currently use one or more of the reclassified options have 6 months following this RFC's publication date to notify the DHC WG and IANA that they are using particular options numbers and agree to document that usage in an RFC." This procedure was immediately followed. It further states, "Vendors have 18 months from this RFC's publication date to start the documentation process by submitting an Internet-Draft." This procedure was also followed. For the purposes of clarity, it was thought important for the submitted draft to go through Working Group review. This process took quite a long time, with the document moving to "Last Call" multiple times. Since Cisco Systems already had deployed products, and thus wanted to avoid anything except for minor changes to the existing option definition, it was deemed best for the document to be Informational instead of Standard Track. This decision was made in cooperation with the Working Group and Work Group Chair at the time. Document Quality There is at least one existing implementation of this specification. It is not known if additional DHCP server implementations have or will implement this draft. Existing implementations are believed to be available today. Beyond what was performed with key members of the dhc WG no special reviews were performed or required. Personnel The document shepherd is John Brzozowski &lt;John_Brzozowski&lt; at &gt;Cable.Comcast.com&gt;. The responsible Area Director is Ralph Droms &lt;rdroms.ietf&lt; at &gt;gmail.com&gt;. </pre> The IESG 2012-05-11T19:30:00 http://permalink.gmane.org/gmane.ietf.dhc/11286 <pre>+1 I also support this draft to move forward. The draft provides a practical approach to secure the DHCPv6 interaction with using the mature CGA mechanisms. B.R. Bing From: dhcwg-bounces&lt; at &gt;ietf.org [mailto:dhcwg-bounces&lt; at &gt;ietf.org] On Behalf Of Di Ma Sent: Tuesday, May 08, 2012 11:48 AM To: DHC WG Subject: [dhcwg] Fw: WGLC: draft-ietf-dhc-secure-dhcpv6 Considering DHCPv6 is somehow of big importance in the era of IPv6, CGA, as a well-fashioned IPv6 address, is going to protect DHCPv6 away from various attacks. Some efforts on the standardization of related techniques should be made. I am in favor of advancing this document. ________________________________ Di Ma CNNIC Advanced Research Department ___________________________________________________ China Internet Network Information Center Tel: (8610)-58813216 Https://www.cnnic.cn Add: 4, South 4th Street, Zhongguancun Haidian District, Beijing P.R.China 100190 POB: Beijing 349, Branch 6 ____________________________________________________ From: Ted Lemon&lt;mailto:Ted.Lemon&lt; at &gt;nominum.com&gt; Date: 2012-05-07 12:37 To: DHC WG&lt;mailto:dhcwg&lt; at &gt;ietf.org&gt; Subject: [dhcwg] WGLC: draft-ietf-dhc-secure-dhcpv6 In the Paris meeting a show of hands indicated that the group favored bringing this document to last call. So this is the last call for this document. If you are in favor of advancing it, and have read it, please say so. If you think it needs work, please send text or suggestions. If you don't think it should advance, please say so. We will determine consensus on May 21. _______________________________________________ dhcwg mailing list dhcwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dhcwg </pre> Liubing (Leo 2012-05-11T03:21:13 http://permalink.gmane.org/gmane.ietf.dhc/11285 <pre>Hi all, I am in favor of advancing this draft. Thanks Yu -----Original Message----- From: dhcwg-bounces&lt; at &gt;ietf.org [mailto:dhcwg-bounces&lt; at &gt;ietf.org] On Behalf Of Ted Lemon Sent: Monday, May 07, 2012 12:37 PM To: DHC WG Subject: [dhcwg] WGLC: draft-ietf-dhc-secure-dhcpv6 In the Paris meeting a show of hands indicated that the group favored bringing this document to last call. So this is the last call for this document. If you are in favor of advancing it, and have read it, please say so. If you think it needs work, please send text or suggestions. If you don't think it should advance, please say so. We will determine consensus on May 21. _______________________________________________ dhcwg mailing list dhcwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dhcwg </pre> Fuyu (Eleven 2012-05-10T09:19:56 http://permalink.gmane.org/gmane.ietf.dhc/11284 <pre>Nine people were in favor of adopting this work and said so on the mailing list. Nobody spoke to oppose doing the work. So there is consensus to adopt it. Leaf agreed to change the name of the draft to make it more clear that it's about radius options. Oops. I just realized that I closed the call for adoption five days early. If somebody had objections and didn't voice them because of this, please let me know. I'm assuming nobody did, but this was a mistake, and I don't want to just leave it unacknowledged or miss the opportunity to correct it. Sorry about this! _______________________________________________ dhcwg mailing list dhcwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dhcwg </pre> Ted Lemon 2012-05-09T15:08:02 http://permalink.gmane.org/gmane.ietf.dhc/11283 <pre>Considering DHCPv6 is somehow of big importance in the era of IPv6, CGA, as a well-fashioned IPv6 address, is going to protect DHCPv6 away from various attacks. Some efforts on the standardization of related techniques should be made. I am in favor of advancing this document. Di Ma CNNIC Advanced Research Department ___________________________________________________ China Internet Network Information Center Tel: (8610)-58813216 Https://www.cnnic.cn Add: 4, South 4th Street, Zhongguancun Haidian District, Beijing P.R.China 100190 POB: Beijing 349, Branch 6 ____________________________________________________ From: Ted Lemon Date: 2012-05-07 12:37 To: DHC WG Subject: [dhcwg] WGLC: draft-ietf-dhc-secure-dhcpv6 In the Paris meeting a show of hands indicated that the group favored bringing this document to last call. So this is the last call for this document. If you are in favor of advancing it, and have read it, please say so. If you think it needs work, please send text or suggestions. If you don't think it should advance, please say so. We will determine consensus on May 21. _______________________________________________ dhcwg mailing list dhcwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dhcwg_______________________________________________ dhcwg mailing list dhcwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dhcwg </pre> Di Ma 2012-05-08T03:48:19 http://permalink.gmane.org/gmane.ietf.dhc/11281 <pre>In the Paris meeting a show of hands indicated that the group favored bringing this document to last call. So this is the last call for this document. If you are in favor of advancing it, and have read it, please say so. If you think it needs work, please send text or suggestions. If you don't think it should advance, please say so. We will determine consensus on May 21. </pre> Ted Lemon 2012-05-07T04:37:18 http://permalink.gmane.org/gmane.ietf.dhc/11280 <pre>We will determine consensus on May 1, 2012. Nine were in favor of adopting, none opposed, so the working group has adopted this as a work item. _______________________________________________ dhcwg mailing list dhcwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dhcwg </pre> Ted Lemon 2012-05-07T04:34:50 http://permalink.gmane.org/gmane.ietf.dhc/11279 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Issues with multiple stateful DHCPv6 options Author(s) : Ole Troan Bernie Volz Filename : draft-ietf-dhc-dhcpv6-stateful-issues-00.txt Pages : 8 Date : 2012-05-06 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) was not written with the expectation that additional stateful DHCPv6 options would be developed. IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6 shoe-horned the new options for Prefix Delegation into DHCPv6. Implementation experience of the CPE model described in has shown multiple issues with the DHCPv6 protocol in supporting multiple stateful options. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-stateful-issues-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-stateful-issues-00.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-stateful-issues/ </pre> internet-drafts< at >ietf.org 2012-05-07T03:28:57 http://permalink.gmane.org/gmane.ietf.dhc/11277 <pre> Nine people were in favor of adopting this work and said so on the mailing list. Nobody spoke to oppose doing the work. So there is consensus to adopt it. Leaf agreed to change the name of the draft to make it more clear that it's about radius options. Leaf, please publish a -00 version as a working group draft when you are ready. Thanks! </pre> Ted Lemon 2012-05-04T19:44:47 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.dhc