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

[Erik Nordmark <[e-mail]>]

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

However, ttl decrements break the protocols that use the ttl=255 check 
(and ND isn't the only protocol which does this.)

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