I have reviewed this document as part of the transport area directorate's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors for their information and to allow them to address any issues
raised. When done at the time of IETF Last Call, the authors should consider
this review together with any other last-call comments they receive. Please
always CC tsv-dir(_at_)ietf(_dot_)org if you reply to or forward this review.
This draft is basically ready for publication, but has nits that should be
fixed before publication.
Nits:
Section 1:
Such problems are not specific of Shim6, but
are suffered by the hosts of any site which is connected to multiple
transit providers, and which receives an IPv6 prefix from each of the
providers.
It might be useful to add a non-normative reference to RFC5220 at the end of
that sentence.
Section 3.4:
The use of HBA is more efficient in the sense that addresses require
less computation than CGA, involving only hash operations for both
the generation and the verification of locator sets. However, the
locators of an HBA set are determined during the generation process,
and cannot be subsequently changed; the addition of new locators to
that initial set is not supported, except by re-generation of the
entire set which will in turn cause all addresses to change.
I think that paragraph is too harsh, as it implies the old addresses
have to be invalidated immediately. I expect existing connections
could continue with the old addresses, and, if the host wanted to,
could even have new connections use the old addresses. If that
is not possible, the draft should explain why. If that is possible,
the draft should probably explain it is possible.
Section 4:
In order to configure source and destination address selection, tools
such as DHCPv6 can be used to disseminate a [RFC3484] policy table to
a host.
It might be useful to add a non-normative reference to
draft-ietf-6man-addr-select-opt.
Section 4:
The sentence ending with "properties exhibited by REAP." needs a reference
to RFC5544, which seems to be the RFC defining REAP.
Section 7.7, "Shim6 and IPv6 NAT", the problem could be overcome by the
Shim6 node knowing its IPv6 address after NPTv6 translation. Probably not
worth adjusting the document, though, as NPTv6 is experimental.
Section 7.7:
Note that an Application Level Gateway designed to modify the Shim6
control packets would not be able to generate a valid signature, in
case a CGA is being used, or a Parameter Data Structure binding the
translated locator to the other locators of a node, in case a HBA is
being used. Therefore, the same failure cases described before would
remain.
Applications are layer 7, Shim6 is layer 3, so an "Application Layer
Gateway" that modifies Shim6 control packets seems an abuse of terminology.
Suggest:
OLD:
Note that an Application Level Gateway designed to modify the Shim6
control packets would not be able to generate a valid signature, in
NEW:
Note that modification of the Shim6 control packets by the IPv6 NAT
.............^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
would not be able to generate a valid signature, in
-d
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf