Subject: [v6ops] I-D Action: draft-ietf-v6ops-transition-comparison-00.txt

From: [email-masked]
Date: Thu, 15 Apr 2021 13:15:40 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations WG of the IETF.

        Title           : Pros and Cons of IPv6 Transition Technologies for IPv4aaS
        Authors         : Gabor Lencse
                          Jordi Palet Martinez
                          Lee Howard
                          Richard Patterson
                          Ian Farrer
	Filename        : draft-ietf-v6ops-transition-comparison-00.txt
	Pages           : 30
	Date            : 2021-04-15

Abstract:
   Several IPv6 transition technologies have been developed to provide
   customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only
   access and/or core network.  All these technologies have their
   advantages and disadvantages, and depending on existing topology,
   skills, strategy and other preferences, one of these technologies may
   be the most appropriate solution for a network operator.

   This document examines the five most prominent IPv4aaS technologies
   considering a number of different aspects to provide network
   operators with an easy to use reference to assist in selecting the
   technology that best suits their needs.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-comparison/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-v6ops-transition-comparison-00
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-comparison-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 16 Apr 2021 12:02:05 +0000

Hi all,
iOS does not support 464XLAT/CLAT.
They do use RFC 6535 (Bump in the host) instead.
It is probably an important fact for 4.4.2

I am not sure that it is needed here. But there is the story of how to initiate a NAT connection in the opposite direction.
PCP (RFC 7225, RFC 6887), STUN (RFC 5389), EAM (RFC 7757), public IP allocation on CGNAT.
Different translation technologies have different compatibility and different tools for how to punch a hole in the opposite direction.
Some FBBs have a real shortage of public IPv4 to play with this.

It is a little strange that PCP (RFC 7225) has not been mentioned at all.

Eduard
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, April 15, 2021 11:16 PM
To: [email-masked]
Cc: [email-masked]
Subject: [v6ops] I-D Action: draft-ietf-v6ops-transition-comparison-00.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 16 Apr 2021 14:20:18 +0200

Hi Eduard,

I think I can provide some light on this.

iOS was not supporting CLAT since a few years ago, which was a problem for using 464XLAT in tethering, but this is no longer true. Thanks to the push from several operators Apple finally implemented CLAT, which is only needed for the tethering, because the "similar" solution to bump-in-the-host resolve the problem for the apps in the iOS device. Further to that, this is supported because Apple took a very good decision long time ago (2016 I believe), to only allow in the AppStore apps that work in IPv6-only, so that's why the CLAT is not need for the iOS device itself.

Having no need for the CLAT to be enabled means lower battery consumption, and of course, lower CPU cost and delay if the other end is also using IPv6, so not NAT at all.

We have indeed some mentions about PCP and EAM in the text, not sure what you will like to see in the document. Could you please elaborate a bit more? An specific section about that or?

Regards,
Jordi
@jordipalet

El 16/4/21 14:03, "v6ops en nombre de Vasilenko Eduard" <[email-masked] en nombre de [email-masked]> escribió:

    Hi all,

    Eduard
    -----Original Message-----
    From: v6ops [mailto:[email-masked]] On Behalf Of [email-masked]
    Sent: Thursday, April 15, 2021 11:16 PM
    To: [email-masked]
    Cc: [email-masked]
    Subject: [v6ops] I-D Action: draft-ietf-v6ops-transition-comparison-00.txt

    Abstract:

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 16 Apr 2021 13:05:09 +0000

Hi Jordi,
You did bring the news about iOS that is a big secret for the community. What is the iOS version that supports CLAT?
Then it is mandatory to include such important information in the draft.

I am not so interested in any specific protocol. We have too many.
I am interested in the use case: "to initiate a connection from the outside to an IPv4 server that is behind translation solution".
We could assume that port forwarding on the CPE subscriber could provision himself (probably port 80). But the CPE should receive incoming TCP session from the internet.
It would probably bring onto the discussion PCP (for some translation technologies), but if not - I would not be much disappointed.
By the way, you could dispute the use case then the question is closed.
I now carriers where all subscribers do receive public IPv4 even now.
But I know Carriers that have a shortage of public IPv4 for CGNAT pools.
Of course, you could send them to buy IPv4 on the open market because NAT connection initiated in opposite direction is additional complexity.
You choose.

Eduard
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
Sent: Friday, April 16, 2021 3:20 PM
To: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-comparison-00.txt

Hi Eduard,

Regards,
Jordi
@jordipalet

    Hi all,

    Eduard
    -----Original Message-----
    From: v6ops [mailto:[email-masked]] On Behalf Of [email-masked]
    Sent: Thursday, April 15, 2021 11:16 PM
    To: [email-masked]
    Cc: [email-masked]
    Subject: [v6ops] I-D Action: draft-ietf-v6ops-transition-comparison-00.txt

    Abstract:

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 16 Apr 2021 15:31:51 +0200

Mmm ... I don't think it was a secret!

If you're working on actual deployments, you need to configure the features you want to enable in the carrier config files, and then Apple publish it. Pretty standard Apple procedure. Alternatively, you can also use the Apple Mobile Configurator, for earlier testing, etc.

Many operators have been using this for about 3 years already. I don't recall right now the iOS version number but was 2017-2018. I believe I've mention this already other times in v6ops.

Because that happened several years ago, I don't think it should be necessary to include what OS versions, not just for Apple, for any OS, however I'm happy to have it if the WG believes so.

I got now your point about incoming connections examples/behavior. We will have some text in the next version.

I believe most of the carriers that use CGN, don't allow incoming connection. If you need that, you pay an alternative service and then you get a "persistent" IPv4.

The problem of CGN is still that if you have Sony PlayStation gamers, the IPv4 addresses in the CGN get into the blacklist forever, so you need to rotate all the IPv4 addresses in the CGNs, until you finish them. Then you go to the market and pay for more transfers, etc. Clearly it doesn't make sense. It is smarter to not install CGNs and instead directly pay for the transfers now, before price keeps going up.

Regards,
Jordi
@jordipalet

El 16/4/21 15:05, "v6ops en nombre de Vasilenko Eduard" <[email-masked] en nombre de [email-masked]> escribió:

    Hi Jordi,

    Eduard
    -----Original Message-----
    From: v6ops [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
    Sent: Friday, April 16, 2021 3:20 PM
    To: [email-masked]
    Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-comparison-00.txt

    Hi Eduard,

    Regards,
    Jordi
    @jordipalet

        Hi all,

        Eduard
        -----Original Message-----
        From: v6ops [mailto:[email-masked]] On Behalf Of [email-masked]
        Sent: Thursday, April 15, 2021 11:16 PM
        To: [email-masked]
        Cc: [email-masked]
        Subject: [v6ops] I-D Action: draft-ietf-v6ops-transition-comparison-00.txt

        Abstract:

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 16 Apr 2021 16:40:47 +0000

I did try to instigate iOS CLAT support 1y ago - I have found many evidences that iOS did not support it but RFC 6535 was a good replacement, not a big problem. Just interesting fact of partial 464XLAT compliance.

The probability of requirement from subscribers (and commercial department as a result) to give subs public IPv4 is very high.
The number of such subs is small but the headache for Carrier to organize it is big.
Different IPv4aaS have different difficulties to organize it.
It could be the deciding factor in the IPv4aaS type choice.
But you could omit it because not every Carrier needs this problem resolution.

Ed/
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
Sent: Friday, April 16, 2021 4:32 PM
To: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-comparison-00.txt

Regards,
Jordi
@jordipalet

    Hi Jordi,

    Eduard
    -----Original Message-----
    From: v6ops [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
    Sent: Friday, April 16, 2021 3:20 PM
    To: [email-masked]
    Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-comparison-00.txt

    Hi Eduard,

    Regards,
    Jordi
    @jordipalet

        Hi all,

        Eduard
        -----Original Message-----
        From: v6ops [mailto:[email-masked]] On Behalf Of [email-masked]
        Sent: Thursday, April 15, 2021 11:16 PM
        To: [email-masked]
        Cc: [email-masked]
        Subject: [v6ops] I-D Action: draft-ietf-v6ops-transition-comparison-00.txt

        Abstract:

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 16 Apr 2021 20:37:33 +0200

Hi Eduard,

In order to have the CLAT enabled, something needs to triggered it in the phone.

This usually is done because the operator profile tells that to the iOS, so if the operator doesn't enable that in the profile, which is *only* published by Apple, it will not work.

Alternatively, you can enable it manually, using an Apple application (Apple Configurator) in a Mac and getting that phone connected to it via USB. This is typically done when a phone is provided to employees (so for example, you configure some settings, such as VPNs, some apps, etc., etc.), but it can be used also for "trials" when you are deploying a 464XLAT small pilot in an operator.

As said, it is lessons learnt from actual customer projects.

Regards,
Jordi
@jordipalet

El 16/4/21 18:41, "v6ops en nombre de Vasilenko Eduard" <[email-masked] en nombre de [email-masked]> escribió:

    Ed/
    -----Original Message-----
    From: v6ops [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
    Sent: Friday, April 16, 2021 4:32 PM
    To: [email-masked]
    Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-comparison-00.txt

    Regards,
    Jordi
    @jordipalet

        Hi Jordi,

        Eduard
        -----Original Message-----
        From: v6ops [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
        Sent: Friday, April 16, 2021 3:20 PM
        To: [email-masked]
        Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-comparison-00.txt

        Hi Eduard,

        Regards,
        Jordi
        @jordipalet

            Hi all,

            Eduard
            -----Original Message-----

            Abstract:

---

From: "Chongfeng Xie" <[email-masked]>
Date: Mon, 19 Apr 2021 16:43:01 +0800

I don't think CLAT is only used for tethering,  it also be responsible for synthetisingIPv4 address into IPv6 address when the DNS query is not processed by DNS64 of the carrier network, for instance, the DNS service is provided via HTTPDNS by some other organzations, which is very popular in the current Internet.

Regards
Chongfeng

From: JORDI PALET MARTINEZ
Date: 2021-04-16 20:20
To: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-comparison-00.txt
Hi Eduard,

 

Regards,
Jordi
@jordipalet

    Hi all,

 
    Eduard
    -----Original Message-----
    From: v6ops [mailto:[email-masked]] On Behalf Of [email-masked]
    Sent: Thursday, April 15, 2021 11:16 PM
    To: [email-masked]
    Cc: [email-masked]
    Subject: [v6ops] I-D Action: draft-ietf-v6ops-transition-comparison-00.txt

 
    Abstract:

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 19 Apr 2021 10:56:52 +0200

Hi Chongfeng,

I’m not sure if you mean in the context of iOS or in general.

In iOS (and also other OSs started doing the same, according to what I understood from other vendors and testing that I’ve done myself), DNS64 synthesis is done by the OS or the apps.

If HEv2 (RFC8305) is implemented, this is described in section 7.1 & 7.2.

I’ve also described that in RFC8683, across many sections, also showing other possible solutions.

This resolves the problem of breaking DNSSEC which may happen in certain situations when the DNS64 is done by the operator.

Regards,

Jordi

@jordipalet

El 19/4/21 10:43, "v6ops en nombre de Chongfeng Xie" <[email-masked] en nombre de [email-masked]> escribió:

Regards

Chongfeng

Date: 2021-04-16 20:20

To: [email-masked]

Hi Eduard,

Regards,

Jordi

@jordipalet

    Hi all,

    Eduard

    -----Original Message-----

    Cc: [email-masked]

 

            Authors         : Gabor Lencse

                              Jordi Palet Martinez

                              Lee Howard

                              Richard Patterson

                              Ian Farrer

    Pages           : 30

    Date            : 2021-04-15

    Abstract:

 

 

 

    v6ops mailing list

    [email-masked]

    v6ops mailing list

    [email-masked]

 

IPv4 is over

The IPv6 Company

 

v6ops mailing list

[email-masked]

_______________________________________________ v6ops mailing list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops

---

From: Henri Alves de Godoy <[email-masked]>
Date: Mon, 19 Apr 2021 10:12:14 -0300

Hi Jordi,

Some comments contribute to the subject

Despite the advantages of not needing the CLAT, they are good, but this is
still a dream, it will take a long time to happen.

CLAT is still required to connect legacy devices. In addition, navigation
on devices that have only IPv6 on your device is not yet viable, as many
services will no longer be accessed.

I don't know what a 4G telecom scenario would be like, but on wireless
networks, where I've been working, I don't see a CLAT daemon on any OS
(Windows, iOS, Android) available. Convincing these manufacturers of the
need for a CLAT is an impossible task.

In my studies of the 464XLAT mechanism, I have inserted the CLAT into the
wireless network as an intermediate VM on the same network. So I don't need
CLAT on users' devices and mainly I don't need to intervene and guide in
any installation. The less you interact with users' devices the less
problems are.

Thanks
Henri

Em sex., 16 de abr. de 2021 às 15:38, JORDI PALET MARTINEZ <jordi.palet=
[email-masked]> escreveu:

> This usually is done because the operator profile tells that to the iOS,
> so if the operator doesn't enable that in the profile, which is *only*
> published by Apple, it will not work.
>
> Alternatively, you can enable it manually, using an Apple application
> (Apple Configurator) in a Mac and getting that phone connected to it via
> USB. This is typically done when a phone is provided to employees (so for
> example, you configure some settings, such as VPNs, some apps, etc., etc.),
> but it can be used also for "trials" when you are deploying a 464XLAT small
> pilot in an operator.
>
> El 16/4/21 18:41, "v6ops en nombre de Vasilenko Eduard" <
> [email-masked] en nombre de [email-masked]> escribió:
>
>     I did try to instigate iOS CLAT support 1y ago - I have found many
> evidences that iOS did not support it but RFC 6535 was a good replacement,
> not a big problem. Just interesting fact of partial 464XLAT compliance.
>
>     The probability of requirement from subscribers (and commercial
> department as a result) to give subs public IPv4 is very high.
>     Subject: Re: [v6ops] I-D Action:
> draft-ietf-v6ops-transition-comparison-00.txt
>
>     If you're working on actual deployments, you need to configure the
> features you want to enable in the carrier config files, and then Apple
> publish it. Pretty standard Apple procedure. Alternatively, you can also
> use the Apple Mobile Configurator, for earlier testing, etc.
>
>     Many operators have been using this for about 3 years already. I don't
> recall right now the iOS version number but was 2017-2018. I believe I've
> mention this already other times in v6ops.
>
>     Because that happened several years ago, I don't think it should be
> necessary to include what OS versions, not just for Apple, for any OS,
> however I'm happy to have it if the WG believes so.
>
>     I believe most of the carriers that use CGN, don't allow incoming
> connection. If you need that, you pay an alternative service and then you
> get a "persistent" IPv4.
>
>     The problem of CGN is still that if you have Sony PlayStation gamers,
> the IPv4 addresses in the CGN get into the blacklist forever, so you need
> to rotate all the IPv4 addresses in the CGNs, until you finish them. Then
> you go to the market and pay for more transfers, etc. Clearly it doesn't
> make sense. It is smarter to not install CGNs and instead directly pay for
> the transfers now, before price keeps going up.
>
>
>     Regards,
>     Jordi
>     @jordipalet
>
>
>
>     El 16/4/21 15:05, "v6ops en nombre de Vasilenko Eduard" <
> [email-masked] en nombre de [email-masked]> escribió:
>
>         Hi Jordi,
>         You did bring the news about iOS that is a big secret for the
> community. What is the iOS version that supports CLAT?
>         I am interested in the use case: "to initiate a connection from
> the outside to an IPv4 server that is behind translation solution".
>         We could assume that port forwarding on the CPE subscriber could
> provision himself (probably port 80). But the CPE should receive incoming
> TCP session from the internet.
>         It would probably bring onto the discussion PCP (for some
> translation technologies), but if not - I would not be much disappointed.
>         Of course, you could send them to buy IPv4 on the open market
> because NAT connection initiated in opposite direction is additional
> complexity.
>         You choose.
>
>         Eduard
>         Subject: Re: [v6ops] I-D Action:
> draft-ietf-v6ops-transition-comparison-00.txt
>
>         Hi Eduard,
>
>         iOS was not supporting CLAT since a few years ago, which was a
> problem for using 464XLAT in tethering, but this is no longer true. Thanks
> to the push from several operators Apple finally implemented CLAT, which is
> only needed for the tethering, because the "similar" solution to
> bump-in-the-host resolve the problem for the apps in the iOS device.
> Further to that, this is supported because Apple took a very good decision
> long time ago (2016 I believe), to only allow in the AppStore apps that
> work in IPv6-only, so that's why the CLAT is not need for the iOS device
> itself.
>
>         Having no need for the CLAT to be enabled means lower battery
> consumption, and of course, lower CPU cost and delay if the other end is
> also using IPv6, so not NAT at all.
>
>         We have indeed some mentions about PCP and EAM in the text, not
> sure what you will like to see in the document. Could you please elaborate
> a bit more? An specific section about that or?
>
>         Regards,
>         Jordi
>         @jordipalet
>
>
>
>         El 16/4/21 14:03, "v6ops en nombre de Vasilenko Eduard" <
> [email-masked] en nombre de [email-masked]> escribió:
>
>             Hi all,
>             I am not sure that it is needed here. But there is the story
> of how to initiate a NAT connection in the opposite direction.
>             Different translation technologies have different
> compatibility and different tools for how to punch a hole in the opposite
> direction.
>             Subject: [v6ops] I-D Action:
> draft-ietf-v6ops-transition-comparison-00.txt
>
>
>                 Filename        :
> draft-ietf-v6ops-transition-comparison-00.txt
>                 Pages           : 30
>                 Date            : 2021-04-15
>
>             Abstract:
>             Please note that it may take a couple of minutes from the time
> of submission until the htmlized version and diff are available at
> tools.ietf.org.
>
>         This electronic message contains information which may be
> privileged or confidential. The information is intended to be for the
> exclusive use of the individual(s) named above and further non-explicilty
> authorized disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
>
>
>     This electronic message contains information which may be privileged
> or confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
>
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
>
>

-- 
-- 
Henri Alves Godoy
Tecnologia da Informação e Comunicação
Faculdade de Ciências Aplicadas - FCA
Universidade Estadual de Campinas - UNICAMP
Fone: (19) 3701-6682

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 19 Apr 2021 16:15:45 +0200

Hi Henri,

My original comment was related to iOS, where the phone has not CLAT for “its own” apps, but a) the apps must support IPv6-only AND b) it has happy eyeballs with the bump-in-the-host, resolves 99.9999% of the cases.

You can’t just forget about CLAT, if you don’t do a) and b) above as well.

What you’re doing is the right way in a generic “IPv6-only WAN” network, is the equivalent to having the CLAT in the CPE/router, it ensures that any device, even if the OS vendor is not resolving it, your network provides the solution (RFC8585).

Regards,

Jordi

@jordipalet

El 19/4/21 15:13, "v6ops en nombre de Henri Alves de Godoy" <[email-masked] en nombre de [email-masked]> escribió:

Hi Jordi,

Despite the advantages of not needing the CLAT, they are good, but this is still a dream, it will take a long time to happen.

CLAT is still required to connect legacy devices. In addition, navigation on devices that have only IPv6 on your device is not yet viable, as many services will no longer be accessed.

I don't know what a 4G telecom scenario would be like, but on wireless networks, where I've been working, I don't see a CLAT daemon on any OS (Windows, iOS, Android) available. Convincing these manufacturers of the need for a CLAT is an impossible task.

In my studies of the 464XLAT mechanism, I have inserted the CLAT into the wireless network as an intermediate VM on the same network. So I don't need CLAT on users' devices and mainly I don't need to intervene and guide in any installation. The less you interact with users' devices the less problems are.

Thanks

Henri

Em sex., 16 de abr. de 2021 às 15:38, JORDI PALET MARTINEZ <jordi.palet=[email-masked]> escreveu:

Hi Eduard,

Regards,
Jordi
@jordipalet

    Ed/
    -----Original Message-----
    From: v6ops [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
    Sent: Friday, April 16, 2021 4:32 PM
    To: [email-masked]
    Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-comparison-00.txt

    Regards,
    Jordi
    @jordipalet

        Hi Jordi,

        Eduard
        -----Original Message-----
        From: v6ops [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
        Sent: Friday, April 16, 2021 3:20 PM
        To: [email-masked]
        Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-comparison-00.txt

        Hi Eduard,

        Regards,
        Jordi
        @jordipalet

            Hi all,

            Eduard
            -----Original Message-----

            Abstract:

 

-- 

-- 

Henri Alves Godoy

Fone: (19) 3701-6682