Re: [v6ops] Robert Wilton's No Objection on draft-ietf-v6ops-transition-comparison-03: (with COMMENT)

[Gábor LENCSE <[e-mail]>]

Dear Robert,

Thank you for your review and I am sorry for my late response. (Now, I 
perform the changes in the XML file and submit the new version after 
being ready with processing the comments of the other reviewers, too.)

Please see my answers inline.


4/21/2022 12:36 PM keltezéssel, Robert Wilton via Datatracker írta:
> Robert Wilton has entered the following ballot position for
> draft-ietf-v6ops-transition-comparison-03: No Objection

[...]

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 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) ...

Regarding the code size, I wanted to say that there is a greater chance 
that a programmer made a mistake in a more complex program than in a 
less complex one. But I admit that it is rather a speculation than a 
well defensible statement. So, we decided to remove that paragraph.

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

In the first case, we meant to use the word "stateless NAT64" as the 
general expression for the stateless translation between IPv4 and IPv6 
independently from its direction, and then wanted to make it more 
precise by using "stateless NAT46" to express the direction. But it 
could be done in a more straightforward way. :-)

OLD:

    The customer-side translator (CLAT) is located in the customer's
    device, and it performs stateless NAT64 translation [RFC7915  <https://datatracker.ietf.org/doc/html/rfc7915>] (more
    precisely, stateless NAT46, a stateless IP/ICMP translation from IPv4
    to IPv6).

NEW:

    The customer-side translator (CLAT) is located in the customer's
    device, and it performs stateless NAT46 translation [RFC7915] (more
    precisely, a stateless IP/ICMP translation from IPv4 to IPv6).

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

Yes, it has been criticized by several other Reviewers, too. I agree 
that more than 4 devices may be used simultaneously.

I have changed the text to:

    According to [MIY2010], each user-device (computer, tablet,
    smartphone) behind a NAT, could simultaneously use up to 300 ports.
    (Table 1 of [MIY2010] lists the port number usage of various
    applications.  According to [REP2014] the downloading of some web
    pages may consume up to 200 port numbers.)  If the extended NAPT
    algorithm is used, which includes the full five tuple into the
    connection tracking table, then the port numbers are reused, when the
    destinations are different.  Therefore, we need to consider the
    number of "port hungry" applications that are accessing the same
    destination simultaneously.  We estimate that in the case of a
    residential subscriber, there will be typically no more than 4 of
    port hungry applications communicating with the same destination
    simultaneously, which means a total of 1,200 ports.


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

Yes, I think adding a summarizing table could be a good idea. However, 
this draft is now over a lot of reviews, and adding some new material 
could result in further comments, which I would like to avoid so that 
our draft could be published as soon as possible.
Therefore, if it is not absolutely necessary, I would like to omit the 
table.

Once again, thank you for your review and suggestions!

Best regards,

Gábor Lencse


> Thanks,
> Rob
>
>
>