<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc category="std" 
     docName="draft-ietf-dhc-dhcpv6-agentopt-delegate-05.txt"
     ipr="trust200902">
  <front>
    <title abbrev="DHCPv6 Assignment Notification Option">
    DHCPv6 Relay Agent Assignment Notification (RAAN) Option</title>

    <author initials="R" surname="Droms" fullname="Ralph Droms">
      <organization></organization>
      <address>
        <postal>
          <street></street>
          <city></city>
          <region></region>
          <code></code>
          <country></country>
        </postal>
        <email>rdroms.ietf@gmail.com</email>
      </address>
    </author>

    <author fullname="Bernie Volz" initials="B" surname="Volz">
      <organization abbrev="Cisco Systems">Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>1414 Massachusetts Ave</street>
          <city>Boxborough, MA  01719</city>
          <region></region>
          <code></code>
          <country>USA</country>
        </postal>
        <email>volz@cisco.com</email>
      </address>
    </author>

    <author initials="O" surname="Troan" fullname="Ole Troan">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street></street>
          <city>Oslo</city>
          <region></region>
          <code></code>
          <country>Norway</country>
        </postal>
        <email>otroan@cisco.com</email>
      </address>
    </author>

    <date year="2017" />

    <area>Internet</area>

    <workgroup>Network Working Group</workgroup>

    <!--  SECTION 0:  Abstract                      -->

    <abstract>
      <t>
   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.
      </t>

    </abstract>
  </front>

  <middle>
    <!--  SECTION 1:  Introduction                  -->

    <section title="Introduction">

      <t>
   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.
      </t>

      <t>
   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.
      </t>

      <t>
    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
    <xref target="I-D.ietf-dhc-sedhcpv6"/> to encrypt their communication.
      </t>

      <t>
     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.
      </t>

    </section>

    <!--  SECTION 2: Terminology                                         -->

    <section title="Requirements Language and Terminology">

      <t>
   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 <xref target="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 <xref target="RFC2119"/> key words.
      </t>

      <t>
   The term "DHCP" in this document refers to DHCP for IPv6, as defined
   in <xref target="RFC3315"/>.  The terms "DHCP prefix delegation" and "DHCP
   PD" refer DHCP for IPv6 prefix delegation, as defined in
   <xref target="RFC3633"/>.
      </t>

      <t>
   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.
      </t>

    </section>

    <section title="Option Semantics and Usage">

      <t>
   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.
      </t>

      <t>
   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.
      </t>

      <t>
   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.
      </t>

      <t>
   Examples of use:
      <list hangIndent="3" style="hanging">
      <t hangText="o">
      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.
      </t>
      <t hangText="o">
      Inject routing information into a routing infrastructure about a
      delegated prefix on behalf of a requesting router.
      </t>
      </list>
      </t>

    </section>

    <section title="Relay Agent Behavior">

     <t>
   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.
      </t>

      <t>
   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.
      </t>

      <t>
   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.
      </t>
        
      <t>
   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
   (<xref target="RFC5007"/>) to resolve conflicts.
      </t>        

    </section>

    <section title="Server Behavior">

     <t>
   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.
      </t>

      <t>
   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.
      </t>

      <t>
   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.
      </t>

    </section>

    <section title="Option Format">

      <t>
   The RAAN option has the following format:
      </t>

      <figure align="center" anchor="RAAN-Option"
              title="Relay Agent Assignment Notification Option Format">
        <preamble></preamble>

        <artwork align="left"><![CDATA[

     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                     .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        ]]></artwork>

        <postamble></postamble>
      </figure>

        <t><list hangIndent="21" style="hanging">
            <t hangText="option-code">OPTION_AGENT_NOTIFY (TBD).</t>

            <t hangText="option-len">Length of encapsulated options, in octets.</t>

            <t hangText="encapsulated-options">DHCP options to be delivered by the relay agent
                        Assignment Notification option.</t>
          </list></t>

    </section>

    <section title="Encapsulating DHCP Options in the RAAN Option">

      <t>
   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.
      </t>

      <t>
   Note that the contents of these options are not necessarily the same
   as in the corresponding options sent to the DHCP client.
      </t>

    <section title="IA Address Option">

      <t>
   The fields in an IA Address option (OPTION_IAADDR, option code 5) are
   used as follows:

        <list hangIndent="21" style="hanging">
            <t hangText="IPv6 address">
                The IPv6 address assigned in this DHCP message
            </t>

            <t hangText="preferred-lifetime">
                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
            </t>

            <t hangText="valid-lifetime">
                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
            </t>

            <t hangText="IAaddr-options">
                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
            </t>
        </list>
      </t>
    </section>

    <section title="IA Prefix Option">

      <t>
   The fields in an IA Prefix option (OPTION_IAPREFIX, option code 28)
   are used as follows:

        <list hangIndent="21" style="hanging">
            <t hangText="preferred-lifetime">
                       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
           </t>

           <t hangText="valid-lifetime">
                       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
           </t>

           <t hangText="prefix-length">
                       Length for this prefix in bits
           </t>

           <t hangText="IPv6-prefix">
                       The IPv6 prefix assigned in this DHCP message
           </t>

           <t hangText="IAprefix-options">
                       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
           </t>
           </list>
      </t>

    </section>

    </section>

    <section title="Requesting Assignment Information from the DHCP Server">

      <t>
   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.
      </t>

    </section>

    <section title="IANA Considerations">

      <t>
   IANA is requested to assign an option code from the "DHCPv6 and
   DHCPv6 options" registry
   http://www.iana.org/assignments/dhcpv6-parameters to
   OPTION_AGENT_NOTIFY.
      </t>

    </section>

    <section title="Security Considerations">

      <t>
   Security issues related to DHCP are described in RFC 3315 and RFC
   3633.
      </t>

      <t>
   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 <xref target="I-D.ietf-dhc-relay-server-security"/>.
      </t>

    </section>

    <section title="Changes Log">

      <t>
   If this section is included in the document when it is submitted for
   publication, the RFC Editor is requested to remove it.
      </t>

      <t>
   Changes in rev -01:
      <list hangIndent="6" style="hanging">
      <t hangText="   o">
      Added section describing use of "Server Reply Sequence Number"
      option to allow resequencing of out-of-order messages.
      </t>
      </list>
      </t>

      <t>
   Changes in rev -02:
      <list hangIndent="6" style="hanging">
      <t hangText="   o">
      Made editorial change in section 1: s/the appropriate routing
      protocols/the routing infrastructure/
      </t>
      <t hangText="   o">
      Updated first paragraph in Section 3 to allow multiple IA Address
      options and/or IA Prefix options
      </t>
      <t hangText="   o">
      Renamed section 3 to "Options Semantics and Usage"
      </t>
      <t hangText="   o">
      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
      </t>
      <t hangText="   o">
      Added list of use cases to section "Option Semantics and Usage"
      </t>
      <t hangText="   o">
      Added section "Relay Agent Behavior"
      </t>
      <t hangText="   o">
      Added section "Server Behavior"; moved second paragraph of section
      "Option Semantics and Usage" to "Server Behavior"
      </t>
      <t hangText="   o">
      Updated reference to draft-ietf-dhc-dhcpv6-srsn-option-00
      </t>
      <t hangText="   o">
      Clarified descriptions of various option fields in section
      "Encapsulating DHCP options in the RAAN Option"
      </t>
      </list>
      </t>

      <t>
   Changes in rev -03: refreshed after expiration.
      </t>

      <t>
   Changes in rev -04: all references to the "Server Reply Sequence
   Number" option were removed from the draft.
      </t>

      <t>
   Changes in rev -05:
      <list hangIndent="6" style="hanging">
          <t hangText="   o">
              Converted the -04 text version to xml.
          </t>
          <t hangText="   o">
              Updated introduction to add motivation for option because
              of <xref target="I-D.ietf-dhc-sedhcpv6"/>, and also Reply
              to Release "snooping" issues.
          </t>
          <t hangText="   o">
              Updated security considerations to reference IPsec
              document (<xref target="I-D.ietf-dhc-relay-server-security"/>).
          </t>
      </list>
      </t>
        
    </section>

  </middle>

  <back>
    <!--  SECTION:  Normative References		-->

    <references title="Normative References">
      <?rfc include='reference.RFC.2119'?>
      <?rfc include='reference.RFC.3315'?>
      <?rfc include='reference.RFC.3633'?>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.5007'?>
      <?rfc include='reference.I-D.ietf-dhc-sedhcpv6'?>
      <?rfc include='reference.I-D.ietf-dhc-relay-server-security'?>
    </references>

  </back>
</rfc>
