Pros and Cons of IPv6 Transition Technologies for IPv4-as-a-Service (IPv4aaS)
draft-ietf-v6ops-transition-comparison-04

# Internet AD comments for {draft-ietf-v6ops-transition-comparison-03}
CC @ekline

## Comments

An note throughout: consider preferring "transport layer" over "layer-4".

### S2.3, S4.3

* Suggest: s/layer-4 ports/transport layer ports/.

### S3.2

* Suggest: s/layer-4 next-header/transport layer next-header/.

### S3.4

* With respect to the 300 ports x ~4 devices numbers: I think it would be
  an improvement if there were some study that could be cited to back up
  these numbers.

* You might consider noting here that in some jurisdictions the number of
  available ports per subscriber for CGNAT/Large-scale NAT could be set by
  a relevant authority.

  I tried to find a reference to the Belgian ISP regulation limited CGNAT
  deployments to 16 subscribers per public IPv4 address, but I couldn't
  easily find it.  Maybe I'm misremembering something.

  (update) Aha, I see you mention something in S4.2.  Thanks.

* Some text from RFC 6888 might be useful, in terms of requirements for
  sizing CGNATs.

### S4.5.2, S4.5.3

* Probably best to have a citation here for where these numbers come from.

### S4.7

* You might see if RFC 6888 section 4 is worth referring to here.

### S5

* Since the text raises the point, you might explain what sorts of "tricks"
  are needed, and why.

### S8

* I support Roman's recommendation to remove the "bugs proportional to code
  size" text altogether.

Thank you for addressing my DISCUSS points and some of my COMMENTs.

Thank you to Joe Salowey for the SECDIR review.  I too would have found it useful for a comparative security analysis across the different IPv4aaS techniques.

===
** Section 3.4
   An alternative approximation for the other IPv4aaS technologies, when
   dynamically assignment of addresses is not possible, must ensure
   sufficient number of ports per subscriber.  That means 1,200 ports,
   and typically, it comes to 2,000 ports in many deployments. 

What is the basis of these values?

** Section 4.4.2.

In broadband networks, there are some deployments of 464XLAT, MAP-E
   and MAP-T.  Lw4o6 and DS-Lite have more deployments, with DS-Lite
   being the most common, but lw4o6 taking over in the last years.

   Please refer to Table 2 and Table 3 of [LEN2019] for a limited set of
   deployment information.

Is there a reference for these trends?  They don’t appear to fall out of Table 2 or 3 of [LEN2019].

** Section 4.5.2 and 4.5.3.  Both sections appear to cite real work measurement.  Can a reference or a more detailed explanation of the source be provided.   For example, is the 3/4 vs. 1/4 split in Section 4.5.2 a representative pattern of some kind?

** Section 5.  I don’t follow the intent of this section.  There are no performance results to share.  This text appears to be foreshadowing another draft (draft-lencse-v6ops-transition-benchmarking).  However, this draft is -00 and contains no results.  I recommend removing this section.

Thanks for working on this informational document. It helps to get an overview of IPv4aaS technologies and I learned + got reminded number of stuffs while reading this document.

I have following comments/observations, I think addressing them would help improving this document even more.

-  Section 2.1: it has a note regarding mobile network and CLAT. It would be great if this references to some appropriate document ( any architectural description document should do the job here). 

- Section 3.1 : it strongly recommends the MTU in the IPv6-only domain to be "well managed". First, can the "strongly recommends" be replaced by normative text? second and more important, where is the definition of "well managed"? is there any description available or BCP's that we can refer to? To me, the "well managed" here is that we have sufficiently large MTU to support the tunneling and translation. if we are only meaning that feature the we can very well write it instead of asking them to be "well managed". If we mean more then I would recommend to either define what we mean by "well managed" or refer to where this is described.

- Section 4.5.2 and section 4.5.3: these sections refers to some figures from existing deployments. what are the sources of such figures? did the WG run some analysis or tests to derive those data? were they published somewhere? I think it is necessary to refer to the data source or describe the methods on how those data were collected and comprehended to be included here if those figures supposed to help the reader to understand and influence their decisions.

Section 3.4, paragraph 1, comment:
>    Often it is assumed that each user-device (computer, tablet,
>    smartphone) behind a NAT, could simultaneously use about 300 ports.
>    Typically, in the case of a residential subscriber, there will be a
>    maximum of 4 of those devices in use simultaneously, which means a
>    total of 1,200 ports.

Is there a reference for these numbers? They seem awfully low.

Section 4.2, paragraph 1, comment:
> 4.2.  Tradeoff between Port Number Efficiency and Stateless Operation

I'm missing some text in this section that clearly describes the bad and hard to
debug consequences of assigning too few ports to an end user, and ideally a
recommendation to assign a conservatively large number of ports.

Section 5, paragraph 1, comment:
> 5.  Performance Comparison

This section is entirely about future work, which could IMO be removed before
the RFC is published. (This should go into
I-D.lencse-v6ops-transition-benchmarking.)

The datatracker state does not indicate whether the consensus boilerplate
should be included in this document.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "native"; alternatives might be "built-in", "fundamental", "ingrained",
   "intrinsic", "original"

Thanks to Dan Romascanu for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/0LD7N9OxJR4KupJKbaISQ9518ng).

-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Uncited references: [RFC2119] and [RFC8174].

Paragraph 683, nit:
> rovide network operators with an easy to use reference to assist in selecting
>                                  ^^^^^^^^^^^
It appears that two hyphens are missing.

Paragraph 2448, nit:
> t have been developed makes it time consuming for a network operator to iden
>                                ^^^^^^^^^^^^^^
This word is normally spelled with a hyphen.

Paragraph 6866, nit:
> 275,000 subscribers being served with a only a /22. In the other IPv4aaS tec
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Paragraph 7145, nit:
> t extreme limit is probably not a very a safe choice. This extremely reduced
>                                 ^^^^^^^^^^^^^
It seems like one article is redundant in this context.

Paragraph 10011, nit:
> time of writing is not available in MacOS. The remaining four solutions are
>                                     ^^^^^
The operating system from Apple is written "macOS".

Paragraph 10205, nit:
> ar networks, as they are neither standardised nor implemented in UE devices.
>                                  ^^^^^^^^^^^^
Do not mix variants of the same word ("standardise" and "standardize") within a
single text.

Paragraph 11483, nit:
>  with a stateless technology alone. Thus a centralized NAPT44 model may be th
>                                     ^^^^
A comma may be missing after the conjunctive/linking adverb "Thus".

Paragraph 11593, nit:
> ns that the traffic flow will cross thru the AFTR, lwAFTR or BR, depending o
>                                     ^^^^
The word "thru" is informal. Consider replacing it with "through".

Paragraph 11654, nit:
> head. However, in the case of those mechanism that use a NAT46 function, in
>                               ^^^^^^^^^^^^^^^
The plural demonstrative "those" does not agree with the singular noun
"mechanism".

Paragraph 12129, nit:
> e format of [RFC2544] including "hard wired" source and destination port num
>                                  ^^^^^^^^^^
This expression is normally spelled as one or with a hyphen.

Thanks to Brian Trammell for the tsvart review.

It would be nice to at least point to draft-ietf-tsvwg-natsupp-23 to discuss the issues with SCTP and NAT.

Thanks Dan for the OPSDIR review.

I support Roman's discuss comment regarding comparing security based on the binary object size - I think that there are many more significant factors that come into play (source language, LOC in source, how widely is the technology used/deployed, experience of the developers, is the code being actively maintained, what level of regression/fuzz testing exists) ...

Thank you for this document, I think that it is useful.  Some minor comments/suggestions:

2.1.  464XLAT
   The customer-side translator (CLAT) is located in the customer's
   device, and it performs stateless NAT64 translation [RFC7915] (more
   precisely,

Is NAT64 definitely right here, and not NAT46?

3.4.  IPv4 Pool Size Considerations

   Often it is assumed that each user-device (computer, tablet,
   smartphone) behind a NAT, could simultaneously use about 300 ports.
   Typically, in the case of a residential subscriber, there will be a
   maximum of 4 of those devices in use simultaneously, which means a
   total of 1,200 ports.

Is a maximum of 4 devices in simultaneous use on a residential internet connection realistic?  This feels low to me, and potentially this is likely to be increasing over time.

   If the CGN (in case of DS-Lite) or the CE (in case of lw4o6, MAP-E
   and MAP-T) make use of a 5-tuple for tracking the NAT connections,
   the number of ports required per subscriber can be limited as low as
   4 ports per subscriber.  However, the practical limit depends on the
   desired limit for parallel connections that any single host behind
   the NAT can have to the same address and port in Internet.  Note that
   it is becoming more common that applications use AJAX and similar
   mechanisms, so taking that extreme limit is probably not a very a
   safe choice.

Previously we were talking about 300 - 1200 ports/subscriber.  It wasn't really clear to me how this goes down to just 4 ports per subscriber.

If QUIC/HTTP3 deployment continues to pick up then I would expect that may reduce the number of ports required since it handled better multiplexing of streams.

Finally, I think that having some sort of high level summary (maybe in tabular form) may be beneficial, e.g., comparing relative MTU overheads of the approaches, stateful vs stateless, IPv4 address scalability/usage.

Thanks,
Rob