Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion
<mohamed.boucadair@orange.com> Fri, 27 April 2018 11:15 UTC
Return-Path: <mohamed.boucadair@orange.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 B6B5D124BFA for <v6ops@ietfa.amsl.com>; Fri, 27 Apr 2018 04:15:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 ypX-HUlnpxHM for <v6ops@ietfa.amsl.com>; Fri, 27 Apr 2018 04:15:43 -0700 (PDT)
Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99E5A1200F1 for <v6ops@ietf.org>; Fri, 27 Apr 2018 04:15:42 -0700 (PDT)
Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 1FEEDA0567; Fri, 27 Apr 2018 13:15:41 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.10]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id EF5771A007B; Fri, 27 Apr 2018 13:15:40 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5C.corporate.adroot.infra.ftgroup ([fe80::4bd:9b2b:3651:6fba%19]) with mapi id 14.03.0389.001; Fri, 27 Apr 2018 13:15:40 +0200
From: mohamed.boucadair@orange.com
To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, V6 Ops List <v6ops@ietf.org>
Thread-Topic: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion
Thread-Index: AQHT3hdsgLpC4qV7eEmkTIPz3I/4hKQUdKWw
Date: Fri, 27 Apr 2018 11:15:39 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302DF12A5B@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
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> <EB927C88-58E9-4AE9-9334-DE565101AB57@consulintel.es> <787AE7BB302AE849A7480A190F8B93302DF12A08@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <3ED28592-574A-4E76-AE01-F9861FE641BB@consulintel.es>
In-Reply-To: <3ED28592-574A-4E76-AE01-F9861FE641BB@consulintel.es>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/cVmoWh_WjDrvfye7sI9dXGbODxE>
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 11:15:47 -0000
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 13:03 > À : V6 Ops List > Objet : Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion > > I mean in the scenario when a CE or host behind a NAT64 want to ask the NAT64 > for specific IPv4 incoming traffic. [Med] Yes. See for example the experiments we did using an Android Phone: https://www.ietf.org/proceedings/85/slides/slides-85-pcp-6.pdf I thought you can do that as well if the > NAT64 supports PCP, and if that's the case, the CE/host will need to tell the > PCP server (so again, if no PCP server is configured, the CE could assume, by > default, that the NAT64 is the PCP server). [Med] Yeah, but the CE is not aware of the NAT64. This is why it is needed to configure explicitly the PCP server on the CE for 464xlat case: RFC 7291. > > Regards, > Jordi > > > -----Mensaje original----- > De: <mohamed.boucadair@orange.com> > Fecha: viernes, 27 de abril de 2018, 12:52 > Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, V6 Ops List > <v6ops@ietf.org> > Asunto: RE: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion > > Re-, > > It does not make sense to use the same text for the following reasons: > > * NAT64 deployments do not require explicit configuration of the NAT64 > instance to use at the CPE/host side, while in DS-Lite the configuration of > the AFTR is required. > * Packets from the host embedding the CLAT are native IPv6 packets, so > PCP requests will just fly as native IPv6 packets. The situation is different > for DS-Lite because IPv4 user traffic is encapsulated over IPv6 to the AFTR. > > Cheers, > Med > > > -----Message d'origine----- > > De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de JORDI PALET > MARTINEZ > > Envoyé : vendredi 27 avril 2018 12:26 > > À : V6 Ops List > > Objet : Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion > > > > 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. > > > > > > > > _______________________________________________ > > 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
- [v6ops] draft-palet-v6ops-transition-ipv4aas disc… Fred Baker
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … JORDI PALET MARTINEZ
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … Richard Patterson
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … JORDI PALET MARTINEZ
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … Fred Baker
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … Richard Patterson
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … Fred Baker
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … JORDI PALET MARTINEZ
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … Lee Howard
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … JORDI PALET MARTINEZ
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … Mikael Abrahamsson
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … Fred Baker
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … Ackermann, Michael
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … Hans Liu
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … Mikael Abrahamsson
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … Sander Steffann
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … Masanobu Kawashima
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … JORDI PALET MARTINEZ
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … Fred Baker
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … JORDI PALET MARTINEZ
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … mohamed.boucadair
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … JORDI PALET MARTINEZ
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … Lee Howard
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … STARK, BARBARA H
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … JORDI PALET MARTINEZ
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … Fred Baker
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … Richard Patterson
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … Ole Troan
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … JORDI PALET MARTINEZ
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … JORDI PALET MARTINEZ
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … mohamed.boucadair
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … JORDI PALET MARTINEZ
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … Ole Troan
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … mohamed.boucadair
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … mohamed.boucadair
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … JORDI PALET MARTINEZ
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … JORDI PALET MARTINEZ
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … mohamed.boucadair
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … JORDI PALET MARTINEZ
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … mohamed.boucadair
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … Richard Patterson
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … JORDI PALET MARTINEZ
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … mohamed.boucadair
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … JORDI PALET MARTINEZ
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … mohamed.boucadair
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … mohamed.boucadair
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … Richard Patterson
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … JORDI PALET MARTINEZ
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … mohamed.boucadair
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … joel jaeggli
- Re: [v6ops] draft-palet-v6ops-transition-ipv4aas … Richard Patterson