Hi Joel. > All of the proposed resolutions look very good. Thank you.
Great! > With regard to routers and ARP caches, my concern is that from what I > saw of the years, common practice did not seem to match the SHOULD from > the RFCs. I am a little remote from most implementations at the moment > (the ones I can check easily are a tiny fraction of the market), so I > was suggesting that be double-checked. I hear you, and I suspect that there is a wide variability in what routers implement. And the easy implementation (especially for the fast path) is not to queue anything at all, which would still be compliant since queuing is only a SHOULD... I've tweaked the text a bit more after looking at the actual requirements (e.g., the spec doesn't say you have to send an ICMP unreachable on an ARP miss, it only says that if you do, you shouldn't do it just because there is no ARP entry). In any case, the point of this paragraph is really just to explain the steps, to show they can be "cpu intensive". I think the WG asserted pretty strongly that for some implementations/deployments, the implementation cost is a problem (i.e., CPU intensive to the point of being problematical). Finally, another area concerns the overhead of processing IP packets for which no ARP entry exists. Existing standards specify that one (or more) IP packets for which no ARP entry exists should be queued pending succesful completion of the address resolution process [RFC1122] [RFC1812]. Once an ARP query has been resolved, any queued packets can be forwarded on. Again, the processing of such packets is handled in the "slow path", effectively limiting the rate at which a router can process ARP "cache misses" and is viewed as a problem in some deployments today. Additionally, if no response is received, the router may send the ARP/ND query multiple times. If no response is received after a number of ARP/ND requests, the router needs to drop any queued data packets, and may send an ICMP destination unreachable message as well [RFC0792]. This entire process can be CPU intensive. Is that any better? Thomas _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
