Skip to main content

Last Call Review of draft-ietf-v6ops-transition-comparison-02
review-ietf-v6ops-transition-comparison-02-tsvart-lc-trammell-2022-03-15-00

Request Review of draft-ietf-v6ops-transition-comparison
Requested revision No specific revision (document currently at 04)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2022-03-18
Requested 2022-03-04
Authors Gábor Lencse , Jordi Palet Martinez , Lee Howard , Richard Patterson , Ian Farrer
Draft last updated 2022-03-15
Completed reviews Tsvart Last Call review of -02 by Brian Trammell (diff)
Opsdir Last Call review of -02 by Dan Romascanu (diff)
Secdir Last Call review of -02 by Joseph A. Salowey (diff)
Genart Last Call review of -02 by Dan Romascanu (diff)
Assignment Reviewer Brian Trammell
State Completed
Review review-ietf-v6ops-transition-comparison-02-tsvart-lc-trammell-2022-03-15
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/6Z79w3fs78NQ98ZnDkc9VAVO1T8
Reviewed revision 02 (document currently at 04)
Result Ready with Nits
Completed 2022-03-15
review-ietf-v6ops-transition-comparison-02-tsvart-lc-trammell-2022-03-15-00
This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

This document is a readable introduction to the landscape of (presently widely
deployed, as opposed to "all defined") translation/encapsulation methods for
providing IPv4 Internet access with a IPv6-only access network. I've reviewed
it solely with an eye toward potential transport issues.

In this aspect, the document is essentially ready. The references and analysis
in operational tradeoffs in port number sharing seem solid. I especially
appreciated the attention to MTU issues, and the reiteration of advice from
MAP-E (RFC7597); as well as the reference for multicast in section 3.6.

The document clearly explains the reliance of double-translation approaches on
ports in the transport layer, though it might be useful to note that "port
aware" means "has a 16-bit source port in network order at octet 0 and a 16-bit
destination port in network order at octet 2", and though I suspect that very
few shipping translators support SCTP, it'd be nice to note that SCTP is indeed
port aware.

I'm a little surprised by the following:

"However, when ports are allocated statically,
   more customers may get ports from the same public IPv4 address, which
   may results in negative consequences with higher probability, e.g.
   many applications and service providers (Sony PlayStation Network,
   OpenDNS, etc.) permanently black-list IPv4 ranges if they detect that
   they are used for address sharing."

(First, please use "block" instead of "blacklist" here, though the RFC editor
respectful language check will also catch that).

and... Really? in 2022? Is there some insight into the business reason behind
this blocking / a citiation for an analysis of it?

Editorial nits (not exhaustive):

" The address sharing efficiency of the five technologies is significantly
different, it is discussed in Section 4.2" appears to be missing a period at
end of sentence.