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

[Ole Troan <[e-mail]>]

Erik,

disclaimer:
let me first be clear about the context I'm discussing this in.
please don't interpret the fact that I have taken the position of 'defending' DHCP to mean that I'm proposing that as the solution. I just want to explore DHCP and understand the short-comings, and what unresolved problems there are. and I reserve the right to change my mind at any point. ;-)

<nochair>

>> <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.)
>>> Note that DHCPv6 (RFC 3315) has a SHOULD for doing DAD on the addresses received from the DHCP server - needed since the server could be confused.
>> I'd like to explore the difference between DHCP address assignment and ND address registration a little more.
>> the state that is required in the network for "efficient ND", why cannot that be created and maintained by DHCP?
>> 
>> there are multiple ways of dealing with DAD in this scenario, including solutions that don't require host changes.
>> DHCP also supports temporary addresses btw.
> DHCP supports RFC 4941 temporary addresses, but it doesn't support others like CGA and stable-privacy-addresses. With IA_TA the DHCP server creates the temporary address, and that approach doesn't work with other addresses that need to be client-generated for security or privacy reasons.
> 
> One could envision changing DHCP to have a separate "please register this address" message and/or option, which would check against duplicates (of assigned and registered addresses) and then add it to the registered addresses in the server. But that would seem like a fair bit of new functionality in DHCP.

RFC3315 says:
  The client MAY include addresses in the IAs as a hint to the server about addresses for
   which the client has a preference.

that's not too far off from the ND register semantics. in both cases the final say of which address the host can used is moved to the network.

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

are there two issues here?
1) DAD detecting a duplicate address
2) DAD wasting bandwidth and energy

on a WIFI link, DAD is sent L2 unicast to the AP. then the AP is expected to forward that packet as L2 multicast back onto the link. if we assume some smarts on the AP, then it doesn't have to send the packet back out on the wire, but only bridge it up to router(s) for example. (this isn't as far fetched as it seems, there are deployed products doing this already).

given all knowing state in the network, then collisions shouldn't happen. if the network suspected it had lost state, it could try to resolve the address on the link before assigning the address to the host.

leaving the host unchanged in this scheme only leaves us with the problem of the sleeping host waking up at ever beacon with a DTIM indication. since there wouldn't be a multicast message, it wouldn't have to stay awake actually waiting for a frame.

to conclude, if my understanding is correct (which it may very well not be, since I haven't really understood how 802.11 works before now), then DAD isn't a big issue. it can be solved (and is in deployed products) on the AP multicast handling.

we could of course also specify in a new IPv6 over foo document that DAD attempts = 0 on these links, or perhaps better add a signal in RAs.

cheers,
Ole