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

[<[e-mail]>]

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. 

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

   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.

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