[v6ops] Éric Vyncke's Yes on draft-ietf-v6ops-transition-comparison-04: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-v6ops-transition-comparison-04: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-comparison/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for addressing all my DISCUSS and COMMENT points (kept below for
archiving purpose only). I have now cleared my DISCUSS ballot for this very
useful and informative document.

Thank you all

-éric

# DISCUSS (for archive)

## Section 2.2

A important and trivial to fix "translates the IPv4 payload to public IPv4
source address using a stateful NAPT44" => "translates the IPv4 source address
in the payload to public IPv4 source address using a stateful NAPT44"

## Section 3.3

"Here, the centralized network function (lwAFTR or BR) only needs to perform
stateless encapsulation/decapsulation or NAT64", actually in MAP-T, BR does
translation.

## Section 3.4

I am afraid that the number of IPv4 public addresses that are required goes
beyond this "simple" computation. There are also other constraints such as
laws, MoU, rules and operators BCP, see:

-
https://bipt.be/operators/publication/consultation-of-11-october-2016-regarding-the-conditions-of-use-of-ipv4cgn
(alas in French/Dutch) but meaning that in my country, Belgium, an IP address
can be shared by 16 subscribers max

-
https://www.europol.europa.eu/media-press/newsroom/news/are-you-sharing-same-ip-address-criminal-law-enforcement-call-for-end-of-carrier-grade-nat-cgn-to-increase-accountability-online

# COMMENTS (for archive)

Note for the shepherding AD: missing consensus boilerplate.

Generally, I would have appreciated some text about the difference between a
residential CE (serving multiple hosts) and a mobile hand-set (serving usually
a single host -- except when tethering)

## Section 1

"As the deployment of IPv6 becomes more prevalent", I hope that this sentence
is a little outdated in 2022...

s/The following IPv6 transition technologies are covered:/The following IPv4aaS
technologies are covered:/ ?

## Section 2.1

s/it performs stateless NAT64 translation/it performs stateless NAT46
translation/ ?

About "64:ff9b::/96 Well-Known Prefix", suggest adding a reference to RFC 8215.

s/In the operator's network, the provider-side translator/At the edge the
operator's network, the provider-side translator/ ?

Hummm "when a dedicated /64 "... RFC 8215 is a /48, the text above is /96 and
now it is a /64 ?

While I appreciate the text "When an IPv6-only client or application
communicates with an IPv4-only server", the reader may benefit of the dual text
for IPv4-only client app communicates with IPv4-only server.

Should figure 1 use "IPv4-only app" rather than "IPv4-only device" ? Especially
when the actual device/handset is IPv6 only ?

## Section 2.3

Please explain / expand what is "only performs A+P routing" at the first use.

I like the last paragraph about hair-pinning the IPv4 traffic BUT this should
also be explained in all sub-sections of section 2.

## Section 3.1

Is it worth mentioning whether the tunnels require any control plane ?

How can a tunnel not require additional header ? While I understand what the
authors mean, I suggest to use the word "overhead".

"to implement buffering and fragment re-assembly in the BR node" but "BR node"
is only applicable to MAP-[ET].

## Section 3.2

The 3rd paragraph is more on multicast and deserves a section on its own (or
added in section 3.6). Especially the last sentence, which is about
encapsulation in a NAT section ;-)

The 4th paragraph has also little to do with NAT but more with L4 visibility
for ECMP/ACL, suggest to make its own section.

## Section 3.3

Should "CGN" be introduced before ? (at least expanded ?)

Please expand "EAMT" even if a reference is given.

## Section 3.4

Even if somehow obvious, please prefix "port" with "TCP/UDP"

Please provide references to the numbers of 300 ports and 4 devices.

Does the above also apply to 464XLAT ?

## Section 4.1.1

A little strange to see a 3-row table associated to "on the basis of two
aspects"... Suggest to have a single row indicating T/E.

## Section 4.2

This section would benefit from version / date for the browser data and for
Netfilter implementation. A reference to Netfilter would be another plus.

## Section 4.4.1

Please add version for the miscellaneous OS and add a date for "at the time of
writing is not available in MacOS."

## Section 8

Should DNSSEC interactions with translation (and not with encapsulation) be
discussed ?

# NITS

## Section 2.1

Figure 1, mostly cosmetic the "stateless/stateful" qualification is once before
xLAT once after ;-) Let's try to be consistent.

## Section 2.2

"Basic Broadband Bridging' (B4)" while RFC 6333 uses "Basic Bridging BroadBand
(B4)" ;-)

## Section 2.4

"The CE (Customer-Edge)", CE has already been expanded before.

s/The client address/port allocation size is a design parameter/The client
address/port allocation size is a configuration parameter/

## Section 4.4.2

A table would be easier to read rather than a list ;-)

## Section 4.5.2 and 4.5.3

Do the authors have more recent data than in 2018 and 2020 ?