Subject: [v6ops] AD review of draft-ietf-v6ops-v4v6-xlat-prefix

From: Warren Kumari <[email-masked]>
Date: Fri, 5 May 2017 11:06:29 -0400

First off, thank you for a clear, well written document.
I have completed my AD review, and had a few comments / suggestions.

I'd also like to thank Fred for requesting early review, and Joe Clarke for
the helpful review. I agree with all of his comments, other than the xref in the
abstract -- but, see below on the Updates bit.

I've annotated my comments with [C].

W

Abstract

   This document reserves the IPv6 prefix 64:ff9b:1::/48 for local use
   within domains that enable IPv4/IPv6 translation mechanisms.  This
   document updates RFC6890.

[C]: This document updates RFC6890 by ... ? A very brief summary would be good.
Actually, I'm not really sure *why* this updates 6890, from what I can see it
simply reserves an additional prefix in the registry. If it really
*does* update 6890 it should also have a section clearly explaining
what changes it makes (including the "new" text). It's entirely
possible that I've missed
something really obvious here...

4.  Why 64:ff9b:1::/48?

[C]: I suspect that there may be some feedback during IESG review that
this section is really long, and provides a lot of (once published)
unnecessary justification -- however, I found it useful and
interesting (and likely needed before publication) - just mentioning
so you are prepared.

5.  Deployment Considerations

   64:ff9b:1::/48 is intended as a technology-agnostic and generic
   reservation.  A network operator may freely use it in combination
   with any kind of IPv4/IPv6 translation mechanism deployed within his
   network.

[C]: If editing anyway, may want to replace "his" with "their" -
normally I wouldn't point this out, but apart from the gender issue,
network operator could be plural / networks are often owned by
multiple people / an org.

   64:ff9b:1::/48 or any other more-specific prefix SHOULD NOT be
   advertised in inter-domain routing, except by explicit agreement
   between all involved parties.  Such prefixes MUST NOT be advertised
   to the default-free zone.

[C]: ... but you *know* that they will leak - what happens when they
do? Does this break anything? (probably not, *might* be worth
mentioning though)

6.  Checksum Neutrality

   Use of 64:ff9b:1::/48 does not in itself guarantee checksum
   neutrality, as many of the IPv4/IPv6 translation algorithms it can be
   used with are fundamentally incompatible with checksum-neutral
   address translations.

[C]: Er?! What is this checksum neutral thing of which you speak?! :-)
(I think you need a reference here -- I *think* that RFC6296, Section
2.6 is the closest.)

   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.

   The following non-exhaustive list contains examples of translation
   prefixes that are checksum neutral when used with the [RFC7915] and
   [RFC6052] algorithms:

   o  64:ff9b:1:fffe::/96

   o  64:ff9b:1:fffd:1::/96

   o  64:ff9b:1:fffc:2::/96

   o  64:ff9b:1:abcd:0:5431::/96

   Section 4.1 of [RFC6052] contains further discussion about IPv4/IPv6
   translation and checksum neutrality.

[C]: Oh! Here is the reference (I think 6296 Sec 2.6 is clearer.)

7.  IANA Considerations

   The IANA is requested to add the following entry to the IPv6 Special-
   Purpose Address Registry:

              +----------------------+---------------------+
              | Attribute            | Value               |
              +----------------------+---------------------+
              | Address Block        | 64:ff9b:1::/48      |
              | Name                 | IPv4-IPv6 Translat. |
              | RFC                  | (TBD)               |
              | Allocation Date      | (TBD)               |
              | Termination Date     | N/A                 |
              | Source               | True                |
              | Destination          | True                |
              | Forwardable          | True                |
              | Global               | False               |
              | Reserved-by-Protocol | False               |
              +----------------------+---------------------+

   The IANA is furthermore requested to add the following footnote to
   the 0000::/8 entry of the Internet Protocol Version 6 Address Space
   registry:

      64:ff9b:1::/48 reserved for Local-use IPv4/IPv6 Translation [TBD]

8.  Security Considerations

   The reservation of 64:ff9b:1::/48 is not known to cause any new
   security considerations beyond those documented in Section 5 of
   [RFC6052].

9.  References

9.1.  Normative References

 [SNIP]

[C]: IMO it would be better to have the Acknowledgments section as a
numbered section, not an Appendix (I'm not sure if this is actually
required, but is, IMO, better form).

Appendix A.  Acknowledgments

   The author would like to thank Fred Baker, Mohamed Boucadair, Brian E
   Carpenter, Pier Carlo Chiodi, David Farmer, Holger Metschulat and
   David Schinazi for contributing to the creation of this document.

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Fred Baker <[email-masked]>
Date: Fri, 5 May 2017 13:28:11 -0700

> On May 5, 2017, at 8:06 AM, Warren Kumari <[email-masked]> wrote:
> 

Tore and I had a conversation about that, and came up with a possible solution. The argument for "updates" was that it creates a prefix that 6890-next should include. But the next question, and the context of our conversation, was the status - "standards track" vs "BCP". I argued that if the document updated a BCP, it should be a BCP. Tore argued that the prefixes 6890 reports are all in standards track documents.

Our outcome, which I wonder if you would buy, would be to drop the "updates" aspect, but make this a "standards track" document that 6890-next might refer to as it does other standards track documents. Does that work?

I'll leave the rest of your email between you and Tore.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 5 May 2017 16:36:20 -0400

> Our outcome, which I wonder if you would buy, would be to drop the "updates" aspect, but make this a "standards track" document that 6890-next might refer to as it does other standards track docume…

That works for me. My reading of 6890 is that its purpose is to
restructure / update the registries. New registrations can simply be
requests to add to the registry. If there is another restructuring (or
a respin of 6890) it would incorporate / reference everything in the
registry.

So, yes, the current Proposed Standard seems right, just drop the
"Updates" bit and all is good...

W

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 6 May 2017 13:27:46 +1200

>  If there is another restructuring (or a respin of 6890)

That would be draft-bchv-rfc6890bis which is now
"Approved-announcement to be sent::Point Raised - writeup needed"

so all this needs to be updated accordingly.

Regards
   Brian

---

From: Warren Kumari <[email-masked]>
Date: Sat, 06 May 2017 18:49:25 +0000

... sob...

Yup.
W
On Fri, May 5, 2017 at 9:27 PM Brian E Carpenter <

---

From: <[email-masked]>
Date: Tue, 9 May 2017 06:36:14 +0000

Hi Warren, all, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : v6ops [mailto:[email-masked]] De la part de Warren Kumari
> Envoyé : vendredi 5 mai 2017 17:06
> À : IPv6 Operations; [email-masked]; Joe
> Clarke
> Objet : [v6ops] AD review of draft-ietf-v6ops-v4v6-xlat-prefix
> 

[Med] I wonder if a pointer to https://tools.ietf.org/html/rfc6052#section-3.2 would be sufficient here instead of having the full discussion. 

> (I think you need a reference here -- I *think* that RFC6296, Section

[Med] The text already cites a pointer that is relevant for IPv4/IPv6 address translation matters: 

> [C]: Oh! Here is the reference (I think 6296 Sec 2.6 is clearer.)

[Med] Citing RFC6052 is appropriate here because it discusses IPv4/IPv6 address translation matters while RFC6269 is about IPv6 prefix translation. RFC6052 is clear about the meaning: 

... one's complement checksum if both the IPv4-
   translatable and the IPv4-converted IPv6 addresses were constructed
   in a "checksum-neutral" manner, that is, if the IPv6 addresses would
   have the same one's complement checksum as the embedded IPv4 address.

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

---

From: Warren Kumari <[email-masked]>
Date: Tue, 9 May 2017 03:15:31 -0400

> [Med] I wonder if a pointer to https://tools.ietf.org/html/rfc6052#section-3.2 would be sufficient here instead of having the full discussion.

Yup, works for me.

> [Med] The text already cites a pointer that is relevant for IPv4/IPv6 address translation matters:

Ok. You might want to mention RFC6052 here, but I'm fine if not
(someone new to the topic will read down to here, and then get
confused and might not read to end of section).

>    have the same one's complement checksum as the embedded IPv4 address.

Ok, fine with me.

Once Tore pushes a new version (without the Updates: , and other
changes)  I can start the IETF LC.
W

---

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

Hi Warren,

* Warren Kumari <[email-masked]>

> something really obvious here...

As discussed later on in this thread, I've "solved" this by dropping the
RFC6890 update completely.

> interesting (and likely needed before publication) - just mentioning

Thanks for the heads up. The reason for it being so long is because the
working group wanted it to be (the selection of the exact prefix took
like 90%+ of the time spent on the draft), so I'm loath to start
trimming it down again...

> multiple people / an org.

Changed, thanks!

> do? Does this break anything? (probably not, *might* be worth

I implemented Mohamed's follow-up suggestion by rewriting this
paragraph as follows:

        64:ff9b:1::/48 or any more-specific prefix may only be used in
        inter-domain routing if done in accordance with the rules
        described in Section 3.2 of [RFC6052].

Does that work for you?

>    neutrality, as many of the IPv4/IPv6 translation algorithms it can
> be used with are fundamentally incompatible with checksum-neutral
>    address translations.
> 
>    Section 4.1 of [RFC6052] contains further discussion about
> IPv4/IPv6 translation and checksum neutrality.
> 

As Mohamed also mentioned in his follow-up I believe RFC6052 section
4.1 is the correct reference here.

I reordered this section though so that the paragraph with the RFC6052
section 4.1 pointer comes second, before the paragraphs with the RFC7915
discussion and examples. No word changes. Better?

> Appendix A.  Acknowledgments

When I wrote RFC7755 I originally had the Acknowledgements section as
an ordinary numbered section, but the RFC Editor moved it into the
<back> with «numbered="no"».

So I'll just leave it where it is but add «numbered="no"», which I'd
forgotten about in this draft. I hope that's good enough.

Tore