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

[Ole Troan <[e-mail]>]

Erik,

>> 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.
> 
> Thanks for finding that text.
> 
> 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.

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

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.

> 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
 - fall back to normal ND behaviour
 - 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.

> 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

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

a fallback to normal ND is the only approach I can see off hand. for any solution we propose here.

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

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

>>> 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
> Yes, we can think about those separate.
> I'd call #1 something like "More robust/reliable DAD" in the presense of packet loss, sleeping hosts, etc.
>> 
>> 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).
> Presumably the AP would do that for a large set of packets - e.g., all solicited-node MC addresses.
>> 
>> 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.
> Unless the host that has the address is in deep sleep at that point in time.
> 
>> 
>> 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.
> If the network lost the state about the address, how can it remember to which MAC address it can unicast it?
> I think it needs to multicast the frame. And the host needs to be in shallow sleep so the multicast will wake it up.
> 
> (Philosophically having completely separate behavior and code to deal with infrequent events like this is a bad idea; that behavior/code will not be exercised hence it is very likely to have bugs.)

agree.

>> 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.
> I don't see the details of how this would work. Hence I can't declare it to be solved.
>> 
>> 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.
> DAD attempts = 0 might make sense for EUI-64 derived addresses. But since we are moving away from those I'm not sure that is a good idea.

DAD was invented largely to detect manual misconfiguration.
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.

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. 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?
 
cheers,
Ole