DHCPv6 Prefix Delegating Relay Requirements
draft-ietf-dhc-dhcpv6-pd-relay-requirements-05

In the Abstract the term "memo" is used, but everywhere else it's called a "document".  I suggest updating the Abstract to conform.

In Section 2.1: "... forwarding DHCPv6 messages containing IA_PD/IAPREFIX ..." -- Just to confirm, does that "/" mean "or"?

Thanks to Christian Huitema for the SECDIR review and for the follow-up conversation.

* Please fix the reference noted by the SECDIR review

* Should this document update RFC8415?

"...error message MAY be sent as per [RFC4443], section 3.1."

"[RFC8213]... It is RECOMMENDED that this is implemented by the delegating relay."


Because of the normative context in which rfc4443/rfc8213 are used, their references should be normative.

I was going to suggest that this should “update” 8415, and then I saw Roman’s comment.  So, yes: it really seems that this should update 8415, if, indeed, this adds interoperability requirements to an aspect of what 8415 defines.

Thanks to Christian Huitema for the secdir review and to all for the
ensuing discussion (even though this draft is agreed to not be the right
place to address the topic of securing the DHCP client/DHCP relay
communications).

Thanks for this document; it's good to see this type of functional
requirements get written out clearly.  That said, I'm not sure I
understand why this document is aiming for Proposed Standard status.  It
seems to make normative requirements for DHCPv6 relay behavior, but does
not have an "Updates:" relationship with RFC 8415 to indicate that
additional requirements are present.  On the other hand, there are no
new protocol mechanisms to indicate that it is a protocol that would be
implemented on its own.  Is it intended to play the role of an
Applicability Statement?

Section 1

   The mechanisms for a relay to inject routes (including aggregated
   ones), on its network-facing interface based on prefixes learned from
   a server via DHCP-PD are out of scope of the document.

Just to check my understanding: the context suggests that the
"network-facing interface" here is the one on the DHCPv6 client side of
the relay, vs the server side.  Is that correct?  (Is the
"network-facing" terminology a term of art?)

   Delegating relay A delegating relay acts as an intermediate device,
                    forwarding DHCPv6 messages containing IA_PD/IAPREFIX

(I agree with Murray that clarification is in order here.)

Section 3.4

   It is an 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.
   [...]
   It should be noted that in some access networks, the MAC address and/
   or DUID are used as part of device identification and authentication.
   In such networks, enforcing MAC address/DUID uniqueness is a
   necessary function and not considered a problem.

It's not entirely clear to me that these two statements are entirely
consistent with each other -- are the costs prohibitive, or not a
problem?  (Putting a caveat on the first statement that it also only
applies to "some" networks, would resolve the apparent disparity.)

Section 3.5

[that loop sounds pretty nasty; I look forward to seeing how it's
resolved]

Section 4.1

   G-6:    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 MUST be
           configurable.

This mechanism is important as a security/anti-DoS mechanism; I hope we
note that somewhere.

   G-8:    The delegating relay MUST update the lease lifetimes based on
           the Client Reply messages it forwards to the client and only
           expire the delegated prefixes when the valid lifetime has
           elapsed.

(The string "Client Reply" does not appear in RFC 8415; I'm not sure why
it's capitalized as if it's a term of art.)

Section 4.2

   R-2:    The delegating relay's routing entry MUST use the same prefix
           length for the delegated prefix as given in the IA_PD.

Could this requirement ever interfere with an aggregation scenario?
(What is it trying to prevent?)

   R-3:    The relay MUST provide a mechanism to dynamically update
           ingress filters permitting ingress traffic sourced from
           client delegated leases and blocking packets from invalid
           source prefixes.  This is to implement anti-spoofing as
           described in [BCP38].  The delegating relay's ingress filter
           entry MUST use the same prefix length for the delegated
           prefix as given in the IA_PD.

Is this imposing a more stringent requirement than BCP38 itself (which,
as far as I can tell, restricts itself to "all providers of Internet
connectivity are urged to implement filtering described in this
document" with no normative requirement.  (To be clear, I'm not opposed
to this trend, just wondering if we should note the change more
prominently.)

Section 4.4

   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.

Is this something that draft-ietf-dhc-dhcpv6-yang would provide (and
thus merit an informative reference)?

Section 7

   This document does not add any new security considerations beyond
   those mentioned in Section 22 of [RFC8213].

Thanks for queuing up the reference fix per the secdir review.
I guess both Section 22 of RFC 8415 and all of RFC 8213 are relevant?
Though perhaps the las paragraph of the section is intended to provide
the needed RFC 8213 reference...

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

I do not see any reference to message snooping in RFC 8213; please
clearify.

Section 8.2

The discussion at
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
combined with the way in which RFC 4443 is referenced ("An ICMPv6 Type
1, Code 6 (Destination Unreachable, reject route to destination) error
message MAY be sent as per [RFC4443], section 3.1." suggest that RFC
4443 would be more properly classified as a normative reference.

I support Ben and Erik's question as to the category of this document.  It isn't immediately obvious to me why this is standard track and perhaps BCP or Informational might be a better classification.