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://comments.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://comments.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 sing</pre> Gaurav Halwasia (ghalwasi 2012-05-24T15:03:25 http://comments.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 Interne</pre> internet-drafts< at >ietf.org 2012-05-23T01:01:43 http://comments.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 </pre> rfc-editor< at >rfc-editor.org 2012-05-15T22:17:55 http://comments.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. The</pre> The IESG 2012-05-11T19:30:00 http://comments.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 s</pre> Di Ma 2012-05-08T03:48:19 http://comments.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://comments.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 av</pre> internet-drafts< at >ietf.org 2012-05-07T03:28:57 http://comments.gmane.org/gmane.ietf.dhc/11268 <pre> The following errata report has been submitted for RFC3942, "Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3942&amp;eid=3204 -------------------------------------- Type: Technical Reported by: Alfred Hoenes &lt;ah&lt; at &gt;TR-Sys.de&gt; Section: 6. IANA Cons Original Text ------------- 4. change the listing of any options listed as "Tentatively-Assigned" | to "Unavailable" 18 months from this RFC's publication date and periodically thereafter as long as there is an option listed as "Tentatively-Assigned", if no un-expired Internet-Draft exists documenting the usage. Corrected Text -------------- 4. change the listing of any options listed as "Tentatively-Assigned" | to "Unassigned" 18 months from this RFC's publication date and periodically thereafter as long as there is an option listed as "Tentatively-Assigned", if no</pre> RFC Errata System 2012-04-27T10:33:57 http://comments.gmane.org/gmane.ietf.dhc/11253 <pre>The IESG has approved the following document: - 'Rebind Capability in DHCPv6 Reconfigure Messages' (draft-ietf-dhc-dhcpv6-reconfigure-rebind-10.txt) as a Proposed Standard 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-dhcpv6-reconfigure-rebind/ Technical Summary This document updates RFC 3315 to allow the Rebind message type to appear in the Reconfigure Message option of a Reconfigure message, which extends the Reconfigure message to allow a DHCPv6 server to cause a DHCPv6 client to send a Rebind message. The document also clarifies how a DHCPv6 client responds to a received Reconfigure message. Working Group Summary This document received a thorough review by the WG, and had broad support. Document Quality We are not aware of any implementations. Personnel Ted Lemon &lt;Ted.Lemon&lt; at &gt;nominum.com&gt; i</pre> The IESG 2012-04-23T17:21:30 http://comments.gmane.org/gmane.ietf.dhc/11215 <pre>(We tentatively adopted quite a few drafts in the meeting, so we're trying to space out the calls for adoption and last calls a bit—I hope the authors will bear with us.) The addr-registration draft proposes a mechanism for allowing clients to autoconfigure their address and then register that address with the DHCP server. At the meeting in Paris, there was strong consensus to adopt this as a working group item. One of the authors has requested a call for adoption to the mailing list. We already had sufficient consensus in Paris to adopt, but it's possible that there are people on the mailing list who were not present in Paris who might object. So for this reason, if you are in favor of adopting the draft, even if you raised your hand in Paris, please signify in a reply to this message. If you are against adopting the draft, please signify as well. We will determine consensus on May 1, 2012. </pre> Ted Lemon 2012-04-18T01:40:12 http://comments.gmane.org/gmane.ietf.dhc/11206 <pre>Some editorial comments about draft-ietf-dhc-dhcpv4-over-ipv6-02.txt: - Abstract page 1: IMHO the abstract is not accurate (or was written far before protocol developments), for instance the "extending DHCP client and server behavior" is clearly wrong. - 1 page 3: perhaps you should add an appendix about usage scenarios (I can provide a real one for Stateless Deterministic NAT in DS-Lite mode if you want). - 3 page 4: I prefer the term "proxy" over the term "bridge" (because bridge is very layer 2 oriented, of course all of them are instance of the more generic "gateway") - 3 page 4: On-link -&gt; On-Link (upper case L for the LCRA abbrev) - 3 page 4: if you really want to add something about multi-interface, the right place is in the LCRA definition, for example: "Note a LCRA serves only one link, e.g., the multiple link case is handled by multiple LCRA instances." - 2 page 4: TSV can listen -&gt; TSV listens - 4 page 5: UDP(figure 2(a)). -&gt; UDP (figure 2(a)). - 4 page 5: "TRA</pre> Francis Dupont 2012-04-16T13:01:55 http://comments.gmane.org/gmane.ietf.dhc/11196 <pre>This document corrects a bug in RFC2131 that forbids the DHCP server from returning a DHCP client identifier. The lack of a DHCP client identifier creates a problem in two cases: where the underlying transport has no link-layer address, and where two clients are running on the same host, supplying different client identifiers so as to present different network identities. In both of these cases, insufficient information is returned from the DHCP server to clearly identify the client that is the intended recipient of the message. The only way to fix this is to _require_ the DHCP server to return the client identifier if it receives it. This is what the proposed document does. We checked for consensus in the meeting, and four people were in favor of advancing the draft; nobody was against. I think this is actually pretty important work—it's a lingering bug in the spec which I think will come back to bite us more and more as we start getting deeper into the dual-stack transition. So if you haven't</pre> Ted Lemon 2012-04-14T12:54:58 http://comments.gmane.org/gmane.ietf.dhc/11189 <pre>At the Paris IETF-83 DHC WG meeting, we present this draft. There was a lot of support for (and no opposition) adopting this as a DHC WG document. I kindly request that we adopt this document as a DHC WG document. Best regards, Sheng Jiang </pre> Sheng Jiang 2012-04-12T09:18:14 http://comments.gmane.org/gmane.ietf.dhc/11180 <pre>Hi Ted, DHC WG was in favor of doing WGLC for http://tools.ietf.org/html/draft-ietf-dhc-client-id-02 during Paris Meeting. Requesting you to kindly do the WGLC for this WG draft. Thanks, Gaurav _______________________________________________ dhcwg mailing list dhcwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dhcwg </pre> Gaurav Halwasia (ghalwasi 2012-04-11T04:10:36 http://comments.gmane.org/gmane.ietf.dhc/11175 <pre>Hello, during the WG meeting in Paris, there was a brief discussion around the subject and the authors asked me to take it to the list. For context: the CRA behavior in section 6 implies that somehow CRA knows 1:1 mapping between server responses, received over IPv6, and IPv4 interfaces where decapsulated DHCPv4 packets should be indicated. The mechanism how CRA knows that is unclear in case there are multiple IPv4 interfaces on the host. It would be useful to add text, that discusses whether multiple IPV4 interfaces are in scope, and if they are - what are the possible ways how they can be handled, and what's the recommended way. If there are multiple ways and all of them are equally preferrable and won't affect interoperability, having such analysis&amp;language would be helpful too. -Dmitry _______________________________________________ dhcwg mailing list dhcwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dhcwg </pre> Dmitry Anipko 2012-04-10T05:18:47 http://comments.gmane.org/gmane.ietf.dhc/11169 <pre>Hi, I finally found some time to read the draft. I do support this work and its adoption (if requested), but I suggest several changes to the text. First and foremost, I agree with Ted's and Bernie's comments. Please pick design 2 and make this a single option that is a container for any Radius options. Here's my opinion why design 1 is very bad. For specific use cases author chose 2 options: pool name and prefix auth, but I'm sure there are cases when other Radius attributes may be useful. There are 160 Radius attributes defined so far. Please do not turn this into one to one Radius to DHCPv6 option translator. Much better approach is to define a single container that conveys required Radius attributes. Don't worry about extra processing required on DHCPv6 server side. Many servers are smart enough to do processing of received options. For example ISC DHCP is able to play various tricks like fancy to string conversion, sub-string search etc. I'm sure other implementations can do similar processing. Also,</pre> Tomek Mrugalski 2012-04-08T22:06:40 http://comments.gmane.org/gmane.ietf.dhc/11157 <pre>At the Paris IETF-83 DHC WG meeting there was a lot of support for (and I believe no opposition) adopting this as a DHC WG item. I kindly request that we adopt this document as a DHC WG work item. - Bernie _______________________________________________ dhcwg mailing list dhcwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dhcwg </pre> Bernie Volz (volz 2012-04-05T17:25:25 http://comments.gmane.org/gmane.ietf.dhc/11155 <pre> Hello Shwetha, hello all As a follow up of the discussion we have had in Paris, please a few comments on this very interesting ID 1. As opposed to the "OPTION_USER_CLASS" whose semantics is undefined and whose impact to the system is loosely defined, the new "PREFIX_CLASS option" allows a well defined structure to ensure inter-operability beyond a corporate proprietary usage, i.e. to make sure that different organisations cannot allocate the same value for the "PREFIX_CLASS option". Indeed the definition and structure and indication of usage of the "User Class Option" is too loose to guarantee inter-operability beyond a corporate deployment 22.15. User Class Option The User Class option is used by a client to identify the type or category of user or applications it represents. ... The information contained in the data area of this option is contained in one or more *opaque* fields that represent the user class or classes of which the client is a member. A server selects configuration informat</pre> THIEBAUT, LAURENT (LAURENT 2012-04-05T12:46:01 http://comments.gmane.org/gmane.ietf.dhc/11151 <pre>Dear all, Softiwre WG adopted recently this document: http://tools.ietf.org/html/draft-ietf-softwire-multicast-prefix-option-00 Comments from DHC WG are are more than welcome. Thanks. Cheers, Med _______________________________________________ dhcwg mailing list dhcwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dhcwg </pre> mohamed.boucadair< at >orange.com 2012-04-04T06:35:46 http://comments.gmane.org/gmane.ietf.dhc/11149 <pre>Ole submitted the draft-troan-dhc-dhcpv6-stateful-issues-00 draft just before the Paris IETF DHC WG meeting and I presented the http://www.ietf.org/proceedings/83/slides/slides-83-dhc-15.pdf slides at that meeting. Please look over the draft and slides as we are hoping to fast-track these RFC 3315/3633 changes for the RFC 6204bis work. In thinking about this some more since, I believe that encouraging use of Renew (section 3.4 and "Confirm / Renew Handling" slide) is not the best. This "Renew" was to follow the RFC 3633 (section 12.1) requirements: If such verification is needed the requesting router MUST initiate a Rebind/Reply message exchange as described in section 18.1.4, "Creation and Transmission of Rebind Messages" of RFC 3315, with the exception that the retransmission parameters should be set as for the Confirm message, described in section 18.1.2, "Creation and Transmission of Confirm Messages" of RFC 3315. The requesting router includes any IA_PDs, along wi</pre> Bernie Volz (volz 2012-04-02T15:56:08 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.dhc