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

[Ray Hunter <[e-mail]>]

Erik Nordmark wrote:
> 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.

How would you do DAD for link-local addresses if the link is NBMA, and 
there's no multicast?

Don't you get into a chicken/egg problem with DHCPv6? [Section 16 of 
RFC3315 has a MUST for using a valid source address, either link-local 
-> multicast or an assigned address -> unicast]

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

Why not? DHCPv6 has retransmission (controlled by the client)
Why would ND registration be any different from the perspective of 
packet loss?

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

I think that's a very good question.


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

DHCPv6 [3315] itself says very little about temporary addresses. I don't 
see why DHCPv6 couldn't be made to support 
draft-ietf-6man-stable-privacy-addresses etc., although it may undermine 
their raison d'etre if there isn't a trust relationship with the DHCPv6 
server. But then again you probably wouldn't trust DHCPv6 at all in that 
case.

>
> 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.
>
Why would new messages be required?

After discovering a unicast DHCPv6 server, wouldn't it be possible for a 
client to send a DHCPv6 request message containing an IA Address option 
in an IA-TA option?
Where the IA Address option contains the temporary IPv6 address 
requested to be registered? If I read RFC3315 18.2.1 that's standard 
behaviour isn't it?

> 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.)
>
Correct. There may be multiple DHCPv6 servers configured via relays, so 
you can also get into race conditions.

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

-- 
Regards,
RayH