Subject: Re: [v6ops] Practical question about MLD join for LL multicast

From: Enno Rey <[email-masked]>
Date: Sun, 3 Apr 2016 10:55:24 +0200

Hi Ole,

On Sat, Mar 12, 2016 at 06:23:50PM +0100, [email-masked] wrote:

> it depends on the platform and how big forwarding table your switch can handle.
> as far as I many switches flood,( and if you want my personal opinion, we should change hosts so that they no longer send MLD joins for link-local groups.)

wouldn't this (your personal suggestion)
- require updating RFC 4861 where it's stated (sect. 7.2.1 on Interface Initialization): "Joining the solicited-node multicast
   address is done using a Multicast Listener Discovery such as [MLD] or
   [MLDv2] protocols."
- maybe break ND on some host OSs/platforms (depending on their interpretation of the exact statement above)?

[it should be noted I consider that statement a quite unfortunate example of ambiguous wording in an RFC as "is done" can be both read as a descriptive and prescriptive/normative statement]

thanks

Enno

> Best regards,
> Ole

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

-- 
Enno Rey

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

=======================================================
Blog: www.insinuator.net || Conference: www.troopers.de
Twitter: @Enno_Insinuator
=======================================================

---

From: [email-masked]
Date: Sat, 9 Apr 2016 04:05:27 +0200

Enno,

Apologies for the late reply, IETF made following email patchy.

>   address is done using a Multicast Listener Discovery such as [MLD] or

Yes, we would have to update 4861.

> - maybe break ND on some host OSs/platforms (depending on their interpretation of the exact statement above)?

Given that the only reason why we added the MLD requirement was to support  MLD snooping bridges, I don't think there is anything in the ND protocol that expects MLD for anything.

> [it should be noted I consider that statement a quite unfortunate example of ambiguous wording in an RFC as "is done" can be both read as a descriptive and prescriptive/normative statement]

Interoperability is king. I think implementors are smart enough to see what requirements are there to achieve interoperability, and which are merely suggestions. And yes we use RFC2119 language for both cases. :-)

Best regards,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 9 Apr 2016 15:35:14 +1200

> Given that the only reason why we added the MLD requirement was to support  MLD snooping bridges, I don't think there is anything in the ND protocol that expects MLD for anything.

I'm sure that's true, and logically it's the same for any protocol that uses
link-local multicast for anything: bridges that aren't bridges, because they
drop LL multicasts by default, force implementations to perform MLD joins.
Worse, bridges that aren't bridges *and* have defective MLD snooping by default
break such protocols.

I'm not sure what the IETF can do about this except scream and shout.

   Brian

---

From: Mark Smith <[email-masked]>
Date: Sat, 9 Apr 2016 13:45:35 +1000

> Yes, we would have to update 4861.

You also have to update a number of other RFCs that talk about or
refer to solicited-node multicast groups and MLD,

RFC2710,

"MLD messages ARE sent for multicast addresses whose scope is 2
   (link-local), including Solicited-Node multicast addresses [ADDR-
   ARCH], except for the link-scope, all-nodes address (FF02::1)."

RFC3810, which only excepts FF02::1 as a special case,

"The link-scope all-nodes multicast address, (FF02::1), is handled as
   a special case.  On all nodes -- that is all hosts and routers,
   including multicast routers -- listening to packets destined to the
   all-nodes multicast address, from all sources, is permanently enabled
   on all interfaces on which multicast listening is supported.  No MLD
   messages are ever sent regarding neither the link-scope all-nodes
   multicast address, nor any multicast address of scope 0 (reserved) or
   1 (node-local)."

RFC3590,

"As the unspecified address is only used when there is no link-local
   address, RFC 2710 implementations discarding these packets will have
   no affect on the packet's sender as the use should only be for
   joining the link-local solicited-node multicast group [RFC 2462]."

RFC4862,

"Note that when a node joins a multicast address, it typically sends a
   Multicast Listener Discovery (MLD) report message [RFC2710] [RFC3810]
   for the multicast address.  In the case of Duplicate Address
   Detection, the MLD report message is required in order to inform MLD-
   snooping switches, rather than routers, to forward multicast packets. [...]"

> Given that the only reason why we added the MLD requirement was to support  MLD snooping bridges, I don't think there is anything in the ND protocol that expects MLD for anything.

You're right, there is nothing in the ND protocol that expects MLD.

Although my answers weren't coming through, I did see your comment at
the end of my presentation in the v6ops session on Monday.

>From what I remember, you expressed a concern about coupling MLD and
ND operation. I don't think my proposal is doing that - ND can operate
without the MLD information I'm suggesting leveraging, although it is
more vulnerable to the ND cache exhaustion attack. The dependency that
ND operation would place on MLD is completely optional.

So it is a trade-off - an optional dependency on MLD's collection of
Solicited-Node multicast group information to provide ND with more
information about what is possibly on the link, to gain less exposure
to ND cache resource exhaustion attacks from remote attackers.

There may be other future opportunities to leverage information
collected MLD for SNMGs that will never be possible if they are
deprecated.

For example, MLDv2s for SNMGs, if collected, would provide a complete
list of at least one Link-Local address of each of the nodes attached
to the link, as LLs are used for MLDv2 source addresses (except the
initial ones when LLs aren't available). If nodes then supported
either Node Information Queries (as it appears Apple devices already
do), or InverseND, then using that list of LL addresses, a router
could ask each of the nodes what its other IPv6 addresses are, giving
the router a complete list of all of the IPv6 unicast and anycast
addresses present on the link. There would now be no need for the
router to send ND NSes at all, as it would know all possible
destinations on the link.

Regards,
Mark.

---

From: Enno Rey <[email-masked]>
Date: Sat, 9 Apr 2016 10:59:06 +0200

Ole,

> Yes, we would have to update 4861.

why is it that such a statement from *your* side sounds a bit like a threat? ;-)

> Given that the only reason why we added the MLD requirement was to support  MLD snooping bridges, I don't think there is anything in the ND protocol that expects MLD for anything.

if just the implementors knew/had realized this... in reality host operating systems behave quite differently in this space. admittedly on quite some one can disable/block MLD *without* breaking ND, e.g. see https://www.insinuator.net/2014/09/mld-and-neighbor-discovery-are-they-related/.

> Interoperability is king. I think implementors are smart enough to see what requirements are there to achieve interoperability, and which are merely suggestions. And yes we use RFC2119 language for…

;-)

have a great weekend everybody (and safe travels home),

Enno

-- 
Enno Rey

---

From: Enno Rey <[email-masked]>
Date: Sat, 9 Apr 2016 11:17:54 +0200

Brian,

On Sat, Apr 09, 2016 at 03:35:14PM +1200, Brian E Carpenter wrote:

> I'm sure that's true

alas, it's not. there's host OSs out there (I hear the not-so-rarely-used one from Redmond is amongst those) whose ND behavior becomes erratic once MLD is suppressed.
sure, we can take a stance of "well, they're to blame for not reading the specs with sufficient scrutiny or they have a reputation of deviating from specs anyway or whatever". my point is that using wording like "is done" in the relevant section of RFC 4861 hasn't exactly helped their (implementors') job. I agree with Ole though that we won't see a change in/update to 4861 anytime soon.

, and logically it's the same for any protocol that uses
> Worse, bridges that aren't bridges *and* have defective MLD snooping by default

fortunately, to the best of my knowledge, as of today there's none which actually have MLD snooping on by default. 

> I'm not sure what the IETF can do about this except scream and shout.

(maybe just sometimes) re-connect to the real-world of operational reality out there? I'm aware that's a harsh and potentially unjust statement. Though I wish the comments made on the mic in sunset4 on Tuesday could serve as a wake-up call somehow...

best

Enno

-- 
Enno Rey