[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 draft-ietf-dhc-dhcpv6-pd-relay-requirements

DHC Work Group                                                 I. Farrer
Internet-Draft                                       Deutsche Telekom AG
Intended status: Standards Track                      Naveen. Kottapalli
Expires: December 27, 2019                                 Benu Networks
                                                                M. Hunek
                                         Technical University of Liberec
                                                      Richard. Patterson
                                                           June 25, 2019

                     DHCPv6 Prefix Delegating relay


   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.

   This document describes functional requirements for a DHCPv6 PD relay
   when used for relaying prefixes delegated by a separate DHCPv6

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 https://datatracker.ietf.org/drafts/current/.

   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 December 27, 2019.

Farrer, et al.          Expires December 27, 2019               [Page 1]

Internet-Draft               DHCPv6 PD relay                   June 2019

Copyright Notice

   Copyright (c) 2019 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
   (https://trustee.ietf.org/license-info) 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Topology  . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Requirements Language . . . . . . . . . . . . . . . . . .   5
   3.  Problems Observed with Existing Delegating Relays
       Implementations . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  DHCP Messages not being Forwarded by the Delegating relay   5
     3.2.  Delegating Relay Loss of State on Reboot  . . . . . . . .   5
     3.3.  Multiple Simultaneous Delegated Prefixes for a Single
           DUID      on a Single Client  . . . . . . . . . . . . . .   5
     3.4.  Dropping Messages from Devices with Duplicate MAC
           addresses       and DUIDs . . . . . . . . . . . . . . . .   6
   4.  Requirements for Delegating Relays  . . . . . . . . . . . . .   6
     4.1.  General Requirements  . . . . . . . . . . . . . . . . . .   6
     4.2.  Routing Requirements  . . . . . . . . . . . . . . . . . .   7
     4.3.  Service Continuity Requirements . . . . . . . . . . . . .   7
     4.4.  Operational Requirements  . . . . . . . . . . . . . . . .   8
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   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

Farrer, et al.          Expires December 27, 2019               [Page 2]

Internet-Draft               DHCPv6 PD relay                   June 2019

   ISP's layer 3 customer edge device and separate, centralized DHCPv6
   server infrastructure.  [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.

   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 these

   This document does not cover the redistribution of the remote routes
   that have been are learnt from DHCP.  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.

   The behavior defined in [RFC7283] is also applicable for DHCv6-PD-
   relay deployments.

2.  Terminology

2.1.  General

   This document uses the terminology defined in [RFC8415], however when
   defining the functional elements for prefix delegation [RFC8415],
   Section 4.2 defines the term 'delegating router' as:

      "The router that acts as a DHCP server and responds to requests
      for delegated prefixes."

   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:

   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

   The device functioning as the delegating relay is also responsible
   for routing traffic for the delegated prefixes.

Farrer, et al.          Expires December 27, 2019               [Page 3]

Internet-Draft               DHCPv6 PD relay                   June 2019

   [RFC8415] defines the 'DHCP server', (or as 'server') as:

      "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.

   This document serves the deployment cases where 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.

   The term 'requesting router' has previously been used to describe the
   DHCP client requesting prefixes for use.  This document adopts the
   [RFC8415] terminology and uses 'DHCP client' or 'client'
   interchangeably for this element.

2.2.  Topology

   The following diagram shows the deployment topology relevant to this

     +                                    _    ,--,_
     |   +--------+    +------------+   _(  `'      )_    +--------+
     +---+   PD   |----| Delegating |--(   Operator   )---| DHCPv6 |
     |   | Client |    |    relay   |   `(_ Network_)'    | server |
     |   +--------+    +----------- +      `--'`---'      +--------+
   Client Network

                                 Figure 1

   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.

   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

Farrer, et al.          Expires December 27, 2019               [Page 4]

Internet-Draft               DHCPv6 PD relay                   June 2019

2.3.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Problems Observed with Existing Delegating Relays Implementations

   The following sections of the document describe problems that have
   been observed with delegating relay implementations in commercially
   available devices.

3.1.  DHCP Messages not being Forwarded by the Delegating relay

   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.

   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.

3.2.  Delegating Relay Loss of State on Reboot

   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.

3.3.  Multiple Simultaneous Delegated Prefixes for a Single DUID on a
      Single Client

   [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

Farrer, et al.          Expires December 27, 2019               [Page 5]

Internet-Draft               DHCPv6 PD relay                   June 2019

   of OPTION_IA_PD, each containing information for a different
   delegated prefix.

   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.

3.4.  Dropping Messages from Devices with Duplicate MAC addresses and

   It is an unfortunate operational reality that client devices with
   duplicate MAC addresses, DUIDs exist and have been deployed.  In this
   situation, the operational costs of locating and swapping out such
   devices are prohibitive.

   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 and active lease, messages
   originating from the second client are dropped causing the second
   client to be unable to obtain a prefix delegation.

4.  Requirements for Delegating Relays

   To resolve the problems described in Section 3 the following section
   of the document describes a set of functional requirements for the
   delegating relay.

4.1.  General Requirements

   G-1:    The delegating router MUST forward messages bidirectionally
           between the client and server without changing the contents
           of the message.

   G-2:    As described in Section 16 of [RFC8415], in the event that a
           received message contains a DHCPv6 option which the relay
           does not implement, the message MUST be forwarded.

   G-3:    The relay MUST allow for multiple prefixes to be delegated
           for the same client IA_PD.  These delegations may have
           different lifetimes.

   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

Farrer, et al.          Expires December 27, 2019               [Page 6]

Internet-Draft               DHCPv6 PD relay                   June 2019

   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

   G-6:    The maximum number of simultaneous prefixes delegated to a
           single client MUST be configurable.

   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

   G-8:    The delegating relay MUST synchronize the lifetimes of active
           prefix delegation leases with server.

4.2.  Routing Requirements

   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.

   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 [BCP38].

   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.

4.3.  Service Continuity Requirements

   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:

                   The relay MAY implement DHCPv6 bulk lease query as
                   defined in [RFC5460].

Farrer, et al.          Expires December 27, 2019               [Page 7]

Internet-Draft               DHCPv6 PD relay                   June 2019

                   The relay MAY store active prefix delegations in
                   persistent storage so they can be re-read after the

   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 client needing to send
           any DHCP messages.

4.4.  Operational Requirements

   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.

   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.

   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.

5.  Acknowledgements

   This template was derived from an initial version written by Pekka
   Savola and contributed by him to the xml2rfc project.

6.  IANA Considerations

   This memo includes no request to IANA.

7.  Security Considerations

   If the delegating relay implements [BCP38] filtering, then the
   filtering rules will need to be dynamically updated as delegated
   prefixes are leased.

   [I-D.ietf-dhc-relay-server-security] 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

Farrer, et al.          Expires December 27, 2019               [Page 8]

Internet-Draft               DHCPv6 PD relay                   June 2019

   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.

8.  References

8.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,

   [RFC5460]  Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460,
              DOI 10.17487/RFC5460, February 2009,

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8415]  Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
              Richardson, M., Jiang, S., Lemon, T., and T. Winters,
              "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
              RFC 8415, DOI 10.17487/RFC8415, November 2018,

8.2.  Informative References

   [BCP38]    IETF, "Network Ingress Filtering: Defeating Denial of
              Service Attacks which employ IP Source Address Spoofing
              https://tools.ietf.org/html/bcp38", RFC 2827, BCP 38.

              Volz, B. and Y. Pal, "Security of Messages Exchanged
              Between Servers and Relay Agents", draft-ietf-dhc-relay-
              server-security-05 (work in progress), April 2017.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              DOI 10.17487/RFC2629, June 1999,

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              DOI 10.17487/RFC3552, July 2003,

Farrer, et al.          Expires December 27, 2019               [Page 9]

Internet-Draft               DHCPv6 PD relay                   June 2019

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 5226,
              DOI 10.17487/RFC5226, May 2008,

   [RFC7283]  Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6
              Messages", RFC 7283, DOI 10.17487/RFC7283, July 2014,

Authors' Addresses

   Ian Farrer
   Deutsche Telekom AG
   Landgrabenweg 151
   Bonn, NRW  53227

   Email: ian.farrer@telekom.de

   Naveen Kottapalli
   Benu Networks
   300 Concord Road
   Billerica, MA  01821

   Email: naveen.sarma@gmail.com

   Martin Hunek
   Technical University of Liberec
   Studentska 1402/2
   Liberec, L  46017

   Email: martin.hunek@tul.cz

   Richard Patterson

   Email: richard@helix.net.nz

Farrer, et al.          Expires December 27, 2019              [Page 10]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/