Re: [v6ops] Feedback on draft-collink-v6ops-ent64pd-01

[Jen Linkova <[e-mail]>]

First of all, thanks a lot for reading the draft and for your comments.

On Thu, Jan 12, 2023 at 9:09 PM Fernando Gont <[e-mail]> wrote:
> > At the very least, a host can be expected to have one
> >    link-local address, one stable global address and one privacy
> >    address.
>
> This is no longer the case. As per RFC8981, host can also do temporary only.

In -02 it will be rephrased as
"At the very least, a host can be expected to have one link-local
address, one temporary address and, in most cases, one stable global
address."

> Note: I'd also use the terminology in RFC7721 (or similarly in RFC8981),
> and not use the term "privacy addresses" but rather "temporary addresses".

Thanks, will update the text.

> Intro:
> >  Devices
> >    running containers/namespaces would need even more addresses per
> >    physical host.
>
> This seems to imply that containers get exposed on different addresses
> each, which is not what typically happens with e.g. Kubernetes.

It happens in many cases, if the traffic is bridged.  Would it be
better if we s/would/might/?

> Section 3:
> >    *  The allocated /64 is installed into the first-hop router routing
> >       table as a route pointing to the client's link-local address.  For
> >       the router and all other infrastructure devices that prefix is
> >       considered off-link, so no traffic to that prefix does not trigger
> >       any ND packets.
>
> It's Friday night, but, of the top of my head, this would lead to a
> bunch of ICMPv6 Redirects (one for each address in use).

To be honest, the topologies where the proposed design is most useful,
tend to block peer2peer anyway (and in many cases redirects are
disabled on the router).
Anyway a single ICMPv6 is better than keeping a neighbor cache entry state.
I'll add some text to section 5 re: redirects.

>So one might
> wonder why not, e.g., have routers send RIOs to allow for more direct
> communication where possible?

I guess the router may do this. However it would be useful only if
each interface has its own DHCPv6-PD pool (I, for example, might want
to have 5 different VLANs with the same pool shared between them.
Sending RIOs for each /64 wouldn't scale - unless the router is
capable of aggregating multiple /64s into a shorter supernet - but
then there will be issues with setting a lifetime..
I guess we can say smth like "if each interface has its own pool, and
intra-segment traffic is allowed, the administration might want to
configure the routers to include the pool supernet as a Route
Information Option (RFC4191) in RAs".


> Section 3:
> >    *  The host uses /64 to allocate addresses to its interfaces,
> >       containers etc.
>
> Did you mean "the leased /64"? --- one way or another, please clarify
> this.

Will updated the text in -02.

>Additionally, the plural might be confusing... it would seem to
> me that the leased /64 would be employed to assign addresses on *this*
> network interface (the one receiving the lease), rather than on any
> interfaces....

Actually, no. The whole idea is that the device can use /64 to address
*other* interfaces as well. For example, the device can include that
/64 into Router Advertisements sent to virtual systems or to any other
devices connected to its downstream interface.
I'll update the text to clarify it.

> Section 8:
> >    *  When the network supports both /64 per host and SLAAC as address
> >       assignment methods, it's highly desirable for the host NOT to use
> >       SLAAC and only use the prefix delegated via DHCPv6-PD.
>
> Strictly speaking, even that of configuring link-local addresses (e.g.
> with RFC7217) is considered "SLAAC" -- so you probably want to rephrase
> the text a bit.

Done.


> Section 9:
> >    *  If all devices support this mode of operation, it is possible to
> >       remove the global /64 prefix from the interface completely,
> >       reducing the attack surface for Neighbor Discovery attacks
> >       described in [RFC6583].
>
> Could you please elaborate on this one?

How about this:

 If all devices connected to the given network segment support this
mode of operation and can generate addresses from the delegated /64,
there is no reason to advertize a common /64 assigned to that segment
in PIO with 'A' flag set. Therefore it is possible to remove the
global /64 prefix from that network segment and the router interface
completely, so no global addresses are on-link for the segment.
This would lead to  reducing the attack surface for Neighbor Discovery
attacks described in RFC6583.

Better?

--
SY, Jen Linkova aka Furry