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

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

A 


----- Original Message -----
> From: Erik Nordmark <[e-mail]>
> To: Ole Troan <[e-mail]>; Erik Nordmark <[e-mail]>
> Cc: Andrew Yourtchenko <[e-mail]>; 6man WG <[e-mail]>
> Sent: Tuesday, 25 February 2014 10:02 AM
> Subject: Re: Comments on draft-yourtchenko-colitti-nd-reduce-multicast
> 
> On 2/20/14 6:43 AM, Ole Troan wrote:
>>  <nochair>
>> 
>>>  4.8 seems to conflate the address assignment with DAD. Just because we 
> might want to centralize the DAD checks doesn't imply that we want to remove 
> the ability for the host to pick its own privacy enhanced interface-IDs to form 
> its addresses.
>>>   From a deployment perspective DHCPv6 is available for address 
> assignment, but don't think we want to require that for WiFi or other links 
> which have packet loss. (Packet loss occurs on wired networks as well, but the 
> drop distribution is different - might happen during spanning tree reconvergence 
> etc.)

<snip>

> 
> Currently RFC 3315 separates address assignment and DAD - the client 
> SHOULD perform DAD on an address that is assigned by the DHCP server. 
> This separation goes back to DHCPv4 where there was a similar check (I 
> think using ICMP echo) which I believe is there for the reason that the 
> DHCP servers list of assigned addresses could get out of sync with the 
> hosts. (If DAD fails the host declines the address hence will get a 
> different one.)
> 
> 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."


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. 

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