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

["Eric Levy- Abegnoli (elevyabe)" <[e-mail]>]

DHCP won't work without changes which would be a lot bigger that anything
envisioned for ND address registration.

DHCP does not maintain link-locals. That would be a major change to fix
that, including on hosts, since address requests are responded in unicast.
DHCP does not maintain <IP, MAC> binding. It does not have the MAC (not to
confuse with DUID).
DHCP is not on the forwarding path where we need the information quickly
Eric

On 20/02/14 15:43, "Ole Troan" <[e-mail]> 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.)
>> 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.
>
>cheers,
>Ole
>
></nochair>