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

> On Feb 26, 2014, at 6:31 AM, Ole Troan <otroan@employees.org> wrote:
> 
> Erik,
> 
>>> So a potential approach would be to have the host form its address using the SLAAC method it prefers (such as stable-privacy) and then go through the DHCP (discovery plus request/response having the IA_NA/TA with the formed address). I don't know if we can use the 2 packet DHCP exchange for this or need the 4 packet one.  The host would get lifetimes back from the DHCP server so it would know when it needs to renew.
>>> 
>>> you could only use 2 message exchange if there was a single DHCP server on the link.
>> I guess the host would need to do the discover once, but then can do each address registration with just 2 messages.
> 
> after discovery the other protocol exchanges are 2 message.
> that should be the same as efficient ND. first you discover the routers, then you exchange messages with chosen routers. 
> 
>>>> If all the hosts on the link were to do this, and the DHCP service is 100% reliable, then this would ensure no duplicates.
>>>> But it has issues with incremental deployment where some hosts do this but not the legacy hosts, since the legacy hosts would do current DAD probes and not find out about the addresses registered with the DHCP server. If the DHCP server is on-link it could proxy respond (and also implicitly learn about registrations from those DAD probes - with the limitations for implicit registrations which I'm trying to write down), but what about the case of DHCP relay(s) on the link and an off-link DHCP server?
>>> DHCP always has an on-link presence, be it the relay or the server. in theory (which is very far from practice), relays are stateless. for this discussion I suggest we assume DHCP must be deployed so that there is a DHCP server on-link and on every router.
>> You can't have it on every router unless there is a server-server protocol to coordinate the address assignments/registrations between the routers that are on the same link. There is no IETF standard for this (it was discussed and abandoned in the DHC WG a long time back).
> 
> there is work apparently on failover:
> RFC7031
> draft-ietf-dhc-dhcpv6-failover-design
> 
> by moving the state into the network, maintaining that state on all first-hop router is going to be a challenge. that is the same problem, if you use DHCP or if you use ND.

Or, the ND messages could be relayed to the DHCP server...

The relay could even snoop the assigned addresses (which is already done now [?] for other purposes.

> 
>>> with regards to your legacy point, with DHCP we can "declare" that there is no legacy. if you want to connect to networks like these, then DHCP is the only option for address assignment. just like there are networks deployed like that today.
>> I fear you are equating DHCPv6 as implemented by hosts today, and the extensions on the hosts necessary to use DHCP for address registrations. If you say that you will only support hosts that implement DHCP address registrations (for all addresses SLAAC - 4941, stable-privacy, microsoft privacy addresses, etc) then you will support no hosts at all on those links.
>> 
>> That sounds like a non starter to me.
> 
> you are quick to jump to conclusions. ;-)
> I think we need to separate what _can_ be done within the protocol and how the protocol is deployed today.
> 
> in DHCP as deployed today, you get address assignment. what addresses are assigned to hosts is defined in the address assignment policy on the DHCP server. just like on any other network that uses DHCP for address assignment
> 
> is it really a requirement that hosts must generate addresses? if so why? what problem does that solve in this context?

So, legacy hosts can be assigned addresses w/o hints while registering hosts send in the hint to indicate address registration.

> 
>>>> In that case it seems like the DHCP relays need to relay all DAD packets to the DHCP server, so that it can respond (duplicate or ok), and build it state.
>>> any scheme we can find that has no or few legacy implications would be good.
>>> in the above scheme with the deployment restrictions outlined, DAD messages could be silently dropped at the AP/router.
>>> 
>>> 
>>>> And should the DHCP service loose some or all of its state (e.g., a cold standby is started after a hardware failure) then it doesn't have a way to rebuild its state from the network until the lifetimes cause the new hosts to renew. And for legacy hosts the DHCP server/relay would need to glean on data packets to reliably find out about addresses that are in use since the legacy host do not "renew" with an additional DAD probe in a predictable time.
>>> I agree that DHCP performs poorly with regards to "server initiated" messages.
>>> after a state-loss event you could do one of (again assuming no host changes):
>>> - DHCP bulk lease query
>> Who would respond to that? There is no relay in your picture as I understand it.
>>> - fall back to normal ND behaviour
>> When the DHCP server or router crashes it typically starts clean, hence it doesn't know whether it lost state, or is a newly installed/configured node. Thus it wouldn't be "fall back" AFAICT, but actually a requirement to always start in normal ND behavior and then somehow move towards DHCP address registrations.
>> 
>> You probably want to walk through all the details and write down the proposal - more efficient than me trying to guess and second guess how you think it might work and poke holes at my own guesses.
> 
> right, maintaining this state is the crux of the problem. which is also the main reason why I'm skeptical about efficient ND.

...and DHCP already has tackled the problem of restoring state through leasequery.

> 
>>> - low timers
>>> - learn DHCP database from neighbouring routers
>>> 
>>> 
>>>> Thus it seems like in order to solve DAD using DHCPv6 we need to
>>>> 1. solve how do reliably do implicit registrations from DAD (and data packets?) for legacy hosts in DHCP relay/server
>>>> 2. new interaction between DHCP relay and server to handle legacy hosts in normal operation
>>>> 3. ditto in the case of DHCP server state loss
>>> I don't think we should go there, and if that's where we want to go, then I'm much more open at looking at new approaches.
>> I don't see how you can support legacy hosts without that. We can't assume that legacy hosts do DHCP address registrations for RFC 4941 temporary addresses when the A flag is set. Clearing the A flag means that some legacy hosts will not work on those links.

Hosts with no DHCP implementation at all?

> 
> as above. legacy hosts get address assignment, hosts that care about self generating interface identifiers will get address registration (if allowed by network policy).

I agree...

> 
>>>> Note that this doesn't remove the need to multicast Neighbor Solutions for address resolutions, since the DHCP server or relay is not required to be implemented in the router (it might be in some deployments and products). Even when it implemented in the router, there would need to be a mechanism to share the state of IP->MAC address between the routers on the link.
>>>> Thus to solve that we need
>>>> 4. DHCP server track MAC address to get IP->MAC binding
>>> yes. so I have never heard about a case where a DHCP relay wasn't on the forwarding path.
>>> relays or servers must in any case be on-link. I suggested above that we simplify the scenario (and discussion) by assuming the DHCP server was on-link and running on a router.
>>> 
>>> with regards to the IP -> MAC binding.
>>> - DHCP server gleans that information from ND/DHCP packets (e.g. RS) (ugly score of 3)
>>> - Hosts implement RFC6939 (ugly score of 2)
>>> - DHCP server uses normal address resolution to learn the L3/L2 mapping
>> The last choice implies a multicast NS from the DHCP server, right?
>> 
>> The idea was to avoid modifying hosts (by reusing DHCP) and reduce multicast - that seems to be hard.
> 
> yes, but it would only be on initial connect.
> I think Andrew would argue that you can achieve the same optimisation by increasing the reachable timers.
> full circle. ;-)
> 
>>>> 5. Sharing of DHCP server state with all the routers on the link
>>> yes, that's the trickiest part of this scheme.
>>> this is a challenge whatever solution you choose here. even with ND register, where the proposal is for hosts to register with all on-link routers, you may get into a state where the databases aren't in sync. and also it forces hosts to quickly detect the appearance of a new router on the link.
>> efficient-nd (that you like to call nd register) is robust against database inconsistencies - eventual consistency. 
>> 
>> If a new router appears and there are no use of multicast NS then the router needs to get the NCE database in any approach. 
>> That could be using a yet-to-be-invented-and-standardized db sync protocol, vendor proprietary protocol, using unicast NS/NA between the routers, or involving the hosts as in ARO.
>> 
>> In all of those cases the new router might be asked to forward packets before it has a complete db. Might result in packets being dropped on the floor, or fallback to multicast NS to the hosts.
> 
> yes, it is the yet-to-be-invented that scares me.

There may be something to learn about the sync protocol from work on DHCP sync.  We thought it was pretty straightforward until we got to the problem of simultaneous updates between different host/server pairs.

> 
>>> a fallback to normal ND is the only approach I can see off hand. for any solution we propose here.
>> I want to verify that I understand the context. Are you saying that any time there are two or more routers on the link we can not use the new scheme and can only use 4861? That doesn't make sense - we must aim higher.
> 
> write it down.
> might be my Scandinavian pessimism (which I assume you share), I'm not too hopeful on simple solutions here.
> if you can assume the routers are wired, then you could run a routing protocol to advertise the bindings between themselves. sounds like we have a bar bof, napkin, pen and beer required for this part of the discussion. ;-)

Where and when?

> 
>>>> With the above we still haven't addressed the unsolicited multicast RAs, thus we'd also need
>>>> 6. Method to avoid multicast RAs - host driven unicast RS to refresh?
>>> yes, that's independent of this I think. but as I think Andrew outlines in his document you can get reasonably far with that without host changes.
>>> 
>>> 
>>>> Note that if we solve 1, 5', and 6 we have a complete solution i.e.
>>>> 1. solve how do reliably do implicit registrations from DAD (and data packets) in routers
>>>> 5': sharing of that registration state (explicitly or implicitly) between the routers on the link
>>>> 6. Method to avoid multicast RAs - host driven unicast RS to refresh?
>>>> 
>>>> 
>>>> Thus I don't see how "reusing DHCP" makes for less work - it seems to create a lot more  work by changing not only hosts and routers but also DHCP servers and DHCP relays plus defining additional need for state sharing which doesn't exist today.
>>> if we need to put the state in the network, then I don't see that the maintaining network state for the L3/L2 mapping is different regardless of how you wrap the data.
>> Sorry, I don't understand your comment nor how it relates to the part of my text that you quoted.
>> Please explain.
> 
> same as above. maintaining synchronized state across all first-hop routes for sleepy nodes, needs some thought.
> regardless of the wrapping (ND or DHCP) of the bits on the wire between host and router.

Yup.

> 
> 
>>>> [And as I've indicated, I think that #1 is actually hard even if there are products that do that with constrained applicability today. More about that later since it doesn't affect the difference between "reuse DHCP" and other parts of the solution space AFAICT.]
>>> I think DHCP is largely a deployment choice. and that unless we agree on the assumptions, e.g. no legacy (which means we don't need 1) then I agree with you. DHCP as a solution only makes sense within certain constraints.
>>> 
>>> again I don't see how 6 isn't orthogonal to this. ah, sorry double negative. ;-)
>>> 
>>> 4 and 5 are the biggest issues with a DHCP based solution.
>>> no host changes, but definitely router/DHCP changes, and possibly AP changes.
>> Explain how a host which uses RFC 4941 address does not need changes.
> 
> it uses IA_TA. no change.
> 
>>> DAD was invented largely to detect manual misconfiguration.
>> No, it was actually a lot more about EUI-64 derived IIDs and the fact that some vendors had issued NICs which all had the same MAC addresses. Those rare situations were a pain to track down. Hence at or around the time of the 1st Stockholm IETF we came up with this single NUD probe.
>> 
>> Since then we have temporary addresses, CGA, stable-privacy etc  which depend on DAD being able to detect duplicates.
>> But manual misconfig never entered in the picture AFAIR.
> 
> OK, that I got from Steve, and is probably the assignment type with the biggest probability of collision.
> 
>>> as long as the network is assigning the address instead of the host, DAD isn't required.
>>> the assigning entity could do the duplicate detection itself, and that it can do from its own valid source address.
>> Yes, but that doesn't work with the security and privacy model for stable-privacy and CGA and their likes. Hence a non-starter AFAICT.
> 
> privacy addresses are supported in DHCP.
> I don't understand the requirement for supporting CGA, I think there have been proposals for CGA and DHCP.
> we need to go back and understand the requirements. with the DHCP hint mechanism the hosts can in any case suggest a CGA address to use. for both efficient ND and DHCP the "network" is in control if which addresses the hosts are allowed to use.
> 
> 
>>> depending on network entities detecting a DAD message and using that to inject state in the network is a poor choice I think. DAD is unreliable, default DAD attempts is zero.
>> Default DAD attempts is one - not zero.
> 
> yes, of course. "might as well have been zero". ;-)
> 
>> But it isn't reliable in the case of random packet loss, spanning tree reconvergence triggering packet loss, sleeping hosts, etc, etc.
>>> although it is sent as L2 unicast it will still have a typical failure rate of 1-5% on WIFI.
>>> 
>>> if we want network state for link-local addresses, and duplicate address detection, and also allow applications to use link-local addresses, then we need to 'figure' something out. I agree that without host changes that's tricky. while the network might detect and install state for the link-local address on e.g. RS/DHCP SOLICIT, the host might not be receptible to changing it after DAD has passed.
>>> 
>>> lots of good points here, do you collect them for a later draft?
>> Yes, I'm trying to capture the design tradeoffs.
>> Counting on you all to keep me honest ;-)
> 
> cheers,
> Ole

- Ralph

> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------