Subject: [v6ops] privacy point re. unsolicited NA / router neighbor cache

From: David Lamparter <[email-masked]>
Date: Mon, 22 Jul 2019 23:37:27 +0200

Hi all,

to clarify and document the point I made on the mic a few minutes ago:

I'm generating a privacy address.  I do DAD for it, and I send it to,
say, ff02::1:ffc6:3a4b.  On shitty networks, this will be a broadcast,
so everyone knows the address I'm using and can associate the MAC.  But
on non-shitty networks, it doesn't go anywhere because no one is
interested in that particular group.

I really don't want to suggest advertising privacy addrs to ff02::1.
Yes, the privacy might already be broken due to nonexistent multicast
filtering, but it's not broken by design.  Broadcasting it to ff02::1
breaks it by design.

ff02::2 has the problem Lorenzo mentioned with battery lifetimes.  It
might be broken in practice, but would work in theory, if you had proper
multicast filtering everywhere.  That might not even be the device's
wifi chip firmware, it could also be in APs.  I feel some strong deja vu
here from 802.11 multicast discussions.

The third option is for the router to pick up all DAD groups.  It
certainly won't report /ALL/ DAD groups in MLD, so this would break if
you have MLD-snooping switches... unless you configure multicast routing
properly with "all multicast on router ports".

Is there another choice? How about ff02::16 (All MLDv2-capable routers)?

-David

---

From: Mark Smith <[email-masked]>
Date: Tue, 23 Jul 2019 09:13:19 +1000

> Is there another choice? How about ff02::16 (All MLDv2-capable routers)?

Why not have routers on the link learn of a node's link-local address via
source addresses of the node's RSes and MLDv2 joins, and then have the
routers query the node via unicast for all its other addresses.

There's already two ways the unicast query could be supported to collect
the node's other addresses, via ICMPv6 Node Information queries (RFC 4620)
, or Inverse ND (RFC 3122).

Regards,
Mark.

>
> -David
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: David Lamparter <[email-masked]>
Date: Tue, 23 Jul 2019 02:00:49 +0200

> > interested in that particular group.
[...]
> routers query the node via unicast for all its other addresses.

Neither of these contains the global address(es) that a host generated,
so you would need...

> , or Inverse ND (RFC 3122).

... either of these options, which I strongly hope no one implements
because then I can just chuck all my privacy considerations straight out
the window...

(Coincidentally, I'm pretty sure most hosts won't respond to either of
these two.)

I'm tentatively in the DAD snooping camp, but this is a tricky problem.
My decision tree for DAD is this:

1. do you have a network with multicast snooping / limited multicast
   propagation?

=> No: your router sees all DAD anyway, but also your privacy is already
   f*cked from the DADs you sent.  Either way we're not making it worse
   by picking the DADs up on the router.  End tree.

=> Yes: it seems someone configured multicast.  (You don't get this
   without config, it's a bit of a PITA honestly.)  Proceed to 2.

2. is whoever configured multicast competent?

=> No: you're screwed already because broken multicast is broken DAD.
   So if not all DAD makes it to the router, some or all clients will
   experience connectivity delays.  ff02::1 or ff02::2 could /lessen/
   these issues, but they come with their own bag of troubles and your
   broken multicast setup might be messing with them anyway.

=> Yes: the competent person needs to understand that unicast routers
   need to receive all multicast traffic in order to catch and snoop
   DAD.  Set the "multicast router present" bits on the appropriate
   ports on your L2 devices and you're golden.  Also, this is the only
   scenario where some measure of address privacy can be provided, since
   this is the only scenario in which DAD wouldn't turn into a
   broadcast, and it remains so even with the router picking up all DAD.

-David

---

From: Mark Smith <[email-masked]>
Date: Tue, 23 Jul 2019 10:34:05 +1000

> because then I can just chuck all my privacy considerations straight out

If that's enough of a concern to you, them you must isolate your hosts to
their own individual links, virtual or physical, so the only other devices
on the link is one or more trusted routers.

You can't attach a set of untrustworthy hosts to a mutual trust,
multi-access link and then trust those hosts to always behave. The explicit
point of those types of links is to be able to send anything to anyone.

> (Coincidentally, I'm pretty sure most hosts won't respond to either of

We invent the future here.

However, I have some small distant evidence that Mac OS X already does,
because it sends MLDv2 joins for the NI multicast group. (I don't have
access to OS X to further look, and it wasn't something I was looking into
at the time.)

There's already a BSD/Linux NI implementation available. The out of the box
version of 'ping' that comes with Fedora 30 can send NI queries.

So we're not talking about 'from scratch' implementation, or complete
replacement of ND.

There would need to be a transition mechanism and period for hosts that
don't support these queries. That's no different to any other solution that
requires changes to either or both host and router behaviour.

> My decision tree for DAD is this:

DAD doesn't occur with anycast addresses, do it isn't a complete solution.

I'm pretty sure Ericsson have IPR for that idea, because it came up with
the discussion of this draft.

Not that IPR is a reason not to use the idea, however I think it is better
to avoid it, combined with not supporting onlink anycast addresses.

Triggering ND Address Resolution on Receiving DAD-NS

https://tools.ietf.org/id/draft-halpern-6man-nd-pre-resolve-addr-00.txt

---

From: Gert Doering <[email-masked]>
Date: Tue, 23 Jul 2019 09:01:41 +0200

Hi,

> 2. is whoever configured multicast competent?

The general assumption for on-link multicast should be "it's broadcast
or it is getting lost".

Switch vendor track record shows that this is a constantly recurring
problem, and the *best* you can hope for operational robustness is
"on-link multicast is handled like broadcast".  All the other snooping
things just cause more work in figuring out this week's bugs and how
to turn off the snopping bits.

The general idea that on-link multicast is a positive aspect of IPv6 
is nice, but wrong.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Sander Steffann <[email-masked]>
Date: Tue, 23 Jul 2019 15:32:47 +0200

Hi,

> The general idea that on-link multicast is a positive aspect of IPv6

Well, a little bit :)

There is still the advantage that the NIC can apply its MAC address filter. L2 destination FF:FF:FF:FF:FF:FF can't be filtered there, but 33:33:* can :)

Cheers,
Sander

---

From: Gert Doering <[email-masked]>
Date: Tue, 23 Jul 2019 15:48:25 +0200

Hi,

> There is still the advantage that the NIC can apply its MAC address filter. L2 destination FF:FF:FF:FF:FF:FF can't be filtered there, but 33:33:* can :)

Given the insanity of modern NICs, I have no doubt it could filter about
everything the host want to see :-)

(Shall I say "LLDP agent inside the NIC that you can't easily get rid of"?)

But seriously - given that the amount of multicast traffic that goes 
to a group address is totally negilible compared to the amount of 
"TO ALL!" traffic caused by netbios, bonjour, ... - and that we do not
really have 10 Mbit NICs anymore, I still maintain that this was one
of the IPv6 "improvements" where unintended side effects by far outweigh
the small benefits.

Gert Doering
        -- NetMaster

---

From: Sander Steffann <[email-masked]>
Date: Tue, 23 Jul 2019 15:58:26 +0200

Hi,

> (Shall I say "LLDP agent inside the NIC that you can't easily get rid of"?)

Hello X710!

Device ID           Local Intf     Hold-time  Capability      Port ID
246e.9646.6890      Te1/0/1        121                        246e.9646.6890
246e.9646.6892      Te1/0/2        121                        246e.9646.6892

To be absolutely clear: the device connected to those ports is currently switched off... This is the NIC speaking from standby-mode.

Cheers,
Sander

---

From: David Lamparter <[email-masked]>
Date: Tue, 23 Jul 2019 16:30:57 +0200

> The general idea that on-link multicast is a positive aspect of IPv6 

I'm happy to agree that in most cases multicast will be broadcast, and
gleaning DAD on the router(s) to prime a neighbor cache entry works
perfectly fine for that situation.

I also think that we shouldn't break things by design, and the
address-dependent DAD multicast groups are a feature both in terms of
limiting flooding as well as improving privacy, even if neither of these
two materializes in common setups.

Which of these matters more is of no impact for DAD gleaning since it
happens to work out to a good solution for both.  It *does* break for
networks with badly configured multicast, but I believe this is an
acceptable caveat -- what we're trying to fix here is a delay in
establishing communication, so the failure case is that this delay
remains.  I'd argue this is an acceptable result of an incompatible
multicast configuration made out of either ignorance or error.

I'm also confident enough in saying I don't believe any relevant switch
or router default configurations include such broken multicast snooping
config.  If it's broken, it's something the operator broke.  I'd even
agree with you that operators are well-advised to not enable multicast
snooping in most cases, so it keeps being broadcast.  Exceptions prove
the rule.

Cheers,

-David

---

From: Gert Doering <[email-masked]>
Date: Tue, 23 Jul 2019 17:34:56 +0200

Hi,

On Tue, Jul 23, 2019 at 04:30:57PM +0200, David Lamparter wrote:
> config.  If it's broken, it's something the operator broke.  

Yeah.  That's what one would expect.  Like "protocols igmp-snooping" either
being off-by-default *or* not breaking IPv6.

But hey, out there, we have the reality zone.

Vendors will break *anything* that is not immediately obvious in their
"we tested this with IPv4 unicast!" test sets.

So yeah, if all this IPv6 multicast stuff *works*, it's not hurting much,
but it breaks often enough, across enough gear of enough vendors, that 
it's actually making IPv6 more brittle than IPv4.

Gert Doering
        -- NetMaster

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 23 Jul 2019 20:40:49 +0100

Sander Steffann wrote on 23/07/2019 14:58:
> To be absolutely clear: the device connected to those ports is currently switched off

"switched off"?  What a quaint, antiquated idea :-)

Nick

---

From: Fred Baker <[email-masked]>
Date: Tue, 23 Jul 2019 12:49:09 -0700

> On Jul 23, 2019, at 7:30 AM, David Lamparter <[email-masked]> wrote:
> 
> I'm happy to agree that in most cases multicast will be broadcast

Technically, I think it is fair to say that, at least on anything called "Ethernet", multicast is a filter that reviews received broadcasts. The message either arrives at an end node or not. Unicast goes to a specific node or goes nowhere at all, and broadcast is the service that gets it to all of them. The end node then looks at the first 48 bits received, and either stores the message or doesn't based on its configuration. Multicast is broadcast with that filter.

Speaking from the perspective of someone who has written several drivers for such interfaces, it is a little amazing that the configuration of the multicast filter seems to not be a ubiquitous feature. But apparently it is not.

---

From: Mark Smith <[email-masked]>
Date: Wed, 24 Jul 2019 11:13:42 +1000

On Tue., 23 Jul. 2019, 23:33 Sander Steffann, <[email-masked]> wrote:

> There is still the advantage that the NIC can apply its MAC address
> filter. L2 destination FF:FF:FF:FF:FF:FF can't be filtered there, but
> 33:33:* can :)

It's no surprise that Steve Deering also wrote RFC 1112, "Host Extensions
for IP Multicasting", which says,

"7.4. Extensions to an Ethernet Local Network Module
...
It is highly desirable to take advantage of any address
   filtering capabilities that the Ethernet hardware interface may have,
   so that the host receives only those packets that are destined to it."
...

IPv4 and IPX uses/used link-layer broadcasts. Appletalk used link-layer
multicasts, however, from memory, it used the same or a few multicast
address for everything.

IPv6 improves Appletalk by using much more specific link-layer multicast
addresses for different purposes, which allows NIC filtering to be much
more fine grained.

If a host is only running protocols that use link-layer multicasts, then it
could switch off broadcast reception in its NIC (IFF_BROADCAST interface
flag).

For example, an IPv6 only host attached to a link that also has IPv4 hosts
would be able to drop in its NIC hardware IPv4 ARPs and DHCPv4 DISCOVERS,
rather than processing and then dropping them at higher layers in the stack.

Regards,
Mark.

---

From: Jen Linkova <[email-masked]>
Date: Wed, 24 Jul 2019 22:25:49 +1000

> The general assumption for on-link multicast should be "it's broadcast

I'd disagree with that statement but your experience may vary indeed.
I'll add more text describing different scenarios but off top of my
head using NA has one advantage over DAD:
it reduces probability of disruption in case of address conflicts
(again, for the rare scenario when the rightful owner does not have a
cache entry for some reason).

Ah, as I've said, my experience is that DAD packets have less chances
to get through 'smart' WiFi infrastructure.

> The general idea that on-link multicast is a positive aspect of IPv6

I see a subtle difference between 'wrong' and 'not true for every network'.

-- 
SY, Jen Linkova aka Furry

---

From: Gert Doering <[email-masked]>
Date: Wed, 24 Jul 2019 14:48:18 +0200

Hi,

> I see a subtle difference between 'wrong' and 'not true for every network'.

Ideas are not bound to a particular network.  If the benefits are small to
zero, but it adds complexity that (inevitably) causes more breakage than
"no added complexity", the overall aspect can no longer be called "positive".

Kudos on your vendors if you never had any IPv6 issue that was related
to multicast.  I've had plenty (... incidentially, the first ever IPv6
related explosion I saw was a Linux E100 driver that misprogrammed 
something regarding multicast filtering in the NIC, causing it to send 
out multicast packets at wire speed... around 2002 or so).

Gert Doering
        -- NetMaster

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 24 Jul 2019 13:02:32 +0000

Hello Jen

Though I made a good living of a 'smart' infrastructure, I just hate the concept of playing with the expectations of the protocols by dropping or changing packets in intermediate boxes. 
In a fashion doing that we're no better than NAT. We are 'obliged' to do it because the way the archaic protocols uses the modern media would kill us. 
But one cannot be 'smart' enough. Things 'mostly' work, and there's a word too many in that sentence.

Like NAT, the consequence is that we are making it much harder for the next generation to update the protocols because now they are afraid of all the possible variations for vendor secret sauce. 
Note: I tried to document some of that secret sauce in the past, e.g., https://tools.ietf.org/html/draft-thubert-savi-ra-throttler but did not raise much interest/echo. Most of it is vendor specific and undocumented. In that regards it is actually worse than NAT. Some 'smart' APs just drop RS on wireless interface. What if in the future I want to have a router there?

And by hiding most of the problem under the snooping carpet, we are removing the incentive to update the archaic protocol. Doing so we are impairing the evolution of that protocol and condemning it to deprecation. 
I want the upper layer protocols to get what they expect from the lower layers end-to-end and to do that I want the upper layers to use the lower layer services wisely. This way we can make the infrastructure stupid again.

All the best,

Pascal

> -----Original Message-----
> From: v6ops <[email-masked]> On Behalf Of Jen Linkova
> Sent: mercredi 24 juillet 2019 05:26
> To: Gert Doering <[email-masked]>
> Cc: v6ops list <[email-masked]>
> Subject: Re: [v6ops] privacy point re. unsolicited NA / router neighbor cache
> 
> I'll add more text describing different scenarios but off top of my head using
> NA has one advantage over DAD:
> it reduces probability of disruption in case of address conflicts (again, for the
> rare scenario when the rightful owner does not have a cache entry for some
> reason).
> 
> Ah, as I've said, my experience is that DAD packets have less chances to get
> through 'smart' WiFi infrastructure.
>