Subject: [v6ops] AD Review of draft-ietf-v6ops-transition-comparison

From: Warren Kumari <[email-masked]>
Date: Tue, 1 Feb 2022 19:17:20 -0500

Firstly, thank you very much to the authors and WG for writing this, and
apologies for the delay in reviewing it -- I did the review, but then
forgot to transfer my notes.
I think that it is a very useful document; there are many different
transition technologies to choose from, and it can be really intimidating
for an operator to have to choose which one(s) to deploy.

I do have a number of concerns that I’d like to see addressed before moving
this forward. Many / most of them will be really easy to address, and
getting them done before IETF LC and IESG will make the whole process go
much smoother (and should result in less drama :-) )

Questions / comments / issues:

Section 2.1:
1: “464XLAT is a single/dual translation model, …” - please explain what a
“single” vs “dual” translation model *is*. This is a bit of a common theme
throughout the document - you are using terms which are well known within
the V6 operator world, but your audience is not really IPv6 experts…

2: “Note that we generally do not see state close to the end-user as
equally problematic as state in the middle of the network.”
- Who is this “we” of which you speak? (The authors? The IETF? Operators?)

3: “In this case, the IPv6-only client sends out IPv6 packets, thus CLAT
functions as an IPv6 router and the PLAT performs a stateful NAT64 for
these packets.”
The “thus” is confusing. Perhaps “and”?

4: “Alternatively, one can say that the DNS64 + stateful NAT64 is used to …”
The “the” seems superfluous -> “Alternatively, one can say that DNS64 +
stateful NAT64 is used to …”

Section 2.2:
1: “The AFTR performs encapsulation/decapsulation of the 4in6 traffic and
translates the IPv4 payload to public IPv4 source address using a stateful
NAPT44 function.“
What is “4in6” and “NAPT44”? (yeah, obviously I know, but please add
references / an explanation)

Section 2.3:
1: “... of provisioning each lwB4 with a unique tuple of IPv4 address
unique range of layer-4 ports.“
Unable to parse. I think you are missing “and a” between “address” and
“unique”.

2: “Direct communication between two lwB4s is performed by hair-pinning
traffic through the lwAFTR.”
Very minor issue, but it’s a little hard to figure out what is meant by
“Direct” - if it hairpins through something else, then it feels like it
isn't really “direct” any more. I don’t have any useful suggestions to
offer though (unless you say things about “on the same network” or “that
don’t need translation” or something, but that feels messy)

Section 2.4:
1: “MAP-E uses a stateless algorithm to embed portions of the customer's
allocated IPv4 address (or part of an address with A+P routing) into the
IPv6 prefix delegated to the client.”
Ok, fine, but in Section 2.1 you say “IPv4-embedded IPv6 addresses
[RFC6052] are used for both source and destination addresses.” - how is
this different?

2: “The CE (Customer-Edge) router typically performs stateful
NAPT44[RFC2663] to translate the private IPv4 source addresses and source
ports into an address and port range defined by applying the MAP rule
applied to the delegated IPv6 prefix.”
Too many “applies” (“applying the MAP rule applied”) - perhaps just drop
the second?

Sec 2.5:
1:”A MAP CE typically performs stateful NAPT44 to translate traffic …“
Please expand “CE”. Actually, while writing this I tried to find a good
expansion – the RFC Editor list has “Customer Edge”, but you first use CE
on page 5 ("customer’s CE router”), so perhaps just fix it there and drop
the first “customer’s”?

Sec 3.1:
1: General note: This entire section (“High-level architectures and their
Consequences”) seems to me to do a much better job of explaining what the
document is all about, explains 464 and 6-in4, etc. I’d strongly suggest
moving at least 3.1, 3.2 and 3.3 before Section 2. I realize that this is a
fair bit of work / shuffling, but I’m also fairly sure that someone will
raise it during LC / IESG eval, so probably worth doing now…

Sec 3.4:
1: “ From the 65,535 ports available per IPv4 address, we could even
consider reserving 1,024 ports, in order to allow customers that need EAMT
entries for incoming connections to well-known ports, …“
Please try to find a reference for “well-known ports”. I figured that the
IANA port list would work (
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml),
but it actually calls them “system ports” (“Port numbers are assigned in
various ways, based on three ranges: System Ports (0-1023), …” Maybe just
change to “system ports” instead?

2: “ Further to that, the NAT46 in the CLAT will actually hide the
subscriber LANs port usage …”
“Further to that, “ feels like a fragment, largely because it is a new
paragraph / does not follow on from the previous paragraph. Perhaps just
drop it.

Sec 4.4.1:
1: “For the operator side functionality, some free open-source
implementations exist:”
This will not age well. Perhaps add something about “At the time of
publication…”

Sec 4.4.2:
1: “ Several cellular networks use 464XLAT, whereas we are not aware of any
deployment of the four other technologies …”
Again, who is this “we”?

Section 8:
1: “For all five technologies, the CE device should contain a DNS proxy.”
Erm. I’m quite uncomfortable with this being suggested here. I’d think that
a recommendation like this would need some much wider discussion. I suspect
that many DNS operators would seriously disagree with a suggestion like
this. I suggest you remove it. Even if most CPE *do* include a proxy,
having it recommended in an RFC is another matter entirely.

Please shout LOUDLY once you've had a change to address these, or with any
questions, etc.
W

---

From: Gábor LENCSE <[email-masked]>
Date: Wed, 9 Feb 2022 20:30:27 +0100

Dear Warren,

Thank you very much for your review!

First, I would like to check, if you agree with our responses, so I did 
not submit the revised version yet, but I give a detailed answer about 
each of your comments, how we addressed it.

(However, if you think, that it would be easier for you to check the 
changes using the "diff", I have the modified XML file ready, and I can 
upload in it a few minutes. I just did not want to publish a version, 
which may need to be replaced in a few days.)

2/2/2022 1:17 AM keltezéssel, Warren Kumari írta:
> Firstly, thank you very much to the authors and WG for writing this, 
> and apologies for the delay in reviewing it -- I did the review, but 
> then forgot to transfer my notes.
> transition technologies to choose from, and it can be really 
> intimidating for an operator to have to choose which one(s) to deploy.
>
> I do have a number of concerns that I’d like to see addressed before 
> moving this forward. Many / most of them will be really easy to 
> address, and getting them done before IETF LC and IESG will make the 
> whole process go much smoother (and should result in less drama :-) )
>
> 1: “464XLAT is a single/dual translation model, …” - please explain 
> what a “single” vs “dual” translation model *is*. This is a bit of a 
> common theme throughout the document - you are using terms which are 
> well known within the V6 operator world, but your audience is not 
> really IPv6 experts…

OLD:

    464XLAT is a single/dual translation model, which uses a customer-
    side translator (CLAT) located in the customer's device to perform
    stateless NAT64 translation [RFC7915] (more precisely, stateless
    NAT46, a stateless IP/ICMP translation from IPv4 to IPv6).

NEW:

    464XLAT may use double translation (stateless NAT46 + stateful NAT64)
    or single translation (stateful NAT64), depending on different
    factors, such as the use of DNS by the applications and the
    availability of a DNS64 function (in the host or in the service
    provider network).

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

> - Who is this “we” of which you speak? (The authors? The IETF? Operators?)

OLD:

    Note that we generally do not see state close to the end-user as
    equally problematic as state in the middle of the network.

  NEW:

    In general, state close to the end-user network (i.e. at the CE) is
    not perceived as problematic as state in the operators network.

What do you think of it?

We wrote it in that way, as we (the authors) believe that it is not only 
our view, but a kind of general belief. But if you would like the 
authors to take the responsibility, I am ready to write that:

    The authors generally do not see state close to the end-user as
    equally problematic as state in the middle of the network.

>
> 3: “In this case, the IPv6-only client sends out IPv6 packets, thus 
> CLAT functions as an IPv6 router and the PLAT performs a stateful 
> NAT64 for these packets.”

OLD:

    thus CLAT functions

NEW:

    and the CLAT functions

> The “the” seems superfluous -> “Alternatively, one can say that DNS64 
> + stateful NAT64 is used to …”

Corrected.

> Section 2.2:
> 1: “The AFTR performs encapsulation/decapsulation of the 4in6 traffic 
> and translates the IPv4 payload to public IPv4 source address using a 
> stateful NAPT44 function.“

We added the references as:

OLD:

    Router' (AFTR).  The AFTR performs encapsulation/decapsulation of the
    4in6 traffic and translates the IPv4 payload to public IPv4 source
    address using a stateful NAPT44 function.

NEW:

    Router' (AFTR).  The AFTR performs encapsulation/decapsulation of the
    4in6 [RFC2473] traffic and translates the IPv4 payload to public IPv4
    source address using a stateful NAPT44 [RFC2663] function.

> Unable to parse. I think you are missing “and a” between “address” and 

Corrected.

>
> 2: “Direct communication between two lwB4s is performed by 
> hair-pinning traffic through the lwAFTR.”
> Very minor issue, but it’s a little hard to figure out what is meant 
> by “Direct” - if it hairpins through something else, then it feels 
> like it isn't really “direct” any more. I don’t have any useful 
> suggestions to offer though (unless you say things about “on the same 
> network” or “that don’t need translation” or something, but that feels 
> messy)

We suggest the following:

OLD:

    Direct communication between two lwB4s is performed by hair-pinning
    traffic through the lwAFTR.

NEW:

    Direct communication (that is, without translation) between two lwB4s
    is performed by hair-pinning traffic through the lwAFTR.

What do you think about it?

> Section 2.4:
> 1: “MAP-E uses a stateless algorithm to embed portions of the 
> customer's allocated IPv4 address (or part of an address with A+P 
> routing) into the IPv6 prefix delegated to the client.”
> [RFC6052] are used for both source and destination addresses.” - how 
> is this different?

464XLAT (discussed in Section 2.1) uses [RFC6052] IPv4-embedded IPv6 
addresses. They are very easy to construct: we simply append the 32 bits 
of an IPv4 address to the proper IPv6 prefix.

The MAP protocols (MAP-E and MAP-T) also use [RFC6052] IPv4-embedded 
IPv6 addresses to represent IPv4 hosts outside the MAP domain. (E.g. the 
address of an IPv4 only server.)

However, the so called /MAP addresses/ (IPv6 addresses referring to IPv4 
hosts in the MAP domain) are MUCH-MUCH more complicated to construct.  
Please see Section 5 of RFC 7597.

An illustrated and (IMHO) easy to follow explanation can be found here: 
https://www.jool.mx/en/run-mapt.html

I am not sure, how much we should talk about it. Or if we should do it 
at all.

> NAPT44[RFC2663] to translate the private IPv4 source addresses and 
> source ports into an address and port range defined by applying the 
> MAP rule applied to the delegated IPv6 prefix.”
> Too many “applies” (“applying the MAP rule applied”) - perhaps just 
> drop the second?

Done. :-)

OLD:

    ports into an address and port range defined by applying the MAP rule
    applied to the delegated IPv6 prefix.  The client address/port

NEW:

    ports into an address and port range defined by applying the MAP rule
    to the delegated IPv6 prefix.  The client address/port allocation

> Please expand “CE”. Actually, while writing this I tried to find a 
> good expansion – the RFC Editor list has “Customer Edge”, but you 
> first use CE on page 5 ("customer’s CE router”), so perhaps just fix 
> it there and drop the first “customer’s”?

In Section 2.4, CE has already been expanded as: "The CE (Customer-Edge) 
router". (We intended to expand abbreviation only the first time they 
are used.)

Do you think that people do not read the document sequentially, but 
rather use it as a "handbook", I mean just looking up different parts in 
random order?

Now I have made the following change:

OLD:

    A MAP CE typically performs stateful NAPT44 to translate traffic to a
    public IPv4 address and port-range calculated by applying the

NEW:

    The CE (Customer-Edge) router typically performs stateful NAPT44
    [RFC2663] to translate traffic to a public IPv4 address and port-

>
> Sec 3.1:
> 1: General note: This entire section (“High-level architectures and 
> their Consequences”) seems to me to do a much better job of explaining 
> what the document is all about, explains 464 and 6-in4, etc. I’d 
> strongly suggest moving at least 3.1, 3.2 and 3.3 before Section 2. I 
> realize that this is a fair bit of work / shuffling, but I’m also 
> fairly sure that someone will raise it during LC / IESG eval, so 
> probably worth doing now…

I believe that some of our readers are not familiar with the five 
IPv4aaS technologies, and thus they would not understand Sections 3.1 to 
3.3 without a short introduction to them in Section 2. Originally, 
current Section 2 ("Overview of the Technologies") was not a part of our 
draft, and it was added to fill this gap.

> consider reserving 1,024 ports, in order to allow customers that need 
> EAMT entries for incoming connections to well-known ports, …“
> Please try to find a reference for “well-known ports”. I figured that 
> the IANA port list would work 
> (https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml), 
> but it actually calls them “system ports” (“Port numbers are assigned 
> in various ways, based on three ranges: System Ports (0-1023), …” 
> Maybe just change to “system ports” instead?

OLD:

    EAMT entries for incoming connections to well-known ports, which
    means 64,511 ports actually available per each IPv4 address.

NEW:

    EAMT entries for incoming connections to System Ports (0-1023, also
    called well-known ports) [RFC7605], which means 64,511 ports actually
    available per each IPv4 address.

> paragraph / does not follow on from the previous paragraph. Perhaps 
> just drop it.

OLD:

    Further to that, the NAT46 in the CLAT will actually hide the
    subscriber LANs port usage and only that will be the limiting factor.
    So even subscribers with higher demands of ports, will not make a big
    difference.

NEW:

    The NAT46 in the CLAT will actually hide the subscriber LANs port
    usage and only that will be the limiting factor.  So even subscribers
    with higher demands of ports, will not make a big difference.

But I think some further corrections may be necessary, as the NAT46 in 
the CLAT is a stateless NAT46. It does NOT touch the port numbers, thus 
it may not hide the subscriber LANs port usage.

Of course, the CLAT device (as a home router) may well do stateful NAT44 
(also called NAPT44), but then this sentence should be further clarified...

> This will not age well. Perhaps add something about “At the time of 

OLD:

    For the operator side functionality, some free open-source
    implementations exist:

NEW:

    At the time of publication some free open-source implementations
    exist for the operator side functionality:

In addition to that, one of my BSc students did measurements with the 
Jool implementation of MAP-T. So I know it for sure, that Jool 4.2 has a 
working MAP-T implementation.

So I made the following change:

OLD:

    CLAT, NAT64, EAMT:http://www.jool.mx

NEW:

    CLAT, NAT64, EAMT, MAP-T CE, MAP-T BR:http://www.jool.mx

> Sec 4.4.2:
> 1: “ Several cellular networks use 464XLAT, whereas we are not aware 
> of any deployment of the four other technologies …”
> Again, who is this “we”?

OLD:

    Several cellular networks use 464XLAT, whereas we are not aware of
    any deployment of the four other technologies in cellular networks,
    as they are not standardised neither implemented in UE devices.

NEW:

    Several cellular networks use 464XLAT, whereas there are no
    deployments of the four other technologies in cellular networks, as
    they are not standardised neither implemented in UE devices.

> Erm. I’m quite uncomfortable with this being suggested here. I’d think 
> that a recommendation like this would need some much wider discussion. 
> I suspect that many DNS operators would seriously disagree with a 
> suggestion like this. I suggest you remove it. Even if most CPE *do* 
> include a proxy, having it recommended in an RFC is another matter 
> entirely.

OLD:

    For all five technologies, the CE device should contain a DNS proxy.

NEW:

    For all five technologies, the CE device typically contains a DNS
    proxy.

>
> Please shout LOUDLY once you've had a change to address these, or with 
> any questions, etc.
> W

Please let us know, if you are satisfied with our corrections.

And, of course, we are happy to receive comments from any of the WG 
members, too.

Best regards,

Gábor

---

From: Warren Kumari <[email-masked]>
Date: Wed, 23 Feb 2022 18:18:52 -0500

Erk! Huge apologies to the authors; I've fallen behind on email and am
scrambling to catch up again...

On Wed, Feb 9, 2022 at 2:30 PM Gábor LENCSE <[email-masked]> wrote:

> not submit the revised version yet, but I give a detailed answer about each
> of your comments, how we addressed it.
>
> upload in it a few minutes. I just did not want to publish a version, which
> may need to be replaced in a few days.)
>
>
> moving this forward. Many / most of them will be really easy to address,
> and getting them done before IETF LC and IESG will make the whole process
> go much smoother (and should result in less drama :-) )
>
WFM! Thanks!

>    not perceived as problematic as state in the operators network.

That still doesn't really answer *who* doesn't perceive it as problematic,
but I think that this is much better than the original, and is probably
fine / understandable from context.
I think let's leave it like this and see if anyone fusses...

> our view, but a kind of general belief. But if you would like the authors
> to take the responsibility, I am ready to write that:
>
Great, thanks.

> stateful NAT64 is used to …”

Thanks!

>    source address using a stateful NAPT44 [RFC2663] function.
Thanks!

> Unable to parse. I think you are missing “and a” between “address” and

Thanks!

> What do you think about it?

Great! Thanks!

> addresses. They are very easy to construct: we simply append the 32 bits of
> an IPv4 address to the proper IPv6 prefix.
>
> The MAP protocols (MAP-E and MAP-T) also use [RFC6052] IPv4-embedded IPv6
> addresses to represent IPv4 hosts outside the MAP domain. (E.g. the address
> of an IPv4 only server.)
>
> However, the so called *MAP addresses* (IPv6 addresses referring to IPv4
> I am not sure, how much we should talk about it. Or if we should do it at
> all.
>

Would:
Section 2.4:
"Like 464XLAT (Sec 2.1), MAP-E and MAP-T use [RFC6052] IPv4-embedded IPv6
addresses. MAP-E uses a stateless algorithm to embed portions of the
customer's allocated IPv4 address (or part of an address with A+P routing)
into the IPv6 prefix delegated to the client."
work?

>    to the delegated IPv6 prefix.  The client address/port allocation
Yay! Thanks!

> router". (We intended to expand abbreviation only the first time they are
> used.)
>
> Do you think that people do not read the document sequentially, but rather
> use it as a "handbook", I mean just looking up different parts in random
> order?
>
>
Nah, I probably just missed the initial expansion, sorry.

>    [RFC2663] to translate traffic to a public IPv4 address and port-
Fine to leave it expanded this second time, or revert, whichever you prefer.

> I believe that some of our readers are not familiar with the five IPv4aaS
> technologies, and thus they would not understand Sections 3.1 to 3.3
> without a short introduction to them in Section 2. Originally, current
> Section 2 ("Overview of the Technologies") was not a part of our draft, and
> it was added to fill this gap.
>

Okey dokey. I still think it would be more readable with the overview
(High-level Architectures) first, and then the dive into the IPv4aaS
technologies, but it's just my opinion, fine to leave as is...

>    available per each IPv4 address.
Thanks!

> But I think some further corrections may be necessary, as the NAT46 in the
> CLAT is a stateless NAT46. It does NOT touch the port numbers, thus it may
> not hide the subscriber LANs port usage.
>

Perhaps:
"The NAT46 function in the CLAT hides the subscriber LANs port usage and so
subscribers with high port usage will not make a significant difference."
or
"The NAT46 function in the CLAT hides the subscribers port usage and so,
even if they do use a large number of ports, this will have no effect" ?

Otherwise let's just stick with the original and see what happens?

> In addition to that, one of my BSc students did measurements with the Jool
> implementation of MAP-T. So I know it for sure, that Jool 4.2 has a working
> MAP-T implementation.
>
>    CLAT, NAT64, EAMT:  http://www.jool.mx
>
> NEW:
>
>    CLAT, NAT64, EAMT, MAP-T CE, MAP-T BR:  http://www.jool.mx
>
>
>
Sweet!

> Sec 4.4.2:
> 1: “ Several cellular networks use 464XLAT, whereas we are not aware of
> any deployment of the four other technologies …”
> Again, who is this “we”?
>
>
> OLD:
>
Thanks!

> that a recommendation like this would need some much wider discussion. I
> suspect that many DNS operators would seriously disagree with a suggestion
> like this. I suggest you remove it. Even if most CPE *do* include a proxy,
Perfect, thanks.

> And, of course, we are happy to receive comments from any of the WG

Thank you very much for addressing my comments, and apologies again for the
delay in replying.
W

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra

---

From: Gábor LENCSE <[email-masked]>
Date: Thu, 24 Feb 2022 11:50:09 +0100

Dear Warren,

Thank you very much for your answer and for your careful review of our 
replies!

Now, I keep only those parts needed a reaction from our side.

>>     2: “Note that we generally do not see state close to the end-user
>>     as equally problematic as state in the middle of the network.”
> That still doesn't really answer *who* doesn't perceive it as 
> problematic, but I think that this is much better than the original, 
> and is probably fine / understandable from context.

OK, let us leave it so.

If later needed, I am ready to change it as below (we=authors):

>
>     We wrote it in that way, as we (the authors) believe that it is
>     not only our view, but a kind of general belief. But if you would
>     like the authors to take the responsibility, I am ready to write that:
>

>>     Ok, fine, but in Section 2.1 you say “IPv4-embedded IPv6
>>     addresses [RFC6052] are used for both source and destination
>>     addresses.” - how is this different?
>
>     464XLAT (discussed in Section 2.1) uses [RFC6052] IPv4-embedded
>     IPv6 addresses. They are very easy to construct: we simply append
>     the 32 bits of an IPv4 address to the proper IPv6 prefix.
>
>     The MAP protocols (MAP-E and MAP-T) also use [RFC6052]
>     IPv4-embedded IPv6 addresses to represent IPv4 hosts outside the
>     MAP domain. (E.g. the address of an IPv4 only server.)
>
>     However, the so called /MAP addresses/ (IPv6 addresses referring
>     to IPv4 hosts in the MAP domain) are MUCH-MUCH more complicated to
>     construct.  Please see Section 5 of RFC 7597.
>
>     An illustrated and (IMHO) easy to follow explanation can be found
>     here: https://www.jool.mx/en/run-mapt.html
>
>     I am not sure, how much we should talk about it. Or if we should
>     do it at all.
>
>
>
> Would:
> Section 2.4:
> "Like 464XLAT (Sec 2.1), MAP-E and MAP-T use [RFC6052] IPv4-embedded 
> IPv6 addresses. MAP-E uses a stateless algorithm to embed portions of 
> the customer's allocated IPv4 address (or part of an address with A+P 
> routing) into the IPv6 prefix delegated to the client."
> work?

IMHO, this statement is not exact, as it would suggest that MAP-T uses 
only [RFC6052] IPv4-embedded IPv6 addresses, what is not true.

What do you think of the following?

"Like 464XLAT (Sec 2.1), MAP-E and MAP-T use [RFC6052] IPv4-embedded 
IPv6 addresses _to represent IPv4 hosts outside the MAP domain_. MAP-E 
_and MAP-T use_ a stateless algorithm to embed portions of the 
customer's allocated IPv4 address (or part of an address with A+P 
routing) into the IPv6 prefix delegated to the client."

>>     Please expand “CE”. Actually, while writing this I tried to find
>>     a good expansion – the RFC Editor list has “Customer Edge”, but
>>     you first use CE on page 5 ("customer’s CE router”), so perhaps
>>     just fix it there and drop the first “customer’s”?
>
>     In Section 2.4, CE has already been expanded as: "The CE
>     (Customer-Edge) router". (We intended to expand abbreviation only
>     the first time they are used.)
>
>     Do you think that people do not read the document sequentially,
>     but rather use it as a "handbook", I mean just looking up
>     different parts in random order?
>
>

OK. :-)
> Fine to leave it expanded this second time, or revert, whichever you 

OK, then I reverted it. (Leaving it would suggest that Section 2.5. can 
be used as a standalone text. However, Section 2.5 relies on Section 2.4 
in other things, too.)

>>
>>     Sec 3.1:
>>     1: General note: This entire section (“High-level architectures
>>     and their Consequences”) seems to me to do a much better job of
>>     explaining what the document is all about, explains 464 and
>>     6-in4, etc. I’d strongly suggest moving at least 3.1, 3.2 and 3.3
>>     before Section 2. I realize that this is a fair bit of work /
>>     shuffling, but I’m also fairly sure that someone will raise it
>>     during LC / IESG eval, so probably worth doing now…
>
>     IPv4aaS technologies, and thus they would not understand Sections
>     3.1 to 3.3 without a short introduction to them in Section 2.
>     Originally, current Section 2 ("Overview of the Technologies") was
>     not a part of our draft, and it was added to fill this gap.
>
>

OK. :-)

>>     2: “ Further to that, the NAT46 in the CLAT will actually hide
>>     the subscriber LANs port usage …”
>>     “Further to that, “ feels like a fragment, largely because it is
>>     a new paragraph / does not follow on from the previous paragraph.
>>     Perhaps just drop it.
>
>     OLD:
>
>     But I think some further corrections may be necessary, as the
>     NAT46 in the CLAT is a stateless NAT46. It does NOT touch the port
>     numbers, thus it may not hide the subscriber LANs port usage.
>
>
> Perhaps:
> "The NAT46 function in the CLAT hides the subscriber LANs port usage 
> and so subscribers with high port usage will not make a significant 
> difference."
> or
> "The NAT46 function in the CLAT hides the subscribers port usage and 
> so, even if they do use a large number of ports, this will have no 
> effect" ?
>
>     Of course, the CLAT device (as a home router) may well do stateful
>     NAT44 (also called NAPT44), but then this sentence should be
>     further clarified...
>

I would rather delete the entire paragraph, because I think it to be 
misleading.

What do you think of it?

Best regards,

Gábor

---

From: Gábor LENCSE <[email-masked]>
Date: Thu, 24 Feb 2022 13:47:24 +0100

Dear Håvard,

I have corrected it in the XML file. (You will see it in the next version.)

Thank you!

Best regards,

Gábor

2/24/2022 10:32 AM keltezéssel, Havard Eidnes írta:
> [ elided [email-masked], this is a minor language tweak ]
>
>
>>> Sec 4.4.2:
> [...] "are neither standardised nor implemented in UE devices."
>
> Regards,
>
> - Håvard
>