Hi Carsten, Thanks very much for your review and comments.
----- Original Message ----- > From: Carsten Bormann <c...@tzi.org> > To: Mark Smith <markzzzsm...@yahoo.com.au> > Cc: "6...@ietf.org" <6...@ietf.org> > 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 ...) > 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 ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
