Last Call Review of draft-ietf-dhc-dhcpv6-pd-relay-requirements-04
review-ietf-dhc-dhcpv6-pd-relay-requirements-04-secdir-lc-huitema-2020-12-04-00

This document presents a set of requirements for how "Prefix Delegating Relays" should
handle the relaying of IPv6 Prefix delegation requests between DHCP clients and DHCP servers.

This document is Ready. But please fix one tiny nit.

Prefix Delegating Relays are more complex than simple DHCP relays. Instead of
merely passing information back and forth between DHCP clients and DHCP servers,
they also need to install IPv6 routes so the allocated IPv6 prefix is routed towards
the client to which the prefix is allocated via DHCP. The document explains
issues found during past deployments, and presents a set of requirements to
ensure smooth operation of the service.

As written in the security section, stating these requrements does not add
any new security considerations beyond those mentioned in RFC 8213, which requires
using IPSEC between DHCP relay and DHCP server. This is fine and I believe that
the draft is ready, except for one nit. The draft mentions "Section 22 of [RFC8213]",
but RFC 8213 only has 6 sections. Since that RFC is entirely about "Security of
Messages Exchanged between Servers and Relay Agents", I don't understand why the
draft needs to mention this bogus "Section 22". Are the authors trying to trick
this reviewer?

There is a security issue concerning communication between clients and relays. This
draft is not the place to address it, which is why I think it is ready, but I can't
resist using this review to pass a message to the working group. On link attackers
could spoof requests for prefix delegation, or responses, just like
they can spoof any DHCP message. Spoofing prefix delegation requests might be a way
to attack networks, or to cause support issues between clients and providers.
RFC 8213 "suggests" using secure DHCPv6 between client and server, but the "secure
DHCPv6" draft cited in RFC 8213 is now expired. I understand that solutions like RA
Guard will in practice provide some protection, but the use of these solutions are
not discussed in RFC 8213. The DHCP WG might want to address that.