Subject: Adrian Farrel's Discuss on draft-ietf-6man-dad-proxy-05: (with DISCUSS)

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 11 Oct 2012 12:15:13 -0700

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?)