Skip to main content

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 …
[Ballot discuss]
The second paragraph of section 8 should be edited to meet the
guidelines for IANA Registry creation in RFC 5226.  It would be
preferable to choose one of the well-known policies from section 4.1
of RFC 5226 for the new registry.
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