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

[Erik Nordmark <[e-mail]>]

On 2/25/14 3:04 AM, Ray Hunter wrote:
>
>
> 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? '
You can't.
(I'm not the one advocating turning an Ethernet into an NBMA network.)

But we do have an open issue if we want to make link-local addresses 
efficient, since 4861 assumes that they are always on-link hence 
multicasting NSs etc.
>
> 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]
[I'm not the one saying that DHCPv6 would help her - in fact I think it 
is a distraction to conflate address assignment with DAD.]

DHCPv6 assumes that a link-local address can be formed and used (hence 
do DAD on the link-local) before the first DHCPv6 packet can be sent. 
Yet another reason why DHCPv6 doesn't help to reduce the impact of DAD.

>
>>>>  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?
I think there is some context missing.

DHCPv6 can not be used for CGA, stable-privacy, or any other addresses 
that a host can form. For that reason I don't think we should say that 
if you want better reliability you should use DHCPv6 (and loose the 
ability to use those forms of addresses.) [But see below.]

ARO is retransmitted as specified in efficient-nd-05.
> 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.
RFC 3315 has explicit support for 6574 - the address is formed on the 
dhcpv6 server.
That approach implies that any other address assignment scheme such a 
stable-privacy needs to be done on the server. Implies giving the key to 
the server etc. Removes their raison d'etre AFAICT.

One could of course define new DHCP options and behaviors to take a 
different approach to support stable-privacy, but that would be a fair 
bit of DHCP changes.

But you raise questions about RFC 3315 vs. DHCPv6 server behavior when 
addresses are included in the IA_TA option. I can't see anything about 
this in 3315. Makes sense to double-check.

>
>>
>> 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?
I don't see a sentence in 18.2.1 which says that the address in an IA is 
registered (after checked that it hasn't been assigned to anybody else).

The number of IAs (IA_NA and IA_TA) are used to determine how many 
address to assign to the host.

Section 12 says "Clients ask for temporary addresses and servers assign 
them." Nothing about checking whether they are already assigned to 
somebody else in that section. Ditto in section 22.5 - "The server will 
generate new temporary addresses and return them to the client."

(But I haven't checked DHCPv6 server implementations.)

    Erik