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

Ca By <cb.list6@gmail.com> Fri, 03 March 2017 16:37 UTC

Return-Path: <cb.list6@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 F2F701298CE for <ipv6@ietfa.amsl.com>; Fri, 3 Mar 2017 08:37:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.747
X-Spam-Level:
X-Spam-Status: No, score=-0.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 pI3-6mkfdn9V for <ipv6@ietfa.amsl.com>; Fri, 3 Mar 2017 08:37:28 -0800 (PST)
Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 C537A1298D0 for <ipv6@ietf.org>; Fri, 3 Mar 2017 08:37:27 -0800 (PST)
Received: by mail-wr0-x233.google.com with SMTP id g10so77273352wrg.2 for <ipv6@ietf.org>; Fri, 03 Mar 2017 08:37:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qACONTNZ/ycRpKntenDDRp7PAfy07b4lW8JIeQjT2js=; b=b6umh+5dnmYJhnbzyFx0PD6l0NhuCUyvWgib80hfB5usmzzbsW/goruZVRBm6BWAHC M60BLa4fEniJupH4Rl0e7P5lX0OdzEeC9iXDmr4wZXfFZeBUsncTen+Ltst6AW/8TUJR QFu8vv5MGKh5r4YGjhWw7U7J1uE7iZOGk8OCOabd3exTB7nDTE3uL849CCiVRa4NKljc NR8ffxGIjEljYl6aTVc/R+UTSzbd6Cp8nbwHlvelXlV5HvpEpanHh4e/jjJELgp7/PjJ 3Tuv0q59g7BogBi69Iynj2thEZayFwxBpWQLYsPXW3zelqCFl5pe/e9Mx0LcG1EVqrXZ 1v5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qACONTNZ/ycRpKntenDDRp7PAfy07b4lW8JIeQjT2js=; b=GsHDrKqd9QTSxxMTtSFxJXU32GDupbKCNUQsxdGQEp/Xy5J8JjSFdYGzDp3Lwyp+6T tYxs8DNPW5rkJiyAGu7nDfGpYUzWRtms2lk5lXWCkBMoW7CUZotG3HwKCJJQZo8pzgNf /fqXd1x7EXBnD9r9uazGxDodGWqrm4+jGjg+xOXzthCv+YKcOuuIIcrkxEzBoAVztLSi 3Ci1vzsIiUyK4v26XEC0gBK2BHIxxLfciURgT4jqtG3vNeBKM7eNC0x1OeK+EnPNS6XX UysY89chesmg9LB7VYxSq0X1WghTH2Ak/di+EqVEUE5B0lNtoW6kinwff9xMzhQfwjVN amXA==
X-Gm-Message-State: AMke39nsV5u8Yd4HyiGv5JY/7Vbb0Nl/IgOBYPSm8AY9R6VL8O71AvNR+UIykcr04FTFrroyDph5C9ZdXAiUOg==
X-Received: by 10.223.163.206 with SMTP id m14mr3855936wrb.34.1488559046062; Fri, 03 Mar 2017 08:37:26 -0800 (PST)
MIME-Version: 1.0
References: <20170223134026.GI5069@gir.theapt.org> <20170302121104.36ddda4e@echo.ms.redpill-linpro.com> <CAKD1Yr1cNihxMVHjY2j7mcCNU2TE0X6-0p2mDNCBVVUcUbU20Q@mail.gmail.com> <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>
In-Reply-To: <31396f41-0f08-3677-8012-4fd54247aa76@gmail.com>
From: Ca By <cb.list6@gmail.com>
Date: Fri, 03 Mar 2017 16:37:14 +0000
Message-ID: <CAD6AjGQKd9fZr6Aot6LG4CzRdftq5L2xJ5YcVnzWAWWWFXke_A@mail.gmail.com>
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>, Mark Andrews <marka@isc.org>, mohamed.boucadair@orange.com
Content-Type: multipart/alternative; boundary="f403045f22042af9f80549d6292d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/hq0pvndBq57uteSH8F9Z2EsFSTU>
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 16:37:31 -0000

On Fri, Mar 3, 2017 at 2:52 AM Alexandre Petrescu <
alexandre.petrescu@gmail.com> wrote:

>
>
> Le 03/03/2017 à 11:30, 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.  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.

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

Asking for it at ietf, not likely helpful. The standards and guidance all
say do PD, now you just need $



>
> 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] De la part de Alexandre Petrescu
> >> Envoyé : vendredi 3 mars 2017 10:29 À : Mark Andrews Cc :
> >> 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>,
> >>> 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>
> >>>>> en nombre de Alexandre Petrescu
> >>>>> <alexandre.petrescu@gmail.com> Responder a:
> >>>>> <alexandre.petrescu@gmail.com> Fecha: jueves, 2 de marzo de
> >>>>> 2017, 20:15 Para: <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>
> >>>>>> en nombre de Alexandre Petrescu
> >>>>>> <alexandre.petrescu@gmail.com> Responder a:
> >>>>>> <alexandre.petrescu@gmail.com> Fecha: jueves, 2 de marzo de
> >>>>>> 2017, 20:02 Para: <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> en nombre de Mikael Abrahamsson
> >>>>>>> <swmike@swm.pp.se> Organizacin: People's Front Against
> >>>>>>> WWW Responder a: <swmike@swm.pp.se> Fecha: jueves, 2 de
> >>>>>>> marzo de 2017, 19:33 Para: Alexandre Petrescu
> >>>>>>> <alexandre.petrescu@gmail.com> CC: <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
> >>>>>>>
> >>>>>>>
> --------------------------------------------------------------------
> >>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> IETF IPv6 working group mailing list 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 Administrative
> >>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>>>>>>
> --------------------------------------------------------------------
> >>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> --------------------------------------------------------------------
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> IETF IPv6 working group mailing list 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 Administrative
> >>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>>>>> --------------------------------------------------------------------
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>
> >>>>>>
> >>>>>>
> >>>>>>
> --------------------------------------------------------------------
> >>>>> IETF IPv6 working group mailing list 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 Administrative
> >>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>>>> --------------------------------------------------------------------
> >>>>>
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>>
> >>
> >>>>>
> >>>>>
> >>>>>
> --------------------------------------------------------------------
> >>>> IETF IPv6 working group mailing list ipv6@ietf.org
> >>>> Administrative Requests:
> >>>> https://www.ietf.org/mailman/listinfo/ipv6
> >>>> --------------------------------------------------------------------
> >>>
> >>
> >>
> >>>>
> >>>>
> >>>>
> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> >> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>