Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 15 Jul 2020 13:40:08 +0000

Hi all,
I have concern on the capability to use this mechanism for 464XLAT, but it should be fine for MAP-T.

We may have many hosts on CPE LAN. Typically, 70% of FBB traffic is still designated to IPv4 sites.
Source UDP/TCP port collision is still very possible (i.e. active sessions from different host may have the same source TCP/UDP port),
It is not stated anywhere in the document, but we need to squeeze (for path to Internet it would be "source IP address") many private IPv4 hosts to one IPv6 (assigned by carrier to CPE uplink).
Classical N:1 problem that should be resolved by NAPT (port translation is mandatory).

MAP-T has NAPT engine on CPE side - it make sense to clearly state in the document that we are going to reuse NAPT. Then translation would be:
(1) NAPT44 for many private IPv4 to one public IPv4 (well, it could be not public, but public A+P has been given to MAP CE anyway - better to reuse it for unification)
(2) SIIT (with EAMT) for single IPv4 to single IPv6 (1:1)

XLAT/CLAT does have stateful NAPT by RFC 6877, but it is not popular - not implemented by many carriers (if any?).
It would be the big news that Carriers should choose stateful CLAT option for 464XLAT.
It is better to tell them upfront.

The next question could be: does it make sense to use Stateless CLAT for basic 464XLAT and Stateful CLAT for traffic optimization to IPv4 sites?
Or it is better to unify on Stateful CLAT for everything.

In general, it is a revolution for 464XLAT. But it is smooth expansion for MAP-T.
Hence, does it make sense to change the name of this draft to reflect MAP-T as the primary target?

Eduard
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 11 июля 2020 г. 15:34
To: [email-masked]
Cc: [email-masked]
Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02.txt

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           : 464XLAT/NAT64 Optimization
        Authors         : Jordi Palet Martinez
                          Alejandro D'Egidio
	Filename        : draft-ietf-v6ops-464xlat-optimization-02.txt
	Pages           : 21
	Date            : 2020-07-11

Abstract:
   IP/ICMP Translation Algorithm (SIIT) can be used to provide access
   for IPv4-only devices or applications to IPv4-only or dual-stack
   destinations over IPv6-only infrastructure.  In that case, the
   traffic flows are translated twice: first from IPv4 to IPv6
   (stateless NAT46 at the ingress point to the IPv6-only
   infrastructure) and then from IPv6 back to IPv4 (stateful NAT64, at
   the egress point).  When the destination is IPv6-enabled, the second
   translation might be avoided.  This document describes a possible
   optimization to 464XLAT and MAP-T to avoid translating IPv6 flows
   back to IPv4 if the destination is reachable over IPv6.  The proposed
   solution would significantly reduce the NAT64 utilization in the
   operator's network.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-464xlat-optimization/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-v6ops-464xlat-optimization-02
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-464xlat-optimization-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-464xlat-optimization-02

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/

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

---

From: Jordi Palet Martínez <[email-masked]>
Date: Wed, 15 Jul 2020 15:47:58 +0200

Hi Vasilenko,

The implementations of 464XLAT, can do the same (and in fact, many of them is what they do). NAT44 stateful and the 46 stateless. Many SoC have embedded NAT44 acceleration, but not NAT46, so that explains it as well.

I guess that could clear your concern?

I've several customers doing 464XLAT in broadband, one of them 25.000.000 subscribers. There is no difference in doing 464XLAT in cellular and broadband.

When we say in the title 464XLAT/NAT64, I think both are covered. But I've no issue to change the title if this makes sense to others. We could explictily say 464XLAT/NAT64/MAP-T or whatever. This is a minor detail, in my opinion.
 
Regards,
Jordi
@jordipalet

El 15/7/20 15:40, "Vasilenko Eduard" <[email-masked]> escribió:

    Hi all,

    Eduard
    -----Original Message-----
    From: v6ops [mailto:[email-masked]] On Behalf Of [email-masked]
    Sent: 11 июля 2020 г. 15:34
    To: [email-masked]
    Cc: [email-masked]
    Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02.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: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 15 Jul 2020 15:48:45 +0200

Hi Vasilenko,

Regards,
Jordi
@jordipalet

    Hi all,

    Eduard
    -----Original Message-----
    From: v6ops [mailto:[email-masked]] On Behalf Of [email-masked]
    Sent: 11 июля 2020 г. 15:34
    To: [email-masked]
    Cc: [email-masked]
    Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02.txt

    Abstract:

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 15 Jul 2020 13:59:01 +0000

Hi Jordi,
I still believe that tough (new) requirement that CLAT should become Stateful (mandatory)
Make sense to insert into the document.

And explanation why stateful NAPT is needed would be good.
I have spent some time to research this - it is better to save time of other people.
It is important point that is omitted in the document.

For the name: I do not have any strong opinion.
Just I see that draft is applicable mostly to MAP-T,
And not much applicable to XLAT (because majority of installations have stateless CLAT).
But the name mislead to opposite conclusion.

Eduard
-----Original Message-----
From: Jordi Palet Martínez [mailto:[email-masked]] 
Sent: 15 июля 2020 г. 16:48
To: Vasilenko Eduard <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness

Hi Vasilenko,

 
Regards,
Jordi
@jordipalet

    Hi all,

    Eduard
    -----Original Message-----
    From: v6ops [mailto:[email-masked]] On Behalf Of [email-masked]
    Sent: 11 июля 2020 г. 15:34
    To: [email-masked]
    Cc: [email-masked]
    Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02.txt

    Abstract:

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 15 Jul 2020 16:17:23 +0200

I think your point will be to make it clear in the document that for this optimization to work, the CLAT should be stateful?

I think is there (5.2.4.  Forwarding path via stateful NAT for existing EAMT entries), but I will make sure to add the relevant text in the next version to make it clearer. 

I insist: most of the CLAT implementations today (running in both CPEs and UEs) are stateful. At least this is the data I've.
 
Regards,
Jordi
@jordipalet

El 15/7/20 15:59, "v6ops en nombre de Vasilenko Eduard" <[email-masked] en nombre de [email-masked]> escribió:

    Hi Jordi,

    Eduard
    -----Original Message-----
    From: Jordi Palet Martínez [mailto:[email-masked]] 
    Sent: 15 июля 2020 г. 16:48
    To: Vasilenko Eduard <[email-masked]>; [email-masked]
    Cc: [email-masked]
    Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness

    Hi Vasilenko,

    Regards,
    Jordi
    @jordipalet

        Hi all,

        Eduard
        -----Original Message-----
        From: v6ops [mailto:[email-masked]] On Behalf Of [email-masked]
        Sent: 11 июля 2020 г. 15:34
        To: [email-masked]
        Cc: [email-masked]
        Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02.txt

        Abstract:

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 15 Jul 2020 15:52:48 +0000

Hi Jordi,
Yes, this one looks like outside of any context: 
" Consequently, the EAMT entries should not be used directly to
   establish a forwarding path, but instead, to create a stateful NAT
   entry for the 4-tuple for the duration of the session/connection. "
It is difficult to understand that it is about mandatory stateful CLAT.

About "everybody use stateful CLAT":
Your presentation clearly state "Stateless CLAT" (slide 6): https://www.lacnic.net/innovaportal/file/2907/1/ipv6-trans-mechs-status_v1-short-jordi-palet.pdf
And your RFC talking only about "stateless CLAT": https://www.rfc-editor.org/rfc/rfc8683.html

RFC 8585 does not clarify type of CLAT.

Many hundreds of stateless CLAT discussions is possible to google:
https://conference.apnic.net/34/pdf/34th_apnic_464xlat.pdf
https://ipv6council.be/IMG/pdf/12-wuyts-XLAT_at_the_CPE.pdf
https://www.apricot.net/apricot2013/assets/20130226_apricot2013_ipv4_over_ipv6_1361969703.pdf
https://datatracker.ietf.org/meeting/84/materials/slides-84-sunset4-1
https://www.ipv6.org.uk/wp-content/uploads/2018/11/Nick-Heatley_BT_EE_464xlat_UKv6Council_20180925.pdf
https://www.rfc-editor.org/rfc/rfc8683.html
https://archive.nanog.org/sites/default/files/wednesday_general_byrne_breakingfree_11.pdf
Is everybody talking about stateless, but implement stateful?

At least somebody not:
https://sites.google.com/site/tmoipv6/464xlat
" No changes were required to the existing T-Mobile USA IPv6-only + NAT64/DNS64 to support the 464XLAT architecture.  The stateless RFC6145 translation on the handset was the only modification needed. "

OK. Are you sure that Google Android support Stateful CLAT in principle?
Because Linux does not.
Linux daemon https://github.com/toreanderson/clatd
Is based on http://www.litech.org/tayga/
That claimed to be "stateless NAT64 implementation"

Android looks a little behind (using previous version of CLATD): https://android.googlesource.com/platform/external/android-clat/+/c786b7409032050721021583236de8608ac8948e/clatd.h
Android investigation is better to start here: https://android.googlesource.com/platform/external/android-clat/
Hence, Android CLAT daemon does not support stateful CLAT too.

Could it be that CLAT is used together with some other daemon for NAPT before CLAT?
Looks like No CLAT daemon dependency: https://openwrt.org/packages/pkgdata/464xlat

Then how is it possible that Statuful CLAT is used, if it is not supported on CPE/Smartphone?

Eduard
-----Original Message-----
From: JORDI PALET MARTINEZ [mailto:[email-masked]] 
Sent: 15 июля 2020 г. 17:17
To: Vasilenko Eduard <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness

 
Regards,
Jordi
@jordipalet

    Hi Jordi,

    Eduard
    -----Original Message-----
    From: Jordi Palet Martínez [mailto:[email-masked]] 
    Sent: 15 июля 2020 г. 16:48
    To: Vasilenko Eduard <[email-masked]>; [email-masked]
    Cc: [email-masked]
    Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness

    Hi Vasilenko,

    Regards,
    Jordi
    @jordipalet

        Hi all,

        Eduard
        -----Original Message-----
        From: v6ops [mailto:[email-masked]] On Behalf Of [email-masked]
        Sent: 11 июля 2020 г. 15:34
        To: [email-masked]
        Cc: [email-masked]
        Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02.txt

        Abstract:

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 15 Jul 2020 19:29:13 +0200

Hi Vasilenko,

My presentations and I guess the ones from other people, are based in the *current* 464XLAT RFC6877, so they are correct.

Before working in the optimization, not having discovered this issue, I was convinced that stateless is much better. And this is still true, if it is supported in the SoC or implementation. However, it is not true if you want to have the optimization and avoid problems when there are proxies for servers, etc., which require tracking the connections as per 5.2.4.

However, because the optimization can be disabled, it is perfectly possible to support also stateless in a given product so to improve the performance. For example, you can have a SoC and a Linux based CPE that can do hardware stateless NAT46, in some cases (you're a geek and you don't have any IPv4-only smartTV), you could disable the optimization and increase the performance of the CPE. I know it is a extreme case, but it is not a big trouble in terms of implementation to support both ways.

The optimization requires it to be stateful this is clear. I fully agree that it should be more clear, but that doesn't change the status of the current reality or previous presentations of RFC6877.

Same about RFC8683 and RFC8585, they are refering to the actual RFC6877.

This is the same for *any* presentation or RFC referring to a previous RFC. Something may change, some new options could change something that, as in the current case, RFC6877 indicates it may be statless or stateful, and this doesn't invalidates previous work. Right?

I know for sure:
1) Android is stateful NAT44 then stateless NAT46. This has been confirmed by Lorenzo a couple of times in meetings, probably also in the mailing list.
2) OpenWRT it is stateful.
3) I've seen several Linux implementations. Under NDA, working with several CPEs vendors in several proyects, so I can't name them. Some are in the list and could say by themselves.
4) Jool is stateful NAT44 then stateless NAT46.
5) Several SoC (System on Chip) support only stateful NAT44, not directly stateless NAT46.

Ole has indicated that VPP is stateless NAT46, but it also supports supports stateful NAT44.

iOS doesn't support CLAT for the UE itself (because all the apps should be IPv6-only ready and the support of HEv2 does something similar), but for the tethering yes. However I don't know if it is statelss or stateful.

So I'm talking with the information I've for real.

Anyway, this doesn't excludes at all 464XLAT being used in broadband CPEs (T-Mobile also provides broadband service via 4G using 464XLAT, for example), broadband wired, etc. It is clear in RFC6877.

Similarly doesn't preclude that if you want to support the optimization, you make sure that you're using a stateful CLAT in case your existing implementation is stateless now.

Regards,
Jordi

El 15/7/20 17:53, "Vasilenko Eduard" <[email-masked]> escribió:

    Hi Jordi,

    At least somebody not:

    Eduard
    -----Original Message-----
    From: JORDI PALET MARTINEZ [mailto:[email-masked]] 
    Sent: 15 июля 2020 г. 17:17
    To: Vasilenko Eduard <[email-masked]>; [email-masked]
    Cc: [email-masked]
    Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness

    Regards,
    Jordi
    @jordipalet

        Hi Jordi,

        Eduard
        -----Original Message-----
        From: Jordi Palet Martínez [mailto:[email-masked]] 
        Sent: 15 июля 2020 г. 16:48
        To: Vasilenko Eduard <[email-masked]>; [email-masked]
        Cc: [email-masked]
        Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness

        Hi Vasilenko,

        Regards,
        Jordi
        @jordipalet

            Hi all,

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

            Abstract:

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 17 Jul 2020 10:00:45 +0200

Hi Eduard,

Let us know what do you think about this tentative alternative text to resolve this issue:

5.2.4.  Forwarding path via stateful NAT for existing EAMT entries

   Following this approach, if there is a valid EAMT entry, for a given
   IPv4-destination, the IPv6-native path pointed by the IPv6 address of
   that EAMT entry, will take precedence versus the NAT64 path, so the
   traffic will not be forwarded to the NAT64.

   However, this is not sufficient to ensure that individual
   applications are able to keep existing connections.  In many cases,
   audio and video streaming may use a single TCP connection lasting
   from minutes to hours.  Instead, the CDN TTLs may be configured in
   the range from 10 to 300 seconds in order to allow new resolutions to
   switch quickly and to handle large recursive resolvers (with hundreds
   of thousands of clients behind them).

   Consequently, the EAMT entries MUST NOT be used directly to establish
   a forwarding path, but instead, MUST be used to create a stateful NAT
   entry for the 4-tuple for the duration of the session/connection.
   This means that to implement the optimization the NAT46 MUST be
   stateful.  Typically, stateful NAT46 are implemented
   by means of a stateful NAT44 (which often maybe hardware off-loaded),
   followed by a stateless NAT46.  If the SoC/code is able to do
   stateless NAT46, this still could be used when the optimization is
   disabled.

Note that also following Erik inputs, the text has more normative language.

Also, for the title we thought that it will make sense:
464XLAT/MAP-T Optimization

No need to mention NAT64, which is part of the 464XLAT.
  
Regards,
Jordi
@jordipalet

El 15/7/20 16:18, "v6ops en nombre de JORDI PALET MARTINEZ" <[email-masked] en nombre de jordi.palet=[email-masked]> escribió:

    Regards,
    Jordi
    @jordipalet

        Hi Jordi,

        Eduard
        -----Original Message-----
        From: Jordi Palet Martínez [mailto:[email-masked]] 
        Sent: 15 июля 2020 г. 16:48
        To: Vasilenko Eduard <[email-masked]>; [email-masked]
        Cc: [email-masked]
        Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness

        Hi Vasilenko,

        Regards,
        Jordi
        @jordipalet

            Hi all,

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

            Abstract:

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 17 Jul 2020 15:54:30 +0000

Hi Jordi,
It is even longer than I have expected. Fine.

But in separate discussion you have proposed to put source IPv4 into EAMT table,
That would break logic below - it would not be possible anymore to pipeline 2 independent engines: NAPT44 and NAT46. It should be one stateful engine.
Let's wait for the finish of other discussions - may be you have to return to 5.2.4 again.

Eduard
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
Sent: 17 июля 2020 г. 11:01
To: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness

Hi Eduard,

  
Regards,
Jordi
@jordipalet

    Regards,
    Jordi
    @jordipalet

        Hi Jordi,

        Eduard
        -----Original Message-----
        From: Jordi Palet Martínez [mailto:[email-masked]] 
        Sent: 15 июля 2020 г. 16:48
        To: Vasilenko Eduard <[email-masked]>; [email-masked]
        Cc: [email-masked]
        Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness

        Hi Vasilenko,

        Regards,
        Jordi
        @jordipalet

            Hi all,

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

            Abstract:

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 19 Jul 2020 12:57:23 +0200

Hi Eduard,

I'm still thinking in the other email from you about using the MAC of the source hosts instead of the DNS queries to guess if it is a dual-stack or IPv4-only host. It looks like a very smart idea, unless anyone else could tell why not ...

If we use than then we could just include the MAC address in the EAMT.

However, I don't see why identifying the hosts (whether is via MAC or source IPv4) disallows using the NAT44+NAT46. I guess it is a matter of implementation.

El 17/7/20 17:55, "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: 17 июля 2020 г. 11:01
    To: [email-masked]
    Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness

    Hi Eduard,

    Regards,
    Jordi
    @jordipalet

        Regards,
        Jordi
        @jordipalet

            Hi Jordi,

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

            Hi Vasilenko,

            Regards,
            Jordi
            @jordipalet

                Hi all,

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

                Abstract:

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 20 Jul 2020 15:43:40 +0000

Because after NAPT44 you would lose visibility of <source Private IPv4> in principle,

It is left in previous library, only Public IPv4 it transferred in next (CLAT) library.

But you need <source Private IPv4> for your new EAMT.

Hence, these "micro-services" could not solve the problem.

It should be 1 monolithic "partially stateful NG CLAT".

That Android does not have now.

Jordi,

I do agree that destination IPv6 research (and EAMT manipulation) - is the biggest challenge of this draft.

You are utterly concentrated on the most important thing.

But please, pay a little attention how source addresses should be manipulated.

Eduard

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of JORDI PALET MARTINEZ
Sent: 19 июля 2020 г. 13:57
To: [email-masked]
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-optimization-02 - concern on statefulness

Hi Eduard,

El 17/7/20 17:55, "v6ops en nombre de Vasilenko Eduard" <[email-masked] en nombre de [email-masked]<mailto:[email-masked][email-masked]>> escribió:

    Hi Jordi,

    Eduard

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

    To: [email-masked]<mailto:[email-masked]>

    Hi Eduard,

       disabled.

    Regards,

    Jordi

    @jordipalet

    El 15/7/20 16:18, "v6ops en nombre de JORDI PALET MARTINEZ" <[email-masked] en nombre de jordi.palet=[email-masked]<mailto:[email-masked]%20en%20nombre%20de%20jordi.palet=[email-masked]>> escribió:

        Regards,

        Jordi

        @jordipalet

       El 15/7/20 15:59, "v6ops en nombre de Vasilenko Eduard" <[email-masked] en nombre de [email-masked]<mailto:[email-masked][email-masked]>> escribió:

            Hi Jordi,

            Eduard

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

            To: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

            Cc: [email-masked]<mailto:[email-masked]>

            Hi Vasilenko,

            Regards,

            Jordi

            @jordipalet

            El 15/7/20 15:40, "Vasilenko Eduard" <[email-masked]<mailto:[email-masked]>> escribió:

                Hi all,

                Eduard

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

                From: v6ops [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>

                To: [email-masked]<mailto:[email-masked]>

                Cc: [email-masked]<mailto:[email-masked]>

                                          Alejandro D'Egidio

                              Pages           : 21

                              Date            : 2020-07-11

                Abstract:

                   operator's network.

                v6ops mailing list

                [email-masked]<mailto:[email-masked]>

            IPv4 is over

            The IPv6 Company

            v6ops mailing list

            [email-masked]<mailto:[email-masked]>

        IPv4 is over

        The IPv6 Company

        v6ops mailing list

        [email-masked]<mailto:[email-masked]>

    IPv4 is over

    The IPv6 Company

    v6ops mailing list

    [email-masked]<mailto:[email-masked]>

    v6ops mailing list

    [email-masked]<mailto:[email-masked]>

IPv4 is over

The IPv6 Company

v6ops mailing list

[email-masked]<mailto:[email-masked]>