Re: [v6ops] Thoughts about wider operational input

"nalini.elkins@insidethestack.com" <nalini.elkins@insidethestack.com> Wed, 30 March 2022 10:32 UTC

Return-Path: <nalini.elkins@insidethestack.com>
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 5ABA73A0029 for <v6ops@ietfa.amsl.com>; Wed, 30 Mar 2022 03:32:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com
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 Boh-83bBHOAX for <v6ops@ietfa.amsl.com>; Wed, 30 Mar 2022 03:32:48 -0700 (PDT)
Received: from sonic319-28.consmr.mail.ne1.yahoo.com (sonic319-28.consmr.mail.ne1.yahoo.com [66.163.188.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCDBB3A005D for <v6ops@ietf.org>; Wed, 30 Mar 2022 03:32:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1648636365; bh=n8RCM9nsMAmbwsrIzivVyTDGvXOtN33SKDO7pYnm2Nk=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject:Reply-To; b=hQ/deBF4vChL0hWc7BazBsdmcSktISVQlcPq4DqkDh+BY0HyDytfWMLSYgR1OSaPdgWH6qf1nq8qVg8hJ5yVqF19GsLW2Ml+mM5EQHb213pNJFit3voOovv9iNYDhWsxKeeIyxiJX2G8bxSR17RpsojJXcJZxMwiMpQm4+HXGCDAirovuAsPW/+QHsoNErZDLFm8wi1dh54oAfocWG1QUK4pggD4wvx7FshRAWzxDzRRpPr4zxGL5JVuj6GE+U5QKWJVtUy/zF3Tk/wG1NiJOtvBXJCfkMCR+9hg0HDoSUKgUyi9AgccxGFCvtNElky4y/8dlpLtQTA0MKQk8swZzA==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1648636365; bh=vd5Fg44AzVD3LUn9RrPOy+aDpDyE6RVOU6Y5EWyigNm=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=F4eQHQMOqMqhGQl2lwFiI5Br7hefalEM8XZLFUyX9JUphKp8GL09S+njplszBgT/avTmEyink3Wm95FUVSPF80vSHY8n92NY5Vhr6nN7rlaMTQb+7kyLQXIlmjAMFf8ChoFJiM8wlPHGQvqDLjup27Wl883zA6bNQEOltDm/EAEPEXjCVF+t992RlWmz76aNJPO7a/Zag24G6K5/4ZyAV+j9HRWbdWf0+Vz3X3t4XHv9We6T/0PD1AoViFi8X8ZaNwnSlQv7sRz9ipqkVNW6QrQh5Vk75cgTa588Qp3bUfN4cLKZK0urSy4dKrafathu+1ZPx6PfG0RRcrgR/JQekQ==
X-YMail-OSG: HbkhI.kVM1kq8..MMOm9QU_E4teJb7jEqaetCPuDwHNS8OHPE5WxXDJ7JN3nN5T PDA3Jjb0M7MgFpLamzUWZdUWS1TqYJieITQJAPG1oG6ghvd8n4g.cKtU7PuhNFXKSW2qxRkuW85m xNRxiXIog6e8jSoUGT35lqmkWw19QsbNkBaRaT81YOwQkdNr.J_Zfn1oQRt6uFh09caedZnYX.IU 9yLeCTnvNtwEEdGfr5XCINfHFQSur4Cc_FgWHBDLMxDb7DzRhVLlmJ_r7o5vcrGvcfq3lTSe7fox sCmtmP.pUIDNvYgDrYOuI.3kCKT20vmdKWv0gfNcHigPDzAx2kQf1oVWA0QZjQjzTxJeaRz3n3Ja 47EZYrVX1ZcxQRmR8Xmmeh_NQbUXxlDSf_SmCDvlNmRxngJYk3niyrJTtVbNJKcB_5WsL8o4cUp7 YZF_oUuMOT0TffjzB2xREuKrTi5B3Xt3J3uhGGpb7gMjX2Th3sEt3bN9UP4QvhS_yOmqAcxbHcV5 RoBbOTVcwrayn.lJcImdAopxPidT7BN0Mdqp2I3daHI.5BAGh68W.I8T4_V6EYPy8xZJY9J.zxJ4 9_BNKNuXyzdiiTVMCJ1HqZzo4zgWafB_zXdGfVsoSR6ig7fBBNDLCSfqWczwBdUnIV1T5cwNKpwJ KHQruoDpIpEQrJm6ApGIY2UzO751EBNVFCBlRWaDGX5IgBSevabksy3eF5UY8pVploUVbbsZ0cl4 VdnVt_mknpWUTipIeX49LUZ5WRWwikvtPKnStbuBYjUHtLkY7SzL2kYxGQv5uuVITZDewqk33o5u x5sBSbrpD_r8CYalFJUjkNsL5gzqlieKjXecAPeb3Msg9myKt_kgj71lUmhkeUc5QFMiobvFpMjp F7XjsnvLIY7E1hFBv_o5ODumJ7CZGf_.60bJK8PjwxXJiTm2HtUx4QanMoAZ5r7DcR1kqrYRMso6 vLd.hDqpnNAVAb7_FDe9t5hWRbc0TWIkkPXAO0w20eOFSoNBxi0m9L0td.UOPFVm4f4cKooKzPaI _shiLtuxO6a2r0fMRBbEnkbjhNkmoA_mIE97jC0cVNnh3J8grwAv6QxwUhHVYSdJksGwnBBW5cu4 BHJSdl0yKP0jxjU_YSjRpln7oya0vfhVPAcpelAAreMaCwPUThb3IEl3o_CTFIi9WIbzjmad3ClC GIA_X_ZL8i3rHDoT6ArfwZUtRGihX2.DAXR.sTvXQkYEedbPM9FoBy1ImwBxnsUsa9VcFuEZPv9y pvWT9fnNm22psE2hg5kGvnTxnd64bDrO3x774uzgTkCiIkh6NpuAOHHFD4qnbIk5X19pOuSPjXzA cCDX9QoUGRx6Gx_OGIFSLlHGaiV0EsfyuohN9mraa3ywGwas6LMFtzy_1cROadneU79njkX0NExg qOYKhouyX5feGNDoCRaPk8lESb02LmJ7G87WNDhwLaiKMsxj2b6obVz2D_xJYlXF99u9R.yW.hep .VVvz6cxcncl7_UMkOy1M3N4t47aAmouNDuxJrAFOQHd1OHGiIC2BJW5vHr33HP9h5z94150XVFB 4MpWcbzNkKcTvEsI9WFgwK7n5.h1aEvfZwo_D34kiYiGK4nUEAmY798XVGd8pES_e8CaCqnScWyy zaAUVfaLN9Fr6njS9L6vOvK13U88GFveSIEE7sXLzIPv0yJLbpxOq1AGOvxPHFUPeHn4G9P3F_w. eq.WNZFetrx7YHcugX7MiFSUBu..NKZTj8K5rMaxxMvWnzlpjTWRaN84RM1yXTF7Dlx8cwnj5Rie BiZvanPMEcLssJ_5xgLglxL9Sr6ZhKfNnsebmPIPCeWSaBMvGE7p.PveTDYn79A9s2jr8rRjj3Nm MV5LbULm90d5sgC3s.0XQuZcpDo9yBbumUBO6evZajP3r.z7.309MAav7EdzIu3ep5v9iN9ZE7f. YOx_rST73lV_QlSHfJ9YQ3ZNMUuLG4P3x4TD9YmRaoUCTP_rhaAosB4vXEVCv5KfcAHFH7tIgPzm chBmez_15uopZ.OCvf.muTaVwG3ziT7Ny4KT6s.xr5sMjvaQwwrwKW7SMzRQ7cbpWXCYEJuBBkTl PKNcM8YcnCbW8b_hkjiHx36lka87fWdVHrUlo2dZtZ0OfnG_tzDcukoUEI2VT53_Tbt_qwvAt09. LVc1eUVWxemNrve6Czftopmk8_YazKT.a2KAVFjzmgctd0PKPRizmpa1Jo.WAy7TDD8GK5er4A2E LPJk6wiSl4g7Fr2Czmgb4.cCQqvl2s205mWAWS.7a7a_5hyrpEd0x
X-Sonic-MF: <nalini.elkins@insidethestack.com>
Received: from sonic.gate.mail.ne1.yahoo.com by sonic319.consmr.mail.ne1.yahoo.com with HTTP; Wed, 30 Mar 2022 10:32:45 +0000
Date: Wed, 30 Mar 2022 10:32:23 +0000
From: "nalini.elkins@insidethestack.com" <nalini.elkins@insidethestack.com>
To: Mark Smith <markzzzsmith@gmail.com>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>, Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: v6ops list <v6ops@ietf.org>
Message-ID: <1490078896.127608.1648636343527@mail.yahoo.com>
In-Reply-To: <db66fe14-4391-b3ca-2219-e435d7e9cb28@gmail.com>
References: <52661a3d-75dc-111a-3f23-09b10d7cb8d4@gmail.com> <A72CDDDB-CDCE-4EAF-B95E-997C764DB2C4@gmail.com> <9175dc32-45c1-e948-c20a-3bcc958b77b9@gmail.com> <YjmJQMNgnJoSInUw@Space.Net> <D75EF08F-6A41-41B2-AFB2-649CBCC1D83E@consulintel.es> <CAPt1N1nRnYUFA=yyJHx6t52yqWbmcd2Tf1H8gQuCZBd3Q3VqJw@mail.gmail.com> <7F4AEB43-4B24-4A21-AE9D-3EB512B98C46@consulintel.es> <8fac4314b8244ba6b33eea68694296d0@huawei.com> <9A13E47B-75D0-443F-9EE9-D2917ACB2D0F@consulintel.es> <CAO42Z2xUG+BXj+VQpajed9aGjH+q-HR7RX7C-T4DsTbouz7xWQ@mail.gmail.com> <db66fe14-4391-b3ca-2219-e435d7e9cb28@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_127607_957764972.1648636343522"
X-Mailer: WebService/1.1.20001 YMailNorrin
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/LyzHDVqGoItDmlwKggLtQGXfUss>
Subject: Re: [v6ops] Thoughts about wider operational input
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: Wed, 30 Mar 2022 10:32:53 -0000

Brian,
>  Others have mentioned the OPEX cost of diagnosing NAT-induced problems even with the enterprise.
As someone who has been involved with diagnosing problems on enterprise networks for 30+ years, I can tell you the complexity of finding and solving problems with IPv6, adds a huge new and glorious dimension to troubleshooting.
Don't get me wrong, I am a complete IPv6 proponent.  I am just saying that if ease of diagnostics is what you are looking for, IMHO, that is exactly the opposite of what is likely to happen.  
For example, take the scenario below:
- User is connecting via a home network routed through a broadband provider which supports both IPv4 and IPv6.  This home network uses a NAT.
Let's assume the user has the following IP addresses:
1. IPv6 Address. . . . . :2a02:c7d:500e:f900:f5:8404:5e0:430eGlobal Unicast IPv6 : routable over the Internet 
2. IPv6 Address. .   . . :fd4f:f7d8:2459:0:f5:8404:5e0:430eUnique Local Unicast (ULA) IPv6 :not routable over Internet
3. Temporary IPv6 Address:2a02:c7d:500e:f900:a53a:5a06:130b:a2ffPrivacy Global Unicast IPv6 :routable over the Internet 
4. Temporary IPv6 Address:fd4f:f7d8:2459:0:a53a:5a06:130b:a2ffPrivacy ULA IPv6 :not routable over the Internet 
5. Link-local IPv6 Address:fe80::f5:8404:5e0:430e%13Private Interface IPv6: not routable over the Internet 
6. IPv4 Address. . .  . . :192.168.0.6Site Local GUA IPv4 : not routable over the Internet 
The NAT has the external IPv4 address: 156.21.33.134 (IPv4 GUA: made up address)
Today, most enterprises do not have GUA or ULA IPv6 addresses but this will change in the next 5 years.  The above (other than the IPv4 NAT address) are real addresses from an IPConfig on my laptop on a network in the RIPE region. (This is an interesting use of ULAs, BTW.  Their DNS appears to work over ULA.)
So, if this user calls the network Help Desk of an enterprise and says "I have a problem connecting / with my application / with response time" and the Help Desk first wants to know the IP address the user has, this becomes quite interesting.  Which exact IP address are we talking about?  I have actually started a paper to allow enterprises to cope with this scenario, if anyone would like to help / make it into an Internet draft, please let me know.  I will actually start a new email thread with drafts I believe need to be written to help enterprises.
Now, before people start telling me to convert to an IPv6-only network and such like, please stop.   Enterprises move at a snails pace and they are very risk-averse.   I can guarantee you that talk like that will only get you completely not listened to.  
Thanks,

Nalini Elkins
CEO and Founder
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360 

    On Tuesday, March 29, 2022, 09:06:46 PM PDT, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:  
 
 > - What business problem does or can IPv6 solve better than existing IPv4?

That suggests to me that an even earlier question is:

  - What business problems does IPv4 cause today?

For example, I'm convinced that multiple layers of NAT44 (today's reality) cause problems, whose symptoms are often (from the end user's view) failed sessions that have to be repeated. These are *never* reported to any help desk and so don't appear in anybody's statistics - but they do detract from user experience and so presumably have an impact: lost or delayed 
business.

Others have mentioned the OPEX cost of diagnosing NAT-induced problems even with the enterprise.

What else?

Regards
    Brian Carpenter

On 30-Mar-22 16:22, Mark Smith wrote:
> 
> 
> On Wed, 23 Mar 2022, 01:55 JORDI PALET MARTINEZ, <jordi.palet=40consulintel.es@dmarc.ietf.org <mailto:40consulintel.es@dmarc.ietf.org>> wrote:
> 
>    Hi Eduard,____
> 
>    __ __
> 
>    What I meant is that I will like to avoid the issues that NAT creates for apps. We must aim for something better.
> 
> This.
> 
> IPv6+NAT creates a lot of the issues that IPv4+NAT does, so why bother deploying IPv6 when you've already got the equivalent via IPv4 today?
> 
> 
> People need to understand why enterprises go to the expense of deploying technologies.
> 
> Technology is a means to an end, not the end itself. Technology in business either saves money or makes money for the business.
> 
> Enterprises in the 1990s didn't really deploy IPv4, they deployed global email and WWW access. Deploying IPv4 was the means to reaching those ends, because IPv4 underpinned them.
> 
> 
> So the questions to think about in the context of businesses and enterprises and IPv6 are:
> 
> - What business problem does or can IPv6 solve better than existing IPv4?
> 
> - IPv6 is the technology means to an end, so what is or are the ends that are of value to a business, where IPv6 is the better underpinning technology than IPv4 to reach those ends?
> 
> - How can deploying IPv6 save or make money for a business?
> 
> Regards,
> Mark.
> 
> 
> 
>    ____
> 
>    __ __
> 
>    On the other side, using an experimental protocol for production networks, in my opinion is a big “NO”.____
> 
>    __ __
> 
>    Regards,____
> 
>    Jordi____
> 
>    @jordipalet____
> 
>    __ __
> 
>    __ __
> 
>    __ __
> 
>    El 22/3/22, 13:04, "v6ops en nombre de Vasilenko Eduard" <v6ops-bounces@ietf.org <mailto:v6ops-bounces@ietf.org> en nombre de vasilenko.eduard=40huawei.com@dmarc.ietf.org <mailto:40huawei.com@dmarc.ietf.org>> escribió:____
> 
>    __ __
> 
>    Hi Jordi,____
> 
>    __ __
> 
>    I understand the desire to fix broken things. (I doubt it is possible)____
> 
>    But why NPT+ULA is not enough for MHMP now?____
> 
>    It is very similar to what Enterprises and small businesses have now.____
> 
>    They would be happy.____
> 
>    __ __
> 
>    Eduard____
> 
>    *From:*v6ops [mailto:v6ops-bounces@ietf.org <mailto:v6ops-bounces@ietf.org>] *On Behalf Of *JORDI PALET MARTINEZ
>    *Sent:* Tuesday, March 22, 2022 12:34 PM
>    *To:* v6ops@ietf.org <mailto:v6ops@ietf.org>
>    *Subject:* Re: [v6ops] Thoughts about wider operational input____
> 
>    __ __
> 
>    You’re right. Let’s say it in a different way, as may be my first email was not clear on this.____
> 
>    __ __
> 
>    __1.__I don’t think we want again to repeat the NAT problems, so NPT is not a valid solution for me.____
> 
>    __2.__I think in the future almost every site could want to be multihomed, in some cases “n” links active, many other cases just as a backup.____
> 
>    __3.__This means that renumbering is not (probably) a valid choice in any cases.____
> 
>    __4.__Can we make PI work in such “huge scale” scenario?____
> 
>    __5.__Can source-address forwarding work and solve all that, or we need that and/or something else.____
> 
>    __ __
> 
>    Only if we solve this, organizations could learn that NAT with IPv6 
is not the solution, but something better that provides the same results, 
and no need to have “private” addresses, because the way NAT is offering a “different” addressing inside and outside is not NAT per-se, but statefull firewalling.____
> 
>    __ __
> 
>    Regards,____
> 
>    Jordi____
> 
>    @jordipalet____
> 
>    __ __
> 
>    __ __
> 
>    __ __
> 
>    El 22/3/22, 10:27, "v6ops en nombre de Ted Lemon" <v6ops-bounces@ietf.org <mailto:v6ops-bounces@ietf.org> en nombre de mellon@fugue.com <mailto:mellon@fugue.com>> escribió:____
> 
>    __ __
> 
>    Is it really hncp that we needed here?  I think the key tech we need is source-address-based forwarding, and babel i think has delivered that. Granted, getting that into soho routers is a problem. ____
> 
>    __ __
> 
>    On Tue, Mar 22, 2022 at 10:11 JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org <mailto:40consulintel.es@dmarc.ietf.org>> wrote:____
> 
>        Maybe the terminology is not the most appropriate and we should 
talk about "organizations", because there are many types of networks that 
have the same problem and those are not enterprises (such as government sites, NGOs, etc.).
> 
>        The problem is the same regardless of the "size" of the organization. The difference is that "today" most SMEs don't have that problem because they don't have PI, but it may turn the same when they realize that not being PI have renumbering issues if changing the ISP. Of course, again, if we talk about a "small" SME, then may not be an issue, they only have 40 or 50 devices to renumber (your mileage will vary), not easy but not "terrible".
> 
>        On the rest of Gert comments, definitively I agree, and specially on our big mistake not working further on HNCP.
> 
>        Regards,
>        Jordi
>        @jordipalet
> 
> 
> 
>        El 22/3/22, 9:31, "v6ops en nombre de Gert Doering" <v6ops-bounces@ietf.org <mailto:v6ops-bounces@ietf.org> en nombre de gert@space.net <mailto:gert@space.net>> escribió:
> 
>              Hi,
> 
>              On Tue, Mar 22, 2022 at 11:42:12AM +1300, Brian E Carpenter wrote:
>              > I agree with Jordi that multihoming is a genuine impediment. What isn't generally realised is that it's a problem of scale when considering at least 10,000,000 enterprises, much more than it's 
a problem of IPv6 itself.
> 
>              What is "an enterprise"?
> 
>              My stance on this is that for "largely unmanaged 
SoHo networks" - which
>              could be called "small enterprise" - dual-enduser-ISP with dual-/48 or
>              NPT66 gets the job done in an easy and scalable way (HNCP would have
>              been great, but IETF politics killed it).
> 
>              "Enterprise that truly need their own independent fully managed network
>              with multiple ISP uplinks and fully routed independent address space"
>              are probably way less than 10 million...
> 
>              Half of them do not want Internet access anyway, 
just access to their
>              ALGs that will do the filtering and TLS inspection and everything, and
>              then out to the Internet as a new TCP session (= 
could be done with
>              DMZ islands of upstream-provider-allocated space 
just fine).
> 
> 
>              We need to work on our marketing regarding multihoming.  "What is it that
>              you get, what is the cost, which of the variants 
do you want, and why...?"
> 
>              Gert Doering
>                      -- NetMaster
>              --
>              have you enabled IPv6 on something today...?
> 
>              SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
>              Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
>              D-80807 Muenchen          
       HRB: 136055 (AG Muenchen)
>              Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279
> 
>              _______________________________________________
>              v6ops mailing list
>        v6ops@ietf.org <mailto:v6ops@ietf.org>
>        https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> 
> 
> 
>        **********************************************
>        IPv4 is over
>        Are you ready for the new Internet ?
>        http://www.theipv6company.com <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.
> 
> 
> 
>        _______________________________________________
>        v6ops mailing list
>        v6ops@ietf.org <mailto:v6ops@ietf.org>
>        https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>____
> 
>    _______________________________________________ v6ops mailing list v6ops@ietf.org <mailto:v6ops@ietf.org> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops> ____
> 
> 
>    **********************************************
>    IPv4 is over
>    Are you ready for the new Internet ?
>    http://www.theipv6company.com <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.____
> 
>    _______________________________________________ v6ops mailing list v6ops@ietf.org <mailto:v6ops@ietf.org> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops> ____
> 
> 
>    **********************************************
>    IPv4 is over
>    Are you ready for the new Internet ?
>    http://www.theipv6company.com <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.
> 
>    _______________________________________________
>    v6ops mailing list
>    v6ops@ietf.org <mailto:v6ops@ietf.org>
>    https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops