Relay-Supplied DHCP Options
RFC 6422
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2018-12-20
|
09 | (System) | Received changes through RFC Editor sync (changed abstract to 'DHCPv6 relay agents cannot communicate with DHCPv6 clients directly. However, in some cases, the relay agent … Received changes through RFC Editor sync (changed abstract to 'DHCPv6 relay agents cannot communicate with DHCPv6 clients directly. However, in some cases, the relay agent possesses some information that would be useful to the DHCPv6 client. This document describes a mechanism whereby the DHCPv6 relay agent can provide such information to the DHCPv6 server, which can, in turn, pass this information on to the DHCP client. This document updates RFC 3315 (DHCPv6) by making explicit the implicit requirement that relay agents not modify the content of encapsulation payloads as they are relayed back toward clients. [STANDARDS-TRACK]') |
|
2017-05-16
|
09 | (System) | Changed document authors from "Ted Lemon" to "Ted Lemon, Qin Wu" |
|
2015-10-14
|
09 | (System) | Notify list changed from dhc-chairs@ietf.org, draft-ietf-dhc-dhcpv6-relay-supplied-options@ietf.org to (None) |
|
2012-08-22
|
09 | (System) | post-migration administrative database adjustment to the No Objection position for Sean Turner |
|
2012-08-22
|
09 | (System) | post-migration administrative database adjustment to the No Objection position for Pete Resnick |
|
2012-08-22
|
09 | (System) | post-migration administrative database adjustment to the Yes position for Ralph Droms |
|
2012-08-22
|
09 | (System) | post-migration administrative database adjustment to the No Objection position for Stephen Farrell |
|
2011-12-16
|
09 | Cindy Morgan | State changed to RFC Published from RFC Ed Queue. |
|
2011-12-16
|
09 | (System) | RFC published |
|
2011-09-26
|
09 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
|
2011-09-23
|
09 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
|
2011-09-23
|
09 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2011-09-13
|
09 | (System) | IANA Action state changed to In Progress |
|
2011-09-13
|
09 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent. |
|
2011-09-13
|
09 | Cindy Morgan | IESG state changed to Approved-announcement sent |
|
2011-09-13
|
09 | Cindy Morgan | IESG has approved the document |
|
2011-09-13
|
09 | Cindy Morgan | Closed "Approve" ballot |
|
2011-09-13
|
09 | Cindy Morgan | Approval announcement text regenerated |
|
2011-09-13
|
09 | Cindy Morgan | Ballot writeup text changed |
|
2011-09-08
|
09 | Sean Turner | [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss |
|
2011-09-06
|
09 | (System) | New version available: draft-ietf-dhc-dhcpv6-relay-supplied-options-09.txt |
|
2011-08-16
|
09 | Sean Turner | [Ballot comment] |
|
2011-08-16
|
09 | Sean Turner | [Ballot discuss] Updated based on -08 #1) cleared #2) cleared Double checking with IANA on this one: #3) Place holder discuss for IANA who wants … [Ballot discuss] Updated based on -08 #1) cleared #2) cleared Double checking with IANA on this one: #3) Place holder discuss for IANA who wants to make sure the registration procedures are clear. |
|
2011-08-05
|
09 | Ralph Droms | [Ballot comment] The updates to section 8 look fine and I've cleared my Discuss. |
|
2011-08-05
|
09 | Ralph Droms | [Ballot Position Update] Position for Ralph Droms has been changed to Yes from Discuss |
|
2011-07-11
|
08 | (System) | New version available: draft-ietf-dhc-dhcpv6-relay-supplied-options-08.txt |
|
2011-07-11
|
07 | (System) | New version available: draft-ietf-dhc-dhcpv6-relay-supplied-options-07.txt |
|
2011-06-09
|
09 | Cindy Morgan | Removed from agenda for telechat |
|
2011-06-09
|
09 | Cindy Morgan | State changed to IESG Evaluation::AD Followup from IESG Evaluation. |
|
2011-06-09
|
09 | Amy Vezza | State changed to IESG Evaluation from Waiting for AD Go-Ahead. |
|
2011-06-09
|
09 | Sean Turner | [Ballot discuss] #1) Section 5 includes: Relay agents MAY include a Relay-Supplied Options option in the option payload of a Relay-Forward message. Relay … [Ballot discuss] #1) Section 5 includes: Relay agents MAY include a Relay-Supplied Options option in the option payload of a Relay-Forward message. Relay agents MUST NOT modify the contents of any message before forwarding it to the DHCP client. but RFC 3315 says: Clients MUST discard any received Relay-forward messages. so should DHCP client be replaced with DHCP server? If not then I'm really confused because I thought this message was only to be sent by the Relay Agent to the Server (i.e., never to the client). If the last sentence is not specific to the RSSO option, then isn't it an update to RFC 3315 (at least I couldn't find it in 3315)? #2) The security considerations had me scratching my head. It talks about DHCP relay agents being untrusted but 3315 includes the following: If a client message is relayed through multiple relay agents, each of the relay agents must have established independent, pairwise trust relationships. #3) Place holder discuss for IANA who wants to make sure the registration procedures are clear. |
|
2011-06-09
|
09 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-06-09
|
09 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded |
|
2011-06-09
|
09 | Jari Arkko | [Ballot comment] The document says: DHCP server implementations SHOULD have a user-configurable list of RSOO-enabled options, so that new RSOO- enabled options … [Ballot comment] The document says: DHCP server implementations SHOULD have a user-configurable list of RSOO-enabled options, so that new RSOO- enabled options do not require software to be updated. I think you mean "... administrator-configurable list ..." (the real end user should not be the one dictating what RSOO options are acceptable) |
|
2011-06-09
|
09 | Sean Turner | [Ballot comment] In Section 4: r/option should appear in an RSOO/option SHOULD appear in an RSOO ? |
|
2011-06-09
|
09 | Sean Turner | [Ballot discuss] #1) Section 5 includes: Relay agents MAY include a Relay-Supplied Options option in the option payload of a Relay-Forward message. Relay … [Ballot discuss] #1) Section 5 includes: Relay agents MAY include a Relay-Supplied Options option in the option payload of a Relay-Forward message. Relay agents MUST NOT modify the contents of any message before forwarding it to the DHCP client. but RFC 3315 says: Clients MUST discard any received Relay-forward messages. so should DHCP client be replaced with DHCP server? If not then I'm really confused because I thought this message was only to be sent by the Relay Agent to the Server (i.e., never to the client). If the last sentence is not specific to the RSSO option, then isn't it an update to RFC 3315 (at least I couldn't find it in 3315)? #2) The security considerations had me scratching my head. It talks about DHCP relay agents being untrusted but 3315 includes the following: If a client message is relayed through multiple relay agents, each of the relay agents must have established independent, pairwise trust relationships. |
|
2011-06-09
|
09 | Sean Turner | [Ballot Position Update] New position, Discuss, has been recorded |
|
2011-06-09
|
09 | Gonzalo Camarillo | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-06-08
|
09 | Ralph Droms | [Ballot discuss] The second paragraph of section 8 should be edited to meet the guidelines for IANA Registry creation in RFC 5226. It would … |
|
2011-06-08
|
09 | Ralph Droms | [Ballot Position Update] Position for Ralph Droms has been changed to Discuss from Yes |
|
2011-06-08
|
09 | Amanda Baber | [Note]: 'John Brzozowski <John_Brzozowski@Cable.Comcast.com> is the document shepherd.' added by Amanda Baber |
|
2011-06-08
|
09 | Amanda Baber | IANA has questions about the second of the two actions called for by this document. First, in the DHCP Option Codes subregistry of the Dynamic … IANA has questions about the second of the two actions called for by this document. First, in the DHCP Option Codes subregistry of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry located at: http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml#dhcpv6-parameters-2 the following option code will be registered as follows: Value: [ TBD ] Description: Relay-Supplied Options Reference: [ RFC-to-be ] Second, in the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) registry located at: http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml#dhcpv6-parameters-2 a new registry will be created. The new registry will be called "Options Permitted in the Relay-Supplied Options Option". This option will contain a list of names of options from the DHCP Option Codes list. There are no initial registrations. QUESTION: This document says, "Options may be added to this new subregistry either as a result of protocol action or expert review. Expert review may either be in the form of a working group review and consensus call, or IESG review in consultation with the DHC working group chair or chairs." However, this doesn't tell IANA what it needs to do or who it needs to consult when a request appears. Typically Expert Review, as defined in RFC 5226, means that the IESG designates one or more semi-permanent experts, who may or may not be the chairs of a working group, and who might consult ADs or the working group as they see fit. If some requests are going to require us to skip the designated experts and use the IESG Approval process (see RFC 5226) instead, IANA needs this document to explain when that should happen. Furthermore, calling for "protocol action" is an unusual directive; the first time we see an I-D is upon its arrival in IETF Last Call, and at that time we aren't told whether the classification that applies is "protocol action" or "document action." Usually when limits are set on which RFCs can make registrations, we're told that those RFCs have to be Standards Track, or have to be products of the IETF. Is it possible to substitute a requirement we can check more easily? IANA understands that these are the only actions required upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. |
|
2011-06-08
|
09 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-06-07
|
09 | Peter Saint-Andre | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-06-07
|
09 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-06-06
|
09 | Pete Resnick | [Ballot Position Update] Position for Pete Resnick has been changed to No Objection from Discuss |
|
2011-06-06
|
09 | Ralph Droms | Ballot writeup text changed |
|
2011-06-06
|
09 | Russ Housley | [Ballot comment] The Gen-ART Review by Vijay Gurbani on 2-June-2011 includes two editorial improvements. Please consider them. |
|
2011-06-06
|
09 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-06-06
|
09 | Pete Resnick | [Ballot comment] These two paragraphs from section 5: DHCP relay agents that implement this specification MUST be configurable not to send the Relay-Supplied … [Ballot comment] These two paragraphs from section 5: DHCP relay agents that implement this specification MUST be configurable not to send the Relay-Supplied Options option. Relay agents implementing this specification SHOULD have a configuration parameter that determines whether or not they will relay a Relay-Forward message toward the DHCP server if it contains a Relay-Supplied Options option. and this sentence from section 6: DHCP server implementations SHOULD have a user-configurable list of RSOO-enabled options, so that new RSOO- enabled options do not require software to be updated. seem like implementation advice, not protocol interoperability statements, and therefore are not appropriate for 2119 language. They should be re-worded. |
|
2011-06-06
|
09 | Pete Resnick | [Ballot discuss] I don't understand the following from section 5: Relay agents implementing this specification SHOULD have a configuration parameter that determines whether … [Ballot discuss] I don't understand the following from section 5: Relay agents implementing this specification SHOULD have a configuration parameter that determines whether or not they will relay a Relay-Forward message toward the DHCP server if it contains a Relay-Supplied Options option. Relay agents that have this configuration parameter and that are configured to enable this behavior MUST silently discard any Relay- Forward packet that contains a Relay-Supplied Options option. The first paragraph says that I should have a parameter to determine whether or not I will relay a Relay-Forward message if it contains an RSOO. If that parameter says the behavior is *disabled*, then I assume I don't relay these packets. But the second paragraph says if the parameter is *enabled*, I silently discard such packets. I don't get it. |
|
2011-06-06
|
09 | Pete Resnick | [Ballot Position Update] New position, Discuss, has been recorded |
|
2011-06-04
|
09 | Stephen Farrell | [Ballot comment] I added an RFC editor note for the hokey LDN draft as agreed with its authors. That's at: https://datatracker.ietf.org/doc/draft-ietf-hokey-ldn-discovery/writeup/ |
|
2011-06-04
|
09 | Stephen Farrell | [Ballot discuss] Not an issue for this document, but for one that references it that's in the RFC editor queue. Does the IANA considerations section … [Ballot discuss] Not an issue for this document, but for one that references it that's in the RFC editor queue. Does the IANA considerations section of draft-ietf-hokey-ldn-discovery need to change because of the requirement at the end of section 4 here? If so, would it be correct for me to add an RFC editor note for draft-ietf-hokey-ldn-discovery saying that the OPTION_ERP_LOCAL_DOMAIN_NAME is an RSOO? (Just clarifying that I meant an RFC editor note for the hokey document.) |
|
2011-06-04
|
09 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
|
2011-06-02
|
09 | Stephen Farrell | [Ballot discuss] Not an issue for this document, but for one that references it that's in the RFC editor queue. Does the IANA considerations section … [Ballot discuss] Not an issue for this document, but for one that references it that's in the RFC editor queue. Does the IANA considerations section of draft-ietf-hokey-ldn-discovery need to change because of the requirement at the end of section 4 here? If so, would it be correct for me to add an RFC editor note for draft-ietf-hokey-ldn-discovery saying that the OPTION_ERP_LOCAL_DOMAIN_NAME is an RSOO? (Just clarifying that I meant an RFC editor note for the hokey document.) |
|
2011-06-02
|
09 | Stephen Farrell | [Ballot discuss] Not an issue for this document, but for one that references it that's in the RFC editor queue. Does the IANA considerations section … [Ballot discuss] Not an issue for this document, but for one that references it that's in the RFC editor queue. Does the IANA considerations section of draft-ietf-hokey-ldn-discovery need to change because of the requirement at the end of section 4 here? If so, would it be correct for me to add an RFC editor note saying that the OPTIO_ERP_LOCAL_DOMAIN_NAME is an RSOO? |
|
2011-06-02
|
09 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded |
|
2011-06-02
|
09 | Ralph Droms | Ballot writeup text changed |
|
2011-06-02
|
09 | Ralph Droms | [Note]: changed to 'John Brzozowski <John_Brzozowski@Cable.Comcast.com> is the document shepherd.' |
|
2011-06-01
|
09 | David Harrington | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-06-01
|
09 | Stewart Bryant | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-06-01
|
09 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call. |
|
2011-05-26
|
09 | Wesley Eddy | [Ballot Position Update] New position, No Objection, has been recorded |
|
2011-05-19
|
09 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Brian Weis |
|
2011-05-19
|
09 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Brian Weis |
|
2011-05-18
|
09 | David Harrington | Request for Telechat review by TSVDIR is assigned to Richard Woundy |
|
2011-05-18
|
09 | David Harrington | Request for Telechat review by TSVDIR is assigned to Richard Woundy |
|
2011-05-18
|
09 | Amy Vezza | Last call sent |
|
2011-05-18
|
09 | Amy Vezza | State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: … State changed to In Last Call from Last Call Requested. The following Last Call Announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: <dhcwg@ietf.org> Reply-To: ietf@ietf.org Subject: Last Call: <draft-ietf-dhc-dhcpv6-relay-supplied-options-06.txt> (Relay-Supplied DHCP Options) to Proposed Standard The IESG has received a request from the Dynamic Host Configuration WG (dhc) to consider the following document: - 'Relay-Supplied DHCP Options' <draft-ietf-dhc-dhcpv6-relay-supplied-options-06.txt> as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a mechanism whereby a DHCPv6 relay agent can provide options to a DHCPv6 server that the DHCPv6 server can then provide to the DHCPv6 client in certain restricted cases where this is necessary. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-relay-supplied-options/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-relay-supplied-options/ No IPR declarations have been submitted directly on this I-D. |
|
2011-05-18
|
09 | Ralph Droms | Placed on agenda for telechat - 2011-06-09 |
|
2011-05-18
|
09 | Ralph Droms | Last Call was requested |
|
2011-05-18
|
09 | Ralph Droms | State changed to Last Call Requested from AD Evaluation. |
|
2011-05-18
|
09 | Ralph Droms | [Ballot Position Update] New position, Yes, has been recorded for Ralph Droms |
|
2011-05-18
|
09 | Ralph Droms | Ballot has been issued |
|
2011-05-18
|
09 | Ralph Droms | Created "Approve" ballot |
|
2011-05-18
|
09 | (System) | Ballot writeup text was added |
|
2011-05-18
|
09 | (System) | Last call text was added |
|
2011-05-18
|
09 | (System) | Ballot approval text was added |
|
2011-05-11
|
09 | Ralph Droms | State changed to AD Evaluation from Publication Requested. |
|
2011-05-09
|
09 | Cindy Morgan | (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the … (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? I (Ted Lemon <mellon@nominum.com>) am the shepherd for this document. I have personally reviewed the document, and I think it is ready to forward to the IESG for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been carefully reviewed by several experienced DHCP implementors. I have no concerns that the document has not had adequate review. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? This document is DHCP-specific, and doesn't really make use of non-DHCP terminology. I think that the usual review that the IESG gives to documents of this type should be sufficient to capture any unclear use of terminology that wasn't immediately obvious in the DHC working group. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. I am not aware of any IPR concerns, and none have been registered with the IETF. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There was substantial commentary from a variety of independent sources on the document. At least one draft (The ERP Local Domain Name DHCPv6 Option, draft-ietf-hokey-ldn-discovery-10) has a normative reference to this document, which indicates that there is demand for the work. At least one other documents that refers to this document is in the works. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) The document received substantial constructive commentary in last call; after these comments were addressed, a second last call was done; there was no objection to advancing the draft. So we don't expect any conflict on this draft. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? I just ran it through nits, and no nits were found. There are no MIBs, media types or URI types used in the document. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. There are no downward normative references. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? Yes, each of these steps has been followed in the IANA considerations section. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The document doesn't contain any such sections. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document proposes an extention to the DHCP protocol which allows a relay agent along the path to the DHCP server to propose options that will be sent to the client, in cases where the relay agent has configuration information relevant to the client that can't be conveniently configured on the DHCP server. Working Group Summary This document appeared in the working group at the beginning of 2008. There has been substantial review of this document. Document Quality The document has undergone careful review, and the working group is satisfied with its quality. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? If the document requires IANA experts(s), insert 'The IANA Expert(s) for the registries in this document are <TO BE ADDED BY THE AD>.' The document shepherd is Ted Lemon <mellon@nominum.com>. I believe the responsible A-D is Ralph Droms. |
|
2011-05-09
|
09 | Cindy Morgan | Draft added in state Publication Requested |
|
2011-05-09
|
09 | Cindy Morgan | [Note]: 'Ted Lemon (mellon@nominum.com) is the document shepherd.' added |
|
2011-05-09
|
06 | (System) | New version available: draft-ietf-dhc-dhcpv6-relay-supplied-options-06.txt |
|
2011-05-09
|
05 | (System) | New version available: draft-ietf-dhc-dhcpv6-relay-supplied-options-05.txt |
|
2011-04-19
|
09 | (System) | Document has expired |
|
2010-10-16
|
04 | (System) | New version available: draft-ietf-dhc-dhcpv6-relay-supplied-options-04.txt |
|
2010-10-12
|
03 | (System) | New version available: draft-ietf-dhc-dhcpv6-relay-supplied-options-03.txt |
|
2010-09-29
|
02 | (System) | New version available: draft-ietf-dhc-dhcpv6-relay-supplied-options-02.txt |
|
2010-09-18
|
01 | (System) | New version available: draft-ietf-dhc-dhcpv6-relay-supplied-options-01.txt |
|
2010-09-15
|
00 | (System) | New version available: draft-ietf-dhc-dhcpv6-relay-supplied-options-00.txt |