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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
