AD review : draft-ietf-6man-dad-proxy

[Brian Haberman <[e-mail]>]

Hi all,
      I have completed my AD review of draft-ietf-6man-dad-proxy.  I 
have some comments/suggestions/questions that should be addressed prior 
to advancing it along the publication chain.

1. The primary basis for this document is that in a point-to-multipoint 
network with split-horizon forwarding, nodes cannot communicate directly 
with one another.  However, the Introduction does not give a crisp 
definition of split-horizon forwarding.  I suggest that there be a brief 
sub-section of the Introduction that describes the model and the 
difficulties that arise from it.

2. In conjunction with #1, I would suggest re-ordering the Introduction. 
  Conceptually, I think it makes more sense to open the intro with what 
is currently the second paragraph.  This makes a crisp statement of what 
is being defined in this document and why.  The new sub-section provides 
the motivation and working environment for this function.  I would 
suggest dropping the last sentence of the current 2nd paragraph of the 
Introduction ("However, if it is necessary...").

3. I am not sure if the third paragraph of the Introduction is needed. 
Can't an aggregation device delineate devices by including additional 
information (e.g., interface ID or draft-ietf-6man-lineid) in the 
identification process?

4. Section 2

* s/(IPv6) document [RFC4861]/(IPv6) [RFC4861]/

* s/Autoconfiguration document [RFC4862]/Autoconfiguration [RFC4862]/

* Expand the first occurrence of "DSL".

5. Section 3

* Even though the CPEs cannot communicate directly with one another, 
aren't they considered to be on the same link (i.e., share a single IPv6 
prefix)?  If that is the case, the first paragraph is misleading and 
should be re-worded.

6. Section 3.1

* s/set to solicited-node multicast/set to the solicited-node multicast/

* s/nodes on a same link/nodes on the same link/

* s/the NS messages are received/the NS messages to be received/

* s/by other nodes/by any node currently using the tentative address/

* s/from a CPE would be forwarded/from a CPE are forwarded/

* s/by AN only/by the AN only/

* s/That said,//

* s/DAD per [RFC4862]/DAD, as defined in RFC 4862,/

* s/without an additional helper/without additional help/

7. Section 3.2

* s/different IP links/different links/

* s/when AN/the AN/

* The second paragraph is a little confusing since it states that CPEs 
are on different links, but they really aren't.  It would be useful to 
have a crisp definition of "on-link" in order to set the expectations in 
this document.

8. Section 3.3

* s/its default router using/its default routers using/

* I would re-word the last paragraph as : "This mechanism requires 
modifications in all hosts in order to support the Address Registration 
option."

9. Section 3.4

* s/mobile nodes when these last ones/mobile nodes when they/

* This section should also point out that the use of the MIPv6 would 
require all hosts to add support for RFC 6275.

10. Section 4.1

* There are several places in this section that appear to try and 
specify how the proxy should be implemented.  I would suggest re-wording 
this section to omit saying how and focus on what needs to be 
maintained.  An example to look at is how the NDP RFC uses conceptual 
variables and the relationships between those variables.

11. Section 4.2 - s/address as source/address as the source/

12. Section 4.2.1 - s/with following/with the following/

13. Section 4.2.2

* As a meta comment, I think this draft would benefit from having a 
state diagram that allows the reader to visualize the comparisons 
between the Binding Table variables and the Neighbor Cache.

* In the handling of the case where the Neighbor Cache entry contains a 
different link-layer address (bullet #2), can you make some 
recommendation on how to handle the situation even though this is a case 
that violates a key assumption of this approach (all nodes do DAD)?  I 
would also suggest dropping the last sentence of the bullet.

* 3rd bullet - I am not sure how an implementation gets to the state 
described.  The Binding Table contains an entry for the target IPv6 
address but with a different link-layer address.  If that is the case, 
why would the Neighbor Cache not have an entry for that IPv6 address? 
Is there a difference in how the entries are maintained between the 
Binding Table and the Neighbor Cache?

14. Section 4.2.3.2

* Rather than specifying all the fields of the NA message, I would 
suggest simply referencing RFC 4861 and its rules for sending a 
solicited NA in response to a DAD-driven NS.

* The last paragraph states that all CPEs must support RFC 6085.  Does 
that violate the requirement to not have changes in the nodes?

Regards,
Brian