Re: [v6ops] Éric Vyncke's Yes on draft-ietf-v6ops-dhcp-pd-per-device-07: (with COMMENT)

[Jen Linkova <[e-mail]>]

Bonjour Eric,

Thank you very much for such a detailed review!
Comments inline.

On Wed, Apr 3, 2024 at 6:02 PM Éric Vyncke via Datatracker
<[e-mail]> wrote:
> ## Abstract
> "client" is rather vague... or was "node" intended ? "client" is only defined
> later in the terminology section.

Some background: the reason we use 'client' is that the WG discussed
extensively the host/node/device terminology, and we decided to use
'client' as it's a DHCPv6 client.
However for Abstract and Intro sections it doesn't matter much, so
we've changed it to "nodes" and "devices".

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

 It’s not a requirement indeed, it’s just the benefits are much more
substantial for large networks, where scalability of IPv6<>MAC mapping
becomes an issue. Section 5 discusses applicability in more details,
but the reason we use ‘large’ here is to address concerns raised by
the WGon the list about “a lot of networks can not deploy this as they
are small and do not have their own address space”. The proposed
deployment model is targeted to large networks, but can be used by any
network that has enough address space (however, small networks might
face IPv6 address space size issues - that’s the reason for the 6MAN
P-flag draft, which allows networks to tell clients whether asking for
a prefix is appropriate or not.

So we'd rather prefer to keep "large" in the abstract (and in the
document name).

> ## Section 1
>
> Is "large" required in `Often, large broadcast networks` ?

Removed.

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

Changed to ‘devices’

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

Done.

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

I used ‘requires’ as ‘almost inevitably happens’ - in cases of stable
+ privacy addresses or multi-prefix networks. We rephrased it to "
Unlike IPv4, IPv6 allows hosts to have multiple addresses, and this is
the case in most deployments (see Appendix A for more details)."

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

All above fixed.

> ## 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).

What we describe in that section is a typical topology we expect
people to deploy. While in theory DHCPV6 doesn't need to be a router,
I can't imagine a practical scenario when it would work that way for
PD (installing routes would be tricky).
We've rephrased that section a bit, hopefully it's more clear now.

> Even if "NUD" is an accepted abbreviation, suggest expanding it.
> `required by this specification.` is not suitable for an informational I-D.

Fixed.

> 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)

Oh I need to spend more time on it, so it's not yet fixed in -08.

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

Changed to "a simpler and often preferred option.". Is it better?

> ## 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 ?

Done.

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

We rephrased section 4 to make it more clear. that the expected
topology is when the first-hop routers are either relays or servers.
If you have a relay which is not a router, a mechanism would be
required to install routes on the first-hop routers. I'm not sure we
can recommend this.
I guess a network administrator can invent a way to make a topology
with a separate relay work, but I'd rather avoid documenting such
creative scenarios, as we might come up with an infinite number of
them..

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

To be honest I believe it’s justified in this case. The document is
informational as it describes an optional deployment model. However
when an administrator chooses to deploy this, some requirements become
mandatory (MUST), as otherwise things would get badly broken. Those
MUST/SHOULD can be easily translated to MUST/SHOULD in RFPs an
administrator would send to their vendors, or to the configuration
guidelines.

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

Done, RFC3704

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

I’m not sure it’s SLAAC-specific: NSes and NAs are sent even if
addresses are assigned via DHCPv6 IA_NA or statically.

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

We have shuffled the sentences around, please take a look - I hope
it’s less assertive now. As the p-flag draft is an informative
reference, it shouldn’t be a blocker.

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

I believe we are in violent agreement here: the full sentence states
exactly the same:

“Such information is much less dynamic than ND cache and therefore
it's much easier for an operator to collect and process it.”

> ## 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?

Oh that's a very good point, thank you. We added some text, I hope it
addresses your consent.

-- 
Cheers, Jen Linkova