On Aug 7, 2011, at 10:57 , Joel Jaeggli wrote: > > 2. Is there critique of the two proposed 4861 changes? > > A. 7.3 NDP Protocol Gratuitous NA > B. 7.4 ND cache priming and refresh
In the 6MAN session at IETF 81, I got up at the microphone and muttered some dark things about network sleep proxies. I should expand on those comments here on the list. p1. Section 7.3 in the current draft deploys normative language thusly: >> [...] If the link layer address in >> an unsolicited neighbor advertisement matches that of the existing ND >> cache entry, routers SHOULD retain the existing entry updating it's >> status with regards to LRU retention policy. [...] When a network sleep proxy accepts a new host registration, it will send a neighbor advertisement with a new and different source link-layer address, so routers that do this shouldn't have any trouble in the presence of network sleep proxies. The next paragraph is marginally more interesting for its network sleep proxy considerations: >> Hosts MAY be configured to send unsolicited Neighbor advertisement at >> a rate set at the discretion of the operators. The rate SHOULD be >> appropriate to the sizing of ND cache parameters and the host count >> on the subnet. An unsolicited NA rate parameter MUST NOT be enabled >> by default. The unsolicted rate interval as interpreted by hosts >> must jitter the value for the interval between transmissions. Hosts >> receiving a neighbor solicitation requests from a router following >> each of three subsequent gratuitous NA intervals MUST revert to RFC >> 4861 behavior. Network sleep proxies are a subtype of hosts. One imagines that a network sleep proxy might be configured to send unsolicited Neighbor Advertisements messages on behalf of sleeping hosts, which may or may not be configured differently than their proxy. Moreover, network sleep proxies may themselves go to sleep, and transfer their registrations to another proxy. Different proxies may or may not be configured the same way. All this makes me wonder just how a host SHOULD be configured with its unsolicited neighbor advertisement rate. Do we imagine defining a Router Advertisement option? That's my preferred solution, because it would be useful even in the case where both M=0 and O=0. It is, after all, a network configuration parameter and not really a host configuration parameter. If we choose a Router Advertisement option, then we have to think about how to merge the advertisements from multiple default routers. p2. Section 7.4 in the current draft has this to say: >> A solution to this would be that any new host that joins the network >> would "announce" itself, and be added to the cache, therefore not >> requiring packets destined to it to go through the unknown NDP queue. >> This could be done by sending a ping packet to the all-routers >> multicast address, which would then trigger the router's own neighbor >> resolution process, which should be in a different queue then other >> packets. These echo requests will also be sent by network sleep proxies when they accept new registrations from existing hosts (including other sleep proxies) when they enter a sleeping mode. It's probably worth noting that it isn't a good idea for a sleep proxy to send the echo requests *before* sending the unsolicited neighbor advertisement with the new link-layer address. However, if the router under attack correctly processes the unsolicited neighbor advertisement, then the echo request should prime the neighbor cache in the router with the link-layer address of the sleep proxy. Routers serving networks comprising lots of sleeping hosts and one or more network sleep proxies will be receiving a lot of echo requests from a small number of link-layer addresses, i.e. the sleep proxies, as hosts enter and leave sleeping mode. It seems like there should be an opportunity to optimize on that. -- james woodyatt <[email protected]> member of technical staff, core os networking -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
