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

[Warren Kumari <[e-mail]>]

On Tue, May 9, 2017 at 2:36 AM,  <[e-mail]> wrote:
> Hi Warren, all,
>
> Please see inline.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : v6ops [mailto:[e-mail]] De la part de Warren Kumari
>> Envoyé : vendredi 5 mai 2017 17:06
>> À : IPv6 Operations; [e-mail]; Joe
>> Clarke
>> Objet : [v6ops] AD review of draft-ietf-v6ops-v4v6-xlat-prefix
>>
>> 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)
>
> [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.

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

>
>    Section 4.1 of [RFC6052] contains further discussion about IPv4/IPv6
>    translation and checksum neutrality.
>
>>
>>    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.)
>
> [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.

Ok, fine with me.

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

>
>>
>> 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
>>
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops



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