Re: [v6ops] Roman Danyliw's Discuss on draft-ietf-v6ops-transition-comparison-03: (with DISCUSS and COMMENT)

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

Dear Roman,

Thank you very much for your thorough review!

We have discussed your comments and suggestions and now I perform the 
changes on the XML file, but I do not submit the next version yet, because:
- I would like to check with you, if you agree with them
- I want to include the changes recommended by several other reviewers.

Please see our answers inline.

4/19/2022 4:23 AM keltezéssel, Roman Danyliw via Datatracker írta:
> Roman Danyliw has entered the following ballot position for
> draft-ietf-v6ops-transition-comparison-03: Discuss
[...]
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> ** Section 4.7 notes detailed connection level logging of user behaviors.
> Please discuss the privacy and security implications – securing these logs at
> rest from unauthorized access, retention, etc.
We added the following paragraph at the beginning of Section 8:

8.  Security Considerations

    As discussed in section 4.7, the different technologies have varying
    logging capabilities and limitations.  Care should be taken when
    storing, transmitting, and providing access to log entries that may
    be considered personally identifiable information.  However, it
    should be noticed that those issues are not specific to the IPv4aaS
    IPv6 transition technologies, but in general to logging
    functionalities.


> ** Section 8.
>     According to the simplest model, the number of bugs is proportional
>     to the number of code lines.  Please refer to Section 4.4.3 for code
>     sizes of CE implementations.
>
> What is the intent of this text and how should the reader use it to choose a
> IPv4aaS?

It was my text, and 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.

> Taking the simple model above and the text from Section 4.4.3 (“… 17kB, 35kB,
> 15kB, 35kB, and 48kB for 464XLAT, lw4o6, DS-Lite, MAP-E, MAP-T, and lw4o6 …”),
> is it suggesting that 464XLAT the most “secure” protocol because it’s code size
> the smallest?  How does that metric work across different implementation?  I
> recommend removing this text.

I did so.

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

Currently, I have a PhD student, Ameen, Al-Azzawi, who's topic is 
"Vulnerability Analysis of IPv6 Transition Technologies". If there is 
interest in the WG, I would be happy to start a separate I-D about this 
topic based on his results.

> ** Section 3.2
>     For
>     encapsulation, there is an IPv6 header followed by an IPv4 header.
>     This results in less entropy for hashing algorithms, and may mean
>     that devices in the traffic path that perform header inspection (e.g.
>     router ACLs or firewalls) require the functionality to look into the
>     payload header.
>
> Can this text please be clarified.  What is the link between less entropy and
> payload inspection.

To answer your question:
IMHO, the problem of entropy and the problem of header inspection are 
two different things that both caused by encapsulation
If there is a tunnel e.g. between the B4 and the AFTR of DS-Lite, then 
the IPv6 addresses are the same for all IPv6 packets, even though the 
source and destination IPv4 addresses are different in the encapsulated 
IPv4 packets. One may experience two kind of problems:
- The loss of entropy due to using the same IPv6 addresses may have a 
negative impact on RSS (Receive-Side Scaling) of the B4 device.
- The "hidden" nature of the IPv4 addresses cases extra work for 
firewalls (if they need to check the header of the encapsulated IPv4 
packets).

Our proposed change is:

OLD:

    Single and double translation results in native IPv6 traffic with a
    layer-4 next-header.  The fields in these headers can be used for
    functions such as hashing across equal-cost multipaths or ACLs.  For
    encapsulation, there is an IPv6 header followed by an IPv4 header.
    This results in less entropy for hashing algorithms, and may mean
    that devices in the traffic path that perform header inspection (e.g.
    router ACLs or firewalls) require the functionality to look into the
    payload header.

NEW:

    Single and double translation results in native IPv6 traffic with a
    layer-4 next-header.  The fields in these headers can be used for
    functions such as hashing across equal-cost multipaths or access
    control list (ACL) filtering.  Encapsulation technologies, in
    contrast, may hinder hashing algorithms or other functions relying on
    header inspection.


> ** Section 3.4.
>     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.
>
> These text starts of with “often it is assumed” – who makes that assumption?
> What is the basis of this model and where does the assumption about the number
> of devices comes from?  Is there a reference that can be provided?

We propose the following new text:

    According to [MIY2010], each user-device (computer, tablet,
    smartphone) behind a NAT, could simultaneously use up to 300 ports.
    In the case of a residential subscriber, there will be typically a
    maximum of 4 of those devices in use simultaneously, which means a
    total of 1,200 ports.

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

As for 1200, please see above and 2048 is the lowest higher than that 
power of 2.
> ** Section 4.4.1.  Can anything be said about commercial implementations of the
> “operator side functionality”?

We renamed the section to "Vendor Support".

4.4.1.  Vendor Support

    In general, router vendors support AFTR, MAP-E/T BR and NAT64.  Load
    balancer and firewall vendors usually support NAT64 as well, while
    not all of them have support for the other protocols.


> ** Section 4.4.1
>
> ...but at the
>     time of writing is not available in MacOS.
>
> To ensure this assessment ages well and future readers don’t have to check the
> publication date of the RFC against MacOS version numbers, consider adding a
> MacOS version number.

New text:

    A 464XLAT client (CLAT) is implemented in Windows 10, Linux
    (including Android), Windows Mobile, Chrome OS and iOS, but it is not
    available in MacOS 12.3.1.

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

Unfortunately, we are not aware of any good public reference for the 
trends, but it is a well-known status, and it has been discussed even in 
v6ops several times.

We would be thankful, if anyone could point out a good reference!

> ** 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?
4.5.2 comes originally form T-Mobile real data exposed by Cameron in 
v6ops, but it coincides with private data that Jordi has from customers.

4.5.3. It comes from real data, but not public.

We appended the following paragraph at the end of Seciotn 4.5.3:

    This data is consistent with non-public information of actual
    deployments, which can be easily explained.  When a wireline ISP has
    mainly residential customers, content providers and CDNs which are
    already IPv6 enabled (Google/Youtube, Netflix, Facebook, Akamai, etc)
    typically account for the 65-85% of the traffic in the network, so
    when the subscribers are IPv6 enabled, about the same figures of
    traffic will become IPv6.


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

Yes, this section is a stub. The performance analysis of the most 
important free software implementation of the IPv4aaS technologies is in 
progress, but it would need about 2-3 more years, and we decided not to 
wait for such a long time, but rather publish the current draft as an 
RFC to assist the operators with a stable document.

However, I still believe that performance can be an important issue. As 
a illustration, perhaps very few people are aware of the fact that the 
de facto industry standard BIND DNS server is lagging behind the 
performance of Knot DNS or NSD. They 10 times outperfomed BIND in 
authoritative DNS performance, when really LARGE zone files were used:

G. Lencse, "Benchmarking Authoritative DNS Servers", /IEEE Access/, vol. 
8. pp. 130224-130238, July 2020. DOI: 10.1109/ACCESS.2020.3009141
https://ieeexplore.ieee.org/document/9139929 (open access)

Similar differences may exist in the performance of the IPv4aaS 
implementations. And performance may be a decision factor. So I would 
like to make people aware of this issue now and give the readers a 
pointer for the measurement results to be published later.

Unfortunately, draft-lencse-v6ops-transition-benchmarking has been 
expired, because I did not have time to deal with it, but I hope to be 
able to publish the 01 version with some actual results in a few weeks.


> ** Section 8.  Please state that the implementers of any of the fives IPv4aaS
> should consult the Security Considerations of the respective RFCs documenting
> them.
Thank you for suggesting that. We wrote as the last paragraph of Section 8:

    The implementers of any of the five IPv4aaS solutions should consult
    the Security Considerations of the respective RFCs documenting them.



> Editorial
>
> ** idnits returned:
>
>    == Unused Reference: 'RFC2119' is defined on line 1070, but no explicit
>       reference was found in the text
>
>    == Unused Reference: 'RFC8174' is defined on line 1220, but no explicit
>       reference was found in the text
We have removed them.

> ** Section 2.1. Editorial
>
> OLD
>   In general, state close to the end-user network (i.e. at the CE -
>     Customer Edge router) is not perceived as problematic as state in the
>     operators network.
>
> NEW
> In general, keeping state in devices close to the end-user network (i.e. at the
> CE - Customer Edge router) is not perceived as problematic as keeping state in
> the operator’s network.

Replaced.

> ** Section 3.4.  Please expand or cite “EAMT entries”.
We expanded as:

EAMT (Explicit Address Mappings Table) entries

>
> ** Section 3.4.  Please expand AJAX.

We expanded as:

AJAX (Asynchronous JavaScript and XML)



> ** Section 3.  Table 2.  Please provide a reference for TR-069.
>

We added the reference:

TR-069 [TR-069]



    [TR-069]   BroadBand Forum, "TR-069: CPE WAN Management Protocol",
               June 2020,<https://www.broadband- forum.org/technical/download/TR-069.pdf>.

Once again, thank you for your review and suggestions!

Best regards,

Gábor Lencse

>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>