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

[Erik Nordmark <[e-mail]>]

On 2/22/14 4:02 AM, Ole Troan wrote:
> 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.
Ole,
It is at least a question we should ask in 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.
See section 18 "Open Issues".
(6lowpan-nd has a limited-applicability approach to handle link-local 
addresses which we can't use in general.)
>
> 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.
It wouldn't necessarily break - it all depends on the semantics that 
folks expect.
For instance, in 6lowpan a link-local which matches the radio topology 
makes a lot of sense - is useful for routing and other adjacency 
protocols (such as trickle distribution).

A (large) home could be intentionally set up so that the subnet in the 
north wing gives you the mDNS etc resources for the north wing.
But a more likely case is that the routing happens between different 
network topologies (Ethernet, IEEE 802.15.4, etc) where there is no 
particular user intent to have different resource discovery scopes tied 
to the different links.
> 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?
I don't think we can remove link-local from the whole link. For 
instance, the routers might use VRRP and VRRP uses IPv6 link-locals 
(with a ttl=255 check.) And in some topologies the routers might have 
OSPFv3 or other adjacencies over the link, and the routing protocols use 
IPv6 link-locals.

At best we could have the hosts not send packets using link-locals for 
applications.

Telling the host to send link-local packets to the routers wouldn't help 
with protocols with do the ttl=255 check, and I don't know if this 
applies to mDNS or other protocols which use link-locals.
However, it would seem to be useful to avoid the hosts trying to send 
such link-locals, since they would just use resources for no real use. 
Thus a "send link-locals to router" indication in an RA seems useful if 
we want to solve this. That enables some compatibility for hosts (which 
interpret that flag but do not change their application protocols) since 
the router could proxy mDNS etc (handwaving a bit).

    Erik