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

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

Hi Erik,


----- Original Message -----
> From: Erik Nordmark <[e-mail]>
> To: Mark ZZZ Smith <[e-mail]>; Ole Troan <[e-mail]>
> Cc: Andrew Yourtchenko <[e-mail]>; 6man WG <[e-mail]>
> Sent: Tuesday, 25 February 2014 10:10 PM
> Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast
> 
> On 2/25/14 1:12 AM, Mark ZZZ Smith wrote:
>> 
>>  I don't see how we can do this without host changes even for the case 
> of
>>  IA_NA and IA_TA DHCP assigned addresses; the hosts would need to remove
>>  the code which does the DAD check for DHCP. (And there would be
>>  additional DHCP protocol changes needed to support CGA and
>>  stable-privacy-addresses and any future address assignment scheme.)
>>  I think a DAD Proxy is what you're looking for -
>> 
>>  RFC6957 - "Duplicate Address Detection Proxy."
> Mark,
> 
> RFC 6957 is useful for some types of deployment.
> 
> But it don't see how it relates to my observation (in response to Ole) 
> that DHCPv6 doesn't help with different forms of address assignment and 
> DAD. Even with DAD proxy, or some other form of DAD enhancement, we'd 
> still do address assignment (SLAAC, DHCPv6, stable-private, etc) 
> separately from DAD.

I agree. The DAD proxy is how the DAD issue is dealt with in broadband N:1 / hub-and-spoke etc. link-layer forwarding models when hosts/CPE are layer 2 isolated from each other, and can only send traffic to other on-link destinations via the default router (performing the DAD proxy function)

>> 
>>  More broadly though, I think a method that supports any forms of multicast 
> from a host to the other hosts on the link, hair-pinned through the upstream 
> router(s), would be better. It would support DAD operation, and would also 
> support other multicasts from hosts, such as Multicast DNS for device (printer) 
> discovery, and SSDP for DLNA server discovery.
> You mean instead of hair-pinning at L2 (through the AP) do the 
> hair-pinning at L3 (through the router)?
> 
> Would the router decrement ttl as it forwards those packets?
> (If not, then I think you are talking about hair-pinning at L2 but 
> placing it in the router.)

Yes. 

> Note that L2 hair-pinning typically (always?) does split horizon, hence 
> you'd need to it in the devices along the path from the sender to the 
> router (e.g., the AP) if you want to ensure that all receivers can get a 
> copy of the packet.

Yes, layer 2 split horizon is preserved. It is the default router that forwards traffic to all destinations, even those that fall within the prefixes from which the origin host has its addresses.

> Hair-pinning can potentially be avoided for L3 - if the router 
> decrements ttl then it would be safer to send the multicast packet out 
> the input port.
> 

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. 

> 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. 

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.

Regards,
Mark.


> Regards,
> 
>     Erik
> 
>>  I've been thinking about this scenario for quite a while, and it seems 
> to me that there are fundamentally two approaches to this problem.
>> 
>>  The first one involves minimal or no changes to the hosts (e.g., an 
> optional RA PIO for link-local flagged as off-link and that is it, as a host 
> local optimisation instead of ND proxy for link-local addresses), and emulate 
> functions at the upstream router(s) that won't work because of host to host 
> isolation within the link.
>> 
>>  The other one involves wholesale changes to the hosts, and I think that 
> would mean fully implementing an IPv6 NBMA subnet, perhaps with an RA option to 
> announce to the hosts that the link is operating in NBMA mode, and the 
> address(es) of the MARS cluster.
>> 
>>  The NBMA method would be convenient, as all these sorts of 
> multicast/link-local etc. issues are already dealt with. However, I think 
> wholesale changes to hosts to support it are probably infeasible.
>> 
>> 
>>  Regards,
>>  Mark.
>> 
>> 
>> 
>> 
>>>       Erik
>>> 
>>> 
>>>  --------------------------------------------------------------------
>>>  IETF IPv6 working group mailing list
>>>  [e-mail]
>>>  Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>  --------------------------------------------------------------------
>>> 
>