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 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://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 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://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 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://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. 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://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 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://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 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://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 un-expired Internet-Draft exists documenting the usage. Notes ----- The body of the RFC clearly states in Section 4, bullet 4. that the IANA action desired by the RFC is to make these code points available for assignment after the 18-month grace period. This Errata Note is tagged as "Technical" because the inconsistency between the IANA Considerations and the body of the RFC apparently has caused IANA to not follow the body and spirit of the RFC -- at the time this Errata Note is being filed, there are several entries left in the BOOTP+DHCP parameters option codes registry that should have been cleaned up and made available for assignment since the publication of RFC 3942 in November 2004. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3942 (draft-ietf-dhc-reclassify-options-01) -------------------------------------- Title : Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options Publication Date : November 2004 Author(s) : B. Volz Category : PROPOSED STANDARD Source : Dynamic Host Configuration Area : Internet Stream : IETF Verifying Party : IESG </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; is the Document Shepherd. Brian Haberman is the Responsible AD. RFC Editor Note The last sentence of Section 7 should be changed from: OLD: Cryptographically Generated Addresses (CGA) [RFC3972], can provide source address ownership validation, message origin authentication and message integrity without requesting symmetric key pairs or supporting from any key management system. NEW: Cryptographically Generated Addresses (CGA) [RFC3972] can provide source address (for the DHCP server/relay) ownership validation, message origin authentication, and message integrity without requiring symmetric key pairs or support from a key management system. </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 also communicates with a regular DHCPv4 server" is not fully true. The DHCPv4 server needs to handle CRA6ADDR suboptions, but note: * it is possible some DHCPv4 server provides a config hook for unknown RAI suboption, in this case the server code is not changed * I don't believe too much in the previous item because an IPv6 address is not an opaque string of 16 bytes, i.e., there is an easy update to the server code which makes it suitable to handle CRA6ADDR suboptions... I don't know what to put here. Perhaps the current text is the best? - 4 page 5: Option(Option 82) -&gt; Option (Option 82) or (better) Option (Option code 82) - 5 page 6: I can't get the intended meaning of "extract the semantic of IPv6 address". Perhaps it should be: "extract the IPv6 address"? - 6 page 7: I am not sure the MUST for the global address is really required, perhaps a SHOULD is enough? BTW you don't require any thing about the server/agent configured addresses... - 6 page 7: if it has onbe. -&gt; if it has one. - 6 page 7: I don't buy the coexistence of a LCRA and a TRA because in this case it is far simpler to use a plain DHCPv4 relay. Note without a good reason to keep it the SHOULD fro LCRA could be upgraded to a MUST. - 6 page 7: the LCRA MUST serve any client on the link -&gt; SHOULD (note the RFC 2131 doesn't require something to a relay :-) - 6 page 7: in the last sentence of 6 I'd like to get Tomasz's (Tomasza) idea: a CRA MUST be configured to serve either as a CRA or a LCRA, i.e., there is a configuration knob with no default. - 6 page 7: about: A TSV can also listen on IPv4 UDP port 67 like a normal DHCPv4 server, and process normally when receives IPv4 DHCPv4 message. I coded this (i.e., a server which can support both standard DHCPv4, including of course behind a TRA, and the TSV function). So perhaps it is the time for a more visible MAY? - 7 page 8: if I have no concern about the "regular" in 4, this: This document places no new requirements on DHCPv4 servers that do not listen on UDPv6--in order to use an IPv4-only DHCPv4 server through an IPv6 connection, a TRA is required. is wrong. I suggest to add "other than to support the CRA6ADDR sub-option [section 5]" - 11 page 9: please ask Tomasz if he prefers Tomasz over the diminutive Tomek. - 12 page 9: the pagination is a disaster... Thanks Francis.Dupont&lt; at &gt;fdupont.fr PS: I found in RFC 2131 this very interesting section: 3.6 Use of DHCP in clients with multiple interfaces A client with multiple network interfaces must use DHCP through each interface independently to obtain configuration information parameters for those separate interfaces. </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 read the document, please do. If you support advancing it, please signify by replying to this message and saying that you support it. If you think it's a bad idea, please signify by replying to this message and explaining why. If you have comments or changes to propose, please send them along, and also signify whether you are in favor of advancement with the change, without the change, or oppose advancement. We will determine consensus on April 27, based solely on responses on the mailing list, so please do respond. Thanks! </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, that is the same approach that was chosen for DHCPv4 (as defined in RFC4014). It works in v4 and the principles are the same, so keep it the same in v6. Having one container option is also forward compatible with any new radius options that may be defined in the future. 1. Introduction - I'm not sure if introductory paragraph about DHCPv6 with all references to all those RFCs is needed. If you think that is useful, a one short sentence with reference to 3315 will do the trick. If you really want to keep those references, make most of them informative. Normative references are the ones that are required to understand your proposal. In this context RFC3646 is informative as it only provides background information. I think simple reference to primary Radius IPv6 RFC will do as well. I'm not a Radius expert, so it you think that keeping those detailed references are useful, I won't object. Please consider if all of them must be kept normative, though. Perhaps informative will be enough. 2. I would strongly suggest to rename that option to OPTION_RADIUS. This name will instantly tell everyone what that option conveys. Authorization may mean many different things in different contexts. 3. In option format specified in Section 4, option name is typically written in all uppercase (OPTION_AUTHORIZATION rather than Option_Authorization). 4. Section that defines an option often briefly specifies it usage. It may be useful to add couple of sentences there: Client MUST NOT send this option. Client MUST ignore this option if received. Relays MAY include this option in RELAY-FORW messages. Server SHOULD NOT/MUST NOT include it in RELAY-REPL messages. 5. I would reword first sentence in "Relay Agent Behavior" (section 6). "The DHCPv6 relay agent must include Option_Authorization in the relay-forward (12) message..." =&gt; "The DHCPv6 relay agent that supports this mechanism SHOULD include OPTION_RADIUS in the relay-forward message...". (SHOULD instead of must). 6. It would be useful to say that relay does not have to include all RADIUS attributes, just those that would be useful. 7. Negative case. I'm not sure if I understand that correctly, but what happens if a client is not authorized by Radius? Should relay drop the message? Or do you want relay to forward client's message with the negative radius response and finally server is expected to not assign addresses/prefixes? Some kind of clarification about that could be useful. 8. In section 6. you should also mention that relay MUST ignore received incoming OPTION_RADIUS (server should not echo it back, right?). 9. In "Server Behavior" section it is better to say: "The DHCPv6 server MAY use received RADIUS option to pick appropriate addresses, options and delegate prefixes.". 10. I assume that server does not echo RADIUS option back, right? Something to that effect should be added in Section 7. Also, in Fig. 1 you could add extra space between (Option_Authorization) and Relay-reply lines to show that Authorization/Radius option is expected to appear in relay-forward message only, not in both relay-forward and relay-reply. 11. While clients are not expected to ever see this option, it would be explicitely state that using normative language. Something like "Client MUST NOT send RADIUS option. Client MUST ignore received RADIUS option." 12. Are there any security considerations that are specific to RADIUS? You should probably point to a security considerations section in some RADIUS RFC. 13. As a sole author, I'm not sure if that makes sense to mark your role as editor. Despite quite a few comments, I support this work. It looks useful and I'm quite surprised that RADIUS option was not defined yet. Cheers, Tomek </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 information for the client based on the classes identified in this option. For example, the User Class option can be used to configure all clients of people in the accounting department with a different printer than clients of people in the marketing department. The user class information carried in this option MUST be configurable on the client. ...... (The "User Class Option" can't be used in a non proprietary context as different organisations can by accident allocate the same value to this information) This comment is an &lt; endorsement" of draft-bhandari-dhc-class-based-prefix 2. The "PREFIX_CLASS option" should allow to specify * Prefix-classes defined by IETF * Prefix classes defined by other standard fora * (proprietary) Prefix classes defined by a corporate 3. The proposed structure would be as follows * "Prefix class name space" with 2 values: "IETF" / "other organisation" * "Prefix class owner" (required in case the "Prefix class name space" is "other organisation", not present when "Prefix class name space" is "IETF"). Other organisation may be another standard forum (e.g. BBF) or a corporate. * "Prefix class value" whose structure depends on the "Prefix class name space" and "Prefix class owner" 4. As the "User Class Option" does not benefit from such structure it cannot be used beyond a corporate proprietary usage. Thus the "User Class Option" cannot provide an interoperable parameter to be used when a DHCP client sends an Information-Request message to obtain (IP) configuration information. Following alternatives may be envisaged: a) Either the "PREFIX_CLASS option" is used in Information-Request. It is agreed that the name "PREFIX_CLASS option" would then not be well suited for usage in Information-Request and that thus the name of this option should be changed. b) Another possibility is to define a "configuration-information-class option" whose semantics is explicitly made the same as the "PREFIX_CLASS option" and to be used as follows: o The DHCP client puts a "configuration-information-class option"in Information-Request to request that the IP parameters values sent by the DHCP server are determined as the most suitable for the IP service associated with the "configuration-information-class option" o when a DHCPv6 client sends a SOLICIT message to request both * for IA_NA address allocation from a specific prefix class * and to obtain (IP) configuration information using Option Request option (per RFC 3315 section 22.7) it populates the SOLICIT message as follows: * within the IA_NA option, it includes the OPTION_PREFIX_CLASS requesting address to be allocated from a specific prefix class indicated in that option * within the Option Request option (per RFC 3315 section 22.7) it includes the "configuration-information-class option" requesting configuration parameters sent by the DHCP server are determined as the most suitable for the IP service associated with the "configuration-information-class option". If these comments are felt useful, I can provide actual text for the draft. Best regards Laurent _______________________________________________ dhcwg mailing list dhcwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dhcwg </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 with prefixes associated with those IA_PDs in its Rebind message. From RFC 3315: The first Confirm message from the client on the interface MUST be delayed by a random amount of time between 0 and CNF_MAX_DELAY. The client transmits the message according to section 14, using the following parameters: IRT CNF_TIMEOUT MRT CNF_MAX_RT MRC 0 MRD CNF_MAX_RD CNF_MAX_DELAY 1 sec Max delay of first Confirm CNF_TIMEOUT 1 sec Initial Confirm timeout CNF_MAX_RT 4 secs Max Confirm timeout CNF_MAX_RD 10 secs Max Confirm duration Renew is effectively "unicast" to the server that granted the lease(s). Thus: 1. If the client has indeed moved to a new location, or 2. If the client has not moved, but that server is down, The client must always wait 10 seconds (CNF_MAX_RD) before transitioning to sending Rebinds before it can hope to get any feedback (if there is another server present). In many cases, perhaps other information (such as receipt of RAs) might already indicate to the client whether it has likely moved or not? In these cases either using the Confirm or immediately starting with a Rebind has a 10 second advantage. Note also that Confirm has the other advantages outlined in the presentation: 1. It is clear what the client is attempting to do as it doesn't overload the Renew/Rebind requests. 2. It has significant less load on the server since the server does not need to (potentially) extend lifetimes or otherwise record anything about the client/server interaction with respect to these leases (which eliminates any possibility of a write by the server which is generally expensive - especially in a situation where lots of clients might be doing this). The one disadvantage to Confirm is that it provides no useful information to any Relay Agent (CMTS in particular) that might be wanting to gleam information from the transaction. There may also be situations where the Confirm, if used, can't determine if the client has or has not moved in which case the client will get no response to its Confirm - RFC 3315, Section 18.1.2 then states the client SHOULD continue to use the previously obtained information. So what do others think? Do we not consider the 10 second delay to be significant and worth addressing? Do we consider the additional server cost of doing Renew/Rebind processing an issue? - Bernie _______________________________________________ dhcwg mailing list dhcwg&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/dhcwg </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