Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast

[Mark ZZZ Smith <[e-mail]>]

----- Original Message -----
> From: Ole Troan <[e-mail]>
> To: Eric Levy- Abegnoli (elevyabe) <[e-mail]>
> Cc: Erik Nordmark <[e-mail]>; Andrew Yourtchenko <[e-mail]>; 6man WG <[e-mail]>
> Sent: Saturday, 22 February 2014 11:02 PM
> Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast
> 
> Eric,
> 
>>>  do we need to care about link-locals? are they part of the problem we
>>>  need to solve?
>> 
>>  Yes we do. They are about half the problem, an't they? More if most
>>  traffic is local to the link. Less otherwise.
> 
> I think that's an important point for the problem definition.
> I do agree with you that if we need to register link-local addresses too, and 
> change the model of link-local addresses always being on-link, then we might 
> look for other solutions. that's not what efficient ND seems to do though. 
> as far as I can see the ND efficient draft suggests ND for link-local traffic is 
> done like today.
> 
> I did a couple of packet captures on my relatively fruity home network. I did 
> not see a single data packet using link-local addresses. I saw ND and I saw lots 
> of mDNS (someone needs to solve that problem too).
> I don't claim my home network is representative, but I'd really like to 
> see more data here.
> I presume we're not going to justify this work based on the 10000 node 
> dentist's office (1)?
> 
> any application depending on link-locals would also break in the routed home 
> case.
> 
> and if we really wanted to solve it, what's the solution space?
> - redefine link-locals to have an L-flag?
> - physically or virtually restricting the link-local subnet size?
> - disable link-locals?
> 

So I've been thinking about this problem off-and-on for a few months (specifically this, and more generally using hub-and-spoke link-layer forwarding in a multiaccess subnet, as I think it is a more general solution to the various RA/DHCPv6 spoofing etc problems, and also is more energy efficient), and I've started writing up a draft which suggests the following solution:

- Allow RA PIOs to announce the link-local prefix, to switch the on-link assumption for the link-local prefix off (the A bit in the PIO would be ignored for the LL prefix)

- Routers perform a limited form of ND proxying to facilitate hosts that don't support this LL RA PIO. ND proxying only occurs for Link-Local addresses.

The only issue I think that is left open after this link-local issue is host originated multicasts. The link-layer forwarding model would force them to only be received by the router(s) at the hub(s). The question is how do the multicasts reach the other hosts on the link?

Simplistically, the router could just flood the multicasts back to all hosts on the link (continuing to use the link-layer's broadcast/multicast capability retained for the devices at the hub(s)). I don't know if that is legal, but assuming it is, would the multicast origin host ignore its own multicasts? It could tell they were its own because the source address would be one of its own. I've had a bit of a look into the RFCs to see if this router and host multicast behaviour is defined, but haven't been able to find it. 

Alternatively, the router could selectively forward the multicasts back to all hosts on the link except the one it received it from. This could be achieved using link-layer unicasts and "MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast IPv6" (http://tools.ietf.org/html/draft-smith-mldv2-link-unicast-00).

Regards,
Mark.