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

[Erik Nordmark <[e-mail]>]

On 2/26/14 9:52 PM, Mark ZZZ Smith wrote:
> The router would perform standard IPv6 forwarding, including TTL 
> decrement. Although Link-Locals currently won't use their default 
> gateway to reach other Link-Local destinations, if that was changed, I 
> think it is quite legal for a router to forward a link-local packet 
> back onto the same link (with a TTL decrement) - RFC4291 only 
> precludes them being forwarded onto a different link. 
That is correct - link locals can be forwarded out the same link.
I don't know if that is always a good idea for multicast packets - but 
if the router received the L3 multicast packet as a L2 unicast then it 
would make lots of sense to forward it back out on the link.
>> However, ttl decrements break the protocols that use the ttl=255 check
>> (and ND isn't the only protocol which does this.)
>>   
> That is a good point, one I hadn't considered. I'd be interested to know which non-ND protocols use the TTL=255 trick if you know them off of the top of your head. We might be lucky, the other ones which do use the TTL=255 trick might be ones that for security purposes we wouldn't want the default router to forward between hosts attached to the same link anyway.
I haven't tried to compile a list.
I know that routing protocols and VRRP does this (which is a reason why 
a "send link-locals to default router" should not be applied to the 
routers themselves.)

It doesn't look like mDNS uses it according to the RFC. It would be good 
to check this though.

>
> The use of the TTL=255 trick for ND would actually be useful for naturally preventing rogue RAs from the hosts - if the default router forwarded them to other hosts on the link, decrementing the TTL to 254, the receiving hosts should then ignore them.
Yes, for RAs it would help.
But if the hosts still send multicast NSs (e.g., for link-local 
targets), then the ttl decrement ensures that they will never get a 
response.

    Erik