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

[Tore Anderson <[e-mail]>]

Hi Warren,

* Warren Kumari <[e-mail]>

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

Thank you very much! My comments in-line:

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

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

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

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

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

Changed, thanks!

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

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?

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

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?

> [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

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