Early Review of draft-ietf-v6ops-v4v6-xlat-prefix-00
review-ietf-v6ops-v4v6-xlat-prefix-00-opsdir-early-clarke-2017-05-02-00

• Status
• Email expansions
• History

• Versions
• 00

Review
review-ietf-v6ops-v4v6-xlat-prefix-00-opsdir-early-clarke-2017-05-02

Hello, Tore and Fred.  Thanks for requesting an OPSDIR review of this draft.  Up front, I'd like to say that I enjoyed hearing the discussion on why certain decisions were made, especially with concern to ease of use for operators and compatibility with other established translation approaches.   That said, I have a few minor issues/questions and nits concerning this draft.  I think they will be easy to address.

ISSUES/QUESTIONS:

You set out to define WKP as _the_ well-known prefix.  For the most part you adhere to this language in the draft.  However, in section 3, you state (highlighting added by me):

Also, because the WKP is a /96, an operator preferring to use _a WKP_
over an NSP can only do so for only one of his IPv4/IPv6 translation
mechanisms.  All others must necessarily use an NSP.

And then in section 5:

When 64:ff9b:1::/48 or a more-specific prefix is used with the
[RFC6052] algorithm, it is considered to be a Network-Specific
Prefix.

I believe what you're saying is that while you define 64:ff9b:1::/48 as a WKP in _this_ draft, respective to RFC6052, it is an NSP.  However, the combination of text in both sections was a bit confusing to me, and perhaps it would be useful to clarify your use of terms.

===

In Section 3, you state:

Since the WKP 64:ff9b::/96 was reserved by [RFC6052], several new
IPv4/IPv6 translation mechanisms have been defined by the IETF

I think it would be useful to mention some of these new translation mechanisms as non-normative references, and if need be, show an example of interoperability.

NITS:

In your Abstract, you mention RFC6890, but this does not appear to be an xref to it, and it should be.

===

In Section 4.1 you state:

OLD:
The second criterion is that the prefix length chosen is is a
multiple of 16.  This ensures the prefix ends on a colon boundary
when representing it in text, easing operator interaction with it.

NEW:
The second criterion is that the prefix length chosen is a
multiple of 16.  This ensures the prefix ends on a colon boundary
when representing it in text, easing operator interaction with it.

(Removed a redundant "is".)

===

In Section 4.1 again:

OLD:
The [RFC6052] algorithm specifies IPv4/IPv6 translation prefixes as
short as /32.  In order to facilitate multiple instances of
translation mechanisms using /32s, while at the same time aligning on
a 16-bit boundary, it would be necessary to reserve a /16.  Doing so
was however considered as too wasteful by the IPv6 Operations working
group.

NEW:
The [RFC6052] algorithm specifies IPv4/IPv6 translation prefixes as
short as /32.  In order to facilitate multiple instances of
translation mechanisms using /32s, while at the same time aligning on
a 16-bit boundary, it would be necessary to reserve a /16.  Doing so,
however, was considered too wasteful by the IPv6 Operations working
group.

===

In Section 6:

OLD:
The Stateless IP/ICMP Translation algorithm [RFC7915] is one well-
known algorithm that can operate in a checksum-neutral manner, when
using the [RFC6052] algorithm for all of its address translations.
However, in order to attain checksum neutrality is imperative that
the translation prefix is chosen carefully.  Specifically, in order
for a 96-bit [RFC6052] prefix to be checksum neutral, all the six
16-bit words in the prefix must add up to a multiple of 0xffff.

NEW:
The Stateless IP/ICMP Translation algorithm [RFC7915] is one well-
known algorithm that can operate in a checksum-neutral manner, when
using the [RFC6052] algorithm for all of its address translations.
However, in order to attain checksum neutrality it is imperative that
the translation prefix is chosen carefully.  Specifically, in order
for a 96-bit [RFC6052] prefix to be checksum neutral, all the six
16-bit words in the prefix must add up to a multiple of 0xffff.

(Added a missing "it".)

===