Re: Objection to draft-ietf-6man-rfc4291bis-07.txt

Alexandre Petrescu <alexandre.petrescu@gmail.com> Fri, 03 March 2017 17:43 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61D6129507 for <ipv6@ietfa.amsl.com>; Fri, 3 Mar 2017 09:43:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.351
X-Spam-Level:
X-Spam-Status: No, score=-5.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, LOTS_OF_MONEY=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 32pQlDK9kj1M for <ipv6@ietfa.amsl.com>; Fri, 3 Mar 2017 09:43:32 -0800 (PST)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5535D129435 for <ipv6@ietf.org>; Fri, 3 Mar 2017 09:43:31 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v23HhSUu027608; Fri, 3 Mar 2017 18:43:28 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 80D3020D712; Fri, 3 Mar 2017 18:43:28 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 70F9F20D711; Fri, 3 Mar 2017 18:43:28 +0100 (CET)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v23HhSuH021093; Fri, 3 Mar 2017 18:43:28 +0100
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: Ca By <cb.list6@gmail.com>, Mark Andrews <marka@isc.org>, mohamed.boucadair@orange.com
References: <20170223134026.GI5069@gir.theapt.org> <20170302153611.36506f85@envy> <CAKD1Yr1SbdE-i-oGhi2kEFBWTOi_-FzgVdMYkMWjCEtw0MRRMg@mail.gmail.com> <ee3b73b1-64fd-6fef-bc0a-53b325f0bcfd@gmail.com> <alpine.DEB.2.02.1703021902010.30226@uplift.swm.pp.se> <efe2504e-198c-36ce-c79f-be1886e5d031@gmail.com> <alpine.DEB.2.02.1703021929170.30226@uplift.swm.pp.se> <7338F75E-94D9-4330-99C5-C5A9D7B0A066@consulintel.es> <8c848dd1-ceab-887c-5348-2b1bd9920bfa@gmail.com> <367D5BA9-F588-4F2B-A783-2C8BAF9B27BF@consulintel.es> <b6ff1b86-698c-0b8f-6a08-7d6bf8a33c8f@gmail.com> <E2709C92-4C32-4E1C-A8A1-B6B98F0BF336@consulintel.es> <6b89579e-62e8-dfb5-070e-b08989b9492a@gmail.com> <20170302224856.E63AB65D34EC@rock.dv.isc.org> <88e0e23e-d114-8538-a3b5-ff9d8cda1045@gmail.com> <787AE7BB302AE849A7480A190F8B933009E1BE96@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <31396f41-0f08-3677-8012-4fd54247aa76@gmail.com> <CAD6AjGQKd9fZr6Aot6LG4CzRdftq5L2xJ5YcVnzWAWWWFXke_A@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <3f39bb3b-a401-1a1c-d610-b52a7948a98b@gmail.com>
Date: Fri, 3 Mar 2017 18:43:33 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <CAD6AjGQKd9fZr6Aot6LG4CzRdftq5L2xJ5YcVnzWAWWWFXke_A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/O6wTOtGWBKyV9SiQrE_EkN8pjj4>
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Mar 2017 17:43:35 -0000


Le 03/03/2017 à 17:37, Ca By a écrit :
>
> On Fri, Mar 3, 2017 at 2:52 AM Alexandre Petrescu
> <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>>
> wrote:
>
>
>
> Le 03/03/2017 à 11:30, mohamed.boucadair@orange.com
> <mailto:mohamed.boucadair@orange.com> a écrit :
>> Hi Alex,
>>
>>
>>> This is why I dont understand the cellular operators dont do
>>> DHCPv6-PD. And I guess it is so because they are told it's
>>> sufficient to run the 64share INFORMATIONAL RFC.
>>
>> This is a chicken-and-egg problem: you need both the cellular
>> device and the network side to support prefix delegation + prefix
>> exclude option,
>
> How can that vicious circle be broken?
>
>
> Money.

Prior to giving money, investors want to see a proof-of-concept.

We cant make a proof-of-concept with a real cellular operator because
no-one delivers PD.

> This is not a 3GPP release issue, this is a money backing the
> deployment cost. And, despite the cost of free software being $0, my
> ipv6 project was charged nearly a million dollars in QA cost from
> adjacent business units... just as an example that nothing is free.

If cellular operators are going to ask 10.000EUR each time a protocol
needs deployment then we wont go far.

I think they should plan differently.

I think DHCPv6-PD deployment is a too key issue to just put a price tag 
on it.

Just pouring money on something can also worsen the problem worse: you 
just say a figure and then everybody calls you with offers, some with 
less technical merit than others.

> That said, if the v2v customer requiring PD put in an order for
> 10,000+ (guessing) lines , they would likely get dhcpv6-pd.

What is '10.000+' lines?  Do you mean one may need 10.000EUR in order to
get DHCPv6-PD deployed on a cellular operator network?

> Asking for it at ietf, not likely helpful.

I am talking about this at IETF because it is at IETF that many
operators are present and make decisions.  I saw it already.

Obviously I am not asking the IETF to deploy some protocol.

What I am asking at IETF is that people retire 64share from the
recommendation to 3GPP.  That is just a small step.

> The standards and guidance all say do PD,

Well no.  The guidance reads 'until PD arrives do 64share'.  They say
'PD is the target', they dont say 'PD is a MUST'.  A 'target' is
something that may take some time to reach... how long time?  It's now
several years...

Now I want them to say 'dont do 64share'.

> now you just need $

But the community of deployers of vehicular network devices _already_
pays money under the form of subscriptions.  And that's huge money
during years, strongly backed alliances, much more than just 10.000EUR.

Isn't it that these cellular operators may be greedy when asking for
more and more money in order to deploy a particular protocol?

I would rather ask these operators:

What's the technical difficulty of deploying DHCPv6-PD?

Is it difficulty to re-visit IPv6 addressing plans? (presumably planned
for one /64 per Host would now have to do more).

Is it billing issue?

Is it fear of too much traffic?

Security?

Is it the 3GPP recommendation of using 64share instead of DHCPv6-PD?

Alex


> I have some smartphone and other M2M modules here on which we could
> try a few things.  What would operator expect to hear from this
> smartphone?
>
> Is the ISC DHCPv6-PD Client messages enough?
>
> Does operator also need 'prefix exclude'?  Mandatory?
>
> Is the ISC DHCPv6-PD implementing 'prefix exclude'?
>
>> but while waiting for that to happen /64 share is your solution.
>
> Operator should understand that /64 share is impossible to use in
> concrete settings like vehicular networks, road-side units, and
> similar.
>
>> Below what you can read in RFC7849:
>
> If I read it I will certainly suggest improvements to it.  It should
>  reflect reality.
>
>> ===== L_REC#1:  For deployments that require that the same /64
>> prefix be shared, the cellular device should support [RFC7278] to
>> enable sharing a /64 prefix between the LAN and the WAN
>> interfaces. The WAN interface is the one towards the Gateway GPRS
>> Support Node (GGSN) / Packet Data Network Gateway (PGW).
>>
>> Prefix Delegation (refer to L_REC#2) is the target solution for
>
> It's not a 'target', it is a 'now'.
>
>> distributing prefixes in the LAN side but, because the device may
>> attach to earlier 3GPP release networks, a means to share a /64
>> prefix is also recommended [RFC7278].
>
> No!  That recommendation is wrong.  That RFC is INFORMATIONAL and we
>  should stop recommending it.  I has huge problems, at least with
> respect to scalability.
>
>> [RFC7278] must be invoked only if Prefix Delegation is not in use.
>
> ... _and_ if it works for the network being deployed.  If it does not
> work, it MUST NOT be invoked.
>
>> L_REC#2:  The cellular device must support Prefix Delegation
>> capabilities [RFC3633] and must support the Prefix Exclude Option
>> for DHCPv6-based Prefix Delegation as defined in [RFC6603].
>
> Why is the 'prefix exclude' option a MUST?  I may need to understand
>  that, by further reading...
>
>> Particularly, it must behave as a Requesting Router.
>
> Yes, and it is a MUST not a must.
>>
>> Cellular networks are more and more perceived as an alternative to
>>  fixed broadband networks for home IP- based services delivery;
>
> I agree.
>
>> especially with the advent of smartphones and 3GPP data dongles.
>
> _and_ M2M and IoT devices which are not 'dongles' (btw, 'dongles' are
> only the USB dongles, there are no other kinds of dongles).
>
>> There is a need for an efficient mechanism to assign larger
>> prefixes (other than /64s) to cellular hosts
>
> I fully agree.
>
>> so that each LAN segment can get its own /64 prefix
>
> _if_ that LAN is an Ethernet, yes it needs a /64.  Often it is the
> case.
>
>> and multi-link subnet issues to be avoided.
>
> I agree, RFC must be cited.
>
>> In case a prefix is delegated to a cellular host using DHCPv6, the
>>  cellular device will be configured with two prefixes:
>>
>> (1)  one for the 3GPP link allocated using the Stateless Address
>> Autoconfiguration (SLAAC) mechanism and
>>
>> (2)  another one delegated for LANs acquired during the Prefix
>> Delegation operation.
>
> I dont know what you mean by 'configured', but this second prefix may
> just be in the rt table of the device (not necessarily on its
> interfaces).
>
> How about the default route?
>
>> Note that the 3GPP network architecture requires both the WAN and
>> the delegated prefix to be aggregatable so the subscriber can be
>> identified using a single prefix.
>
> IT's good to avoid waste.
>
>> Without the Prefix Exclude Option, the delegating router (GGSN/PGW)
>> will have to ensure compliance with [RFC3633] (e.g., halving the
>> delegated prefix and assigning the WAN prefix out of the first half
>> and the prefix to be delegated to the terminal from the second
>> half).
>
> So 'prefix exclude' is not mandatory in order to have DHCPv6-PD
> working.
>
>>
>> Because Prefix Delegation capabilities may not be available in some
>> attached networks, L_REC#1 is strongly recommended to accommodate
>> early deployments. =====
>
> It's wrong.  We should _never_ recommend somehting we know it does
> not scale.  Because if we do it may get in widespread use and later
> we'll have a hard time getting rid of.
>
> Alex
>
>>
>> Cheers, Med
>>
>>
>>> -----Message d'origine----- De : ipv6
>>> [mailto:ipv6-bounces@ietf.org <mailto:ipv6-bounces@ietf.org>] De
> la part de Alexandre Petrescu
>>> Envoyé : vendredi 3 mars 2017 10:29 À : Mark Andrews Cc :
>>> ipv6@ietf.org <mailto:ipv6@ietf.org> Objet : Re: Objection to
>>> draft-ietf-6man-rfc4291bis-07.txt
>>>
>>>
>>>
>>> Le 02/03/2017 à 23:48, Mark Andrews a écrit :
>>>>
>>>> In message <6b89579e-62e8-dfb5-070e-b08989b9492a@gmail.com
> <mailto:6b89579e-62e8-dfb5-070e-b08989b9492a@gmail.com>>,
>>>> Alexandre Petrescu writes:
>>>>> Le 02/03/2017  20:25, JORDI PALET MARTINEZ a crit :
>>>>>> I understood from one of your previous emails that 3GPP
>>>>>> doesnt require DHCPv6-PD.
>>>>>
>>>>> Right - if I understand correctly, it does not require
>>>>> DHCPv6-PD on the UE.  Maybe in the core, but not in the UE.
>>>>>
>>>>>> RFC6653, suggest its use, so probably we got confused
>>>>>> ourselves and 3GPP is actually using it.
>>>>>>
>>>>>> 6rd is a different thing, because is actually IPv4 link and
>>>>>> IPv6 is a tunnel, so you typically use DHCP (v4).
>>>>>
>>>>> I agree.
>>>>>
>>>>>> In IPv6-only world (including cellular), the WAN link will
>>>>>>  be IPv6-only instead of dual-stack. This is already
>>>>>> happening.
>>>>>>
>>>>>> If they dont use it, I guess is the same reason why big
>>>>>> vendors didnt implemented yet RDDNS
>>>>>
>>>>> I wonder if Windows refusing RDNSS doesn't have somehting to
>>>>>  do with its Teredo; and extending this logic to smartphones:
>>>>>  the lack of answers to DHCPv6-PD issued from the UE may have
>>>>>  something to do with 464xlat presence.
>>>>>
>>>>> Could it be that 464xlat presence on UE makes it that
>>>>> DHCPv6-PD is impossible on same UE?
>>>>
>>>> No.  They are or should be orthogonal.  One is about providing
>>>>  IPv4 as as service.  The other is about providing IPv6 address
>>>>  space.
>>>
>>> I can agree.
>>>
>>> With my operator I asked her once 'why not giving DHCPc6-PD to
>>> smartphone' and she replied 'because now we do 464xlat on the
>>> smartphone, and that is sufficient'.  As such it sounds illogical
>>> statement, although I guess s/he has some reasons to say so.
>>>
>>> But let me ask differently: maybe it's because 464xlat requires
>>> some kernel version that DHCPv6-PD doestn support, or vice-versa?
>>> Maybe it's because once you run 464xlat on smartphone it takes
>>> control of the unique default route and DHCPv6-PD couldnt?  Some
>>> reason like that?
>>>
>>> Has one tried DHCPv6-PD software simultaneosuly with 464xlat?
>>> (even knowing the cellular operator would not reply to DHCPv6
>>> Slicitations).
>>>
>>>>>> Cellular world is using 464XLAT, and they use DHCPv6-PD.
>>>>>> Check RFC6877.
>>>>>
>>>>> I guess you mean cellular stations (like BS, not the User
>>>>> Equipment) uses DHCPv6-PD within the fixed network.
>>>>
>>>> No, the UE should be using DHCPv6-PD.  This is how tethered
>>>> equipement should be getting IPv6 address space.
>>>
>>> I agree with yuo.
>>>
>>> This is why I dont understand the cellular operators dont do
>>> DHCPv6-PD. And I guess it is so because they are told it's
>>> sufficient to run the 64share INFORMATIONAL RFC.
>>>
>>> Are the people advising 64share to tethering-willing telecom
>>> operators conscious it's non-interoperable?
>>>
>>> Is the 64share advice coming together with the claim there are
>>> enough /64s out there?
>>>
>>> Alex
>>>
>>>>> Because cellular operator I am aware of replies to DHCPv6-PD
>>>>>  requests issued from an User Equipment.
>>>>>
>>>>> Alex
>>>>>
>>>>>>
>>>>>> Saludos, Jordi
>>>>>>
>>>>>>
>>>>>> -----Mensaje original----- De: ipv6 <ipv6-bounces@ietf.org
> <mailto:ipv6-bounces@ietf.org>>
>>>>>> en nombre de Alexandre Petrescu
>>>>>> <alexandre.petrescu@gmail.com
> <mailto:alexandre.petrescu@gmail.com>> Responder a:
>>>>>> <alexandre.petrescu@gmail.com
> <mailto:alexandre.petrescu@gmail.com>> Fecha: jueves, 2 de marzo de
>>>>>> 2017, 20:15 Para: <ipv6@ietf.org <mailto:ipv6@ietf.org>>
> Asunto: Re: Objection to
>>>>>> draft-ietf-6man-rfc4291bis-07.txt
>>>>>>
>>>>>>
>>>>>>
>>>>>> Le 02/03/2017  20:06, JORDI PALET MARTINEZ a crit :
>>>>>>> I guess because the lack of DHCPv6-PD support, as you
>>>>>>> already indicated?
>>>>>>
>>>>>> But for deity's sake - DHCPv6-PD is available as open
>>>>>> source... it's common software.  Just download and install.
>>>>>> The IETF Specs suggest it, and the 3GPP specs require it
>>>>>> too.
>>>>>>
>>>>>> There must be something else making these router equipment
>>>>>>  manufacturers refraining from downloading and installing
>>>>>> DHCPv6-PD.
>>>>>>
>>>>>>> I think majority of the households and business customers
>>>>>>> get configured the CPE by means for DHCPv6-PD
>>>>>>
>>>>>> AFAIK my CPE at home does not use DHCPv6-PD, but something
>>>>>>  based on IPv4, like 6rd.  I think it's something
>>>>>> developped in-house at that particular operator.
>>>>>>
>>>>>> Alex
>>>>>>
>>>>>>>
>>>>>>> Saludos, Jordi
>>>>>>>
>>>>>>>
>>>>>>> -----Mensaje original----- De: ipv6
>>>>>>> <ipv6-bounces@ietf.org
> <mailto:ipv6-bounces@ietf.org>>
>>>>>>> en nombre de Alexandre Petrescu
>>>>>>> <alexandre.petrescu@gmail.com
> <mailto:alexandre.petrescu@gmail.com>> Responder a:
>>>>>>> <alexandre.petrescu@gmail.com
> <mailto:alexandre.petrescu@gmail.com>> Fecha: jueves, 2 de marzo de
>>>>>>> 2017, 20:02 Para: <ipv6@ietf.org <mailto:ipv6@ietf.org>>
> Asunto: Re: Objection to
>>>>>>> draft-ietf-6man-rfc4291bis-07.txt
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Le 02/03/2017  19:54, JORDI PALET MARTINEZ a crit :
>>>>>>>> Actually, is not correct that most use /56 for
>>>>>>>> residential.
>>>>>>>>
>>>>>>>>> From my last review of the survey, worldwide, 22% use
>>>>>>>>> /48, 35% use /56, but there is a lot of ISPs (33%)
>>>>>>>>> doing it wrong and using /64, which of course, we are
>>>>>>>>> explaining them that is wrong. 10% use other sizes.
>>>>>>>
>>>>>>> So how comes that households can get /56s but smartphones
>>>>>>> no?
>>>>>>>
>>>>>>> Really there must be something there hidden.
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>>>
>>>>>>>> Full details at:
>>>>>>>>
>>>>>>>>
>>>>> https://labs.ripe.net/Members/jordipaletm/results-of-the-ipv6-
>
>>>>>
>>>>>
>>>>>
>>>>>
>> deployment-s
>>>>>
>>>>>
>>>>>
>>>>>
>>> urvey
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>> Saludos, Jordi
>>>>>>>>
>>>>>>>>
>>>>>>>> -----Mensaje original----- De: ipv6
>>>>>>>> <ipv6-bounces@ietf.org <mailto:ipv6-bounces@ietf.org>>
>>>>>>>> en
> nombre de Mikael Abrahamsson
>>>>>>>> <swmike@swm.pp.se <mailto:swmike@swm.pp.se>>
>>>>>>>> Organizacin:
> People's Front Against
>>>>>>>> WWW Responder a: <swmike@swm.pp.se
> <mailto:swmike@swm.pp.se>> Fecha: jueves, 2 de
>>>>>>>> marzo de 2017, 19:33 Para: Alexandre Petrescu
>>>>>>>> <alexandre.petrescu@gmail.com
> <mailto:alexandre.petrescu@gmail.com>> CC: <ipv6@ietf.org
> <mailto:ipv6@ietf.org>>
>>>>>>>> Asunto: Re: Objection to
>>>>>>>> draft-ietf-6man-rfc4291bis-07.txt
>>>>>>>>
>>>>>>>> On Thu, 2 Mar 2017, Alexandre Petrescu wrote:
>>>>>>>>
>>>>>>>>> YEs yes, but how much of that /44 is covering the
>>>>>>>>> end-users and how much is reserved for
>>>>>>>>> interconnnections?
>>>>>>>>
>>>>>>>> Nothing. It's /44 to the GGSN/SPGW.
>>>>>>>>
>>>>>>>>> Ah great, but I guess few cellular operators (if
>>>>>>>>> any?) are LIRs. Or maybe that's true and I didnt
>>>>>>>>> know.
>>>>>>>>
>>>>>>>> You don't know.
>>>>>>>>
>>>>>>>>> If all this were that simple and clearcut - there are
>>>>>>>>> enough /64s out there - then why operators only
>>>>>>>>> assign one per one end user?
>>>>>>>>
>>>>>>>> Because DHCPv6-PD hasn't been implemented in mobile
>>>>>>>> networks yet (that I know of). So that's all they can
>>>>>>>> do per 3GPP standards.
>>>>>>>>
>>>>>>>> Residential rollouts, most use /56 per customer.
>>>>>>>>
>>>>>>>>> From the RIRs, you can without further justification
>>>>>>>>>  get /48 per "site",
>>>>>>>> so if you show up to RIR and you're LIR and you say
>>>>>>>> "hello, I have 40 million customers and I want to give
>>>>>>>>  each customer a /48" then they'll give you a /22 most
>>>>>>>>  likely. You're perfectly within your right as an
>>>>>>>> operator to deploy /48 per customer per current RIR
>>>>>>>> rules that I am aware of.
>>>>>>>>
>>>>>>>> -- Mikael Abrahamsson    email: swmike@swm.pp.se
> <mailto:swmike@swm.pp.se>
>>>>>>>>
>>>>>>>>
> --------------------------------------------------------------------
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
> IETF IPv6 working group mailing list ipv6@ietf.org
> <mailto:ipv6@ietf.org> Administrative
>>>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>>>
> --------------------------------------------------------------------
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
> ********************************************** IPv4 is over Are
>>>>>>>> you ready for the new Internet ?
>>>>>>>> http://www.consulintel.es The IPv6 Company
>>>>>>>>
>>>>>>>> This electronic message contains information which may
>>>>>>>>  be privileged or confidential. The information is
>>>>>>>> intended to be for the use of the individual(s) named
>>>>>>>> above. If you are not the intended recipient be aware
>>>>>>>> that any disclosure, copying, distribution or use of
>>>>>>>> the contents of this information, including attached
>>>>>>>> files, is prohibited.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
> --------------------------------------------------------------------
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
> IETF IPv6 working group mailing list ipv6@ietf.org
> <mailto:ipv6@ietf.org> Administrative
>>>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>>>
> --------------------------------------------------------------------
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
> --------------------------------------------------------------------
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> IETF IPv6 working group mailing list ipv6@ietf.org
> <mailto:ipv6@ietf.org>
>>>>>> Administrative
>>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>>
> --------------------------------------------------------------------
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>>>>>>
>>>>>>>
>>>>>>>
> ********************************************** IPv4 is over Are
>>>>>>> you ready for the new Internet ?
>>>>>>> http://www.consulintel.es The IPv6 Company
>>>>>>>
>>>>>>> This electronic message contains information which may be
>>>>>>> privileged or confidential. The information is intended
>>>>>>> to be for the use of the individual(s) named above. If
>>>>>>> you are not the intended recipient be aware that any
>>>>>>> disclosure, copying, distribution or use of the contents
>>>>>>> of this information, including attached files, is
>>>>>>> prohibited.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
> --------------------------------------------------------------------
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>>>>>>
>>>>>>>
>>>>>>>
> IETF IPv6 working group mailing list ipv6@ietf.org
> <mailto:ipv6@ietf.org> Administrative
>>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>>
> --------------------------------------------------------------------
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>
>>>>>>>
>>>>>>>
>>>>>>>
> --------------------------------------------------------------------
>>>>>> IETF IPv6 working group mailing list ipv6@ietf.org
> <mailto:ipv6@ietf.org>
>>>>>> Administrative Requests:
>>>>>> https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>
> --------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>>>>>>
>>>>>>
>>>>>>
> ********************************************** IPv4 is over Are you
>>>>>> ready for the new Internet ? http://www.consulintel.es The
>>>>>>  IPv6 Company
>>>>>>
>>>>>> This electronic message contains information which may be
>>>>>> privileged or confidential. The information is intended to
>>>>>> be for the use of the individual(s) named above. If you are
>>>>>> not the intended recipient be aware that any disclosure,
>>>>>> copying, distribution or use of the contents of this
>>>>>> information, including attached files, is prohibited.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
> --------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>>>>>>
>>>>>>
>>>>>>
> IETF IPv6 working group mailing list ipv6@ietf.org
> <mailto:ipv6@ietf.org> Administrative
>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>
> --------------------------------------------------------------------
>>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>>>>>>
>>>>>>
>>>>>>
> --------------------------------------------------------------------
>>>>> IETF IPv6 working group mailing list ipv6@ietf.org
> <mailto:ipv6@ietf.org>
>>>>> Administrative Requests:
>>>>> https://www.ietf.org/mailman/listinfo/ipv6
>>>>>
> --------------------------------------------------------------------
>>>>
>>>
>>>
>>>>>
>>>>>
>>>>>
> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list ipv6@ietf.org
> <mailto:ipv6@ietf.org> Administrative
>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>
>>>
>>>
>>>
>>>
>
>
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list ipv6@ietf.org
> <mailto:ipv6@ietf.org> Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>