Skip to main content

Using DHCPv6-PD to Allocate Unique IPv6 Prefix per Client in Large Broadcast Networks


Warren Kumari

No Objection

Jim Guichard
John Scudder
Paul Wouters
Zaheduzzaman Sarker

Note: This ballot was opened for revision 07 and is now closed.

Erik Kline
Comment (2024-03-30 for -07) Not sent
# Internet AD comments for draft-ietf-v6ops-dhcp-pd-per-device-07
CC @ekline

* comment syntax:

* "Handling Ballot Positions":

## Nits

### S12

* "makes the failures" -> "makes any failures"

### S16

* "Other delete" -> "Others delete"
Warren Kumari
Éric Vyncke
Comment (2024-04-03 for -07) Sent
# Éric Vyncke, INT AD, comments for draft-ietf-v6ops-dhcp-pd-per-device-07

Thank you for the work put into this document. It is easy to read and, while being simple, it is brilliant.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Timothy Winters for the shepherd's detailed write-up including the WG *rough* consensus *and* the justification of the intended status.

Other thanks to Tim Chown, the Internet directorate reviewer (at my request), please consider this int-dir review: (I have yet to read any reply by the authors)

I hope that this review helps to improve the document,



# COMMENTS (non-blocking)

## Abstract

"client" is rather vague... or was "node" intended ? "client" is only defined later in the terminology section.

Unsure whether "large" is a requirement for this I-D to be used.

## Section 1

Is "large" required in `Often, large broadcast networks` ?

`individual clients` should it be "individual nodes" or "individual hosts" ?

s/prefixes/IPv6 prefixes/ in the first paragraph ?

"(and often requires)" ? Beside link-local, I am not sure whether it is often a requirement.

s/L2/layer-2/ ?

As this section talks about DHCPv6, please already add a reference to DHCPv6.

s/in this specification/in this document/ as the intended status is informational.

## Section 4

`The first-hop router acts as a DHCPv6 relay` AFAIK a DHCPv6 relay does not need to be a router (this point comes up again later).

Even if "NUD" is an accepted abbreviation, suggest expanding it.

`required by this specification.` is not suitable for an informational I-D.

I love those clear SVG graphics :-) Just a very minor nit on the shared IPv6 link, there is a cross in the middle rather than a T (unsure whether it is fixable though)

## Section 5

For small networks, `SLAAC is a better and simpler option` is probably too assertive, suggest removing 'better' and only keep 'simpler'.

## Section 6.1

Should the routing table size reduction also be a benefit of using a big pool per link ? If so, let's state it already in this section rather than in the next ?

## Section 6.2

Is seems to me that one requirement of the proposed solution is that the DHCP relays *are* the routers, i.e., they can do DHCP snooping to learn the delegated prefixes.  Or is the multicast nature of the DHCP traffic enough? All in all, I do not think that a separate DHCP relay is a problem but some words could be added to the text to state that separate DHCP relay(s) (or local DHCP servers) is also supported.

## Section 7

As usual, I am not a big fan of using normative BCP 14 language in an informational document.

## Section 8

I can only imagine the amount of discussions about the delegated prefix length... No need to reply.

## Section 10

Unsure whether such reference exists, but adding a reference to uRPF would be a plus.

Should SLAAC be added to `When all clients are using the same shared link to form addresses`?

## Section 11

Currently, the IETF cannot publish this document as it includes `To allow the network to signal DHCPv6-PD support, [I-D.collink-6man-pio-pflag] defines a new PIO flag` and we do not know the fate of this other I-D yet. While I hope that it will be published, the sentence should be less assertive or make the 6MAN I-D normative in order to form a RFC editor cluster.

## Section 12

`Such information is much less dynamic than ND cache` moreover, the DHCP-PD logs are centralized and easier to collect.

## Section 15

`the DHCPv6 server or relay MUST support limiting the number of prefixes delegated to a given client at any given time` how can this be achieved if the client spoofs its MAC & link-local IPv6 addresses?

# NITS (non-blocking / cosmetic)

## E.g.

'E.g.' is usually followed by a comma.

## 464XLAT

Be consistent and always use "464XLAT" rather than "464xlat" in section 8.

## Section 16

Usually, appendixes are after the references ;-)
Jim Guichard
No Objection
John Scudder
No Objection
Murray Kucherawy
No Objection
Comment (2024-04-04) Sent
Thanks to Harald Alvestrand for his ARTART review.  Please take a look and consider his feedback.
Paul Wouters
No Objection
Roman Danyliw
No Objection
Comment (2024-04-03 for -07) Sent
Thank you to Peter Yee for the GENART review.

** Section 13.

   Networks that use the proposed mechanism instead of SLAAC or in
   addition to SLAAC, SHOULD minimally:


   *  Use short prefix lifetimes, to ensure that when a client
      disconnects and reconnects it gets a different prefix.

Is there any guidance to provide on what constitutes a “short lifetime”?

** Section 13.
   To provide privacy roughly equivalent to SLAAC with temporary
   addresses ([RFC8981]), the network SHOULD ...

I’m having trouble understanding this guidance.  What should be done to provide SLAAC-privacy-equivalence if this guidance isn’t followed?  There are multiple SHOULDs in this paragraph.  Wouldn’t it be mandatory to follow them to provide SLAAC-privacy-equivalence?
Zaheduzzaman Sarker
No Objection