Re: [v6ops] WGLC: draft-ietf-v6ops-dhcp-pd-per-device-02

[Pascal Thubert <[e-mail]>]

Hello Jen

Le mar. 3 oct. 2023 à 14:50, Jen Linkova <[e-mail]> a écrit :

> Hi Pascal,
>
> First of all, thank you for the review and feedback.
>
> On Sun, Oct 1, 2023 at 6:20 AM Pascal Thubert <[e-mail]>
> wrote:
> > I support the draft and look forward to its publication. I believe that
> 02 is not ready, and the following points should be addressed in this WGLC.
> Main issue is that the draft does not indicate how the routers that need
> the route will know about it,
>
> Do you mean other routers in the network, not the first-hop routers
> for which the client is  on-link?
> You are right, we might need to update Section 6 and say explicitly
> that the operator would need to ensure that relays have the
> functionality defined in R-4 of RFC8987 (it says 'MAY' but I'm yet to
> see a relay in production which doesn't do that - still, we'll make it
> more clear).
>
>
Yes. I think we have sync'ed on that in another exchange in this thread


> > and how the route is maintained when the host moves.
>
> Would you like to see a short subsection in Section 6 which would talk
> about L2/L3 roaming? It would be basically very simple:
> - L2 roaming (the network segment doesn't change): the route doesn't
> change as the next-hop is the host link-local, so as long as the
> routers have the entry for the host link-local address in the NC, it
> works.
>

Yes, a little text would be neat and yes, that is the easy piece since the
MAC mobility covers it. Bottom line, the draft could say that if there's
some routing involved then the DHCP relay should use its black magic to
inject the route to the /64 and either attract the traffic or indicate the
host as next hop on the local link.


> - the host moves to another network segment (another router L3
> interface). In this case the old e route will be deleted as the
> nexthop becomes unreachable. The host would reconfigure its IP stack
> anyway as it moves to another segment (it would need to do it no
> matter which address assignment mechanism is used - SLAAC, DHCPv6, or
> this one).
> What do you think?
>
>
I think the host would like to retain the prefix as long as it is in the L3
domain that is covered by the upper aggregation, and that domain may be
larger than the L2 (broadcast) domain in an enterprise oir a campus, e.g.,
it would span the whole campus.
Reason is that when there are tethered devices, renewing the /64- would
mean renumbering that network, not good.
This is where draft-ietf-6man-ipv6-over-wireless and
draft-ietf-6lo-prefix-registration become really handy. The host can prove
to the infra that it owns the prefix regardless of the way it got it (DHCP
PD or else) and the router will inject it in the local routing (
SGP/IGP/EVPN rte type5...).



>
> > "Many enterprise-scale wireless solutions implement ND proxy to reduce
> amount of broadcast and multicast downstream (AP to clients) traffic."
> > The one major reason in my  experience is SAVI as opposed to the claim
> above. Saving broadcast is a limited side effect that can only work when
> the switch, or more likely the AP, knows for sure all the addresses on the
> links it's proxying for. This works with IPv4 that is DHCP- only and one
> address per MAC, but mostly impossible to achieve with SLAAC.
>
> My experience varies dramatically. All WiFi vendors I deal with
> implement ND proxy and hence their devices maintain a list of IP
> addresses for each client, hence the issue described in the draft.
> Do you think "Many" is too strong? I definitely know more than 2, so..;)
>

Your text is fully correct for IPv4 and the ARP proxy function that 802.11
mandates and IPv4 provides specs for. The design can be extended to DHCPv6.
because the AP will always see the unicast REPLY. Yes, the Many is a bit
unsubstantial and could be avoided.

The main trouble is with SLAAC. In that case, the AP has to tap dance
because it is never sure that it knows all the addresses of the associated
STAs, and conversely whether there is still an address in the STA for each
entry in its table. If the AP cancels the MAC-level broadcasts too
aggressively, then it will (overtime) cause that some DADs and NS lookups
are not delivered to the owner for the target address. And again you get
calls to support; not good. So the AP code tends to let them through when
it is not too sure, proprietary_heuristics_alert there. You'll find the
term BUM to refer to this problem, the U is for unknown, and unknown is the
root of all evils in that game.

This is why we published RFC 8929, which is the only way to provide a
deterministic "ARP function" for IPv6 together with autoconf. But it's not
implemented in the major stacks so the issue is the same as it was 20 years
ago, and enterprises ban at least  SLAAC and more often than not IPv6 as a
whole.

What hurt me in your text was not so much the  " Many " as the stated
objective. If you just add " and provide SAVI functions" I'd already be
happy.


>
> > I believe the draft could mention that the idea of DHCP prefix
> delegation would allow a reduction of broadcast but may interfere with the
> proxy operation. Reason is, the proxy is usually a proprietary middle box,
> doing a non-standard operation, thus it cannot be expected to behave
> properly in conjunction with this work or any other new situation.
> Middleboxes are famous PITAs for any new standard operation and I believe
> the IETF was alerted many times about that risk in this particular
> situation. Note: RFC 8929 is an attempt to remove this middlebox operation
> and move to standards. But we made little progress in deployment on that
> front, either.
>
> IMHO broadcast/mcast noise would be drastically reduced if all clients
> are using PD and the given segment (a router interface)  doesn't need
> to have a shared /64 assigned - that would eliminate ND attacks, and
> we do mention it in Section 10.
> For traffic to/from existing hosts, I do not think [b|m]cast would be
> reduced much.
>

Agreed. If we know that there is only stateful protocols like DHCP and RFC
8505 but no SLAAC, then the situation changes dramatically and the AP can
make assumptions like "I know all the addresses that this guy may use".


>
> But you are right, the proposed solution would lead to some multicast
> reduction because:
> - in a "addresses formed from a shared prefix with A=1" case a packet
> to an address the router doesn't have a NC entry for would trigger a
> multicast ND packet (and if the routers/hosts do not support RFC 9131
> it might also cause some packet loss). With the proposed solution this
> problem goes away as all traffic to the delegated prefix would be
> *routed* to the host link-local address, for which the router has an
> entry anyway.
> - if the host uses /64 to expand the network downstream, no DAD
> packets are sent to the shared link. Also good ;)
> Thanks, I didn't think about that, I'll update the text.
>

Cool : ) What really happens is that the routers involved in forwarding
within the aggregation of the delegated prefix will have routes to the
delegated prefix. True along the path from the aggregating border router,
also true at the last router with in that case the next hop set to the
host. That route will forward all the packets with the destination within
the delegated prefix to the host, no ND involved, no broadcast. That's
good. There will also be no check on whether the address exists so the host
will take the full hit of all the DDOS scanning attacks: and the routers
will not protect it anymore. In the security section, it would be good to
have some text about that issue.



>
> Now, I'm not sure why the ND proxy would be an issue. ND proxy is only
> applicable for resolving onlink addresses. So traffic to the delegated
> prefixes doesn't trigger any ND except for STALE ND cache entry for
> the host link-local addresses (from the router downstream) and for the
> default gateway address (sent by the hosts upstream). That ND traffic
> exists anyway, even without PD.
>
> Or am I missing smth?


That's the problem with unspecified "features" vs standards. Since the IPv6
"ARP proxy" is a hack with no standard to back it up, and since it is
coupled with SAVI functionality (you see here the reason of my point above)
then the "feature" may do a lot more than filtering anything that they do
not see as correct. The "ARP proxy" becomes a middle box that kills
everything that it does not understand and validates, like firewalls do
with unknown ULPs causing us to do everything new over UDP. This is what I
meant here: unspecified middlebox behaviours are major PITAs for deploying
new protocols, and sorry to say that the highly desirable function that
your draft discusses will also be subject to that bug / feature. A new AP
can be converted to understand this situation but an old AP with code that
only forwards when it has a BCE/NCE will drop the packets (to protect the
host!). We (the IETF) are guilty for the existence of middleboxes when they
show up to cover the lack or deficiencies of standard. If you remember my
interventions at 6MAN for years, I was trying to prevent that from
happening and now we are in the middle of the predictable crap.

My only solution was and still is to provide the standard for the IPv6 ARP
proxy, and my attempt to do that is RFC 8929.

Actionable for your draft: in addition to the text that you suggest above,
maybe you could also place a warning in the security section about legacy
"ARP proxy" functions that may drop the packet when there's no BCE in
either direction. Lorenzo and I discussed a case like that recently, and I
did all I could to get that situation to progress, not much success so far.
Is the middlebox a bug or a feature?





>
> > Section 4: There's  a missing bullet about how we handle the routing to
> the delegated prefix. The PD-Relay must ensure that all the routers that
> operate within the higher aggregation know how to route that prefix. As
> written, it seems that there's only one router
> >and that router is also the relay. Even in that case, the router needs to
> install a route to the delegated prefix via the host seen as a neighbor.
> This should be mentioned.
> > In a more complex case (see discussion on 6.2), there are more routers
> that need to install a route, so the delegated prefix must be injected in
> the IGP or SGP. In an even more complex case (think overlays) the prefix
> needs to be injected, e.g., as a route type 5 in EVPN.
>
> Yes, see my comment above. The solution relies on the rfc8987 R-4
> requirement but indeed we shall make it explicit.
> Will add some text in -03.
>
>
cool, looking forward


> >And then there's route maintenance when the device moves within the
> higher level aggregation domain. Since the draft deals with hosts that can
> be mobile, the effect on mobility to the assignment  and routing, and the
> possible renumbering of the tethered or inner network if the host cannot
> retain the prefix, must be discussed.
>
> Ah, thanks for pointing this out. another thing we didn't say
> explicitly while we definitely should!
> Moving to another segment (VLAN/link - as Ole pointed out we'd need to
> define the term) should trigger reconfiguration of the IP stack. The
>

I tried to stick to L2 broadcast domain. This is the limit within which
it's a L2 problem and renumbering is not needed.



> same way when a host moves between different segments where addresses
> are assigned by SLAAC or IA_NA (and yes, a lot of OSes can't get it
> right still).
>
>
I'm worried about the case where there are tethered nodes that do SLAAC and
stuff, which the argument the draft uses for asking for short <=64 plens.
I insist that there should be 2 cases, and the problem here mostly for the
tethered case and the implied renumbering.



> > Section 5 1st paragraph. The draft should consider the case of tethered
> wifi and VM separately from the case of distributing addresses inside the
> device. In the former case, plen > 64 is desirable but it entails the
> renumbering issues, so either the host is fixed or the solution should
> allow the node to move the prefix with it.
>
> The host must be capable of dealing with network change/renumbering,
> no matter what mechanics of address assignment is used.
> Even w/o delegating prefixes (so addresses are assigned via
> SLAAC/IA_NA) if your laptop with virtual machines is moved from one
> network segment to another - all those downstream systems (which got
> addresses from RA or from the DHCPv6 server) need to be renumbered.
>
>
Is that your experience that the tethered devices will renumber quickly
enough when the device to which they are attached roams? It would be a lot
safer for enterprise networks to be able to inject the route after the
mobility event. This is what the NBMA architecture does.




> >In the latter plan >= 64 is a huge waste of resources and a loss of
> privacy. being an ops document, Section 5 should spend the necessary time
> to explain the pro/cons in all situations.
>
> IMHO the line between "VM" and "distributing addresses inside the
> device" is very much blured. When a device connects to my network, I
> have no idea if it needs addresses for VMs, expanding the network to
> physical elements or just "an address per application" - or maybe all
> of the above.
> So this proposal recommends the least common denominator.
>
>
As long as there is no tethering there is no slaac either, and the problem
you put forward as if it was the major thing just does not exist. This is
an ops document. It should explain the pros and cons of prefix sizes. The
reader should be able to form an option on what's major for him.

If there is no slaac then the host could get a /96 and if that's not enough
(meaning your host is bigger than the current public internet), get another
later and then another.

To address your response, the host should know whether there's tethering
because there must be an interface (physical or logical) on which it has to
send RAs for the 64s out of the delegated prefix, even to VMs. So it could
adapt its PD requests based on whether this is happening or not. For VMs in
particular, we should also consider whether the embedded OS supports SLAAC
for longer prefixes in the real world use cases (meaning Linux variations
for the most part).



> > Section 6.2 does not address the routing aspect of the delegated prefix.
> Not all first hop routers will see the REPLY since it is unicast,
>
> First hop routers would be relays, otherwise it would cause some
> asymmetric routing, where traffic to the delegated prefixes is sent to
> the relay, while traffic from the prefix is sent to the client's
> default gateway). I'll add a text to make it explicit.
>
> >and not all routers within the next level of aggregation will know what
> to do with it, since they might not be on path of the reply. The prefix
> must be injected in the IGP / SGP and either it follows the mobility of the
> host which is the expectation in an SGP, or it must be released when moving.
>
> Indeed. I'd say it's a case for any infrastructure which uses
> DHCPv6-PD and relays, so there is nothing new here (or maybe it's just
> me, I have tons of devices receiving prefixes via PD in my routed
> network - dynamic routing protocols seem to be doing their job so far
> ;)
>
> > "The server MUST provide a prefix short enough for the client to assign
> addresses to its interfaces and connected systems via SLAAC.
>
> > How does the Server know whether the client has tethered systems or not?
> In that case only it might also need the number of interface (each needing
> a /64). If not, then the argument for the MUST does not hold: instead, the
> sentence should recommend one or more long plen, which alleviates the
> issues with the number of hosts that can be served in section 11.
>
> How about "at least one interface"? That would cover the most common
> use case while still allowing the client to ask for more. Some of
> clients in my network get /60, some /56, some /64. It depends.
> The server doesn't need to know the number of interfaces, it's the
> client's job.
>
>
Yes, exactly. The text should conclude after explaining pros and cons that
if the host knows that it has at least one interface (logical or physical)
on which there are  (logical or physical) devices that need SLAAC, then it
must get a prefix that is long enough to provide them the plen they need
for their SLAAC operation. But also that when this is not the case, it is
free to ask for one or more longer prefixes beyond 64. I've discussed the
pros of longer prefixes in previous mails, I can help if you need text.



> Thanks again for the review, stay tuned to -03.
>
>
Very cool!

Pascal


> > Le 30/09/2023 à 22:42, Xipengxiao a écrit :
> >
> > Hi Folks,
> >
> >
> >
> > This message initiates a WGLC for
> draft-ietf-v6ops-dhcp-pd-per-device-02. The call will end on Oct 14, 2023.
> Your opinion will be valued.
> >
> >
> >
> > Ron & XiPeng
> >
> >
> >
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
> >
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
> --
> SY, Jen Linkova aka Furry
>


-- 
Pascal