Network Working Group R. Droms
Intended status: Standards Track B. Volz
Expires: October 3, 2017 Cisco Systems
O. Troan
Cisco Systems, Inc.
April 1, 2017

DHCPv6 Relay Agent Assignment Notification (RAAN) Option


The DHCP Relay Agent Assignment Notification (RAAN) option is sent from a DHCP server to a DHCP relay agent to inform the relay agent of IPv6 addresses that have been assigned or IPv6 prefixes that have been delegated to DHCP clients.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on October 3, 2017.

Copyright Notice

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

The DHCP Relay Agent Assignment Notification (RAAN) option encapsulates address and prefix options to indicate that an address or prefix has been assigned. The option may also carry other information required by the network element for configuration related to the assigned address or prefix.

For example, a relay agent uses the RAAN option to learn when a prefix that has been delegated through DHCP prefix delegation (PD) to a DHCP client. The relay agent notifies the network element on which it is implemented of the delegation information so the network element can add routing information about the delegated prefix into the routing infrastructure.

While the practice to date for DHCPv6 has been for the relay agents to "snoop" the client's message (encapsulated in the received Relay Message option, and which is forwarded to the client), this will no longer be possible when clients and servers use [I-D.ietf-dhc-sedhcpv6] to encrypt their communication.

Use of the RAAN option has another benefit in that the Reply to a client's Release message, which does not have any useful information for the relay agent about the addresses or delegated prefixes the client released, can now communicate this information in the RAAN option to the relay agent.

2. Requirements Language and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] when they appear in ALL CAPS. When these words are not in ALL CAPS (such as "should" or "Should"), they have their usual English meanings, and are not to be interpreted as [RFC2119] key words.

The term "DHCP" in this document refers to DHCP for IPv6, as defined in [RFC3315]. The terms "DHCP prefix delegation" and "DHCP PD" refer DHCP for IPv6 prefix delegation, as defined in [RFC3633].

Additional terms used in the description of DHCP and DHCP prefix delegation are defined in RFC 3315 and RFC 3633. In this document "assigning" an IPv6 prefix is equivalent to "delegating" a prefix.

3. Option Semantics and Usage

The RAAN option carries information about assigned IPv6 addresses and prefixes. It encapsulates IA Address options (RFC 3315) and/or IA Prefix options (RFC 3633), and possibly other options that carry other information related to the assigned IPv6 address or prefix.

The DHCP server is responsible for synchronizing any state created by a node through the use of the RAAN option. For example, if a DHCP server receives a Release message for a delegated prefix, it causes the node to delete any state associated with that prefix by sending a RAAN option containing an IA Prefix option with the released prefix and a valid lifetime of zero.

When a DHCP server sends this option to a relay agent, it MUST include all addresses and prefixes assigned to the client on the link to which the option refers at the time the option is sent.

Examples of use:

Populate an ACL with an assigned IPv6 address if the network security policy requires limiting IPv6 forwarding to devices that have obtained an address through DHCP.
Inject routing information into a routing infrastructure about a delegated prefix on behalf of a requesting router.

4. Relay Agent Behavior

A relay agent that wants information from the server in a RAAN option includes an ORO requesting the RAAN option in its Relay-Forw message. A relay agent may do this for any relayed message, regardless of the message type or the message contents.

When a relay agent receives a Relay-Reply message containing a RAAN option, the relay agent may forward that option data to the node in which the relay agent is instantiated. If no RAAN option is included in the Relay-Reply, the relay agent MUST NOT assume anything with regard to RAAN data and MUST NOT forward any indication to the node in which the relay agent is instantiated.

If a node creates state based on the information included in this option, it MUST remove that state when the lifetime as specified in the option expires.

One concern with the RAAN option is that messages from the DHCP server may be received (or processed) out of order. But this concern is no different than that for the "snooping" which has been used by relay agents for many years (both in DHCPv4 and DHCPv6). Implementers should be aware of this and should consider making use of Leasequery ([RFC5007]) to resolve conflicts.

5. Server Behavior

When a server is responding to a request and the ORO contains an RAAN option, the server SHOULD include a RAAN option with all of the addresses and prefixes that have been (or are being assigned) to the client. If no addresses or prefixes are assigned, the server SHOULD send a RAAN option with no addresses or prefixes.

If the DHCP server does include this option in a Relay-Reply message, it MUST include it in the option area of the Relay-Reply message sent to the relay agent intended as the recipient of the option.

If the message received from the client contains no Client Identifier option or the server is otherwise unable to identify the client or the client's link (perhaps because of missing or invalid data in the request), the server MUST NOT include a RAAN option in the response.

6. Option Format

The RAAN option has the following format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    |         option-code           |            length             |
    .                                                               .
    .                      encapsulated-options                     .
    .                                                               .


Figure 1: Relay Agent Assignment Notification Option Format

Length of encapsulated options, in octets.
DHCP options to be delivered by the relay agent Assignment Notification option.

7. Encapsulating DHCP Options in the RAAN Option

The contents of options encapsulated in the RAAN option are interpreted according to the use of those options in the node on which the relay agent is implemented. For the purposes of address and prefix assignment, the uses of the DHCP IA Address and IA Prefix options are defined in this document.

Note that the contents of these options are not necessarily the same as in the corresponding options sent to the DHCP client.

7.1. IA Address Option

The fields in an IA Address option (OPTION_IAADDR, option code 5) are used as follows:

IPv6 address
The IPv6 address assigned in this DHCP message
Not used by the relay agent; the server SHOULD set this field to the preferred-lifetime of the corresponding IA Address options in the message to be forwarded to the client
The lifetime of the information carried in this IA Address option, expressed in units of seconds; if the valid-lifetime is 0, the information is no longer valid
Not used by the relay agent; the server SHOULD set this field to the IAaddr-options of the corresponding IA Address option in the message to be forwarded to the client

7.2. IA Prefix Option

The fields in an IA Prefix option (OPTION_IAPREFIX, option code 28) are used as follows:

Not used by the relay agent; the server SHOULD set this field to the preferred-lifetime of the corresponding IA Prefix options in the message to be forwarded to the client
The lifetime of the information carried in this IA Prefix option, expressed in units of seconds; if the valid-lifetime is 0, the information is no longer valid
Length for this prefix in bits
The IPv6 prefix assigned in this DHCP message
Not used by the relay agent; the server SHOULD set this field to the IAprefix-options of the corresponding IA Prefix option in the message to be forwarded to the client

8. Requesting Assignment Information from the DHCP Server

If a relay agent requires the DHCP server to provide information about assigned addresses and prefixes, it MUST include an Option Request option, requesting the Assignment Notification option, as described in section 22.7 of RFC 3315.

9. IANA Considerations

IANA is requested to assign an option code from the "DHCPv6 and DHCPv6 options" registry to OPTION_AGENT_NOTIFY.

10. Security Considerations

Security issues related to DHCP are described in RFC 3315 and RFC 3633.

The RAAN option may be used to mount a denial of service attack by causing a node to incorrectly populate an ACL or incorrectly configure routing information for a delegated prefix. This option may also be used to insert invalid prefixes into the routing infrastructure or add invalid IP addresses to ACLs in nodes. Communication between a server and a relay agent, and communication between relay agents, can be secured through the use of IPSec, as described in [I-D.ietf-dhc-relay-server-security].

11. Changes Log

If this section is included in the document when it is submitted for publication, the RFC Editor is requested to remove it.

Changes in rev -01:

Added section describing use of "Server Reply Sequence Number" option to allow resequencing of out-of-order messages.

Changes in rev -02:

Made editorial change in section 1: s/the appropriate routing protocols/the routing infrastructure/
Updated first paragraph in Section 3 to allow multiple IA Address options and/or IA Prefix options
Renamed section 3 to "Options Semantics and Usage"
Added paragraph to section "Option Semantics and Usage" requiring that the DHCP server must include all addresses/prefixes for the client (on that link) in the RAAN option
Added list of use cases to section "Option Semantics and Usage"
Added section "Relay Agent Behavior"
Added section "Server Behavior"; moved second paragraph of section "Option Semantics and Usage" to "Server Behavior"
Updated reference to draft-ietf-dhc-dhcpv6-srsn-option-00
Clarified descriptions of various option fields in section "Encapsulating DHCP options in the RAAN Option"

Changes in rev -03: refreshed after expiration.

Changes in rev -04: all references to the "Server Reply Sequence Number" option were removed from the draft.

Changes in rev -05:

Converted the -04 text version to xml.
Updated introduction to add motivation for option because of [I-D.ietf-dhc-sedhcpv6], and also Reply to Release "snooping" issues.
Updated security considerations to reference IPsec document ([I-D.ietf-dhc-relay-server-security]).

12. References

12.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, DOI 10.17487/RFC3633, December 2003.

12.2. Informative References

[I-D.ietf-dhc-relay-server-security] Volz, B. and Y. Pal, "Security of Messages Exchanged Between Servers and Relay Agents", Internet-Draft draft-ietf-dhc-relay-server-security-04, March 2017.
[I-D.ietf-dhc-sedhcpv6] Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T. and D. Zhang, "Secure DHCPv6", Internet-Draft draft-ietf-dhc-sedhcpv6-21, February 2017.
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B. and S. Zeng, "DHCPv6 Leasequery", RFC 5007, DOI 10.17487/RFC5007, September 2007.

Authors' Addresses

Ralph Droms EMail:
Bernie Volz Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719, USA EMail:
Ole Troan Cisco Systems, Inc. Oslo, Norway EMail: