Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Fri, 27 April 2018 10:26 UTC

Return-Path: <prvs=16558f0734=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 BB2A91243FE for <v6ops@ietfa.amsl.com>; Fri, 27 Apr 2018 03:26:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 Afk2R1-PpkVE for <v6ops@ietfa.amsl.com>; Fri, 27 Apr 2018 03:26:05 -0700 (PDT)
Received: from mail.consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FE4E12DA41 for <v6ops@ietf.org>; Fri, 27 Apr 2018 03:26:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1524824762; x=1525429562; 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=C8EkSmAt qJ2a7nFCml5W+DHmteTdqjzSR7XfY2CWk9w=; b=AMWYSozwfIuOivo24XW/kIbL izjZ/8Y1D2ZIlmjvD4YzBfmWynQokKciz6KHyMi1csgElgI9AJsgdRCBu9n7xXwl GjWAnFelYjRHm2jGHC+Kq1nXwJbXrlMrCY8FHgW9sxGRcSCALvxjiltaw7OpquOC JjukztmppgG65jAMyRk=
X-MDAV-Result: clean
X-MDAV-Processed: mail.consulintel.es, Fri, 27 Apr 2018 12:26:02 +0200
X-Spam-Processed: mail.consulintel.es, Fri, 27 Apr 2018 12:26:01 +0200
Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005759233.msg for <v6ops@ietf.org>; Fri, 27 Apr 2018 12:26:00 +0200
X-MDRemoteIP: 2001:470:1f09:495:84e0:2b0d:5b07:af6a
X-MDHelo: [10.10.10.129]
X-MDArrival-Date: Fri, 27 Apr 2018 12:26:00 +0200
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Return-Path: prvs=16558f0734=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ietf.org
User-Agent: Microsoft-MacOutlook/10.c.0.180410
Date: Fri, 27 Apr 2018 12:25:55 +0200
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: V6 Ops List <v6ops@ietf.org>
Message-ID: <EB927C88-58E9-4AE9-9334-DE565101AB57@consulintel.es>
Thread-Topic: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion
References: <3A083AA8-41D3-4BF8-BE31-5071975B6F98@gmail.com> <CAHL_VyC1xUDDqZRz1r--u8nyuLaZRnsT0ZR7hzOw4HWUkgwPXg@mail.gmail.com> <52D64464-A1BB-4FFA-AA79-28B8953E3B93@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DD7F981@GAALPA1MSGUSRBF.ITServices.sbc.com> <ECDF4B32-1A4E-49A9-9255-091F2FEA78AF@gmail.com> <CAHL_VyBnRkmpNDcwqTTxu8DnUGFAdKgL+PB1pt9yFLQ==cM0aA@mail.gmail.com> <D8000940-273D-4C25-8B71-F75833B74462@consulintel.es> <787AE7BB302AE849A7480A190F8B93302DF126EC@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <EB620943-8AAC-4736-9BBB-3B0433C54A31@consulintel.es> <787AE7BB302AE849A7480A190F8B93302DF12819@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <6EFCF64D-3D6E-4A05-BA29-EB18C13FF7B9@consulintel.es> <97D94545-B06B-46D7-8874-C7C2BE141745@consulintel.es> <787AE7BB302AE849A7480A190F8B93302DF128D1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <18D5AA86-E01A-4D0B-BDDA-8760454C870C@consulintel.es> <787AE7BB302AE849A7480A190F8B93302DF12930@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DF12930@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
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/PwP4CQupV2tukJkQtqq226PraZo>
Subject: Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 27 Apr 2018 10:26:09 -0000

Agree, it makes sense.

I don't know if other operators are using also the same approach when using NAT64. May be nobody considered, but I think it will make sense to have the same text as well?

Regards,
Jordi
 
 
-----Mensaje original-----
De: <mohamed.boucadair@orange.com>
Fecha: viernes, 27 de abril de 2018, 11:21
Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, V6 Ops List <v6ops@ietf.org>
Asunto: RE: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion

    Re-,
    
    Thank you. 
    
    For DS-Lite, you may mention the following :
    - when no PCP server is configured, the CPE assumes by default that the AFTR is the PCP server. 
    - a plain IPv6 mode is used to send PCP requests to the server.
    
    This is how PCP is deployed today for DS-lite. It is worth to have it documented. 
    
    Cheers,
    Med
    
    > -----Message d'origine-----
    > De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de JORDI PALET MARTINEZ
    > Envoyé : vendredi 27 avril 2018 11:04
    > À : V6 Ops List
    > Objet : Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion
    > 
    > Done, thanks!
    > 
    > So, I removed the SHOULD for PCP, as it is already in RFC7084, but added (DS-
    > LITE and 464XLAT):
    > 
    > 	The CE Router SHOULD support IGD-PCP IWF [RFC6970] (UPnP
    >                Internet Gateway Device - Port Control Protocol
    >                Interworking Function).
    > 
    > Regards,
    > Jordi
    > 
    > 
    > -----Mensaje original-----
    > De: <mohamed.boucadair@orange.com>
    > Fecha: viernes, 27 de abril de 2018, 10:37
    > Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, V6 Ops List
    > <v6ops@ietf.org>
    > Asunto: RE: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion
    > 
    >     Jordi,
    > 
    >     That is what I was suggesting.
    > 
    >     Cheers,
    >     Med
    > 
    >     > -----Message d'origine-----
    >     > De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de JORDI PALET
    > MARTINEZ
    >     > Envoyé : vendredi 27 avril 2018 10:32
    >     > À : V6 Ops List
    >     > Objet : Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion
    >     >
    >     > Responding to myself ... The alternative maybe to not say anything
    > about
    >     > RFC6887, so the SHOULD in RFC7084 is in effect and add a SHOULD for
    > RFC6970.
    >     >
    >     > Regards,
    >     > Jordi
    >     >
    >     >
    >     > -----Mensaje original-----
    >     > De: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
    >     > Fecha: viernes, 27 de abril de 2018, 10:27
    >     > Para: V6 Ops List <v6ops@ietf.org>
    >     > Asunto: Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion
    >     >
    >     >     The difference is in RFC7084 is a SHOULD for RFC6887, while here
    > I'm
    >     > suggesting a MUST when DS-LITE or 464XLAT are implemented.
    >     >
    >     >     Asking a MUST for RFC6970, and not having a MUST in RFC6887 seems
    > weird
    >     > ...
    >     >
    >     >     Regards,
    >     >     Jordi
    >     >
    >     >
    >     >     -----Mensaje original-----
    >     >     De: <mohamed.boucadair@orange.com>
    >     >     Fecha: viernes, 27 de abril de 2018, 9:45
    >     >     Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, V6 Ops
    > List
    >     > <v6ops@ietf.org>
    >     >     Asunto: RE: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion
    >     >
    >     >         Re-,
    >     >
    >     >         Please see inline.
    >     >
    >     >         Cheers,
    >     >         Med
    >     >
    >     >         > -----Message d'origine-----
    >     >         > De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de
    > JORDI
    >     > PALET MARTINEZ
    >     >         > Envoyé : vendredi 27 avril 2018 08:27
    >     >         > À : V6 Ops List
    >     >         > Objet : Re: [v6ops] draft-palet-v6ops-transition-ipv4aas
    > discussion
    >     >         >
    >     >         > Hi Med,
    >     >         >
    >     >         > In the document I'm editing right now, I've it already
    > support for
    >     > RFC6887
    >     >         > (464XLAT-2):
    >     >
    >     >         [Med] You don't need to add an item for 6887 since this is
    > already
    >     > covered in 7084:
    >     >
    >     >            W-6:  The WAN interface of the CE router SHOULD support a
    > Port
    >     >                  Control Protocol (PCP) client as specified in
    > [RFC6887] for
    >     > use
    >     >                  by applications on the CE router.  The PCP client
    > SHOULD
    >     > follow
    >     >                  the procedure specified in Section 8.1 of [RFC6887] to
    >     > discover
    >     >                  its PCP server.  This document takes no position on
    > whether
    >     >                  such functionality is enabled by default or mechanisms
    > by
    >     > which
    >     >                  users would configure the functionality.  Handling PCP
    >     > requests
    >     >                  from PCP clients in the LAN side of the CE router is
    > out of
    >     >                  scope.
    >     >
    >     >         My comment is about the IWF which is needed to allow an UPnP
    > Control
    >     > Point to interact with a PCP server.
    >     >
    >     >         >
    >     >         >    464XLAT requirements:
    >     >         >
    >     >         >    464XLAT-1:  The CE Router MUST perform IPv4 Network
    > Address
    >     >         >                Translation (NAT) on IPv4 traffic translated
    > using
    >     > the
    >     >         >                CLAT, unless a dedicated /64 prefix has been
    >     > acquired
    >     >         >                using DHCPv6-PD [RFC3633] (IPv6 Prefix Options
    > for
    >     >         >                DHCPv6).
    >     >         >
    >     >         >    464XLAT-2:  The CE Router MUST support PCP [RFC6887] (Port
    >     > Control
    >     >         >                Protocol), for explicit control over NAT64
    > mappings.
    >     >
    >     >         [Med] This one should be removed since it overlaps with W-6 in
    > 7084.
    >     >
    >     >         >
    >     >         >    464XLAT-3:  The CE Router MUST implement [RFC7050]
    > (Discovery of
    >     > the
    >     >         >                IPv6 Prefix Used for IPv6 Address Synthesis)
    > in
    >     > order to
    >     >         >                discover the PLAT-side translation IPv4 and
    > IPv6
    >     >         >                prefix(es)/suffix(es).  The CE Router MUST
    > follow
    >     >         >                [RFC7225] (Discovering NAT64 IPv6 Prefixes
    > Using the
    >     >         >                PCP), in order to learn the PLAT-side
    > translation
    >     > IPv4
    >     >         >                and IPv6 prefix(es)/suffix(es) used by an
    > upstream
    >     > PCP-
    >     >         >                controlled NAT64 device.
    >     >         >
    >     >         >
    >     >         > But I now realice that it should be added as well to the DS-
    > Lite
    >     > section, as
    >     >         > it was not present in RFC7084. This is what I've right now:
    >     >         >
    >     >         >   DS-Lite requirements:
    >     >         >
    >     >         >    DSLITE-1:  The IPv6 CE router MUST support configuration
    > of DS-
    >     > Lite
    >     >         >               via the DS-Lite DHCPv6 option [RFC6334] (DHCPv6
    >     > Option for
    >     >         >               Dual-Stack Lite).  The IPv6 CE router MAY use
    > other
    >     >         >               mechanisms to configure DS-Lite parameters.
    > Such
    >     >         >               mechanisms are outside the scope of this
    > document.
    >     >         >
    >     >         >    DSLITE-2:  The IPv6 CE router MUST NOT perform IPv4
    > Network
    >     > Address
    >     >         >               Translation (NAT) on IPv4 traffic encapsulated
    > using
    >     > DS-
    >     >         >               Lite.
    >     >         >
    >     >         >
    >     >         > So just to make sure, you mean to add also to both, 464LAT
    > and DS-
    >     > LITE also a
    >     >         > MUST for RFC6970 ?
    >     >
    >     >         [Med] Yes, I'd like to add an item for the IWF, not the PCP
    > Client
    >     > functionality.
    >     >
    >     >         >
    >     >         > We have a new section with this text suggested by Richard:
    >     >         >
    >     >         > 5.  UPnP IGD-PCP IWF Support
    >     >         >
    >     >         >    UPnP MAY be enabled on the CE Router for stateless
    > mechanisms
    >     > that
    >     >         >    forward unsolicited inbound packets through to the CE.  If
    > UPnP
    >     > is
    >     >         >    enabled, the agent MUST reject any port mapping requests
    > for
    >     > ports
    >     >         >    outside of the range(s) allocated to the CE Router.
    >     >         >
    >     >         >    UPnP SHOULD be disabled for stateful mechanisms that do
    > not
    >     > forward
    >     >         >    unsolicited inbound packets to the CE Router, unless
    > implemented
    >     > in
    >     >         >    conjunction with a method to control the external port
    > mapping,
    >     > such
    >     >         >    as IGD-PCP IWF [RFC6970] (UPnP Internet Gateway Device -
    > Port
    >     > Control
    >     >         >    Protocol Interworking Function).
    >     >         >
    >     >
    >     >         [Med] this text does not recommend implementing the IWF.
    >     >
    >     >         >
    >     >         > Regards,
    >     >         > Jordi
    >     >         >
    >     >         >
    >     >         > -----Mensaje original-----
    >     >         > De: <mohamed.boucadair@orange.com>
    >     >         > Fecha: viernes, 27 de abril de 2018, 7:26
    >     >         > Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, V6
    > Ops
    >     > List
    >     >         > <v6ops@ietf.org>
    >     >         > Asunto: RE: [v6ops] draft-palet-v6ops-transition-ipv4aas
    > discussion
    >     >         >
    >     >         >     Hi Jordi,
    >     >         >
    >     >         >     As you are on it, and given the IETF recommendation in
    > RFC6888:
    >     >         >
    >     >         >        REQ-9:  A CGN MUST implement a protocol giving
    > subscribers
    >     > explicit
    >     >         >           control over NAT mappings.  That protocol SHOULD be
    > the
    >     > Port
    >     >         >           Control Protocol [RFC6887].
    >     >         >
    >     >         >     which would apply also to the PLAT, I suggest you add an
    > item
    >     > in the
    >     >         > 464lat section to support RFC6970.
    >     >         >
    >     >         >     Cheers,
    >     >         >     Med
    >     >         >
    >     >         >     > -----Message d'origine-----
    >     >         >     > De : v6ops [mailto:v6ops-bounces@ietf.org] De la part
    > de
    >     > JORDI PALET
    >     >         > MARTINEZ
    >     >         >     > Envoyé : jeudi 26 avril 2018 21:41
    >     >         >     > À : V6 Ops List
    >     >         >     > Objet : Re: [v6ops] draft-palet-v6ops-transition-
    > ipv4aas
    >     > discussion
    >     >         >     >
    >     >         >     > Hi Richard,
    >     >         >     >
    >     >         >     > As I've moved sections 3 & 4 to the end of the document
    > as
    >     > annexes,
    >     >         > I've
    >     >         >     > added a new small section for UPnP with your text. I
    > think
    >     > this also
    >     >         > helps to
    >     >         >     > clarify one of the issues raised by Lee.
    >     >         >     >
    >     >         >     > I'm working on all this changes with my co-authors, and
    > if we
    >     > are good
    >     >         > with
    >     >         >     > them, we probably will submit the new version in a
    > couple of
    >     > days or
    >     >         > so.
    >     >         >     >
    >     >         >     > Thanks!
    >     >         >     >
    >     >         >     > Regards,
    >     >         >     > Jordi
    >     >         >     >
    >     >         >     >
    >     >         >     > -----Mensaje original-----
    >     >         >     > De: v6ops <v6ops-bounces@ietf.org> en nombre de Richard
    >     > Patterson
    >     >         >     > <richard@helix.net.nz>
    >     >         >     > Fecha: miércoles, 25 de abril de 2018, 11:16
    >     >         >     > Para: V6 Ops List <v6ops@ietf.org>
    >     >         >     > Asunto: Re: [v6ops] draft-palet-v6ops-transition-
    > ipv4aas
    >     > discussion
    >     >         >     >
    >     >         >     >     Section 4 only briefly touches on UPnP, I'd like to
    >     > propose that we
    >     >         >     >     make a recommendation around its behaviour if it is
    >     > enabled.
    >     >         >     >
    >     >         >     >     UPnP MAY be enabled on the IPv6 transition CE, for
    >     > stateless
    >     >         >     >     mechanisms that forward unsolicited inbound packets
    >     > through to the
    >     >         > CE.
    >     >         >     >     If UPnP is enabled, the agent MUST reject any port
    >     > mapping requests
    >     >         >     >     for ports outside of the range(s) allocated to the
    > IPv6
    >     > transition
    >     >         > CE.
    >     >         >     >
    >     >         >     >     UPnP SHOULD be disabled for stateful mechanisms
    > that do
    >     > not forward
    >     >         >     >     unsolicited inbound packets to the CE, unless
    > implemented
    >     > in
    >     >         >     >     conjunction with a method to control the external
    > port
    >     > mapping,
    >     >         > such
    >     >         >     >     as IGD-PCP IWF [RFC6970].
    >     >         >     >
    >     >         >     >     -Richard
    >     >         >     >
    >     >         >     >
    >     >         >     >     On 25 April 2018 at 01:38, Fred Baker
    >     > <fredbaker.ietf@gmail.com>
    >     >         > wrote:
    >     >         >     >     >
    >     >         >     >     >
    >     >         >     >     >> On Apr 24, 2018, at 12:13 PM, STARK, BARBARA H
    >     > <bs7652@att.com>
    >     >         > wrote:
    >     >         >     >     >>
    >     >         >     >     >> But that doesn't mean I believe the draft has
    > exactly
    >     > the right
    >     >         > set of
    >     >         >     > features included. My understanding of "adoption" is
    > that it
    >     > is still
    >     >         >     > possible post-adoption to discuss whether specific
    > features /
    >     >         > requirements do
    >     >         >     > or don't belong. If the precise set of features and
    >     > requirements must
    >     >         > be
    >     >         >     > agreed upon prior to adoption, then I would not be in
    > support
    >     > of
    >     >         > adoption.
    >     >         >     > Hopefully we aren't setting the bar that high?
    >     >         >     >     >
    >     >         >     >     > I understand "adoption as a working group draft"
    > to
    >     > mean that the
    >     >         >     > working group has agreed to work on the draft. There
    > are some
    >     > working
    >     >         > groups
    >     >         >     > that seem to confuse "adoption as a work group draft"
    > with
    >     > "agreement
    >     >         > to send
    >     >         >     > it to the IESG"; I don't, but expect conversation in
    > between
    >     > those two
    >     >         >     > events.
    >     >         >     >     >
    >     >         >     >     > That said, I'd like to believe that the draft is
    > pretty
    >     > close,
    >     >         > and that
    >     >         >     > changes that need to be made to it will have text
    > offered by
    >     > the people
    >     >         > that
    >     >         >     > want them. So - keep your cards and letters coming...
    >     >         >     >     >
    >     >         >     >     > _______________________________________________
    >     >         >     >     > 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
    >     >         >     >
    >     >         >     >
    >     >         >     >
    >     >         >     >
    >     >         >     > **********************************************
    >     >         >     > 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
    >     > 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://www.ietf.org/mailman/listinfo/v6ops
    >     >         >
    >     >         >
    >     >         >
    >     >         >
    >     >         > **********************************************
    >     >         > 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
    > 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://www.ietf.org/mailman/listinfo/v6ops
    >     >
    >     >
    >     >
    >     >
    >     >
    >     > **********************************************
    >     > 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 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://www.ietf.org/mailman/listinfo/v6ops
    > 
    > 
    > 
    > 
    > **********************************************
    > 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 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://www.ietf.org/mailman/listinfo/v6ops
    



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