Adrian Farrel has entered the following ballot position for draft-ietf-6man-dad-proxy-05: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Sorry about the ping-pong! Brian and i have been discussing this further and have talked ourselves back into believing that I have a valid concern. So I have moved it back from my Comment and reworded it (with a little help from Brian). There are two scenarios that give rise to concern: 1. Node A with address a sends NS. The message is lost in the network. Because the message is not normally acknowledged, when Node B sends NS with the same address, the duplication is not noticed. Note that an obvious variation of this scenario is when the NS from Node B is lost. 2. Node A with address a sends NS. The message reaches the BNG and is added to the cache. At a later time, the cache becomes full and this entry is discarded according to some local policy. Now Node B sends NS with the same address. The duplicate is added to the cache, but the duplication is not noticed. Note that a variation on the second scenario occurs when the policy of a full cache is to ignore new NSes. This variant gives rise to scenario 1 with the message loss being in the BNG. So, it is not reasonable for this document to have to fix DAD. The problem of lost messages exists in DAD (although at a slightly less probable level because normally there is a chance for Node A to receive Node B's NS even if Node A's NS was lost). I think that the first scenario can be handled in this document simply by noting that the problem exists and is made slightly more of an exposure when a proxy is used because the loss of either of the NSes will lead to duplication being missed. I think that the second scenario is only a problem if the Binding Table is not large enough. So it is clear that "the Binding Table MUST be large enough for the deployment in which it is used." You certainly need to say this, and you should add some guidance. You also need to add that implementations MUST either state the fixed size of Binding Table that they support or make the size configurable. In the latter case, implementations MUST state the largest Binding Table size that they support. Additionally, implementations SHOULD allow an operator to enquire the current occupancy level of the Binding Table to determine if it is about to become full. If you do all that, you only need to note that implementations encountering a full Binding Table will likely handle it in a way similar to NS message loss. And all of that just leaves me with one last question which is: since NS is not refreshed in DAD, is there a risk that the cache will grow forever with undisciplined nodes disappearing or renumbering without bothering to tell the BNG? That would be bad. --- Shouldn't you describe some manageability considerations? What events should be logged? What access to the stored informaiton should be provided? (For example, should the operator be able to read the Binding Table?) -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
