Subject: [Last-Call] Tsvart last call review of draft-ietf-v6ops-transition-comparison-02

From: Brian Trammell via Datatracker <[email-masked]>
Date: Tue, 15 Mar 2022 09:13:00 -0700

Reviewer: Brian Trammell
Review result: Ready with Nits

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
[email-masked] 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.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 15 Mar 2022 16:35:27 +0000

> 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 would be careful here. If one applies NAPT per UDP/TCP model to SCTP it
will break SCTP. SCTP NAT is being worked on:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-natsupp/

/Magnus

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 15 Mar 2022 17:37:20 +0100

Fair enough… so disregard my comment re SCTP, but please do consider being precise about what port-aware means here.

Thanks, cheers,

Brian

> On 15 Mar 2022, at 17:35, Magnus Westerlund <magnus.westerlund=[email-masked]> wrote:
> 
> 
> 
> _______________________________________________
> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 15 Mar 2022 18:07:48 +0100

> On 15. Mar 2022, at 17:13, Brian Trammell via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Brian Trammell
SCTP uses the port number concept, as do TCP, UDP, and DCCP. However, an
endpoint has a list of IP addresses and a single port number. So you can
not translate the port independently on a single path.

Best regards
Michael
> -- 
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call