Re: [v6ops] draft-vf-v6ops-ipv6-deployment

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Mon, 29 March 2021 20:57 UTC

Return-Path: <prvs=172215dd68=jordi.palet@consulintel.es>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1503A2164 for <v6ops@ietfa.amsl.com>; Mon, 29 Mar 2021 13:57:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXnnqivLRDl4 for <v6ops@ietfa.amsl.com>; Mon, 29 Mar 2021 13:57:09 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) by ietfa.amsl.com (Postfix) with ESMTP id 10E473A2198 for <v6ops@ietf.org>; Mon, 29 Mar 2021 13:56:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1617051407; x=1617656207; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=aPQy4v9R yGaFh3gUmhwCDhVRoeFFLaqVSzqR4GbeHtc=; b=nBj+FP5MoDcsoQxBqUlH4aIU MTclRDKGSxjhBk8T5iahiWZVB8dyG36Sv1cA7zwMWKxTBt3v8fVFf/IWdKgefX8b oRZWdmBEhZ+jvlm/0yWb3uU90PKebCP4UeAU8AbDBUA9J+VYW+yJf7zb/ydt6IaW Yj+0bNMzXOH+1JafPZ0=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Mon, 29 Mar 2021 22:56:47 +0200
X-Spam-Processed: mail.consulintel.es, Mon, 29 Mar 2021 22:56:45 +0200
Received: from [10.10.10.140] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50000560393.msg for <v6ops@ietf.org>; Mon, 29 Mar 2021 22:56:45 +0200
X-MDRemoteIP: 2001:470:1f09:495:2c7e:7254:2d6:f4d5
X-MDHelo: [10.10.10.140]
X-MDArrival-Date: Mon, 29 Mar 2021 22:56:45 +0200
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=172215dd68=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/16.47.21031401
Date: Mon, 29 Mar 2021 22:56:44 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: "'v6ops@ietf.org'" <v6ops@ietf.org>
Message-ID: <4BE8E347-2FDD-47E0-9455-1C72CA08EDF9@consulintel.es>
Thread-Topic: [v6ops] draft-vf-v6ops-ipv6-deployment
References: <BL0PR05MB5316425C5650B5D2FE43DE4DAE6C9@BL0PR05MB5316.namprd05.prod.outlook.com> <e770fec1-2189-f683-6c74-36e32541c53d@gmail.com> <abe65114-d9c9-10ee-2c78-449051acbb61@hit.bme.hu> <3c50c72b-b606-a6cf-3095-f08ad48eecf5@gmail.com> <2A0C2B40-2DA4-4941-A09F-5BD31EDA3301@consulintel.es> <2e64b426-3a0a-b5f8-0306-005e9f1023d0@gmail.com> <72754d29-8b57-66fa-2b3a-fc6680c339f2@hit.bme.hu> <69744eb4-2f2e-6876-eba7-c439c5c4db9d@gmail.com> <A9D618FB-00B5-4D87-8D1F-2AE28EF29F62@consulintel.es> <202103281513224517773@chinatelecom.cn> <847EF067-1076-4AC4-9349-2992181119DB@consulintel.es> <43c05777-01c3-df81-9da1-64abd6dc8c91@gmail.com> <683bf6ac-261e-e492-935d-27d5b1051521@hit.bme.hu> <8D04AA80-A140-4D9D-84AF-35D4206A7C55@consulintel.es> <17a374be46564ceca76387cb5c0dde33@huawei.com> <3d70a2e2-f13c-60bc-ab36-3ed400faa9dd@gmail.com> <fdc3dbd59c344a4fb8d431c7bdc06f7b@huawei.com> <3392b9c6-2d32-54c8-69c9-20061d6d041b@gmail.com> <17c3e0fd83b74b8fb572c71f6e0f73a0@huawei.com> <55d0bbc7-e476-5835-0449-cb11b169cefa@gmail.com> <DM6PR02MB6924A7132D9B3C23672C5996C37E9@DM6PR02MB6924.namprd02.prod.outlook.com>
In-Reply-To: <DM6PR02MB6924A7132D9B3C23672C5996C37E9@DM6PR02MB6924.namprd02.prod.outlook.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/hsos3XtalsNXFMfjnpW-eroTq08>
Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Mar 2021 20:57:15 -0000

    I agree. I see from https://www.worldipv6launch.org/measurements/ that my current employer is shown as being at 75.24% for wireline and 83.52% wireless (of traffic to certain sites from those ASNs). My *guess* is that the remaining 25% of wireline is due to enterprises and people with non-IPv6 retail routers connected to the CE router, because it's been 9 years since IPv6 launch. Wireless is probably due to old (non VoLTE) UEs.

-> Yes, I forgot to mention it before. In my experience most of the "lack" of IPv6 traffic comes from enterprise customers. That's why I was insisting in wireline residential. Of course, when you look at stats (example APNIC) per ASN, most of the ISPs serve residential and enterprises using the same ASN, so again, we can't "look" into the details, unless the ISP discloses the data.

    With that said, I can't envision recommending to my employer that it move from the current dual stack to IPv4aaS. It makes no sense business-wise and provides no benefit to customers. The costs of deploying dual stack are sunk. The help desk knows how to support it. It works extremely well.  Why recommend the high cost of deploying something new and different (on wireline: development and testing in the CE router and network elements, teams of people spending massive time, help desk training, etc.) when it provides zero benefit over what you have? Wireless is working fine, too.

-> In most of the cases, it depends on your number of IPv4 addresses and future needs. Your employer may have sufficient addresses, most of the rest of the world is not in that situation. Of course, the alternative is to use CGN for the IPv4 (using only private addresses), but CGN and addresses to run it have a bigger cost even than replacing the CPEs. We did those numbers for real customers. There was a very recent discussion on that in NANOG, and several folks reached the same conclusion. There are also "service" consequences when using NAT444, such as that Sony Play Station blacklist forever the addresses detected in the CGN (NAT444, not in the case of NAT64), so you need to rotate your IPv4 pools, and at the end, you're forced to "buy" (via transfers) more and more IPv4 addresses. If that's the case, it is cheaper to buy "tons" of IPv4 addresses up-front and not use CGN at all ...

    Barbara

    > For an
    > operator with zero experience with IPv6, there is an obvious risk with IPv4aaS
    > compared to dual stack.
    > 
    >    Brian
    > 
    > > Eduard
    > > -----Original Message-----
    > > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
    > > Sent: Monday, March 29, 2021 9:42 PM
    > > To: Vasilenko Eduard <vasilenko.eduard@huawei.com>; v6ops@ietf.org
    > > Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment
    > >
    > > I didn't mention IPv6aas. Of course that is too new for 75% to be a reasonable
    > expectation.
    > >
    > > As made clear by the draft, dual stack is the most popular solution today. At
    > least where I live, the national move to fibre to the home has led to massive
    > replacement of CPE in recent years. Put those facts together and you will find a
    > lot of IPv6.
    > >
    > > Regards
    > >    Brian
    > >
    > > On 29-Mar-21 22:13, Vasilenko Eduard wrote:
    > >> Looking to the fact that RFC 8585 has specified IPv4aaS requirements
    > >> to CPE less than 2 years ago And Fixed Broadband CPEs have 5+years
    > refreshment cycle.
    > >> I am very doubt that any fixed carrier has achieved 75% of IPv6 up today.
    > >> CPEs is the most expensive layer in carrier's networks (CPE itself +
    > replacement cost) - very difficult to replace.
    > >> Potentially, it could be India, Pakistan, or Bangladesh where we could still see
    > many new home subscribers per year. Or China where IPv6 is national program
    > and money are not so important.
    > >>
    > >> It would be very valuable if anyone would claim the biggest % for IPv6
    > >> FBB, Even if carrier name would not be mentioned.
    > >>
    > >> My expectation (not supported by facts) that FBB overnight is not more than
    > 50%.
    > >> It is definitely above 30%, because I know example.
    > >> Ed/
    > >> -----Original Message-----
    > >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E
    > >> Carpenter
    > >> Sent: Monday, March 29, 2021 11:43 AM
    > >> To: v6ops@ietf.org
    > >> Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment
    > >>
    > >> On 29-Mar-21 20:41, Vasilenko Eduard wrote:
    > >>> Do we have any fixed carrier in the world that has reached 75% for IPv6?
    > >>> It is primarily "CPE problem".
    > >>
    > >> Yes, so any ISP that supplies CPEs to most of its customers could easily reach
    > 75%. I've had an ISP-provided dual stack CPE since 2013. However, I don't have
    > data, and I don't know if any ISPs publish such data.
    > >>
    > >>    Brian
    > >>
    > >>> Mobile UE could be not compliant too, but It is a much smaller probability.
    > >>> Eduard
    > >>> -----Original Message-----
    > >>> From: Vasilenko Eduard
    > >>> Sent: Monday, March 29, 2021 10:34 AM
    > >>> To: 'JORDI PALET MARTINEZ'
    > >>> <jordi.palet=40consulintel.es@dmarc.ietf.org>; v6ops@ietf.org
    > >>> Subject: RE: [v6ops] draft-vf-v6ops-ipv6-deployment
    > >>>
    > >>> Hi Jordi,
    > >>> Your last statement is probably too strong.
    > >>> About half of Mobile carriers have 464XLAT, but only a couple of them
    > reached 90%+.
    > >>> If one would think logically about this fact then one would conclude that
    > 90% is not easy to reach, not overnight.
    > >>> I have seen in some RFC (do not remember the number) that 75% is easy to
    > reach (it was supported by numbers), but it was a few years ago - this data
    > should be better now because we have 20%+ CAGR for Webservers IPv6
    > support.
    > >>> Hence, the truth is probably somewhere between 75% and 90%.
    > >>> Eduard
    > >>> -----Original Message-----
    > >>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of JORDI PALET
    > >>> MARTINEZ
    > >>> Sent: Sunday, March 28, 2021 11:20 PM
    > >>> To: v6ops@ietf.org
    > >>> Subject: Re: [v6ops] draft-vf-v6ops-ipv6-deployment
    > >>>
    > >>> I can confirm that ... just say it in my previous email ...
    > >>>
    > >>> Note also that for residential ISPs, reaching IPv6 levels close to 90% is
    > trivial. It happens overnight, because the big volume of traffic to CDNs such as
    > Netflix, Youtube/Google, Facebook, Akamai, etc., etc. which have already IPv6
    > on.
    > >>>
    > >>>
    > >>>
    > >>>
    > >>> El 28/3/21 21:25, "v6ops en nombre de Lencse Gábor" <v6ops-
    > bounces@ietf.org en nombre de lencse@hit.bme.hu> escribió:
    > >>>
    > >>>     However, a statement like:
    > >>>
    > >>>     "For this reason, when IPv4 traffic is vanishingly small (e.g. less than 1%),
    > it would be better to switch to the IPv6-only stage."
    > >>>
    > >>>     seems to be trivial.
    > >>>
    > >>>     Can we state something stronger?
    > >>>
    > >>>     For example:
    > >>>
    > >>>     "For this reason, when IPv6 increases to a certain limit (e.g. more than
    > 90%), it would be better to switch to the IPv6-only stage."
    > >>>
    > >>>     Rationale:
    > >>>     - Introducing an IPv4aaS technology has its costs, but the selling of
    > >>>     the lions share of the public IPv4 addresses brings in more money.
    > >>>     - The maintenance cost of the IPv4aaS solution is less than that of a
    > >>>     complete IPv4 network.
    > >>>
    > >>>     I do not state that it is true, I just ask, if it can be true. Because
    > >>>     if it is so, then it could be a better guidance.
    > >>>
    > >>>     Gábor
    > >>>
    > >>>     28/03/2021 20:47 keltezéssel, Brian E Carpenter írta:
    > >>>     > On 28-Mar-21 21:25, JORDI PALET MARTINEZ wrote:
    > >>>     >> Yes and not … IPv6 in IPv4 (6in4, proto41, etc.) … 6over4 is another
    > protocol.
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >> Agree, right thing is to use IPv6-only and IPv4aaS, I was just saying that
    > Free was the initiation of 6RD and they were using that. I’m not saying they still
    > use the same or they should keep using the same.
    > >>>     > But please consider that if an operator is already supporting its
    > customers using classical dual stack or a solid solution like 6rd, there may be no
    > good reason to change for the next ten years or more. Dual stack has no time
    > limit.
    > >>>     >
    > >>>     > I think this statement in the draft:
    > >>>     > "For this reason, when IPv6 increases to a certain limit,
    > >>>     > it would be better to switch to the IPv6-only stage."
    > >>>     > is too vague to be useful. Switching costs might be very high, including
    > loss of customers. In fact, the criterion for switching might be as simple as
    > "when IPv4 traffic is vanishingly small."
    > >>>     >
    > >>>     >     Brian
    > >>>     >
    > >>>     >
    > >>>     >
    > >>>     >>
    > >>>     >>
    > >>>     >> Regards,
    > >>>     >>
    > >>>     >> Jordi
    > >>>     >>
    > >>>     >> @jordipalet
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >> El 28/3/21 9:14, "v6ops en nombre de xiechf@chinatelecom.cn
    > <mailto:xiechf@chinatelecom.cn>" <v6ops-bounces@ietf.org <mailto:v6ops-
    > bounces@ietf.org> en nombre de xiechf@chinatelecom.cn
    > <mailto:xiechf@chinatelecom.cn>> escribió:
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >> 6rd is a mode of IPv6 over IPv4, it is opposite to the concept of "IPv4
    > as a Service" of IPv6-only, so it should be replaced to make IPv6 as a univeral
    > and underlying network protocol gradually.
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >> Regards
    > >>>     >>
    > >>>     >> Chongfeng
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>      *From:* JORDI PALET MARTINEZ
    > <mailto:jordi.palet=40consulintel.es@dmarc.ietf.org>
    > >>>     >>
    > >>>     >>      *Date:* 2021-03-25 17:15
    > >>>     >>
    > >>>     >>      *To:* v6ops@ietf.org <mailto:v6ops@ietf.org>
    > >>>     >>
    > >>>     >>      *Subject:* Re: [v6ops] draft-vf-v6ops-ipv6-deployment
    > >>>     >>
    > >>>     >>      Free was using 6RD initially, not sure if they turned into dual-stack,
    > may be with IPv4 via CGN.
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>      Regards,
    > >>>     >>
    > >>>     >>      Jordi
    > >>>     >>
    > >>>     >>      @jordipalet
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>      El 24/3/21 17:23, "v6ops en nombre de Alexandre Petrescu" <v6ops-
    > bounces@ietf.org en nombre de alexandre.petrescu@gmail.com> escribió:
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>          Le 24/03/2021 à 16:59, Gabor LENCSE a écrit :
    > >>>     >>
    > >>>     >>          > Dear Alex,
    > >>>     >>
    > >>>     >>          >
    > >>>     >>
    > >>>     >>          > On 3/24/2021 4:12 PM, Alexandre Petrescu wrote: [...]
    > >>>     >>
    > >>>     >>          >> Does IPv6 mandate the use of DNS64 and NAT64?
    > >>>     >>
    > >>>     >>          >
    > >>>     >>
    > >>>     >>          > Of course, not. :)
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>          So I agree with you about that.
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>          > There are several IPv4 as a Services solutions exist. We have
    > >>>     >>
    > >>>     >>          > covered the five most prominent ones 464XLAT, DS-Lite, MAP-E,
    > MAP-T
    > >>>     >>
    > >>>     >>          > and lw4o6 in our I-D:
    > >>>     >>
    > >>>     >>          > https://urldefense.com/v3/__https://tools.ietf.org/html/draft-
    > lmhp-v6ops-transition-comparison-
    > 06__;!!BhdT!zHXQsXv7_su5r1zxivBMhBCDaRAaeXD0e7aJOWEXUoLZkStKq75TdC
    > dReme-vw$
    > >>>     >>
    > >>>     >>          > > Your ISP is likely using one of them.
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>          For clarification - my ISP is called 'Free' (it has freedom features).
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>          They offer me paid IPv4 and IPv6 native access at home on ADSL.
    > It's
    > >>>     >>
    > >>>     >>          one publicly routable IPv4 address and an IPv6 /56 prefix globally
    > >>>     >>
    > >>>     >>          routable prefix (a 'GUP' if I can say so, not a GUA'(ddress)).
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>          Up to now, looking through the configuration interface of my
    > freebox at
    > >>>     >>
    > >>>     >>          home I could not see the options that you mention (464XLAT,
    > DSLITE,
    > >>>     >>
    > >>>     >>          MAP-E, MAP-T, lw4o6).  One might say that they are there
    > invisible, but
    > >>>     >>
    > >>>     >>          I doubt that, I need a proof of it.  How can I check for presence of
    > >>>     >>
    > >>>     >>          options 464XLAT, DSLITE, MAP-E, MAP-T or lw4o6?
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>          The problems that appear when I try to browse IPv6 sites that
    > absolutely
    > >>>     >>
    > >>>     >>          need IPv4 might be because I turned off the IPv4 stack on my
    > computer's
    > >>>     >>
    > >>>     >>          interface (Windows Properties on the Interface, check off IPv4).
    > This
    > >>>     >>
    > >>>     >>          operation (turning off IPv4 in a computer) is possible only on
    > Windows,
    > >>>     >>
    > >>>     >>          not on linux, AFAIR.  One cant do 'rmmod ipv4' in linux.
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>          That also explains the fact that installing IPv4-IPv6 translation
    > boxes
    > >>>     >>
    > >>>     >>          (NAT64, 464LAT, etc.) in a network is not sufficient to access IPv4
    > >>>     >>
    > >>>     >>          sites from an IPv6-only computer.
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>          In order to access IPv4 sites from IPv6-only computers one also
    > needs
    > >>>     >>
    > >>>     >>          the IPv4 stack to work ok on that computer and, moreover, it
    > needs some
    > >>>     >>
    > >>>     >>          times software features in the Client that support the 64::
    > notation of
    > >>>     >>
    > >>>     >>          IPv6 addresses.  For example, thunderbird (a very modern MUA)
    > does not
    > >>>     >>
    > >>>     >>          understand it and gets confused by it.  It takes it for an fqdn, and
    > >>>     >>
    > >>>     >>          does not even try to connect the translation boxes.
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>          This means that if one wants to migrate more to IPv6 then one
    > has to
    > >>>     >>
    > >>>     >>          think about the NAT64 and 464XLAT concepts more outside of the
    > cellular
    > >>>     >>
    > >>>     >>          network concept.
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>          And yes, I agree with you, NAT64 and 464XLAT are good tools to
    > >>>     >>
    > >>>     >>          migrate.  In particular, if one is on a smartphone or other
    > computer
    > >>>     >>
    > >>>     >>          using an OS that cant turn off their IPv4 stacks.
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>          Alex
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>          >
    > >>>     >>
    > >>>     >>          > Best regards,
    > >>>     >>
    > >>>     >>          >
    > >>>     >>
    > >>>     >>          > Gábor
    > >>>     >>
    > >>>     >>          >
    > >>>     >>
    > >>>     >>          > _______________________________________________ v6ops
    > mailing list
    > >>>     >>
    > >>>     >>          > v6ops@ietf.org
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;!!
    > BhdT!zHXQsXv7_su5r1zxivBMhBCDaRAaeXD0e7aJOWEXUoLZkStKq75TdCeEx7Ju
    > xw$
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>          _______________________________________________
    > >>>     >>
    > >>>     >>          v6ops mailing list
    > >>>     >>
    > >>>     >>          v6ops@ietf.org
    > >>>     >>
    > >>>     >>
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;!!
    > BhdT!zHXQsXv7_su5r1zxivBMhBCDaRAaeXD0e7aJOWEXUoLZkStKq75TdCeEx7Ju
    > xw$
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>      **********************************************
    > >>>     >>
    > >>>     >>      IPv4 is over
    > >>>     >>
    > >>>     >>      Are you ready for the new Internet ?
    > >>>     >>
    > >>>     >>
    > https://urldefense.com/v3/__http://www.theipv6company.com__;!!BhdT!zHXQ
    > sXv7_su5r1zxivBMhBCDaRAaeXD0e7aJOWEXUoLZkStKq75TdCdIu5dCHQ$
    > >>>     >>
    > >>>     >>      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.
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>
    > >>>     >>      _______________________________________________
    > >>>     >>
    > >>>     >>      v6ops mailing list
    > >>>     >>
    > >>>     >>      v6ops@ietf.org
    > >>>     >>
    > >>>     >>
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;!!
    > BhdT!zHXQsXv7_su5r1zxivBMhBCDaRAaeXD0e7aJOWEXUoLZkStKq75TdCeEx7Ju
    > xw$
    > >>>     >>
    > >>>     >> _______________________________________________ v6ops
    > mailing list v6ops@ietf.org
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;!!
    > BhdT!zHXQsXv7_su5r1zxivBMhBCDaRAaeXD0e7aJOWEXUoLZkStKq75TdCeEx7Ju
    > xw$
    > >>>     >>
    > >>>     >>
    > >>>     >> **********************************************
    > >>>     >> IPv4 is over
    > >>>     >> Are you ready for the new Internet ?
    > >>>     >>
    > https://urldefense.com/v3/__http://www.theipv6company.com__;!!BhdT!zHXQ
    > sXv7_su5r1zxivBMhBCDaRAaeXD0e7aJOWEXUoLZkStKq75TdCdIu5dCHQ$
    > >>>     >> 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.
    > >>>     >>
    > >>>     >>
    > >>>     >> _______________________________________________
    > >>>     >> v6ops mailing list
    > >>>     >> v6ops@ietf.org
    > >>>     >>
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;!!
    > BhdT!zHXQsXv7_su5r1zxivBMhBCDaRAaeXD0e7aJOWEXUoLZkStKq75TdCeEx7Ju
    > xw$
    > >>>     >>
    > >>>     > _______________________________________________
    > >>>     > v6ops mailing list
    > >>>     > v6ops@ietf.org
    > >>>     >
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;!!
    > BhdT!zHXQsXv7_su5r1zxivBMhBCDaRAaeXD0e7aJOWEXUoLZkStKq75TdCeEx7Ju
    > xw$
    > >>>     >
    > >>>
    > >>>     _______________________________________________
    > >>>     v6ops mailing list
    > >>>     v6ops@ietf.org
    > >>>
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;!!
    > BhdT!zHXQsXv7_su5r1zxivBMhBCDaRAaeXD0e7aJOWEXUoLZkStKq75TdCeEx7Ju
    > xw$
    > >>>
    > >>>
    > >>>
    > >>> **********************************************
    > >>> IPv4 is over
    > >>> Are you ready for the new Internet ?
    > >>>
    > https://urldefense.com/v3/__http://www.theipv6company.com__;!!BhdT!zHXQ
    > sXv7_su5r1zxivBMhBCDaRAaeXD0e7aJOWEXUoLZkStKq75TdCdIu5dCHQ$
    > >>> 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.
    > >>>
    > >>>
    > >>>
    > >>> _______________________________________________
    > >>> v6ops mailing list
    > >>> v6ops@ietf.org
    > >>>
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;!!
    > BhdT!zHXQsXv7_su5r1zxivBMhBCDaRAaeXD0e7aJOWEXUoLZkStKq75TdCeEx7Ju
    > xw$
    > >>> _______________________________________________
    > >>> v6ops mailing list
    > >>> v6ops@ietf.org
    > >>>
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;!!
    > BhdT!zHXQsXv7_su5r1zxivBMhBCDaRAaeXD0e7aJOWEXUoLZkStKq75TdCeEx7Ju
    > xw$
    > >>>
    > >>
    > >> _______________________________________________
    > >> v6ops mailing list
    > >> v6ops@ietf.org
    > >>
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;!!
    > BhdT!zHXQsXv7_su5r1zxivBMhBCDaRAaeXD0e7aJOWEXUoLZkStKq75TdCeEx7Ju
    > xw$
    > >>
    > >
    > 
    > _______________________________________________
    > v6ops mailing list
    > v6ops@ietf.org
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/v6ops__;!!
    > BhdT!zHXQsXv7_su5r1zxivBMhBCDaRAaeXD0e7aJOWEXUoLZkStKq75TdCeEx7Ju
    > xw$
    _______________________________________________
    v6ops mailing list
    v6ops@ietf.org
    https://www.ietf.org/mailman/listinfo/v6ops



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