Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-pd-relay-requirements-00.txt

["Bernie Volz (volz)" <[e-mail]>]

Hi:

I did a more thorough review of the draft and have the following comments. As the draft is fairly short, I’ve decided to copy and paste the bulk of the text here to provide the comments. I do encourage others to read this draft and provide their comments.

WARNING: It may not be wise to just Reply (Reply-All) to this message without editing out much of the text below as it is likely a large message and may not go through (without WG chair approval).

Abstract

   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
- l think that “not being routed” might be better here?
   [RFC8415<https://tools.ietf.org/html/rfc8415>] mentions this deployment scenario, it does not provide
   necessary detail on how the relay element should behave when used
   with PD.
- Spell out PD – prefix delegation. Another choice would be to add “ (PD)” after the first occurrence and then used this in the abstract.

   This document describes functional requirements for a DHCPv6 PD relay
- Same issue for PD – see above
   when used for relaying prefixes delegated by a separate DHCPv6
   server.

Status of This Memo
…
1<https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-pd-relay-requirements-00#section-1>.  Introduction
   For Internet service providers that offer native IPv6 access with
   prefix delegation to their customers, a common deployment
- Perhaps add “ (PD)” here so you can use the term later? Note that RFC8415 never used “PD” by itself.
   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.  [RFC8415<https://tools.ietf.org/html/rfc8415>] describes the functionality of a
   DHCPv6 relay and Section 19.1.3<https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-pd-relay-requirements-00#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.
…

   The behavior defined in [RFC7283<https://tools.ietf.org/html/rfc7283>] is also applicable for DHCv6-PD-
   relay deployments.
- “DHCv6”? And perhaps “DHC[P]v6-PD-relay deployments” is best replaced by “relay deployments”. I think this applies to all relays; even if they are not doing PD.
2<https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-pd-relay-requirements-00#section-2>.  Terminology
2.1<https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-pd-relay-requirements-00#section-2.1>.  General
…

   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.

   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.
- I wonder if adding some additional text such as “In CableLabs DOCSIS environments, the Cable Modem Termination System (CMTS) would be considered a delegating relay with respect to Customer Premises Devices (CPEs).” Perhaps could also mention something about Broadband Network Gateway (BNG)?

   [RFC8415] defines the 'DHCP server', (or '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.
- Add the closing “

…
3<https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-pd-relay-requirements-00#section-3>.  Problems Observed with Existing Delegating Relays Implementations
- Replace Relays with Relay in title.
   The following sections of the document describe problems that have
   been observed with delegating relay implementations in commercially
   available devices.
3.1<https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-pd-relay-requirements-00#section-3.1>.  DHCP Messages not being Forwarded by the Delegating relay
- Upper case R in relay in title
   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.
- Use RFC8415 style casing for the message names (Solicit message, Release message)
…
3.2<https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-pd-relay-requirements-00#section-3.2>.  Delegating Relay Loss of State on Reboot
   For proper routing of client's traffic, the delegating relay requires
- I think just “client traffic” would be fine here.
   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<https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-pd-relay-requirements-00#section-3.3>.  Multiple Simultaneous Delegated Prefixes for a Single DUID on a
      Single Client
- Retitle as “Multiple Delegated Prefixes for 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
- “one (or more)”? There’s no reason there could not be multiple IAPREFIX options for an IA_PD. And, I don’t want someone pointing to this text to only support one.
   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
- second only is not needed. Also shouldn’t “delegated router” be “delegated prefixes”?
   prefixes delegated to a client are unreachable.
3.4<https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-pd-relay-requirements-00#section-3.4>.  Dropping Messages from Devices with Duplicate MAC addresses and
      DUIDs
   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.

   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.
- We need to be a bit careful in this section and not sure exactly how to fix it. But in DOCSIS, for Cable Modems, often these restrictions exist to prevent theft of service (as there have been cloned devices). I think this document means the devices behind the CMs (in the case of DOCSIS) and perhaps similar environments. The complexity here is that “delegating relays” are the devices passing DHCPv6 packets and so could be interpreted to include all devices. Perhaps this will require some further discussions.
…

   G-4:    The relay MUST allow for multiple prefixes with separate
           IA_PDs to be delegated to a single client connected to a
- I think you should either drop “with separate IA_PDs” or say “with or without separate IA_PDs”. Again, a single IA_PD could contain multiple IAPREFIX options.
           single interface, identified by its DHCPv6 Client Identifier
           (DUID).

   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.
- See earlier my points in section 3.4; not sure how best to “modify” this item.

   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
           configurable.
- For G-6 ad G-7, are there some recommendations about what (a) a reasonable number to support is and (b) what the default should be? While it would be great to have this be “unlimited”, likely equipment manufacturers might like some guidance. For example we could say that “While allowing this to be fully configurable, delegating relays should support at least 8 per client device and use this as the default limit.” That’s just an example.

   G-8:    The delegating relay MUST synchronize the lifetimes of active
           prefix delegation leases with server.
- I’m not sure I completely understand what this requirement means. Are you suggesting NTP or similar time synchronization be used? As lifetimes are relative (seconds remaining, not absolute time stamps) in DHCP messages, I’m not sure why NTP would be that critical. As there are 3 places lifetimes would be stored (server, delegating relay, client), unless all of these clocks were synchronized, some drift should be tolerated (i.e., not all clocks will tick at the same rate).
4.2<https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-pd-relay-requirements-00#section-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-
- Probably just “client delegated prefixes” is sufficient?
           spoofing as described in [BCP38<https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-pd-relay-requirements-00#ref-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
- I think “using which” should be “by which”
           is out of the scope of this document.
4.3<https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-pd-relay-requirements-00#section-4.3>.  Service Continuity Requirements
…

   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.
- Should “relay” be replaced by “delegating prefixes”.

…
4.4<https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-pd-relay-requirements-00#section-4.4>.  Operational Requirements
…

   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.
- Would adding something like “using NTP [RFC7822] or similar time synchronization protocol”? Perhaps reword as “it is RECOMMENDED that a time synchronization protocol is used by the delegating routers and DHCP servers”? That would avoid the RFC7822 reference.
…
7<https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-pd-relay-requirements-00#section-7>.  Security Considerations
   If the delegating relay implements [BCP38<https://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-pd-relay-requirements-00#ref-BCP38>] filtering, then the
   filtering rules will need to be dynamically updated as delegated
   prefixes are leased.

   [RFC8213] describes a method for securing traffic between the relay
- I’m not sure if this is a tools bug, but RFC8213 is not hyperlinked. I suspect it is just a tools issue as this is the only reference to this document.
   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.


  *   Bernie