Subject: Opsdir early review of draft-ietf-v6ops-v4v6-xlat-prefix-00

From: Joe Clarke <[email-masked]>
Date: Tue, 02 May 2017 06:30:51 -0700

Reviewer: Joe Clarke
Review result: Has Issues

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".)

===

---

From: Fred Baker <[email-masked]>
Date: Tue, 2 May 2017 11:00:27 -0400

Thanks!

> On May 2, 2017, at 9:30 AM, Joe Clarke <[email-masked]> wrote:
> 
> Reviewer: Joe Clarke

---

From: David Farmer <[email-masked]>
Date: Tue, 2 May 2017 10:40:22 -0500

Prompted by this review, I reread the document and found what I think are a
couple additional typos.

Section 4.2, Prefix Value, compares two options: 64:ff9a:ffff:ffff::/48 and
64:ff9b:1::/48. However in the fifth paragraph of the section, I believe
there are two errant references to 64:ff9b:1::/96, that should instead
be 64:ff9b:1::/48,
unless I'm misunderstanding the intent of the paragraph.

Thanks.

On Tue, May 2, 2017 at 10:00 AM, Fred Baker <[email-masked]>
wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 3 May 2017 11:01:54 +1200

On 03/05/2017 01:30, Joe Clarke wrote:
...
> an xref to it, and it should be.

afaik, the RFC Editor style does not allow xrefs in the Abstract.

(Also: draft-bchv-rfc6890bis will update 6890 soon. I don't know whether
that's relevant.)

    Brian

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Tue, 2 May 2017 23:06:33 +0000

PGP Key : http://www.marcuscom.com/pgp.asc

> On May 2, 2017, at 19:01, Brian E Carpenter <[email-masked]> wrote:
> 

I've seen some that do (ostensibly).  But this if this isn't required, it wasn't critical.

Joe

---

From: Fred Baker <[email-masked]>
Date: Wed, 3 May 2017 06:21:14 -0400

One of the issues with a document that updates another document is that it is supposed to say in the abstract that it does.

> On May 2, 2017, at 7:06 PM, Joe Clarke (jclarke) <[email-masked]> wrote:
> 
> 
>

---

From: Phil Shafer <[email-masked]>
Date: Wed, 3 May 2017 08:50:48 -0400

>I've seen some that do (ostensibly).  But this if this isn't required, it wasn't critical.

idnits certainly complains about it.

Thanks,
 Phil

---

From: Tore Anderson <[email-masked]>
Date: Thu, 11 May 2017 13:16:42 +0200

Hi Joe, and thank you very much for your review. See in-line for my
comments.

* Joe Clarke <[email-masked]>

> mechanisms.  All others must necessarily use an NSP.

Good catch! I changed «a WKP» to «the WKP».

> to me, and perhaps it would be useful to clarify your use of terms.

Actually I'm trying to not imply anywhere that 64:ff9b:1::/48 is a/the
«WKP» (although the previous point you brought up was a failure in that
regard). The WKP is defined to be exactly 64:ff9b::/96 by RFC6052, and
I do not want to cause any ambiguity here.

I rewrote the paragraph in question as follows:

      Note that 64:ff9b:1::/48 (or any more-specific prefix) is distinct from
      the WKP 64:ff9b::/96. Therefore, the restrictions on the use of the WKP
      described in Section 3.1 of <xref target="RFC6052"/> do not apply to the
      use of 64:ff9b:1::/48.

Is that better?

> example of interoperability.

How about: «Since the WKP 64:ff9b::/96 was reserved by [RFC6052],
several new IPv4/IPv6 translation mechanisms have been defined by the
IETF, such as [RFC6146] and [RFC7915].» ?

These two mechanisms do not interoperate at all, so they need different
translation prefixes if they're to be deployed in the same network.

> an xref to it, and it should be.

As mentioned by others, the idnits tool complains about xrefs in the
abstract. In any case I've just dropped the Updates on 6890 completely.

> (Removed a redundant "is".)

Fixed, thanks!

> however, was considered too wasteful by the IPv6 Operations working

Fixed, thanks!

> 16-bit words in the prefix must add up to a multiple of 0xffff.

Fixed, thanks!

Tore

---

From: Tore Anderson <[email-masked]>
Date: Thu, 11 May 2017 13:21:53 +0200

Hi David,

> unless I'm misunderstanding the intent of the paragraph.

You're absolutely right. Fixed. Thank you!

Tore

---

From: Joe Clarke <[email-masked]>
Date: Thu, 11 May 2017 13:13:10 -0400

>       described in Section 3.1 of <xref target="RFC6052"/> do not apply to the

Yes, I think that text plus the previous clarification is good.

> translation prefixes if they're to be deployed in the same network.

That works.

Thanks.

Joe