<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5460.xml">
<!ENTITY RFC7283 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7283.xml">
<!ENTITY RFC7513 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7513.xml">
<!ENTITY RFC7653 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7653.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8213 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8213.xml">
<!ENTITY RFC8415 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8415.xml">
]>
<?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-pd-relay-requirements-00" ipr="trust200902">

<front>
  <title abbrev="DHCPv6 PD Relay">DHCPv6 Prefix Delegating Relay</title>

  <author fullname="Ian Farrer" initials="I.F." surname="Farrer">
    <organization>Deutsche Telekom AG</organization>
    <address>
      <postal>
        <street>Landgrabenweg 151</street>
        <city>Bonn</city>
        <region>NRW</region>
        <code>53227</code>
        <country>DE</country>
      </postal>
      <email>ian.farrer@telekom.de</email>
    </address>
  </author>

  <author fullname="Naveen Kottapalli" initials="Naveen" surname="Kottapalli"> 
    <organization>Benu Networks</organization>
    <address>
      <postal>
        <street>300 Concord Road</street>
        <city>Billerica</city>
        <code>01821</code>
        <region>MA</region>
        <country>US</country>
      </postal>
      <email>naveen.sarma@gmail.com</email>
    </address>
  </author>

  <author fullname="Martin Hunek" initials="M" surname="Hunek">
    <organization>Technical University of Liberec</organization>
    <address>
      <postal>
        <street>Studentska 1402/2</street>
        <city>Liberec</city>
        <code>46017</code>
        <region>L</region>
        <country>CZ</country>
      </postal>
      <email>martin.hunek@tul.cz</email>
    </address>
  </author>

  <author fullname="Richard Patterson" initials="Richard" surname="Patterson">
    <address>
      <email>richard@helix.net.nz</email>
    </address>
  </author>

  <date month="March" year="2020"/>

  <area>Internet</area>

  <workgroup>DHC Work Group</workgroup>

  <keyword>Prefix Delegation</keyword>
  <keyword>DHCPv6 relay</keyword>
  <keyword>Delegating router</keyword>
  <keyword>Requesting router</keyword>

  <abstract>
    <t>Operational experience with DHCPv6 prefix delegation has shown that 
    when the DHCPv6 relay function is not co-located with the DHCPv6 server
    function, issues such as timer synchronization between the DHCP functional 
    elements, rejection of client's messages by the relay, and other
    problems have been observed. These problems can result in prefix delegation
    failing or traffic to/from clients addressed from the delegated prefix
    being unrouteable. Although [RFC8415] mentions this deployment 
    scenario, it does not provide necessary detail on how the relay element
    should behave when used with PD.</t>
    
    <t>This document describes functional requirements for a DHCPv6 PD relay 
    when used for relaying prefixes delegated by a separate DHCPv6 server.</t>
  </abstract>
</front>

<middle>
  <section title="Introduction">
    <t>For Internet service providers that offer native IPv6 access with prefix
    delegation to their customers, a common deployment architecture is to have
    a DHCPv6 relay agent function located in the ISP's Layer-3 customer
    edge device and separate, centralized DHCPv6 server infrastructure.
    <xref target="RFC8415"/> describes the functionality of a DHCPv6 relay and
    Section 19.1.3 mentions the deployment scenario, but does not provide
    detail for all of the functional requirements that the relay needs to
    fulfill to operate deterministically in this deployment scenario.</t>

    <t>A DHCPv6 relay agent for prefix delegation is a function commonly
    implemented in routing devices, but implementations vary in 
    their functionality and client/server inter-working. This can
    result in operational problems such as messages not being forwarded by 
    the relay or unreachability of the delegated prefixes. This document
    provides a set of requirements for devices implementing a relay function
    for use with prefix delegation.
    </t>

    <t>The mechanisms for a relay to inject routes (including aggregated ones), 
    on its network-facing interface based on prefixes learnt from a server 
    via DHCP-PD are out of scope of the document.</t>

    <t>Multi-hop relaying is also not considered as the functionality is 
    solely required by a DHCP relay agent that is co-located with the 
    first-hop router that the DHCPv6 client requesting the prefix is connected 
    to.</t>

    <t>The behavior defined in <xref target="RFC7283"/> is also applicable
    for DHCv6-PD-relay deployments.</t>

<!-- IF - Having spent some time looking at RFC7515, I don't think that 
we need to have this text. I suggest that we leave it in the source for now 
(but not in the posted version). If we get any comments related to the 
relationship with SAVI, then we can put it back.>
    <t>The this document is not intended to overlap with the scope of Source
    Address Validation Improvement (SAVI) <xref target="RFC7513"/>. The
    differences are described in <xref target="comp-savi"/>.</t>-->
  </section>

  <section title="Terminology">
    <section title="General">
      <t>This document uses the terminology defined in <xref
        target="RFC8415"/>, however when defining the functional elements for 
        prefix delegation <xref target="RFC8415"/>, Section 4.2 defines the term
        'delegating router' as:
        <list style="empty">
          <t>"The router that acts as a DHCP server and responds to requests for
            delegated prefixes."
          </t>
        </list>

        This document is concerned with deployment scenarios in which the 
        DHCPv6 relay and DHCPv6 server functions are separated, so the term 
        'delegating router' is not used. Instead, a new term is introduced to 
        describe the relaying function:

        <list style="hanging" hangIndent="17">
          <t hangText="Delegating relay">A delegating relay acts as an
            intermediate device, forwarding DHCPv6 messages containing
            IA_PD/IAPREFIX options between the client and server. The
            delegating relay does not implement a DHCPv6 server function. The
            delegating relay is also responsible for routing traffic for the
            delegated prefixes.
          </t>
        </list>
      </t>

      <t>Where the term 'relay' is used on its own within this document, it 
        should be understood to be a delegating relay, unless specifically
        stated otherwise.
      </t>

      <t><xref target="RFC8415"/> defines the 'DHCP server', (or 'server')
        as:
        <list style="empty">
          <t>"A node that responds to requests from clients.  It may or may
            not be on the same link as the client(s).  Depending on its
            capabilities, if it supports prefix delegation it may also feature
            the functionality of a delegating router.
          </t>
        </list>
        This document serves the deployment cases where a DHCPv6 server is not
        located on the same link as the client (necessitating the delegating
        relay). The server supports prefix delegation and is capable of
        leasing prefixes to clients, but is not responsible for other functions
        required of a delegating router, such as managing routes for the
        delegated prefixes.
      </t>
      <t>The term 'requesting router' has previously been used to describe the
        DHCP client requesting prefixes for use. This document adopts the 
        <xref target="RFC8415"/> terminology and uses 'DHCP client' or 'client'
        interchangeably for this element.
      </t>
    </section>

    <section title="Topology">
      <t>The following diagram shows the deployment topology relevant to this
        document.
      </t>
      <figure align="center" anchor="topology_overview">
        <artwork align="left"><![CDATA[
  +                                    _    ,--,_
  |   +--------+    +------------+   _(  `'      )_    +--------+
  +---+   PD   |----| Delegating |--(   Operator   )---| DHCPv6 |
  |   | Client |    |    relay   |   `(_ Network_)'    | server |
  |   +--------+    +----------- +      `--'`---'      +--------+
  |
  +
Client Network
        ]]></artwork>
      </figure>      
      <t>The client request prefixes via the client facing interface of the 
        delegating relay.  The resulting prefixes will be used for addressing 
        the client network.  The delegating relay is responsible for forwarding 
        DHCP messages, including prefix delegation requests and responses 
        between the client and server.  Messages are forwarded from the 
        delegating relay to the server using multicast or unicast via the 
        operator network facing interface.
      </t>

      <t>The delegating relay provides the operator's Layer-3 edge towards the
        client and is responsible for routing traffic to and from clients
        connected to the client network using addresses from the delegated
        prefixes.
      </t>
    </section>

    <section title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
        "OPTIONAL" in this document are to be interpreted as described in BCP
        14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
        when, they appear in all capitals, as shown here. This document uses 
        these keywords not strictly for the purpose of interoperability, but
        rather for the purpose of establishing industry-common baseline
        functionality.  As such, the document points to several other
        specifications (preferably in RFC or stable form) to provide additional
        guidance to implementers regarding any protocol implementation required
        to produce a DHCP relaying router that functions successfully with
        prefix delegation.
      </t>
    </section>
  </section>

  <section title="Problems Observed with Existing Delegating Relays 
    Implementations"
    anchor="relay_problems">
    <t>The following sections of the document describe problems that have been
      observed with delegating relay implementations in commercially available
      devices.
    </t>

    <section title="DHCP Messages not being Forwarded by the Delegating relay">
      <t>Delegating relay implementations have been observed not to forward
        messages between the client and server. This generally occurs if a
        client sends a message which is unexpected by the delegating relay. 
        For example, the delegating router already has an active PD lease entry
        for an existing client on a port. A new client is connected to 
        this port and sends a solicit message. The delegating relay then drops
        the solicit messages until it receives either a DHCP release message
        from the original client, or the existing lease times out. This causes
        a particular problem when a client device needs to be replaced due to a 
        failure.
      </t>

      <t>In addition to dropping messages, in some cases the delegating
        relay will generate error messages and send them to the client, e.g. 
        'NoBinding' messages being sent in the event that the delegating relay
        does not have an active delegated prefix lease.
      </t>
    </section>

    <section title="Delegating Relay Loss of State on Reboot">
       <t>For proper routing of client's traffic, the delegating relay requires
        a corresponding routing table entry for each active prefix delegated 
        to a connected client.  A delegating router which does not store this 
        state persistently across reboots will not be able to forward traffic to
        client's delegated leases until the state is re-established through
        new DHCP messages.
      </t>
    </section>

    <section title="Multiple Simultaneous Delegated Prefixes for a Single DUID
     on a Single Client">
     <t><xref target="RFC8415"/> allows for a client to include more than one
       instance of OPTION_IA_PD in messages in order to request multiple 
       prefix delegations by the server.  If configured for this, the
       server supplies one instance of OPTION_IAPREFIX for each received 
       instance of OPTION_IA_PD, each containing information for a different
       delegated prefix.
     </t>
     <t>In some delegating relay implementations, only a single delegated 
       prefix per-DUID is supported. In those cases only one IPv6 route for only
       one of the delegated router is installed; meaning that other prefixes
       delegated to a client are unreachable.
     </t>
    </section>

    <section title="Dropping Messages from Devices with Duplicate MAC addresses
      and DUIDs">
      <t>It is an unfortunate operational reality that client devices with
        duplicate MAC addresses and/or DUIDs exist and have been deployed. In
        this situation, the operational costs of locating and swapping out such
        devices are prohibitive.
      </t>
      <t>Delegating relays have been observed to restrict forwarding client
        messages originating from one client DUID to a single interface. In this
        case if the same client DUID appears from a second client on another 
        interface while there is already an active lease, messages originating
        from the second client are dropped causing the second client to be
        unable to obtain a prefix delegation.
      </t>
    </section>
  </section>

  <section title="Requirements for Delegating Relays">
    <t>To resolve the problems described in <xref target="relay_problems"/>
      the following section of the document describes a set of functional
      requirements for the delegating relay.
    </t>

    <section title="General Requirements">
      <t>
        <list style="hanging" hangIndent="8">
          <t hangText="G-1:">The delegating router MUST forward messages
            bidirectionally between the client and server without changing the
            contents of the message.
          </t>
          <t hangText="G-2:">As described in Section 16 of
            <xref target="RFC8415"/>, in the event that a received message
            contains a DHCPv6 option which the relay does not implement, the
            message MUST be forwarded.
          </t>
          <t hangText="G-3:">The relay MUST allow for multiple prefixes to be
            delegated for the same client IA_PD. These delegations may have
            different lifetimes.
          </t>
          <t hangText="G-4:">The relay MUST allow for multiple prefixes with
            separate IA_PDs to be delegated to a single client connected to
            a single interface, identified by its DHCPv6 Client Identifier
            (DUID).
          </t>
          <t hangText="G-5:">The relay MUST allow the same client identifier
            (DUID) to have active delegated prefix leases on more than one
            interface simultaneously. This is to allow client devices with
            duplicate DUIDs to function on separate broadcast domains.
          </t>
          <!--
          <t hangText="G-6:">The relay up on detecting that the current
            lease information of any delegated prefix is no more valid,
            then the relay MUST deprecate the invalid prefixes as quick
            as possible so that the clients use a new prefix quickly.
          </t>-->
          <t hangText="G-6:">The maximum number of simultaneous prefixes
            delegated to a single client MUST be configurable.
          </t>
          <t hangText="G-7:">The relay MUST implement a mechanism to limit the
            maximum number of active prefix delegations on a single port for all
            client identifiers and IA_PDs. This value SHOULD be configurable.
          </t>
          <t hangText="G-8:">The delegating relay MUST synchronize the lifetimes
            of active prefix delegation leases with server.
          </t>
          <!--Note - G-7, G-9 Should the above be done by the relay or is this
          really serverpolicy.-->
        </list>
      </t>
    </section>

    <section title="Routing Requirements">
      <t>
        <list style="hanging" hangIndent="8">
          <t hangText="R-1:">The relay MUST maintain a local routing table that
            is dynamically updated with prefixes and the associated next-hops as
            they are delegated to clients. When a delegated prefix is released
            or expires, the associated route MUST be removed from the relay's
            routing table.
          </t>
          <t hangText="R-2:">The relay MUST provide a mechanism to dynamically
            update access control lists permitting ingress traffic sourced from
            clients' delegated prefixes. This is to implement anti-spoofing as
            described in <xref target="BCP38"/>.
          </t>
          <t hangText="R-3:">The relay MAY provide a mechanism to dynamically
            advertise delegated prefixes into an routing protocol as they are
            learnt. When a delegated prefix is released or expires, the
            delegated route MUST be withdrawn from the routing protocol.  The
            mechanism using which the routes are inserted and deleted is out of
            the scope of this document.</t>
          </list>
      </t>
    </section>

    <section title="Service Continuity Requirements"
             anchor="service_continuity">
      <t>
        <list style="hanging" hangIndent="8">
          <t hangText="S-1:">In the event that the relay is restarted, active
           client prefix delegations will be lost. This may result in clients
           becoming unreachable. In order to mitigate this problem, it is
           RECOMMENDED that the relay implements either of the following:
          </t>

          <t>
            <list style="hanging" hangIndent="8">
              <t>The relay MAY implement DHCPv6 bulk lease query as defined in 
                <xref target="RFC5460"/>.
              </t>

              <t>The relay SHOULD store active prefix delegations in persistent
                storage so they can be re-read after the reboot.
              </t>
            </list>
          </t>

          <t hangText="S-2:">If a client's next-hop link-local address becomes
            unreachable (e.g., due to a link-down event on the relevant physical
            interface), routes for the client's delegated prefixes MUST be
            retained by the delegating relay unless they are released or removed
            due to expiring DHCP timers. This is to re-establish routing for the
            delegated prefix if the client next-hop becomes reachable without
            the relay needing to be re-learnt.
          </t>
          
          <t hangText="S-3:">The relay MAY implement DHCPv6 active lease query
            as defined in <xref target="RFC7653"/> to keep the local lease
            database in sync with the DHCPv6 server.
          </t>
        </list>
      </t>
    </section>

    <section title="Operational Requirements">
      <t>
        <list style="hanging" hangIndent="8">
          <t hangText="O-1:">The relay SHOULD implement an interface allowing
            the operator to view the active delegated prefixes. This SHOULD
            provide information about the delegated lease and client details
            such as client identifier, next-hop address, connected interface,
            and remaining lifetimes.
          </t>

          <t hangText="O-2:">The relay SHOULD provide a method for the operator
            to clear active bindings for an individual lease, client or all
            bindings on a port.
          </t>

          <t hangText="O-3:">To facilitate troubleshooting of operational
            problems between the delegating relay and other elements, it is
            RECOMMENDED that the delegating relay's system time is synchronised
            with the network.
          </t>
        </list>
      </t>
    </section>
  </section>

  <section anchor="Acknowledgements" title="Acknowledgements">
    <t>The authors of this document would like to thank Bernie Volz
      for his valuable comments.
    </t>
  </section>

   <!-- Possibly a 'Contributors' section ... -->

  <section anchor="IANA" title="IANA Considerations">
    <t>This memo includes no request to IANA.</t>
  </section>

  <section anchor="Security" title="Security Considerations">
    <t>If the delegating relay implements <xref target="BCP38"/> filtering, then
      the filtering rules will need to be dynamically updated as delegated
      prefixes are leased.
    </t>

    <t><xref target="RFC8213"/> describes a method for securing traffic between
    the relay agent and server by sending DHCP messages over an IPSec tunnel.
    In this case the IPSec tunnel is functionally the server-facing interface
    and DHCPv6 message snooping can be carried out as described. It is
    RECOMMENDED that this is implemented by the delegating relay.</t>

<!-- IF - I'm not sure what's meant by this point as there are two variables:
the message type and the interface, which effectively means 'receipt of 
random, unexpected messages anywhere.' From what I've seen, functions like this
which are implmented are a big part of why this document is needed in the 
first place. My thinking is that the relay should not be trying to add 
'intelligence' here as it almost always gets it wrong. The server holds the
actual state and can decide what is relevant.
    <t>NOTE Security - dropping of incorrect message types received on the
      wrong interface (This is probably already covered in RFC8415).</t>-->
  </section>
</middle>

 <!--  *****BACK MATTER ***** -->

 <back>
  <references title="Normative References">
    <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
    &RFC2119;
    &RFC5460;
    &RFC7653;
    &RFC8174;
    &RFC8415;
  </references>

  <references title="Informative References">
    <!-- Here we use entities that we defined at the beginning. -->
    &RFC8213;
    &RFC7283;
<!--    &RFC7513;-->

    <reference anchor="BCP38">
      <front>
        <title>Network Ingress Filtering:
          Defeating Denial of Service Attacks which employ
                IP Source Address Spoofing
        https://tools.ietf.org/html/bcp38
        </title>

        <author>
          <organization>IETF</organization>
        </author>

        <date />
      </front>
      <seriesInfo name="RFC" value="2827"/>
      <seriesInfo name="BCP" value="38" />
    </reference>
  </references>

<!-- 
  <section anchor="app-additional" title="Appendix">
    <section anchor="comp-savi" title="Comparison with SAVI">
      <t><xref target="RFC7513"/> describes the Source Address Validation
        Improvement (SAVI) for DHCP. 
      <t>Scope of the requirements defined in this specification are
      different from the ones defined in SAVI <xref target="RFC7513"/>,
      following are the notable points.</t>
      <t><list style="symbols">
      <t>SAVI cannot be used at L3 edge router</t>
      <t>SAVI deals with complete 128 bit addresses rather than prefixes
        delegated</t>
      </list></t>
    </section>
  </section>
-->
   <!-- Change Log
   v00 2019-05-7  IF   Initial version 
   2020-02-20 IF - Name change after adoption and typo fixes -->
 </back>
</rfc>