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

[Erik Nordmark <[e-mail]>]

On 2/22/14 4:08 PM, Mark ZZZ Smith wrote:
>
>
>
> ----- 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:
Mark,

I understand the potential benefits of doing this for multicast.
Are you also looking at requiring it for unicast?
(Direct host-host unicast would seem more efficient - but in some use 
cases with filtering requirements it would make sense to send those via 
the router as well.)
>
> - 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.
*If* we need to solve this I think that is a reasonable design.

We do need to look at ttl=255 in a bit more detail - I assume you'd 
decrement ttl when the routers forward link-locals back out on the link.
>
> 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.
DAD as currently defined would break, since DAD can't cope with hearing 
its own packets.
But if we do that differently (enhanced-dad draft with nonce, or address 
registration) that wouldn't be an issue for hosts that implement that 
new approach. Still need to handle legacy hosts doing current DAD though 
... need to think about that one.

Once DAD is taken care of and we assume unique link-layer addresses, 
then having the host ignore multicast packets with its own IP source 
address will ensure that other protocols/applications don't see any change.

>
> 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).
That would be hard to implement in existing hardware. The hardware which 
performs multicast replication assumes the same packet is being 
replicated (with some handling of ttl decrement vs. not in order to 
handle the bridge-route-bridge paradigm for devices that are both 
routers and bridges i.e. where some ports see a L2 forwarded multicast 
packet and other ports get the same packet after a ttl decrement by the 
L3 forwarding function.)

Regards,
    Erik