Hi
Interesting draft. I need to think more about it, but I have a
comment below.
On 3/29/2013 2:52 AM, Mark Smith wrote:
Hi Carsten,
Thanks very much for your review and comments.
----- Original Message -----
From: Carsten Bormann <[email protected]>
To: Mark Smith <[email protected]>
Cc: "[email protected]" <[email protected]>
Sent: Friday, 29 March 2013 7:21 PM
Subject: Re: "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast"
Hi Mark,
interesting draft. I'm interested in this from a 6LoWPAN perspective --
everything we can do to get rid of multicasts is very good for 6LoWPANs.
I don't understand how you think NUD would work with this (3.2) -- are you
saying that the multicast emitter actively runs NUD to the targets?
Yes. NUD is performed on the link-local addresses used as the source addresses
for the MLDv2 messages.
Originally when I was thinking about this, I thought that might be one of the things that
would need to be changed. However, when I reviewed the part of RFC3810 (MLDv2) related to
MLD Report source addresses, I came across the following in 5.2.13, "Source
Addresses for Reports":
On the other hand, routers MUST silently discard a message that is
not sent with a valid link-local address, without taking any action
on the contents of the packet. Thus, a Report is discarded if the
router cannot identify the source address of the packet as belonging
to a link connected to the interface on which the packet was
received. A Report sent with the unspecified address is also
discarded by the router. This enhances security, as unidentified
reporting nodes cannot influence the state of the MLDv2 router(s).
It seems to me that the only way to be sure a MLDv2 source link-local address
is valid and belongs to the link is to test it's existence, which is of course
what neighbor discovery does using an NS/NA transaction. So the existing ND
neighor presence discovery mechanism can, and I think the above implies should
be used to determine MLDv2 link-local source address validity, and therefore
the ND NUD mechanism can then be used to determine when the neighbor
disappears, and therefore link-layer unicasting of mulicast IPv6 should stop
for that now absent listener.
(Out of interest, I checked to see if this sort of link-local address validity
checking is being performed by Linux and one of the BSDs (I can't remember
which one). Neither of them did, all they checked was that the source address
of the MLDv2 report was a link-local address. So they're vulnerable to MLDv2
reports with spoofed, non-existent link-local addresses ...)
I'm not at all surprised it's not checked. But note that even if such
a check is in place, there is a certain risk of spoofing. It's not that
hard to guess some valid link-local addresses. E.g. if SLAAC, just look
at the global addresses used. I'm wondering a bit if we should have, or
maybe still should, use hop limit 255 for MLDv2.
Stig
MLDv2 is a protocol that runs between multicast listeners and multicast routers.
How do you handle multicast emitters that aren't multicast routers?
The main use case scenario I've been thinking about is multicast IPTV over a
carrier network, towards a residential customer, where the last hop in the
customer's home is 802.11, and where the multicast performance problems appear.
So the multicast source servers would be wired, and on segments where the
volumes of multicast traffic didn't impact link performance.
My main overriding goals were to avoid changes to the end-hosts, leaving
changes to be made to the multicast router's behaviour (e.g. residential CPE),
and to reduce the number of multicasts as much as possible, but not eliminate
them. Low levels of multicast on 802.11 works ok, it's the high levels that
cause problems.
If a host implementation can be changed, then it could implement the procedures
I've described. It could listen to the MLDv2 reports (as non-Querier multicast
routers do), do neighbor discovery/NUD on the MLDv2 source link-local
addresses, and then proceed to link-layer unicast the multicast IPv6 traffic to
its on-link neighbors.
How do you wean MLDv2 itself off multicast? (Now that would be my holy grail.
We didn't get around to do this in RFC 6775 -- we didn't think we'd
have to, since we were addressing a subnet where subnet-multicast doesn't
work at all.) Maybe efficient-ND could do something here.
I've put a little bit of thought into this. If you're able to change the host and the
router implementations, then I've thought might be able to eliminate multicasts by
treating the broadcast/multicast link as a Non-Broadcast Multi-Access link, and then use
RFC2491, "IPv6 over Non-Broadcast Multiple Access (NBMA) networks" methods.
Briefly looking at it, it does mention how to handle the SMDS link layer, and my
understanding is that was a connectionless (rather than a connection oriented) NBMA
link-layer, so treating 802.11 or 802.3 as an NMBA link could probably use the NBMA IPv6
techniques used for SMDS.
Regards,
Mark.
Grüße, Carsten
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
