From nobody Tue May 1 10:46:59 2018 Return-Path: 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 E759512E8D7 for ; Tue, 1 May 2018 10:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 MgoTm-Rfpi9q for ; Tue, 1 May 2018 10:46:55 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D18A012E8D4 for ; Tue, 1 May 2018 10:46:54 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w41HkmF5017110; Tue, 1 May 2018 19:46:48 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 705EC201FED; Tue, 1 May 2018 19:46:48 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5F2D5200E2F; Tue, 1 May 2018 19:46:48 +0200 (CEST) Received: from [132.166.84.81] ([132.166.84.81]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w41Hklw1011572; Tue, 1 May 2018 19:46:47 +0200 To: Joe Touch Cc: "Templin (US), Fred L" , V6 Ops List References: <4AFC3A31-4A5A-433A-B02E-A154BBE5A566@gmail.com> <4bdf9f83e75ab30384ae32774b63d2a5@strayalpha.com> <279dd3a9d8f748a1afe22924ba980e9b@XCH15-06-08.nw.nos.boeing.com> <853a042cffb96849875b816e69c28aef@strayalpha.com> From: Alexandre Petrescu Message-ID: Date: Tue, 1 May 2018 19:46:47 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <853a042cffb96849875b816e69c28aef@strayalpha.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 17:46:58 -0000 Le 30/04/2018 à 22:58, Joe Touch a écrit : > > > On 2018-04-30 16:06, Templin (US), Fred L wrote: > >> Hi Joe/Fred, >> >> A comment on one point that was made: >> >> >Although there can be addresses assigned to a "node" rather than an interface, >> >> I always understood that addresses were assigned to an interface, >> >> even if only a loopback or other internal virtual interface. >> > They strictly don't need to be assigned to an interface at all, except > as an artifact of how certain OSes are designed. In some case, yes. I know a Home Address (Mobile IP protocol) is put in a configuration file of the node and is not assigned to any of its interfaces. The Care-of Address is assigned to real interface. In some other Mobile IP case the Home Address is assigned to a virtual interface. Alex > > I.e., you can assign one to "the node" that is not assigned to an > interface, so that it would be used as a source address only when > explicitly indicated by the application or as a reply to that address > (and never, e.g., as a side effect of 1122 forwarding lookup). > >> An >> >> address (or prefix) can be delegated to the node, but until the >> >> node assigns the addresses to an interface they are unreachable. >> >> And, if the node receives packets with destination addresses that >> >> are unassigned it can either send a Destination Unreachable, or >> >> just let it black hole. Do I have this right? >> > They may be unreachable from L2 packets received on an addressed LAN, > but they would be reachable from unnumbered pt-pt interfaces or via > decapsulation (again, depending on how the OS implements tunnels). > > Yes, it's simpler in most current OSes do assign these to an interface > (at least a virtual interface), but it isn't strictly required. > > For IPv6, this would require a way to assign an address that was NOT a > direct effect of receiving an RA message, but that's permitted. > > Joe > >> Thanks - Fred >> >> *From:*v6ops [mailto:v6ops-bounces@ietf.org] *On Behalf Of *Joe Touch >> *Sent:* Monday, April 30, 2018 9:03 AM >> *To:* Fred Baker >> *Cc:* V6 Ops List >> *Subject:* Re: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101 >> >> On 2018-04-29 20:09, Fred Baker wrote: >> >> On Apr 28, 2018, at 9:41 PM, Fred Baker > > wrote: >> >> 3. Does the answer to 2. depend on the weak-host, strong-host >> distinction? >> >> >> Speaking for myself, and hats off, I think the >> weak-host/strong-host distinction isn't currently an accurate >> depiction of how hosts or routers work in 2018, and isn't an >> obvious choice for a virtualized system. I refer to RFC 1122, >> section 3.3.4.2,  Multihoming Requirements, which has to do with >> the choice of source address from a host with more than one interface. >> >> IMO, Internet nodes are inherently weak-host at the IP layer and >> strong-host at the link layer. >> >> The weak-host part is validated, as you note, by RFC 1122. >> >> The strong-host part is validate, AFAICT, by ARP and neighbor discovery. >> >> Although there can be addresses assigned to a "node" rather than an >> interface, the distinction is philosophical at best; as you point out, >> all addresses are effectively virtual interfaces anyway - and those >> interfaces are defined in the context of the network over which they >> reach other interfaces. >> >> Joe >> > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue May 1 10:54:38 2018 Return-Path: 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 EDEF412E8D9 for ; Tue, 1 May 2018 10:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, 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 ZjlMvJikxC6w for ; Tue, 1 May 2018 10:54:34 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8935C12E8D7 for ; Tue, 1 May 2018 10:54:33 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w41HsUhs035948 for ; Tue, 1 May 2018 19:54:30 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8D74320320F for ; Tue, 1 May 2018 19:54:30 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 83C6C2019A4 for ; Tue, 1 May 2018 19:54:30 +0200 (CEST) Received: from [132.166.84.81] ([132.166.84.81]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w41HsT5F012286 for ; Tue, 1 May 2018 19:54:30 +0200 To: v6ops@ietf.org References: <4AFC3A31-4A5A-433A-B02E-A154BBE5A566@gmail.com> <4bdf9f83e75ab30384ae32774b63d2a5@strayalpha.com> <279dd3a9d8f748a1afe22924ba980e9b@XCH15-06-08.nw.nos.boeing.com> <25077_1525138099_5AE7C2B2_25077_7665_1_34390557-A240-400D-A9E3-255E82DE922F@gmail.com> From: Alexandre Petrescu Message-ID: Date: Tue, 1 May 2018 19:54:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <25077_1525138099_5AE7C2B2_25077_7665_1_34390557-A240-400D-A9E3-255E82DE922F@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 17:54:37 -0000 Le 01/05/2018 à 03:27, Fred Baker a écrit : > [SECURITE : MISE EN QUARANTAINE DES PIECES JOINTES POTENTIELLEMENT > DANGEREUSES] > > Ce message contient des pieces jointes potentiellement dangereuses > car susceptibles de contenir des virus. Pour lutter contre > l'expansion de ce type d'attaque, les documents [null] ont ete > retires du message original ci-dessous. Pour les documents Office, le > CEA recommande l'usage exclusif des formats plus recents exempts de > macros comme DOCX, XLSX, PPTX, merci de le signaler a votre > expediteur. > > Pour de plus amples informations ou pour connaitre les mecanismes de > mise en quarantaine, vous pouvez vous rapprocher de votre service > informatique ou consulter le site USCIpedia - rubrique PureMessage. > > ----------------MESSAGE ORGINAL ci-dessous------------------ > > > >> On Apr 30, 2018, at 4:06 PM, Templin (US), Fred L >> wrote: >> >> I always understood that addresses were assigned to an interface, >> even if only a loopback or other internal virtual interface. An >> address (or prefix) can be delegated to the node, but until the >> node assigns the addresses to an interface they are unreachable. >> And, if the node receives packets with destination addresses that >> are unassigned it can either send a Destination Unreachable, or >> just let it black hole. Do I have this right? > > Ole and Joe already replied. I'd be interested in comments from > people that have deployed the allocation of a prefix to a node. My > understanding is that the address is assigned to a virtual interface > used by a container or whatever. When people talk about assigning one > to an application (which I have also heard), I tend to think they are > using it as a combination of an address (get the packet to the > destination node) and a port (deliver the packet to a transport > session or application). At that point, it diverges a bit from the > historic "address on an interface" model in the sense that the > interface isn't completely obvious. I agree. In my trial, the /56 prefix that is obtained with DHCPv6 Prefix Delegation is used to form other /64 prefixes (Px). These Px are put in RAs whose receivers form addresses. The IoT Router does not form an address out of any Px. That /56 prefix is not assigned on any interface nor to any application. But I agree it is very well possible to assign an IPv6 address to some application or to some configuration file, or to some virtual machine; it is not mandatory to assign an IPv6 address to an interface. Alex > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue May 1 11:00:46 2018 Return-Path: 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 EB1AB12E8D7 for ; Tue, 1 May 2018 11:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, 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 OZ-Sic7qH6RH for ; Tue, 1 May 2018 11:00:41 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6963F12E8D6 for ; Tue, 1 May 2018 11:00:41 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w41I0doZ019301 for ; Tue, 1 May 2018 20:00:39 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1369E20321F for ; Tue, 1 May 2018 20:00:39 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 08F0C20199B for ; Tue, 1 May 2018 20:00:39 +0200 (CEST) Received: from [132.166.84.81] ([132.166.84.81]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w41I0cO5013117 for ; Tue, 1 May 2018 20:00:38 +0200 To: v6ops@ietf.org References: <7931_1525047000_5AE65ECE_7931_11070_1_4AFC3A31-4A5A-433A-B02E-A154BBE5A566@gmail.com> From: Alexandre Petrescu Message-ID: <125d560c-2a26-7daf-9788-617e544224f5@gmail.com> Date: Tue, 1 May 2018 20:00:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <7931_1525047000_5AE65ECE_7931_11070_1_4AFC3A31-4A5A-433A-B02E-A154BBE5A566@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 18:00:45 -0000 Le 30/04/2018 à 02:09, Fred Baker a écrit : > [SECURITE : MISE EN QUARANTAINE DES PIECES JOINTES POTENTIELLEMENT > DANGEREUSES] > > Ce message contient des pieces jointes potentiellement dangereuses > car susceptibles de contenir des virus. Pour lutter contre > l'expansion de ce type d'attaque, les documents [null] ont ete > retires du message original ci-dessous. Pour les documents Office, le > CEA recommande l'usage exclusif des formats plus recents exempts de > macros comme DOCX, XLSX, PPTX, merci de le signaler a votre > expediteur. > > Pour de plus amples informations ou pour connaitre les mecanismes de > mise en quarantaine, vous pouvez vous rapprocher de votre service > informatique ou consulter le site USCIpedia - rubrique PureMessage. > > ----------------MESSAGE ORGINAL ci-dessous------------------ > > > > On Apr 28, 2018, at 9:41 PM, Fred Baker > wrote: >> 3. Does the answer to 2. depend on the weak-host, strong-host >> distinction? > > Speaking for myself, and hats off, I think the weak-host/strong-host > distinction isn't currently an accurate depiction of how hosts or > routers work in 2018, and isn't an obvious choice for a virtualized > system. I refer to RFC 1122, section 3.3.4.2, Multihoming > Requirements, which has to do with the choice of source address from > a host with more than one interface. > > The rules given are that (1) if the packet is being sent in response > to a packet received, it MUST use the destination address in that > packet as its source address, (2) it MUST be possible for the > application to specify the source address, and (3) if neither (1) nor > (2) apply, the communication layers below the application MUST (as > in, "are forced to") select a source address. As additional > considerations, (A) a host MAY discard a packet received on a > physical interface other than that which its destination address is > used on, and (B) a host MAY restrict itself to sending datagrams from > the interface configured with whatever source address it uses. > > The document then continues with "discussion", which to my thinking > is the most interesting part of RFC 1122, 1123, and 1812, which has > to do with "why". The "Weak ES model" and the "Strong ES model" are > found in that discussion, and are explicitly non-normative. > > In the Strong ES model, The Strong ES (End System, i.e., host) model > emphasizes the host/gateway (ES/IS) distinction, and would therefore > substitute MUST for MAY in issues (A) and (B) above. It tends to > model a multihomed host as a set of logical hosts within the same > physical host. > > In other words, (A) a host MUST discard a packet received on a > physical interface other than that which its destination address is > used on, and (B) a host MUST restrict itself to sending datagrams > from the interface configured with whatever source address it uses. > > Note that this model logically requires that in general there be at > least one default gateway, and preferably multiple defaults, for each > IP source address. > > The Weak ES Model de-emphasizes the ES/IS distinction, and would > therefore substitute MUST NOT for MAY in issues (A) and (B). This > model may be the more natural one for hosts that wiretap gateway > routing protocols, and is necessary for hosts that have embedded > gateway functionality. > > In other words, (A) a host MUST NOT discard a packet received on a > physical interface other than that which its destination address is > used on, and (B) a host MUST NOT restrict itself to sending datagrams > from the interface configured with whatever source address it uses. > > > The question Fred is asking has to do with "end systems that receive > a prefix delegation", and whether we would call such a one a host, a > router, a node, or something else. IMHO it should be called a router. A Host does not need more than the RA it receives. A 'node' is an ambiguous Host or Router. I also agree that a prefix delegation operation could be something else than DHCPv6-PD, or complimentary to it. Just runnin DHCPv6-PD is not sufficient to make a router work with a delegated prefix. One also needs a method to form sub-prefixes, to keep track of them, and more. DHCPv6-PD does not do these and others. Alex >> From my perspective, if a prefix is assigned to a chassis for use >> in addressing its applications, containers, virtual hosts, or >> whatever, it is not assigned to an interface per se. It is best >> thought of as having been assigned to a network that in some sense >> lies "behind" a router, comparable to having been assigned to a >> home or other network through the CPE that connects to the upstream >> network. So any discussion of the prefix being "on an interface" >> isn't visible to that upstream network. There is an address there, >> of course, which may be only a link-local address, and in the >> upstream router is primarily used as the next hop in the route >> toward the prefix in question. Whether it as available for network >> management purposes is not specified; if it is a global address, it >> might be used for network management purposes, and if it is >> link-local, the network management application would have to be on >> the same LAN for that to work. I would expect, rather, that network >> management is done via some application in the same chassis, >> perhaps in a container or virtual host. Yes, that address would be >> used in network management messages on the interface in question; >> if the chassis had multiple physical interfaces, it might also be >> used on them. > > In other words, the weak and strong ES models are inadequate to > describe a chassis allocated a prefix. It is a case not discussed in > currently-published RFCs. > > What do we call such a chassis? I call it a chassis. It would be > valid to call it a node, although from a networking perspective it > contains multiple virtualized nodes. It is not, in my view, exactly a > host (a system with an address on one or more interfaces and > responding only packets sent to one of those addresses), nor is it > exactly a router (a system that receives messages sent to an address > not configured on one of its interfaces and forwarding it toward > another system, the indicated host); it is a third category. That > category is a set of systems that contain one or more identifiable > routers and MAY contain one or more identifiable hosts, in some > virtualized sense. > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > From nobody Tue May 1 13:59:39 2018 Return-Path: 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 00CA81200B9 for ; Tue, 1 May 2018 13:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 6lHSsFccPYTl for ; Tue, 1 May 2018 13:59:35 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B9F0126D0C for ; Tue, 1 May 2018 13:59:35 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EAAQDv0+ha/wUHmMZcGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJvVIFbMotkjHqBdIEPjiqEaoF4CyyEQAKCdiE0GAECAQEBAQE?= =?us-ascii?q?BAgICaCiFKgEBAQECARIoTwIBCA0VFBAyJQIEARoahGUIAZ8WjAgaAogmgkKIG?= =?us-ascii?q?YFVPoEPgmArgUGDNIMugiQCmBIIAo9wAYY5hHaQPIElHDmBUnAVgn+QTYIEji8?= =?us-ascii?q?BgRcBAQ?= X-IPAS-Result: =?us-ascii?q?A2EAAQDv0+ha/wUHmMZcGQEBAQEBAQEBAQEBAQcBAQEBAYJ?= =?us-ascii?q?vVIFbMotkjHqBdIEPjiqEaoF4CyyEQAKCdiE0GAECAQEBAQEBAgICaCiFKgEBA?= =?us-ascii?q?QECARIoTwIBCA0VFBAyJQIEARoahGUIAZ8WjAgaAogmgkKIGYFVPoEPgmArgUG?= =?us-ascii?q?DNIMugiQCmBIIAo9wAYY5hHaQPIElHDmBUnAVgn+QTYIEji8BgRcBAQ?= X-IronPort-AV: E=Sophos;i="5.49,352,1520913600"; d="scan'208";a="240257394" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 May 2018 16:59:33 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 May 2018 16:59:32 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.03.0382.000; Tue, 1 May 2018 16:59:31 -0400 From: "Mudric, Dusan (Dusan)" To: Alexandre Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101 Thread-Index: AQHT33RaQlxqk8gs3kyrZF/cdjU/c6QbLfMcgAAxYDA= Date: Tue, 1 May 2018 20:59:30 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E459B59DCE4@AZ-US1EXMB03.global.avaya.com> References: <7931_1525047000_5AE65ECE_7931_11070_1_4AFC3A31-4A5A-433A-B02E-A154BBE5A566@gmail.com> <125d560c-2a26-7daf-9788-617e544224f5@gmail.com> In-Reply-To: <125d560c-2a26-7daf-9788-617e544224f5@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2018 20:59:38 -0000 > > The question Fred is asking has to do with "end systems that receive > > a prefix delegation", and whether we would call such a one a host, a > > router, a node, or something else. >=20 > IMHO it should be called a router. [[Dusan]] Do you envision a delegated prefix being assigned to a host? From nobody Tue May 1 23:33:09 2018 Return-Path: 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 36F7912D86D for ; Tue, 1 May 2018 23:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 sLDvDBIZE6VA for ; Tue, 1 May 2018 23:33:05 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9114B12D86C for ; Tue, 1 May 2018 23:33:04 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 65E94AF; Wed, 2 May 2018 08:33:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1525242781; bh=8U7Jw+MUQ9ySecWp2KRqC6rBPaJuaWsRgLGDU9ehL2c=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=Gs2jdjGKU9PrFmnN09kU2U6u0ViYQKdH/hm/uX2akfo1Q3qWKxfHkWK9i3tB7mGIo hVTZvwNH2/k4DeYqs6SI3g1YV49wt5PT5E+JdlyXQJWy8Q8AG7Qn8A76W6/FwLeMNk aLZgCvg0pmrzDQKKl4Pftr/uaebdHH9oXf0he7lc= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 627E89F; Wed, 2 May 2018 08:33:01 +0200 (CEST) Date: Wed, 2 May 2018 08:33:01 +0200 (CEST) From: Mikael Abrahamsson To: Fred Baker cc: Fred Templin , V6 Ops List In-Reply-To: <34390557-A240-400D-A9E3-255E82DE922F@gmail.com> Message-ID: References: <4AFC3A31-4A5A-433A-B02E-A154BBE5A566@gmail.com> <4bdf9f83e75ab30384ae32774b63d2a5@strayalpha.com> <279dd3a9d8f748a1afe22924ba980e9b@XCH15-06-08.nw.nos.boeing.com> <34390557-A240-400D-A9E3-255E82DE922F@gmail.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 06:33:08 -0000 On Mon, 30 Apr 2018, Fred Baker wrote: > Ole and Joe already replied. I'd be interested in comments from people > that have deployed the allocation of a prefix to a node. My I have seen discussions on how to make web servers get IPv6 address ranges without having to set "listen" for each individual IPv6 address in that range. Same thing with docker containers, which might today be implemented with interface semantics, but this is not necessarily needed, it's just the way it has to be done right now. So going forward, perhaps we'll see "routing" with "destinations" being a socket, or some new construct in some new API that hasn't been designed yet. Is this an "interface"? I don't know. Having to create interfaces and addresses for each application, binding to individual sockets for each address etc, that doesn't seem to scale (keeping huge data structs and matching things within these doesn't seem to make sense when one really wants to use the entire range) Instead an application (which can be a container for instance) should be "routed" this space, and know about it by being told this range of addresses. This is why I support prefix delegation of different kinds, and it should not only be DHCPv6-PD. I see no upside in running an DHCPv6 client in the docker container, when all information it needs is what prefix it has and where to expect these packets. Even running RA/ND here is no great upside. https://docs.docker.com/v17.09/engine/userguide/networking/default_network/ipv6/#how-ipv6-works-on-docker It seems to me that they're trying to do what Fred T is trying to do, but within a "host" (whatever that is). Can we come up with a way of doing this that requires the least amount of code and is re-usable both for within and between devices (if we need to make this distinction)? It seems to me that the docker people have done the best they can with current tools, and it shows that the tools are lacking. So I fully support Fred Templin in his quest of making this simpler/faster, I would just like to not have to tunnel DHCP packets within ND/RA packets and thus have everybody figure out how to unwrap this and give it to DHCP codebase, requiring to have these two applications at the same time. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed May 2 02:10:58 2018 Return-Path: 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 1D5FE12D872 for ; Wed, 2 May 2018 02:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 p6Sj6wnq1IR9 for ; Wed, 2 May 2018 02:10:55 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B86D1270A7 for ; Wed, 2 May 2018 02:10:54 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w429AoJO088242; Wed, 2 May 2018 11:10:50 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 992CE2013EA; Wed, 2 May 2018 11:10:50 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8B7D72013DF; Wed, 2 May 2018 11:10:50 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w429Ao9x014651; Wed, 2 May 2018 11:10:50 +0200 To: "Mudric, Dusan (Dusan)" References: <7931_1525047000_5AE65ECE_7931_11070_1_4AFC3A31-4A5A-433A-B02E-A154BBE5A566@gmail.com> <125d560c-2a26-7daf-9788-617e544224f5@gmail.com> <9142206A0C5BF24CB22755C8EC422E459B59DCE4@AZ-US1EXMB03.global.avaya.com> Cc: "v6ops@ietf.org" From: Alexandre Petrescu Message-ID: <90413e48-a994-47eb-152a-0e9ba5f434a0@gmail.com> Date: Wed, 2 May 2018 11:10:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <9142206A0C5BF24CB22755C8EC422E459B59DCE4@AZ-US1EXMB03.global.avaya.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 09:10:57 -0000 Le 01/05/2018 à 22:59, Mudric, Dusan (Dusan) a écrit : >>> The question Fred is asking has to do with "end systems that receive >>> a prefix delegation", and whether we would call such a one a host, a >>> router, a node, or something else. >> >> IMHO it should be called a router. > [[Dusan]] Do you envision a delegated prefix being assigned to a host? In principle no, I do not. The main scenario I am concerned with is an IoT Router that needs to give access always to some IP devices attached to it. It is an in-vehicle network. But, other people may need a smartphone computer to act as a Host most of the time. And some times (not always) to tether. Alex > From nobody Wed May 2 08:05:15 2018 Return-Path: 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 9CDE612D883 for ; Wed, 2 May 2018 08:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 c5P5-0G5Tf80 for ; Wed, 2 May 2018 08:05:11 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D163712025C for ; Wed, 2 May 2018 08:05:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id w42F59pA064123; Wed, 2 May 2018 08:05:10 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w42F51Oj063534 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 2 May 2018 08:05:01 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 2 May 2018 08:05:00 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1365.000; Wed, 2 May 2018 08:05:00 -0700 From: "Templin (US), Fred L" To: Alexandre Petrescu , "Mudric, Dusan (Dusan)" CC: "v6ops@ietf.org" Thread-Topic: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101 Thread-Index: AQHT4fV2JK3t2BQy2EuQsI2p75WazKQch85g Date: Wed, 2 May 2018 15:05:00 +0000 Message-ID: <04aa98098704441186e19197290e8e2a@XCH15-06-08.nw.nos.boeing.com> References: <7931_1525047000_5AE65ECE_7931_11070_1_4AFC3A31-4A5A-433A-B02E-A154BBE5A566@gmail.com> <125d560c-2a26-7daf-9788-617e544224f5@gmail.com> <9142206A0C5BF24CB22755C8EC422E459B59DCE4@AZ-US1EXMB03.global.avaya.com> <90413e48-a994-47eb-152a-0e9ba5f434a0@gmail.com> In-Reply-To: <90413e48-a994-47eb-152a-0e9ba5f434a0@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2018 15:05:14 -0000 SGkgRHVzYW4gYW5kIEFsZXgsDQoNCldlIGFyZSB1c2luZyBwcmVmaXggZGVsZWdhdGlvbiB0byBk ZWxlZ2F0ZSBJUHY2IHByZWZpeGVzIG92ZXIgYSBWUE4gdG8NCmNlbGxwaG9uZXMgdGhhdCBoYXZl IGNlbGx1bGFyIGFuZCBXaUZpIGludGVyZmFjZXMuIFRoZSBWUE4gaW50ZXJmYWNlDQoicmlkZXMg b3ZlciIgdGhlIHVuZGVybHlpbmcgcGh5c2ljYWwgaW50ZXJmYWNlcywgYW5kIHdlIGFzc2lnbiBh ZGRyZXNzZXMNCnRha2VuIGZyb20gdGhlICBwcmVmaXggdG8gdGhlIFZQTiBpbnRlcmZhY2UuDQoN ClVzaW5nIEZyZWQncyBpZGVhLCB0aG91Z2gsIGlmIHRoZSBpbXBsZW1lbnRhdGlvbiBhbGxvd2Vk IHdlIGNvdWxkIGFzc2lnbg0KdGhlIGFkZHJlc3NlcyB0byBhcHBsaWNhdGlvbnMgb24gdGhlIGNl bGxwaG9uZSBpbnN0ZWFkIG9mIHRvIHRoZSBWUE4NCmludGVyZmFjZS4gQUZBSUNULCBleGlzdGlu ZyBpbXBsZW1lbnRhdGlvbnMgZG8gbm90IGN1cnJlbnRseSBhbGxvdyB0aGF0LA0KYnV0IGl0IGNl cnRhaW5seSBzZWVtcyBsaWtlIHNvbWV0aGluZyB0aGF0IGNvdWxkIGJlIGltcGxlbWVudGVkLg0K DQpFaXRoZXIgd2F5LCB0aG91Z2gsIHRoZSBjZWxscGhvbmUgYWN0cyBhcyBhIGhvc3QgYW5kIG5v dCBhIHJvdXRlci4NCg0KVGhhbmtzIC0gRnJlZA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEFsZXhhbmRyZSBQZXRyZXNjdQ0KPiBTZW50OiBXZWRuZXNkYXksIE1heSAwMiwgMjAx OCAyOjExIEFNDQo+IFRvOiBNdWRyaWMsIER1c2FuIChEdXNhbikgPGRtdWRyaWNAYXZheWEuY29t Pg0KPiBDYzogdjZvcHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtdGVt cGxpbi12Nm9wcy1wZGhvc3QgZGlzY3Vzc2lvbiBwb3N0LUlFVEYgMTAxDQo+IA0KPiANCj4gDQo+ IExlIDAxLzA1LzIwMTggw6AgMjI6NTksIE11ZHJpYywgRHVzYW4gKER1c2FuKSBhIMOpY3JpdMKg Og0KPiA+Pj4gVGhlIHF1ZXN0aW9uIEZyZWQgaXMgYXNraW5nIGhhcyB0byBkbyB3aXRoICJlbmQg c3lzdGVtcyB0aGF0IHJlY2VpdmUNCj4gPj4+IGEgcHJlZml4IGRlbGVnYXRpb24iLCBhbmQgd2hl dGhlciB3ZSB3b3VsZCBjYWxsIHN1Y2ggYSBvbmUgYSBob3N0LCBhDQo+ID4+PiByb3V0ZXIsIGEg bm9kZSwgb3Igc29tZXRoaW5nIGVsc2UuDQo+ID4+DQo+ID4+IElNSE8gaXQgc2hvdWxkIGJlIGNh bGxlZCBhIHJvdXRlci4NCj4gPiBbW0R1c2FuXV0gRG8geW91IGVudmlzaW9uIGEgZGVsZWdhdGVk IHByZWZpeCBiZWluZyBhc3NpZ25lZCB0byBhIGhvc3Q/DQo+IA0KPiBJbiBwcmluY2lwbGUgbm8s IEkgZG8gbm90Lg0KPiANCj4gVGhlIG1haW4gc2NlbmFyaW8gSSBhbSBjb25jZXJuZWQgd2l0aCBp cyBhbiBJb1QgUm91dGVyIHRoYXQgbmVlZHMgdG8NCj4gZ2l2ZSBhY2Nlc3MgYWx3YXlzIHRvIHNv bWUgSVAgZGV2aWNlcyBhdHRhY2hlZCB0byBpdC4gSXQgaXMgYW4NCj4gaW4tdmVoaWNsZSBuZXR3 b3JrLg0KPiANCj4gQnV0LCBvdGhlciBwZW9wbGUgbWF5IG5lZWQgYSBzbWFydHBob25lIGNvbXB1 dGVyIHRvIGFjdCBhcyBhIEhvc3QgbW9zdA0KPiBvZiB0aGUgdGltZS4gQW5kIHNvbWUgdGltZXMg KG5vdCBhbHdheXMpIHRvIHRldGhlci4NCj4gDQo+IEFsZXgNCj4gDQo+ID4NCj4gDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHY2b3BzIG1haWxp bmcgbGlzdA0KPiB2Nm9wc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Y2b3BzDQo= From nobody Thu May 3 00:03:44 2018 Return-Path: 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 A9A2B126D73 for ; Thu, 3 May 2018 00:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, 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 A2i25TTDEx7i for ; Thu, 3 May 2018 00:03:41 -0700 (PDT) Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 737DE126B6E for ; Thu, 3 May 2018 00:03:41 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w4373Ya1023755; Thu, 3 May 2018 09:03:34 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 633822021E4; Thu, 3 May 2018 09:03:34 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 52E52200D2C; Thu, 3 May 2018 09:03:34 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w4373YFv007211; Thu, 3 May 2018 09:03:34 +0200 To: "Templin (US), Fred L" , "Mudric, Dusan (Dusan)" Cc: "v6ops@ietf.org" References: <7931_1525047000_5AE65ECE_7931_11070_1_4AFC3A31-4A5A-433A-B02E-A154BBE5A566@gmail.com> <125d560c-2a26-7daf-9788-617e544224f5@gmail.com> <9142206A0C5BF24CB22755C8EC422E459B59DCE4@AZ-US1EXMB03.global.avaya.com> <90413e48-a994-47eb-152a-0e9ba5f434a0@gmail.com> <04aa98098704441186e19197290e8e2a@XCH15-06-08.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: Date: Thu, 3 May 2018 09:03:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <04aa98098704441186e19197290e8e2a@XCH15-06-08.nw.nos.boeing.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 07:03:44 -0000 Le 02/05/2018 à 17:05, Templin (US), Fred L a écrit : > Hi Dusan and Alex, > > We are using prefix delegation to delegate IPv6 prefixes over a VPN to > cellphones that have cellular and WiFi interfaces. The VPN interface > "rides over" the underlying physical interfaces, and we assign addresses > taken from the prefix to the VPN interface. In this sense, this sole VPN interface makes this 'rider' machine be a Host, despite the presence of multiple physical interfaces in the 'under'-machine. I would like to ask you: for which reason was DHCPv6-PD used, instead of RA sent by the 'rider' machine present on the other end of the VPN interface? (and I do agree that prefix delegation can also be necessary for a Host, not only for a Router, when there are so many interfaces, machine instances, each potentially in a need of a distinct /64). Alex > > Using Fred's idea, though, if the implementation allowed we could assign > the addresses to applications on the cellphone instead of to the VPN > interface. AFAICT, existing implementations do not currently allow that, > but it certainly seems like something that could be implemented. > > Either way, though, the cellphone acts as a host and not a router. > > Thanks - Fred > >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petrescu >> Sent: Wednesday, May 02, 2018 2:11 AM >> To: Mudric, Dusan (Dusan) >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101 >> >> >> >> Le 01/05/2018 à 22:59, Mudric, Dusan (Dusan) a écrit : >>>>> The question Fred is asking has to do with "end systems that receive >>>>> a prefix delegation", and whether we would call such a one a host, a >>>>> router, a node, or something else. >>>> >>>> IMHO it should be called a router. >>> [[Dusan]] Do you envision a delegated prefix being assigned to a host? >> >> In principle no, I do not. >> >> The main scenario I am concerned with is an IoT Router that needs to >> give access always to some IP devices attached to it. It is an >> in-vehicle network. >> >> But, other people may need a smartphone computer to act as a Host most >> of the time. And some times (not always) to tether. >> >> Alex >> >>> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu May 3 08:12:24 2018 Return-Path: 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 A2C001277BB for ; Thu, 3 May 2018 08:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 pmnNXeusiV8T for ; Thu, 3 May 2018 08:12:20 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B60B0127076 for ; Thu, 3 May 2018 08:12:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id w43FCIL0012964; Thu, 3 May 2018 08:12:19 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w43FCCjl012893 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 3 May 2018 08:12:12 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 3 May 2018 08:12:11 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1365.000; Thu, 3 May 2018 08:12:11 -0700 From: "Templin (US), Fred L" To: Alexandre Petrescu , "Mudric, Dusan (Dusan)" CC: "v6ops@ietf.org" Thread-Topic: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101 Thread-Index: AQHT4fV2JK3t2BQy2EuQsI2p75WazKQch85ggAGDUoD///zogA== Date: Thu, 3 May 2018 15:12:11 +0000 Message-ID: <14f3235825bb4a1f89e9d9a0ac264cb6@XCH15-06-08.nw.nos.boeing.com> References: <7931_1525047000_5AE65ECE_7931_11070_1_4AFC3A31-4A5A-433A-B02E-A154BBE5A566@gmail.com> <125d560c-2a26-7daf-9788-617e544224f5@gmail.com> <9142206A0C5BF24CB22755C8EC422E459B59DCE4@AZ-US1EXMB03.global.avaya.com> <90413e48-a994-47eb-152a-0e9ba5f434a0@gmail.com> <04aa98098704441186e19197290e8e2a@XCH15-06-08.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 15:12:23 -0000 SGkgQWxleCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBBbGV4YW5k cmUgUGV0cmVzY3UgW21haWx0bzphbGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tXQ0KPiBTZW50 OiBUaHVyc2RheSwgTWF5IDAzLCAyMDE4IDEyOjA0IEFNDQo+IFRvOiBUZW1wbGluIChVUyksIEZy ZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT47IE11ZHJpYywgRHVzYW4gKER1c2FuKSA8 ZG11ZHJpY0BhdmF5YS5jb20+DQo+IENjOiB2Nm9wc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTog W3Y2b3BzXSBkcmFmdC10ZW1wbGluLXY2b3BzLXBkaG9zdCBkaXNjdXNzaW9uIHBvc3QtSUVURiAx MDENCj4gDQo+IA0KPiANCj4gTGUgMDIvMDUvMjAxOCDDoCAxNzowNSwgVGVtcGxpbiAoVVMpLCBG cmVkIEwgYSDDqWNyaXTCoDoNCj4gPiBIaSBEdXNhbiBhbmQgQWxleCwNCj4gPg0KPiA+IFdlIGFy ZSB1c2luZyBwcmVmaXggZGVsZWdhdGlvbiB0byBkZWxlZ2F0ZSBJUHY2IHByZWZpeGVzIG92ZXIg YSBWUE4gdG8NCj4gPiBjZWxscGhvbmVzIHRoYXQgaGF2ZSBjZWxsdWxhciBhbmQgV2lGaSBpbnRl cmZhY2VzLiBUaGUgVlBOIGludGVyZmFjZQ0KPiA+ICJyaWRlcyBvdmVyIiB0aGUgdW5kZXJseWlu ZyBwaHlzaWNhbCBpbnRlcmZhY2VzLCBhbmQgd2UgYXNzaWduIGFkZHJlc3Nlcw0KPiA+IHRha2Vu IGZyb20gdGhlICBwcmVmaXggdG8gdGhlIFZQTiBpbnRlcmZhY2UuDQo+IA0KPiBJbiB0aGlzIHNl bnNlLCB0aGlzIHNvbGUgVlBOIGludGVyZmFjZSBtYWtlcyB0aGlzICdyaWRlcicgbWFjaGluZSBi ZSBhDQo+IEhvc3QsIGRlc3BpdGUgdGhlIHByZXNlbmNlIG9mIG11bHRpcGxlIHBoeXNpY2FsIGlu dGVyZmFjZXMgaW4gdGhlDQo+ICd1bmRlcictbWFjaGluZS4NCj4gDQo+IEkgd291bGQgbGlrZSB0 byBhc2sgeW91OiBmb3Igd2hpY2ggcmVhc29uIHdhcyBESENQdjYtUEQgdXNlZCwgaW5zdGVhZCBv Zg0KPiBSQSBzZW50IGJ5IHRoZSAncmlkZXInIG1hY2hpbmUgcHJlc2VudCBvbiB0aGUgb3RoZXIg ZW5kIG9mIHRoZSBWUE4NCj4gaW50ZXJmYWNlPw0KDQpXZSBhbHJlYWR5IHVzZSBSUy9SQSBhcyBk aXNjdXNzZWQgaW4gJ2RyYWZ0LXRlbXBsaW4tNm1hbi1kaGNwdjYtbmRvcHQnLg0KQWNjb3JkaW5n IHRvIHRoYXQgZHJhZnQsIHRoZSBSUy9SQSBtZXNzYWdlcyBjYW4gY29udGFpbiBESENQdjYgUEQg b3B0aW9ucywNCm9yIHRoZXkgY2FuIGNvbnRhaW4gc29tZSBvdGhlciBmb3JtIG9mIFByZWZpeCBE ZWxlZ2F0aW9uIHNpZ25hbGluZyB0aGF0IGlzIHlldA0KdG8gYmUgc3BlY2lmaWVkLiBCdXQsIGFn YWluLCBpdCBpcyBiYXNlZCBvbiBSUy9SQSBhbmQgdGhlIGFjdHVhbCBQRCBzaWduYWxpbmcNCmVt YmVkZGVkIGluIHRoZSBSUy9SQSBjYW4gYmUgLSBidXQgbmVlZCBub3QgYmUgLSBESENQdjYuDQoN Cj4gKGFuZCBJIGRvIGFncmVlIHRoYXQgcHJlZml4IGRlbGVnYXRpb24gY2FuIGFsc28gYmUgbmVj ZXNzYXJ5IGZvciBhIEhvc3QsDQo+IG5vdCBvbmx5IGZvciBhIFJvdXRlciwgd2hlbiB0aGVyZSBh cmUgc28gbWFueSBpbnRlcmZhY2VzLCBtYWNoaW5lDQo+IGluc3RhbmNlcywgZWFjaCBwb3RlbnRp YWxseSBpbiBhIG5lZWQgb2YgYSBkaXN0aW5jdCAvNjQpLg0KDQpPSywgdGhhbmtzLg0KDQpGcmVk DQoNCj4gQWxleA0KPiANCj4gPg0KPiA+IFVzaW5nIEZyZWQncyBpZGVhLCB0aG91Z2gsIGlmIHRo ZSBpbXBsZW1lbnRhdGlvbiBhbGxvd2VkIHdlIGNvdWxkIGFzc2lnbg0KPiA+IHRoZSBhZGRyZXNz ZXMgdG8gYXBwbGljYXRpb25zIG9uIHRoZSBjZWxscGhvbmUgaW5zdGVhZCBvZiB0byB0aGUgVlBO DQo+ID4gaW50ZXJmYWNlLiBBRkFJQ1QsIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBkbyBub3Qg Y3VycmVudGx5IGFsbG93IHRoYXQsDQo+ID4gYnV0IGl0IGNlcnRhaW5seSBzZWVtcyBsaWtlIHNv bWV0aGluZyB0aGF0IGNvdWxkIGJlIGltcGxlbWVudGVkLg0KPiA+DQo+ID4gRWl0aGVyIHdheSwg dGhvdWdoLCB0aGUgY2VsbHBob25lIGFjdHMgYXMgYSBob3N0IGFuZCBub3QgYSByb3V0ZXIuDQo+ ID4NCj4gPiBUaGFua3MgLSBGcmVkDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gPj4gRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgQWxleGFuZHJlIFBldHJlc2N1DQo+ID4+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDAy LCAyMDE4IDI6MTEgQU0NCj4gPj4gVG86IE11ZHJpYywgRHVzYW4gKER1c2FuKSA8ZG11ZHJpY0Bh dmF5YS5jb20+DQo+ID4+IENjOiB2Nm9wc0BpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW3Y2 b3BzXSBkcmFmdC10ZW1wbGluLXY2b3BzLXBkaG9zdCBkaXNjdXNzaW9uIHBvc3QtSUVURiAxMDEN Cj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gTGUgMDEvMDUvMjAxOCDDoCAyMjo1OSwgTXVkcmljLCBE dXNhbiAoRHVzYW4pIGEgw6ljcml0wqA6DQo+ID4+Pj4+IFRoZSBxdWVzdGlvbiBGcmVkIGlzIGFz a2luZyBoYXMgdG8gZG8gd2l0aCAiZW5kIHN5c3RlbXMgdGhhdCByZWNlaXZlDQo+ID4+Pj4+IGEg cHJlZml4IGRlbGVnYXRpb24iLCBhbmQgd2hldGhlciB3ZSB3b3VsZCBjYWxsIHN1Y2ggYSBvbmUg YSBob3N0LCBhDQo+ID4+Pj4+IHJvdXRlciwgYSBub2RlLCBvciBzb21ldGhpbmcgZWxzZS4NCj4g Pj4+Pg0KPiA+Pj4+IElNSE8gaXQgc2hvdWxkIGJlIGNhbGxlZCBhIHJvdXRlci4NCj4gPj4+IFtb RHVzYW5dXSBEbyB5b3UgZW52aXNpb24gYSBkZWxlZ2F0ZWQgcHJlZml4IGJlaW5nIGFzc2lnbmVk IHRvIGEgaG9zdD8NCj4gPj4NCj4gPj4gSW4gcHJpbmNpcGxlIG5vLCBJIGRvIG5vdC4NCj4gPj4N Cj4gPj4gVGhlIG1haW4gc2NlbmFyaW8gSSBhbSBjb25jZXJuZWQgd2l0aCBpcyBhbiBJb1QgUm91 dGVyIHRoYXQgbmVlZHMgdG8NCj4gPj4gZ2l2ZSBhY2Nlc3MgYWx3YXlzIHRvIHNvbWUgSVAgZGV2 aWNlcyBhdHRhY2hlZCB0byBpdC4gSXQgaXMgYW4NCj4gPj4gaW4tdmVoaWNsZSBuZXR3b3JrLg0K PiA+Pg0KPiA+PiBCdXQsIG90aGVyIHBlb3BsZSBtYXkgbmVlZCBhIHNtYXJ0cGhvbmUgY29tcHV0 ZXIgdG8gYWN0IGFzIGEgSG9zdCBtb3N0DQo+ID4+IG9mIHRoZSB0aW1lLiBBbmQgc29tZSB0aW1l cyAobm90IGFsd2F5cykgdG8gdGV0aGVyLg0KPiA+Pg0KPiA+PiBBbGV4DQo+ID4+DQo+ID4+Pg0K PiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+PiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gPj4gdjZvcHNAaWV0Zi5vcmcNCj4gPj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQo= From nobody Thu May 3 08:20:02 2018 Return-Path: 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 30987128896 for ; Thu, 3 May 2018 08:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 3KFPMj-uJ_mH for ; Thu, 3 May 2018 08:19:58 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBCDE124C27 for ; Thu, 3 May 2018 08:19:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id w43FJv4D009132; Thu, 3 May 2018 08:19:57 -0700 Received: from XCH15-06-09.nw.nos.boeing.com (xch15-06-09.nw.nos.boeing.com [137.136.239.172]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w43FJpEo009079 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 3 May 2018 08:19:51 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-09.nw.nos.boeing.com (2002:8988:efac::8988:efac) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 3 May 2018 08:19:50 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1365.000; Thu, 3 May 2018 08:19:50 -0700 From: "Templin (US), Fred L" To: Fred Baker , V6 Ops List Thread-Topic: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101 Thread-Index: AQHT33RfJK3t2BQy2EuQsI2p75WazKQY5WWAgAU+PTA= Date: Thu, 3 May 2018 15:19:50 +0000 Message-ID: References: <4AFC3A31-4A5A-433A-B02E-A154BBE5A566@gmail.com> In-Reply-To: <4AFC3A31-4A5A-433A-B02E-A154BBE5A566@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 15:20:00 -0000 Hi Fred, > What do we call such a chassis? I call it a chassis. In my industry, we call it a "platform". A platform can be anything from an= airplane to a cellphone to a drone to a laptop computer to an automobile to a high-e= nd router, to a VM to, etc. etc. Platform is a generic term that can be applied to any type of device that m= ight ever want to receive a prefix delegation. I understand your chassis comment= , but to me it sounds a bit too automotive-centric. So, instead of host, rout= er, node, etc. we could refer to them as platforms. Thanks - Fred > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker > Sent: Sunday, April 29, 2018 5:09 PM > To: V6 Ops List > Subject: Re: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101 >=20 >=20 >=20 > On Apr 28, 2018, at 9:41 PM, Fred Baker wrote: > > 3. Does the answer to 2. depend on the weak-host, strong-host distincti= on? >=20 > Speaking for myself, and hats off, I think the weak-host/strong-host dist= inction isn't currently an accurate depiction of how hosts or > routers work in 2018, and isn't an obvious choice for a virtualized syste= m. I refer to RFC 1122, section 3.3.4.2, Multihoming > Requirements, which has to do with the choice of source address from a ho= st with more than one interface. >=20 > The rules given are that (1) if the packet is being sent in response to a= packet received, it MUST use the destination address in that > packet as its source address, (2) it MUST be possible for the application= to specify the source address, and (3) if neither (1) nor (2) > apply, the communication layers below the application MUST (as in, "are f= orced to") select a source address. As additional > considerations, (A) a host MAY discard a packet received on a physical in= terface other than that which its destination address is used > on, and (B) a host MAY restrict itself to sending datagrams from the inte= rface configured with whatever source address it uses. >=20 > The document then continues with "discussion", which to my thinking is th= e most interesting part of RFC 1122, 1123, and 1812, which > has to do with "why". The "Weak ES model" and the "Strong ES model" are f= ound in that discussion, and are explicitly non-normative. >=20 > In the Strong ES model, > The Strong ES (End System, i.e., host) model > emphasizes the host/gateway (ES/IS) distinction, > and would therefore substitute MUST for MAY in > issues (A) and (B) above. It tends to model a > multihomed host as a set of logical hosts within > the same physical host. >=20 > In other words, (A) a host MUST discard a packet received on a physical i= nterface other than that which its destination address is used > on, and (B) a host MUST restrict itself to sending datagrams from the int= erface configured with whatever source address it uses. >=20 > Note that this model logically requires that in > general there be at least one default gateway, and > preferably multiple defaults, for each IP source > address. >=20 > The Weak ES Model > de-emphasizes the ES/IS distinction, and > would therefore substitute MUST NOT for MAY in > issues (A) and (B). This model may be the more > natural one for hosts that wiretap gateway routing > protocols, and is necessary for hosts that have > embedded gateway functionality. >=20 > In other words, (A) a host MUST NOT discard a packet received on a physic= al interface other than that which its destination address is > used on, and (B) a host MUST NOT restrict itself to sending datagrams fro= m the interface configured with whatever source address it > uses. >=20 >=20 > The question Fred is asking has to do with "end systems that receive a pr= efix delegation", and whether we would call such a one a > host, a router, a node, or something else. >=20 >=20 > From my perspective, if a prefix is assigned to a chassis for use in addr= essing its applications, containers, virtual hosts, or whatever, it is > not assigned to an interface per se. It is best thought of as having been= assigned to a network that in some sense lies "behind" a > router, comparable to having been assigned to a home or other network thr= ough the CPE that connects to the upstream network. So > any discussion of the prefix being "on an interface" isn't visible to tha= t upstream network. There is an address there, of course, which > may be only a link-local address, and in the upstream router is primarily= used as the next hop in the route toward the prefix in > question. Whether it as available for network management purposes is not = specified; if it is a global address, it might be used for > network management purposes, and if it is link-local, the network managem= ent application would have to be on the same LAN for > that to work. I would expect, rather, that network management is done via= some application in the same chassis, perhaps in a > container or virtual host. Yes, that address would be used in network man= agement messages on the interface in question; if the > chassis had multiple physical interfaces, it might also be used on them. >=20 > In other words, the weak and strong ES models are inadequate to describe = a chassis allocated a prefix. It is a case not discussed in > currently-published RFCs. >=20 > What do we call such a chassis? I call it a chassis. It would be valid to= call it a node, although from a networking perspective it contains > multiple virtualized nodes. It is not, in my view, exactly a host (a syst= em with an address on one or more interfaces and responding > only packets sent to one of those addresses), nor is it exactly a router = (a system that receives messages sent to an address not > configured on one of its interfaces and forwarding it toward another syst= em, the indicated host); it is a third category. That category is > a set of systems that contain one or more identifiable routers and MAY co= ntain one or more identifiable hosts, in some virtualized > sense. From nobody Thu May 3 10:32:31 2018 Return-Path: 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 B629712EA93 for ; Thu, 3 May 2018 10:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 A0U1HUcfqXyh for ; Thu, 3 May 2018 10:32:27 -0700 (PDT) Received: from accordion.employees.org (accordion.employees.org [198.137.202.74]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DB3812EA8E for ; Thu, 3 May 2018 10:32:27 -0700 (PDT) Received: from [10.176.141.62] (77.16.61.62.tmi.telenormobil.no [77.16.61.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by accordion.employees.org (Postfix) with ESMTPSA id 205582D51D4; Thu, 3 May 2018 17:32:26 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Ole Troan X-Mailer: iPhone Mail (15E302) In-Reply-To: Date: Thu, 3 May 2018 19:32:22 +0200 Cc: Fred Baker , V6 Ops List Content-Transfer-Encoding: quoted-printable Message-Id: <87DF1B2D-F704-48D1-A29C-A735BFE34B7E@employees.org> References: <4AFC3A31-4A5A-433A-B02E-A154BBE5A566@gmail.com> To: "Templin (US), Fred L" Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 17:32:30 -0000 > On 3 May 2018, at 17:19, Templin (US), Fred L w= rote: >=20 > Hi Fred, >=20 >> What do we call such a chassis? I call it a chassis. >=20 > In my industry, we call it a "platform". A platform can be anything from a= n airplane > to a cellphone to a drone to a laptop computer to an automobile to a high-= end > router, to a VM to, etc. etc. >=20 > Platform is a generic term that can be applied to any type of device that m= ight > ever want to receive a prefix delegation. I understand your chassis commen= t, > but to me it sounds a bit too automotive-centric. So, instead of host, rou= ter, > node, etc. we could refer to them as platforms. We already have a name in IPv6. We call them nodes.=20 Ole >=20 > Thanks - Fred >=20 >> -----Original Message----- >> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker >> Sent: Sunday, April 29, 2018 5:09 PM >> To: V6 Ops List >> Subject: Re: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101 >>=20 >>=20 >>=20 >>> On Apr 28, 2018, at 9:41 PM, Fred Baker wrote= : >>> 3. Does the answer to 2. depend on the weak-host, strong-host distinctio= n? >>=20 >> Speaking for myself, and hats off, I think the weak-host/strong-host dist= inction isn't currently an accurate depiction of how hosts or >> routers work in 2018, and isn't an obvious choice for a virtualized syste= m. I refer to RFC 1122, section 3.3.4.2, Multihoming >> Requirements, which has to do with the choice of source address from a ho= st with more than one interface. >>=20 >> The rules given are that (1) if the packet is being sent in response to a= packet received, it MUST use the destination address in that >> packet as its source address, (2) it MUST be possible for the application= to specify the source address, and (3) if neither (1) nor (2) >> apply, the communication layers below the application MUST (as in, "are f= orced to") select a source address. As additional >> considerations, (A) a host MAY discard a packet received on a physical in= terface other than that which its destination address is used >> on, and (B) a host MAY restrict itself to sending datagrams from the inte= rface configured with whatever source address it uses. >>=20 >> The document then continues with "discussion", which to my thinking is th= e most interesting part of RFC 1122, 1123, and 1812, which >> has to do with "why". The "Weak ES model" and the "Strong ES model" are f= ound in that discussion, and are explicitly non-normative. >>=20 >> In the Strong ES model, >> The Strong ES (End System, i.e., host) model >> emphasizes the host/gateway (ES/IS) distinction, >> and would therefore substitute MUST for MAY in >> issues (A) and (B) above. It tends to model a >> multihomed host as a set of logical hosts within >> the same physical host. >>=20 >> In other words, (A) a host MUST discard a packet received on a physical i= nterface other than that which its destination address is used >> on, and (B) a host MUST restrict itself to sending datagrams from the int= erface configured with whatever source address it uses. >>=20 >> Note that this model logically requires that in >> general there be at least one default gateway, and >> preferably multiple defaults, for each IP source >> address. >>=20 >> The Weak ES Model >> de-emphasizes the ES/IS distinction, and >> would therefore substitute MUST NOT for MAY in >> issues (A) and (B). This model may be the more >> natural one for hosts that wiretap gateway routing >> protocols, and is necessary for hosts that have >> embedded gateway functionality. >>=20 >> In other words, (A) a host MUST NOT discard a packet received on a physic= al interface other than that which its destination address is >> used on, and (B) a host MUST NOT restrict itself to sending datagrams fro= m the interface configured with whatever source address it >> uses. >>=20 >>=20 >> The question Fred is asking has to do with "end systems that receive a pr= efix delegation", and whether we would call such a one a >> host, a router, a node, or something else. >>=20 >>=20 >> =46rom my perspective, if a prefix is assigned to a chassis for use in ad= dressing its applications, containers, virtual hosts, or whatever, it is >> not assigned to an interface per se. It is best thought of as having been= assigned to a network that in some sense lies "behind" a >> router, comparable to having been assigned to a home or other network thr= ough the CPE that connects to the upstream network. So >> any discussion of the prefix being "on an interface" isn't visible to tha= t upstream network. There is an address there, of course, which >> may be only a link-local address, and in the upstream router is primarily= used as the next hop in the route toward the prefix in >> question. Whether it as available for network management purposes is not s= pecified; if it is a global address, it might be used for >> network management purposes, and if it is link-local, the network managem= ent application would have to be on the same LAN for >> that to work. I would expect, rather, that network management is done via= some application in the same chassis, perhaps in a >> container or virtual host. Yes, that address would be used in network man= agement messages on the interface in question; if the >> chassis had multiple physical interfaces, it might also be used on them. >>=20 >> In other words, the weak and strong ES models are inadequate to describe a= chassis allocated a prefix. It is a case not discussed in >> currently-published RFCs. >>=20 >> What do we call such a chassis? I call it a chassis. It would be valid to= call it a node, although from a networking perspective it contains >> multiple virtualized nodes. It is not, in my view, exactly a host (a syst= em with an address on one or more interfaces and responding >> only packets sent to one of those addresses), nor is it exactly a router (= a system that receives messages sent to an address not >> configured on one of its interfaces and forwarding it toward another syst= em, the indicated host); it is a third category. That category is >> a set of systems that contain one or more identifiable routers and MAY co= ntain one or more identifiable hosts, in some virtualized >> sense. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu May 3 13:37:05 2018 Return-Path: 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 6992512EAC5 for ; Thu, 3 May 2018 13:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 Ejq_I_wB6TWN for ; Thu, 3 May 2018 13:37:01 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 941D8126CC7 for ; Thu, 3 May 2018 13:37:01 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id f189so15630091pfa.7 for ; Thu, 03 May 2018 13:37:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=NQj+dXJe3h5QfaH/sl46x4EHApxa72nVF4jpGfmoG80=; b=FlGUPUcFQ3L4FeoS2FCrkHi+RZmLswOC4Ct7cvubIXie93TV9lovq0LCUxdq3KwU0h +Jjl5UESmD3SJfVW9JX5XTmBfDskg0X118d6QF79m2tBgaGGNONGdWWGIWpw2IwIEuyV Xkfc9+TYwxrmXFSDHSxTD9INq/J2FcBGHbWceP43B524l7g+Ji8NmmkE2yNBv+JmJoie UbKAA8UwO6w5qNaHO1PE1TUobmQf+oce9RAwpQbTC5wopSkUHRQ1C8b6ONzyBlvn1GUu T6bpQbANd2QHJ2AijVafCo4E1VOaUJjgp3Z1yNc1LYyPlc0eoMgNzy03z4DHO0CEBPtJ FL7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=NQj+dXJe3h5QfaH/sl46x4EHApxa72nVF4jpGfmoG80=; b=Jnk1e4ToKvhMPmPFLLHy1cb7YGwy4WLOU7qDJfwQK5TbsiZzyzd/q3+vMeRzB4CU3U q1TFpnTL2muN3P/f6EHwQQZCGDeBGNS5I6zaXYcl+CcQEa1BU5q0SsdVX1YpOkH6pQWe j8ijs0i2ezvfUHHt5hlfFztR3DsOvG/CopWd3lg9b6u66FDUuhMkW0pEz3V450SZFKpe ekF8k7pR97GLH7MuaXvFr8mPW68QuYlLH6m0VL6DNcMvn2hY7zyl57ivj8IuYcvP/g86 sd6d064FYwDelwyXizlawRApCMz0JfchL5NkUg3C6Ww3GrAekY12rHh7Ij1IZPJbrv9Q XThQ== X-Gm-Message-State: ALQs6tBSCkio5UbnXEQWNJpXkrxRMJ62/zoBfDdO4nvVMMLLeaZO3WuQ ZU/9xmCuA2HHnK81eHgVy7rUSQ== X-Google-Smtp-Source: AB8JxZpcC0LbQDr6sNY5WctHKyyvUOiNgSijNyRZacJwvm0t4bzNuPnqfA0RmyiOJdLQe+Vh01fdSg== X-Received: by 2002:a17:902:7615:: with SMTP id k21-v6mr10753173pll.97.1525379820793; Thu, 03 May 2018 13:37:00 -0700 (PDT) Received: from [192.168.178.26] ([118.149.104.73]) by smtp.gmail.com with ESMTPSA id k24sm3393625pff.118.2018.05.03.13.36.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 May 2018 13:36:59 -0700 (PDT) Sender: Brian Carpenter To: v6ops@ietf.org References: <4AFC3A31-4A5A-433A-B02E-A154BBE5A566@gmail.com> <87DF1B2D-F704-48D1-A29C-A735BFE34B7E@employees.org> From: Brian E Carpenter Message-ID: <899c2848-9ffe-40fc-7216-148d9345ecca@gmail.com> Date: Fri, 4 May 2018 08:37:03 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <87DF1B2D-F704-48D1-A29C-A735BFE34B7E@employees.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 20:37:03 -0000 On 04/05/2018 05:32, Ole Troan wrote: > > >> On 3 May 2018, at 17:19, Templin (US), Fred L wrote: >> >> Hi Fred, >> >>> What do we call such a chassis? I call it a chassis. >> >> In my industry, we call it a "platform". A platform can be anything from an airplane >> to a cellphone to a drone to a laptop computer to an automobile to a high-end >> router, to a VM to, etc. etc. >> >> Platform is a generic term that can be applied to any type of device that might >> ever want to receive a prefix delegation. I understand your chassis comment, >> but to me it sounds a bit too automotive-centric. So, instead of host, router, >> node, etc. we could refer to them as platforms. > > We already have a name in IPv6. We call them nodes. Due to virtualisation, nodes may contain nodes, recursively. Each node may contain multiple (virtual) interfaces. I think that explains some of the confusion. Brian From nobody Thu May 3 14:50:22 2018 Return-Path: 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 EDE8B12EAFC for ; Thu, 3 May 2018 14:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 qqBRHOEWATJx for ; Thu, 3 May 2018 14:50:17 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FD6212EAF9 for ; Thu, 3 May 2018 14:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Type:MIME-Version:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=BxdQe8LYnQ4QZuA39HvaiSDi9gB4P0gLR6gKAndpekg=; b=AWbRBUIw7kIf4/wu0QQaW1AuV 3NPq8VwlWN3vWxToFlcogMqcRP6wpX6M8T1iCdedU2nw/wkiAcPXghm74YdffLHesFNT/iWX0/k+C SfR/B9vbJ5dQGzYuymN4Vp8AS2r3CXOZo68ptqtDIBCgnS2o0HNRToySwzS4tsNoYWUyk8i3g/nyQ KxGsDJU29OybN2Aqe6a8z5rYjviGDCG/8zH4r1o5tuwET4pHZKjqFAz25sj3DaDbYYSC4mfFDITsc lPZ01PwVXP1r4rKOuw3GnXqVmJWZY+Iq5jwgwFnHiPlgav19A9+Bm2LXGVmKyL61sbrI8NKcHcc+O z86nUz2aw==; Received: from [::1] (port=60368 helo=webmail.strayalpha.com) by server217.web-hosting.com with esmtpa (Exim 4.89_1) (envelope-from ) id 1fEM7B-004HQy-SO; Thu, 03 May 2018 17:50:16 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_410a5369ef822b5576041eb30d3ef831" Date: Thu, 03 May 2018 17:50:13 -0400 From: Joe Touch To: Brian E Carpenter Cc: v6ops@ietf.org In-Reply-To: <899c2848-9ffe-40fc-7216-148d9345ecca@gmail.com> References: <4AFC3A31-4A5A-433A-B02E-A154BBE5A566@gmail.com> <87DF1B2D-F704-48D1-A29C-A735BFE34B7E@employees.org> <899c2848-9ffe-40fc-7216-148d9345ecca@gmail.com> Message-ID: <8432d2c011c4bb1364e1378ed5f45a16@strayalpha.com> X-Sender: touch@strayalpha.com User-Agent: Roundcube Webmail/1.2.7 X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 21:50:21 -0000 --=_410a5369ef822b5576041eb30d3ef831 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII On 2018-05-03 16:37, Brian E Carpenter wrote: > On 04/05/2018 05:32, Ole Troan wrote: > >> We already have a name in IPv6. We call them nodes. > > Due to virtualisation, nodes may contain nodes, recursively. Each node may > contain multiple (virtual) interfaces. I think that explains some of the confusion. It really shouldn't. Ultimately, the role of any component (physical or virtual) ought to be very clear in the context of any given network virtualization layer. - if it sources or sinks IP packets within that layer with an address it has been assigned, it is a HOST - if it relays information within that layer without consideration of the IP header, it is a LINK (or link layer/link network) - if it relays information within that layer based on the IP header, it is a ROUTER HOST, LINK, and ROUTER are always defined only in the context of a single virtual/real layer anyway. (and yes, a device that relays based IP headers that also sources/sinks IP packets, such as when a routing device both forwards and supports remote login or SNMP, then it is *both* a HOST and a ROUTER. I.e., generally, routing devices cannot participate in routing protocols without also being HOSTS.) Joe --=_410a5369ef822b5576041eb30d3ef831 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8


 


On 2018-05-03 16:37, Brian E Carpenter wrote:

= On 04/05/2018 05:32, Ole Troan wrote:

We already have a name in IPv6. We call them no= des.

Due to virtualisation, nodes may contain nodes, recursively. Each no= de may
contain multiple (virtual) interfaces. I think that explains s= ome of the confusion.
=  
= It really shouldn't.
=  
= Ultimately, the role of any component (physical or virtual) ought to be ver= y clear in the context of any given network virtualization layer.
=  
= - if it sources or sinks IP packets within that layer with an address it ha= s been assigned, it is a HOST
=  
= - if it relays information within that layer without consideration of the I= P header, it is a LINK (or link layer/link network)
=  
= - if it relays information within that layer based on the IP header, it is = a ROUTER
=  
= HOST, LINK, and ROUTER are always defined only in the context of a single v= irtual/real layer anyway.
=  
= (and yes, a device that relays based IP headers that also sources/sinks IP = packets, such as when a routing device both forwards and supports remote lo= gin or SNMP, then it is *both* a HOST and a ROUTER. I.e., generally, routin= g devices cannot participate in routing protocols without also being HOSTS= =2E)
=  
= Joe
--=_410a5369ef822b5576041eb30d3ef831-- From nobody Thu May 3 14:54:46 2018 Return-Path: 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 2487012EAFC for ; Thu, 3 May 2018 14:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HTML_MESSAGE=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 2rdim4bZB669 for ; Thu, 3 May 2018 14:54:42 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (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 BF3341267BB for ; Thu, 3 May 2018 14:54:41 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id h15so12803557uan.11 for ; Thu, 03 May 2018 14:54:41 -0700 (PDT) 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=cNM+YAN85pxBEoMH3o7X17upt5VUvzFm/YANPntfNSY=; b=XrhgRqA/k9sCinkWVDuVnXc4RqTh8c5iLrSF2/J1p/dnqe25+LhZmybRPAxyS+oGp8 SCekN9lMl/983kSNbugG/lnZD2hT0M6+PhaU8buBKo5+M6Yub1vSpZNZuKrsGaBWSRR5 2rcx9rGnMn9Bfo7EqJgjgCWTr/jsstI2FUTMC+W/PHraHDT6DdolMxYtI6vYZdiyfARX XpZF8YIo9x+VuRxD6EBH+H/GvBFUf8My9PZ+shr93lNyuoMQ/fO62X8N7EBGWOMJON+g AwviysJtQRm8jPtI6Sh6ciVu8BO9ZkevW6AWlbZ+4fakSD6MaNfLo+FKTrnmWmixNMK6 /Rcg== 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=cNM+YAN85pxBEoMH3o7X17upt5VUvzFm/YANPntfNSY=; b=t3bYom1QzahyqrWkItEeMuQbDGkY+SKpw0y3FKW3+NgOBm0sPE9CgYBRAmdAJ35bXk 8XMWVM1Do1lz1SAwyz83aa5j8eTAPpcfVJ7J2cqaX+neCAbXRUuV7igp75tG4JrGEoe2 5AsOciU0OzHFyZw6faKom4S/HxLBvCXSOkGZjywvMSBn9OPg/1X4YcBXuSw+sl6YLdSk XHfrcT5Xu4ahRU7C7NrQsBliQHBaXk2zNVcfnlpLlMJ3nVEwjpwbN8v34FGQIM4xtBjO ENwHA2qMGZdBkWaaSYOgLP6qyWhjePlhTWpv28kctQ6Y+LcxGuZM6kj4RYg97mHazr7U OcxQ== X-Gm-Message-State: ALQs6tDFj6AQuXw6ZjlfF/WhAjF7MEdmQIau+cg++5RzQNEpANCo3mcr iaLr/gqUQU+mqNifcidTE5MVwEsfZZE8fC1A8BM= X-Google-Smtp-Source: AB8JxZozfACnTWDPkluoul1n5bLeUaTDkl30cTAkreOwVIjqm/y+oGlpf36dggpQI0Dp31lcTS7PiAmXsDix1FCkNM0= X-Received: by 10.159.53.231 with SMTP id u36mr22915696uad.187.1525384480621; Thu, 03 May 2018 14:54:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mark Smith Date: Thu, 03 May 2018 21:54:29 +0000 Message-ID: To: Fred Baker Cc: v6ops list Content-Type: multipart/alternative; boundary="001a1145c7ba1d0712056b5440d8" Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2018 21:54:44 -0000 --001a1145c7ba1d0712056b5440d8 Content-Type: text/plain; charset="UTF-8" On Sun., 29 Apr. 2018, 14:41 Fred Baker, wrote: > At IETF 101, Fred Templin presented draft-templin-v6ops-pdhost. The draft > is at https://tools.ietf.org/html/draft-templin-v6ops-pdhost, and his > presentation deck is at > https://datatracker.ietf.org/meeting/101/materials/slides-101-v6ops-ipv6-prefix-delegation-models-00 > . > > I would like to invite discussion. > > In the deck, he asks three questions: > 1. Do we want to remain prefix delegation service agnostic, or focus on > one specific service (e.g., DHCPv6-PD)? > 2. What do we call end systems that receive a prefix delegation? Host? > Router? Node? > The RFC8200 definition of a router is: "a node that forwards IPv6 packets not explicitly addressed to itself." so these qualify as hosts. 3. Does the answer to 2. depend on the weak-host, strong-host distinction? > I don't think so. Strong host/weak host is about how strict a host is about accepting host owned addresses on interfaces that aren't configured with these addresses. WH/SH does have an influence though in this scenario. If the host follows SH, then the delegated prefix has to be assigned to the interface over which the host will receive packets, otherwise it will ignore them. That means the host would by default also respond to ND NSes for any address within the prefix from devices attached to that link. I think there's an ND/NUD DoS attack opportunity in that scenario. This is assuming that other devices somehow know that the delegated prefix is on-link. An attacker could effectively assert that through their tool regardless of the network's view. WH would be a safer option because the prefix is effectively assigned to an internal interface. Regards, Mark. > You are welcome, of course, to also raise any other questions or concerns. > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --001a1145c7ba1d0712056b5440d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


= On Sun., 29 Apr. 2018, 14:41 Fred Baker, <fredbaker.ietf@gmail.com= > wrote:
At IETF 101, Fred T= emplin presented draft-templin-v6ops-pdhost. The draft is at https://tools.ietf.org/html/draft-temp= lin-v6ops-pdhost, and his presentation deck is at https://datatracker.ietf.org/meeting/101/materials/slides-101-v6ops-ipv6-p= refix-delegation-models-00.

I would like to invite discussion.

In the deck, he asks three questions:
1. Do we want to remain prefix delegation service agnostic, or focus on one= specific service (e.g., DHCPv6-PD)?
2. What do we call end systems that receive a prefix delegation? Host? Rout= er? Node?

The RFC8200 definition of a router is:
"a node t= hat forwards IPv6 packets not explicitly
                addressed to =
itself."

so these qualify as hosts.


<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> 3. Does the answer to 2. depend on the weak-host, strong-host distinction?<= br>

I= don't think so.=C2=A0

Strong host/weak host is about how strict a host is about accepting host= owned addresses on interfaces that aren't configured with these addres= ses.

WH/SH does have an = influence though in this scenario.

If the host follows SH, then the delegated prefix has to be assi= gned to the interface over which the host will receive packets, otherwise i= t will ignore them.

That= means the host would by default also respond to ND NSes for any address wi= thin the prefix from devices attached to that link. I think there's an = ND/NUD DoS attack opportunity in that scenario.

=
This is assuming that other devices somehow=C2=A0 k= now that the delegated prefix is on-link. An attacker could effectively ass= ert that through their tool regardless of the network's view.

WH would be a safer option becaus= e the prefix is effectively assigned to an internal interface.

Regards,
Mark= .





You are welcome, of course, to also raise any other questions or concerns.<= br>

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listin= fo/v6ops
--001a1145c7ba1d0712056b5440d8-- From nobody Fri May 4 08:15:03 2018 Return-Path: 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 4CA8A12D86D for ; Fri, 4 May 2018 08:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 7sQqkcu8Xxca for ; Fri, 4 May 2018 08:14:58 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2FA912D7F1 for ; Fri, 4 May 2018 08:14:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id w44FEvER036420; Fri, 4 May 2018 08:14:57 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w44FEs4x036381 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 4 May 2018 08:14:55 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 4 May 2018 08:14:54 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1365.000; Fri, 4 May 2018 08:14:54 -0700 From: "Templin (US), Fred L" To: Mark Smith , Fred Baker CC: v6ops list Thread-Topic: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101 Thread-Index: AQHT4ylPJK3t2BQy2EuQsI2p75WazKQfrNlw Date: Fri, 4 May 2018 15:14:54 +0000 Message-ID: <038d0037f32140ee9c2af880fdf8980f@XCH15-06-08.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.136.248.6] Content-Type: multipart/alternative; boundary="_000_038d0037f32140ee9c2af880fdf8980fXCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 15:15:01 -0000 --_000_038d0037f32140ee9c2af880fdf8980fXCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFyaywNCg0KPlRoYXQgbWVhbnMgdGhlIGhvc3Qgd291bGQgYnkgZGVmYXVsdCBhbHNvIHJl c3BvbmQgdG8gTkQgTlNlcyBmb3IgYW55IGFkZHJlc3Mgd2l0aGluIHRoZSBwcmVmaXggZnJvbSBk ZXZpY2VzIGF0dGFjaGVkIHRvIHRoYXQgbGluay4gSSB0aGluayB0aGVyZSdzIGFuIE5EL05VRCBE b1MgYXR0YWNrIG9wcG9ydHVuaXR5IGluIHRoYXQgc2NlbmFyaW8uDQoNClRoaXMgY291bGQgcGVy aGFwcyBiZSBtYWRlIG1vcmUgY2xlYXIsIGJ1dCBvbmx5IGluZGl2aWR1YWwgYWRkcmVzc2VzIGFy ZSBhc3NpZ25lZA0KdG8gdGhlIGludGVyZmFjZSBvdmVyIHdoaWNoIHRoZSBkZWxlZ2F0ZWQgcHJl Zml4IHdhcyByZWNlaXZlZDsgdGhlIGRlbGVnYXRlZCBwcmVmaXgNCml0c2VsZiBpcyBub3QgYXNz aWduZWQgdG8gdGhlIGludGVyZmFjZSAob3IsIGluIHRoZSBsYW5ndWFnZSBvZiBSRkM0ODYxLCBp cyBub3QgYWRkZWQNCnRvIHRoZSBwcmVmaXggbGlzdCBvZiB0aGUgcmVjZWl2aW5nIGludGVyZmFj ZSkuIFNvLCBhbnkgTkQvTlVEIG1lc3NhZ2luZyBmb3IgYm9ndXMNCmFkZHJlc3NlcyB3b3VsZCBz aW1wbHkgYmUgZHJvcHBlZCBhbmQgbm90IHJlc3BvbmRlZCB0by4gRG9lcyB0aGF0IGhlbHAgY2xh cmlmeT8NCg0KVGhhbmtzIC0gRnJlZA0KDQoNCkZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcmsgU21pdGgNClNlbnQ6IFRodXJzZGF5LCBN YXkgMDMsIDIwMTggMjo1NCBQTQ0KVG86IEZyZWQgQmFrZXIgPGZyZWRiYWtlci5pZXRmQGdtYWls LmNvbT4NCkNjOiB2Nm9wcyBsaXN0IDx2Nm9wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdjZv cHNdIGRyYWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0IGRpc2N1c3Npb24gcG9zdC1JRVRGIDEwMQ0K DQoNCk9uIFN1bi4sIDI5IEFwci4gMjAxOCwgMTQ6NDEgRnJlZCBCYWtlciwgPGZyZWRiYWtlci5p ZXRmQGdtYWlsLmNvbTxtYWlsdG86ZnJlZGJha2VyLmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQpB dCBJRVRGIDEwMSwgRnJlZCBUZW1wbGluIHByZXNlbnRlZCBkcmFmdC10ZW1wbGluLXY2b3BzLXBk aG9zdC4gVGhlIGRyYWZ0IGlzIGF0IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10 ZW1wbGluLXY2b3BzLXBkaG9zdCwgYW5kIGhpcyBwcmVzZW50YXRpb24gZGVjayBpcyBhdCBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL21lZXRpbmcvMTAxL21hdGVyaWFscy9zbGlkZXMtMTAx LXY2b3BzLWlwdjYtcHJlZml4LWRlbGVnYXRpb24tbW9kZWxzLTAwLg0KDQpJIHdvdWxkIGxpa2Ug dG8gaW52aXRlIGRpc2N1c3Npb24uDQoNCkluIHRoZSBkZWNrLCBoZSBhc2tzIHRocmVlIHF1ZXN0 aW9uczoNCjEuIERvIHdlIHdhbnQgdG8gcmVtYWluIHByZWZpeCBkZWxlZ2F0aW9uIHNlcnZpY2Ug YWdub3N0aWMsIG9yIGZvY3VzIG9uIG9uZSBzcGVjaWZpYyBzZXJ2aWNlIChlLmcuLCBESENQdjYt UEQpPw0KMi4gV2hhdCBkbyB3ZSBjYWxsIGVuZCBzeXN0ZW1zIHRoYXQgcmVjZWl2ZSBhIHByZWZp eCBkZWxlZ2F0aW9uPyBIb3N0PyBSb3V0ZXI/IE5vZGU/DQoNClRoZSBSRkM4MjAwIGRlZmluaXRp b24gb2YgYSByb3V0ZXIgaXM6DQoNCiJhIG5vZGUgdGhhdCBmb3J3YXJkcyBJUHY2IHBhY2tldHMg bm90IGV4cGxpY2l0bHkNCg0KICAgICAgICAgICAgICAgIGFkZHJlc3NlZCB0byBpdHNlbGYuIg0K DQoNCg0Kc28gdGhlc2UgcXVhbGlmeSBhcyBob3N0cy4NCg0KMy4gRG9lcyB0aGUgYW5zd2VyIHRv IDIuIGRlcGVuZCBvbiB0aGUgd2Vhay1ob3N0LCBzdHJvbmctaG9zdCBkaXN0aW5jdGlvbj8NCg0K SSBkb24ndCB0aGluayBzby4NCg0KU3Ryb25nIGhvc3Qvd2VhayBob3N0IGlzIGFib3V0IGhvdyBz dHJpY3QgYSBob3N0IGlzIGFib3V0IGFjY2VwdGluZyBob3N0IG93bmVkIGFkZHJlc3NlcyBvbiBp bnRlcmZhY2VzIHRoYXQgYXJlbid0IGNvbmZpZ3VyZWQgd2l0aCB0aGVzZSBhZGRyZXNzZXMuDQoN CldIL1NIIGRvZXMgaGF2ZSBhbiBpbmZsdWVuY2UgdGhvdWdoIGluIHRoaXMgc2NlbmFyaW8uDQoN CklmIHRoZSBob3N0IGZvbGxvd3MgU0gsIHRoZW4gdGhlIGRlbGVnYXRlZCBwcmVmaXggaGFzIHRv IGJlIGFzc2lnbmVkIHRvIHRoZSBpbnRlcmZhY2Ugb3ZlciB3aGljaCB0aGUgaG9zdCB3aWxsIHJl Y2VpdmUgcGFja2V0cywgb3RoZXJ3aXNlIGl0IHdpbGwgaWdub3JlIHRoZW0uDQoNClRoYXQgbWVh bnMgdGhlIGhvc3Qgd291bGQgYnkgZGVmYXVsdCBhbHNvIHJlc3BvbmQgdG8gTkQgTlNlcyBmb3Ig YW55IGFkZHJlc3Mgd2l0aGluIHRoZSBwcmVmaXggZnJvbSBkZXZpY2VzIGF0dGFjaGVkIHRvIHRo YXQgbGluay4gSSB0aGluayB0aGVyZSdzIGFuIE5EL05VRCBEb1MgYXR0YWNrIG9wcG9ydHVuaXR5 IGluIHRoYXQgc2NlbmFyaW8uDQoNClRoaXMgaXMgYXNzdW1pbmcgdGhhdCBvdGhlciBkZXZpY2Vz IHNvbWVob3cgIGtub3cgdGhhdCB0aGUgZGVsZWdhdGVkIHByZWZpeCBpcyBvbi1saW5rLiBBbiBh dHRhY2tlciBjb3VsZCBlZmZlY3RpdmVseSBhc3NlcnQgdGhhdCB0aHJvdWdoIHRoZWlyIHRvb2wg cmVnYXJkbGVzcyBvZiB0aGUgbmV0d29yaydzIHZpZXcuDQoNCldIIHdvdWxkIGJlIGEgc2FmZXIg b3B0aW9uIGJlY2F1c2UgdGhlIHByZWZpeCBpcyBlZmZlY3RpdmVseSBhc3NpZ25lZCB0byBhbiBp bnRlcm5hbCBpbnRlcmZhY2UuDQoNClJlZ2FyZHMsDQpNYXJrLi4NCg0KDQoNCg0KDQpZb3UgYXJl IHdlbGNvbWUsIG9mIGNvdXJzZSwgdG8gYWxzbyByYWlzZSBhbnkgb3RoZXIgcXVlc3Rpb25zIG9y IGNvbmNlcm5zLg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQp2Nm9wcyBtYWlsaW5nIGxpc3QNCnY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0Bp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== --_000_038d0037f32140ee9c2af880fdf8980fXCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0K CXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICov DQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxT dHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjEyMTUxMzgwOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRl LWlkczotMTM3NTA2NTgzOCAtNDYxMzI1NzQwIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxl dmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBNYXJr LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mZ3Q7VGhhdCBtZWFucyB0aGUgaG9zdCB3b3VsZCBieSBkZWZhdWx0IGFs c28gcmVzcG9uZCB0byBORCBOU2VzIGZvciBhbnkgYWRkcmVzcyB3aXRoaW4gdGhlIHByZWZpeCBm cm9tIGRldmljZXMgYXR0YWNoZWQgdG8gdGhhdCBsaW5rLiBJIHRoaW5rIHRoZXJlJ3MgYW4gTkQv TlVEIERvUyBhdHRhY2sgb3Bwb3J0dW5pdHkgaW4gdGhhdCBzY2VuYXJpby48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyRjU1OTc7bXNvLXN0eWxlLXRleHRmaWxs LWZpbGwtY29sb3I6IzJGNTU5Nzttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1hbHBoYToxMDAuMCUi PlRoaXMgY291bGQgcGVyaGFwcyBiZSBtYWRlIG1vcmUgY2xlYXIsIGJ1dCBvbmx5IGluZGl2aWR1 YWwgYWRkcmVzc2VzIGFyZSBhc3NpZ25lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMkY1NTk3O21zby1zdHlsZS10ZXh0Zmls bC1maWxsLWNvbG9yOiMyRjU1OTc7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtYWxwaGE6MTAwLjAl Ij50byB0aGUgaW50ZXJmYWNlIG92ZXIgd2hpY2ggdGhlIGRlbGVnYXRlZCBwcmVmaXggd2FzIHJl Y2VpdmVkOyB0aGUgZGVsZWdhdGVkIHByZWZpeDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMkY1NTk3O21zby1zdHlsZS10ZXh0 ZmlsbC1maWxsLWNvbG9yOiMyRjU1OTc7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtYWxwaGE6MTAw LjAlIj5pdHNlbGYgaXMgbm90IGFzc2lnbmVkIHRvIHRoZSBpbnRlcmZhY2UgKG9yLCBpbiB0aGUg bGFuZ3VhZ2Ugb2YgUkZDNDg2MSwgaXMgbm90IGFkZGVkPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyRjU1OTc7bXNvLXN0eWxl LXRleHRmaWxsLWZpbGwtY29sb3I6IzJGNTU5Nzttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1hbHBo YToxMDAuMCUiPnRvIHRoZSBwcmVmaXggbGlzdCBvZiB0aGUgcmVjZWl2aW5nIGludGVyZmFjZSku IFNvLCBhbnkgTkQvTlVEIG1lc3NhZ2luZyBmb3IgYm9ndXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzJGNTU5Nzttc28tc3R5 bGUtdGV4dGZpbGwtZmlsbC1jb2xvcjojMkY1NTk3O21zby1zdHlsZS10ZXh0ZmlsbC1maWxsLWFs cGhhOjEwMC4wJSI+YWRkcmVzc2VzIHdvdWxkIHNpbXBseSBiZSBkcm9wcGVkIGFuZCBub3QgcmVz cG9uZGVkIHRvLiBEb2VzIHRoYXQgaGVscCBjbGFyaWZ5PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMkY1NTk3O21zby1zdHls ZS10ZXh0ZmlsbC1maWxsLWNvbG9yOiMyRjU1OTc7bXNvLXN0eWxlLXRleHRmaWxsLWZpbGwtYWxw aGE6MTAwLjAlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzJGNTU5Nzttc28tc3R5bGUtdGV4dGZpbGwtZmlsbC1j b2xvcjojMkY1NTk3O21zby1zdHlsZS10ZXh0ZmlsbC1maWxsLWFscGhhOjEwMC4wJSI+VGhhbmtz IC0gRnJlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiB2Nm9wcyBbbWFpbHRvOnY2 b3BzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1hcmsgU21pdGg8YnI+ DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1heSAwMywgMjAxOCAyOjU0IFBNPGJyPg0KPGI+VG86 PC9iPiBGcmVkIEJha2VyICZsdDtmcmVkYmFrZXIuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+ Q2M6PC9iPiB2Nm9wcyBsaXN0ICZsdDt2Nm9wc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFt2Nm9wc10gZHJhZnQtdGVtcGxpbi12Nm9wcy1wZGhvc3QgZGlzY3Vzc2lvbiBw b3N0LUlFVEYgMTAxPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4uLCAy OSBBcHIuIDIwMTgsIDE0OjQxIEZyZWQgQmFrZXIsICZsdDs8YSBocmVmPSJtYWlsdG86ZnJlZGJh a2VyLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZnJlZGJha2VyLmlldGZAZ21haWwu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BdCBJRVRGIDEwMSwgRnJlZCBUZW1wbGluIHByZXNlbnRlZCBk cmFmdC10ZW1wbGluLXY2b3BzLXBkaG9zdC4gVGhlIGRyYWZ0IGlzIGF0DQo8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGVtcGxpbi12Nm9wcy1wZGhvc3QiIHRhcmdl dD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10ZW1wbGluLXY2 b3BzLXBkaG9zdDwvYT4sIGFuZCBoaXMgcHJlc2VudGF0aW9uIGRlY2sgaXMgYXQNCjxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDEvbWF0ZXJpYWxzL3NsaWRl cy0xMDEtdjZvcHMtaXB2Ni1wcmVmaXgtZGVsZWdhdGlvbi1tb2RlbHMtMDAiIHRhcmdldD0iX2Js YW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDEvbWF0ZXJpYWxz L3NsaWRlcy0xMDEtdjZvcHMtaXB2Ni1wcmVmaXgtZGVsZWdhdGlvbi1tb2RlbHMtMDA8L2E+Ljxi cj4NCjxicj4NCkkgd291bGQgbGlrZSB0byBpbnZpdGUgZGlzY3Vzc2lvbi48YnI+DQo8YnI+DQpJ biB0aGUgZGVjaywgaGUgYXNrcyB0aHJlZSBxdWVzdGlvbnM6PGJyPg0KMS4gRG8gd2Ugd2FudCB0 byByZW1haW4gcHJlZml4IGRlbGVnYXRpb24gc2VydmljZSBhZ25vc3RpYywgb3IgZm9jdXMgb24g b25lIHNwZWNpZmljIHNlcnZpY2UgKGUuZy4sIERIQ1B2Ni1QRCk/PGJyPg0KMi4gV2hhdCBkbyB3 ZSBjYWxsIGVuZCBzeXN0ZW1zIHRoYXQgcmVjZWl2ZSBhIHByZWZpeCBkZWxlZ2F0aW9uPyBIb3N0 PyBSb3V0ZXI/IE5vZGU/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIFJGQzgyMDAgZGVmaW5pdGlv biBvZiBhIHJvdXRlciBpczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+JnF1b3Q7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+YSBub2Rl IHRoYXQgZm9yd2FyZHMgSVB2NiBwYWNrZXRzIG5vdCBleHBsaWNpdGx5PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhZGRyZXNzZWQgdG8gaXRzZWxmLiZxdW90Ozxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjVwdCI+c28gdGhlc2UgcXVhbGlmeSBhcyBob3N0cy48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zLiBEb2VzIHRoZSBhbnN3ZXIgdG8g Mi4gZGVwZW5kIG9uIHRoZSB3ZWFrLWhvc3QsIHN0cm9uZy1ob3N0IGRpc3RpbmN0aW9uPzxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3QgdGhpbmsgc28uJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN0cm9uZyBob3N0L3dlYWsgaG9z dCBpcyBhYm91dCBob3cgc3RyaWN0IGEgaG9zdCBpcyBhYm91dCBhY2NlcHRpbmcgaG9zdCBvd25l ZCBhZGRyZXNzZXMgb24gaW50ZXJmYWNlcyB0aGF0IGFyZW4ndCBjb25maWd1cmVkIHdpdGggdGhl c2UgYWRkcmVzc2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5XSC9TSCBkb2VzIGhhdmUgYW4gaW5mbHVlbmNlIHRob3VnaCBpbiB0aGlzIHNj ZW5hcmlvLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JZiB0aGUgaG9zdCBmb2xsb3dzIFNILCB0aGVuIHRoZSBkZWxlZ2F0ZWQgcHJlZml4IGhh cyB0byBiZSBhc3NpZ25lZCB0byB0aGUgaW50ZXJmYWNlIG92ZXIgd2hpY2ggdGhlIGhvc3Qgd2ls bCByZWNlaXZlIHBhY2tldHMsIG90aGVyd2lzZSBpdCB3aWxsIGlnbm9yZSB0aGVtLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IG1lYW5z IHRoZSBob3N0IHdvdWxkIGJ5IGRlZmF1bHQgYWxzbyByZXNwb25kIHRvIE5EIE5TZXMgZm9yIGFu eSBhZGRyZXNzIHdpdGhpbiB0aGUgcHJlZml4IGZyb20gZGV2aWNlcyBhdHRhY2hlZCB0byB0aGF0 IGxpbmsuIEkgdGhpbmsgdGhlcmUncyBhbiBORC9OVUQgRG9TIGF0dGFjayBvcHBvcnR1bml0eSBp biB0aGF0IHNjZW5hcmlvLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGlzIGlzIGFzc3VtaW5nIHRoYXQgb3RoZXIgZGV2aWNlcyBzb21laG93 Jm5ic3A7IGtub3cgdGhhdCB0aGUgZGVsZWdhdGVkIHByZWZpeCBpcyBvbi1saW5rLiBBbiBhdHRh Y2tlciBjb3VsZCBlZmZlY3RpdmVseSBhc3NlcnQgdGhhdCB0aHJvdWdoIHRoZWlyIHRvb2wgcmVn YXJkbGVzcyBvZiB0aGUgbmV0d29yaydzIHZpZXcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldIIHdvdWxkIGJlIGEgc2FmZXIgb3B0aW9uIGJl Y2F1c2UgdGhlIHByZWZpeCBpcyBlZmZlY3RpdmVseSBhc3NpZ25lZCB0byBhbiBpbnRlcm5hbCBp bnRlcmZhY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5NYXJrLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpZb3UgYXJlIHdl bGNvbWUsIG9mIGNvdXJzZSwgdG8gYWxzbyByYWlzZSBhbnkgb3RoZXIgcXVlc3Rpb25zIG9yIGNv bmNlcm5zLjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KdjZvcHMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOnY2b3BzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+djZvcHNAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZv cHM8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_038d0037f32140ee9c2af880fdf8980fXCH150608nwnosboeingcom_-- From nobody Fri May 4 11:19:27 2018 Return-Path: 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 936F6129502 for ; Fri, 4 May 2018 11:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 67L6DjmbBKk6 for ; Fri, 4 May 2018 11:19:21 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (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 31577124217 for ; Fri, 4 May 2018 11:19:21 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id c14-v6so21967691wrd.4 for ; Fri, 04 May 2018 11:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=ffXOlS3DWs22kPjRC/zsPfntxA/ENznXCsUfmHAuDQU=; b=EH8LP+EzC0W0WobL7WoVBdnIcg/ZjaVoIXuHNoFaYRQfeRmxL/X48Erm0aPxF2+CJw LoXfOZue5TJpXv6Zv6qtvhLiSQpjpeqk8f5IrEfkND+2YW9/zAzAeQ7uAWPoS3fs1jXS fHLE+5FhzpG3LPgKRSTWcxqZwpkDzxKLW7GnRK81IY3s8O13nONTMqCwV4J5t/d6PFe4 PqTki7KHlwluvPVCXnhZpAyFSXLAN/fWMdWzNLuj5JOua20y6g6Ix6APow0jqM25bRv3 9lHK/evqoUkkjmrlRGi2ZKOXYSZQV+5IIZl5VLh/canDFItK7n9qxiJmJygNCn/YshZK VNHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ffXOlS3DWs22kPjRC/zsPfntxA/ENznXCsUfmHAuDQU=; b=TYL2bBKs9s2c5MuOxzC6LUjM+RcP4NRgYQEMzXiuDD8lm8a+t+0uL91tsOLLgcF/6D fnqPtNhm7o/uhzYga1M53fAm+c0JHAyskIcNnYk0/hTfAYLX4mnKOeyr46pyKJVB1jA2 TNbyKQY+2u9HCZMujypJDrye3/huSQ4MrFgPqGOGl8KsWLfOX9ytqWGS82AhXuKw9taR Ntcmx7udPNmOEbg9ND0fkYwstfs8R12UaophgcAds0yjAmg92gxhTLwCXd19rEgYokZE m8zVErP4wtToSLdAjJJSC3PmsXNTF6BQrzBLoe1AsS6ksdaNDwibrV4rm9A0OpzOixI0 daSA== X-Gm-Message-State: ALQs6tD0+V79jbgLXjm0A/SaGJzfLhmV5jO49IsYJWwSnKXEbdQmQPlx HTsgqJt7Get+qfRiEpAUEZR2tCsa3UEQKWLTTgK1MBM2THw= X-Google-Smtp-Source: AB8JxZrd7K9thB1V0GFiwQ0RA6RBKmL4E0meiqK8tPdiNBsV0HkG8JvbL34LhEdMCeISH2BXxaxFE2VoDkVPVEh0U3U= X-Received: by 2002:adf:ad61:: with SMTP id p88-v6mr21355126wrc.24.1525457958970; Fri, 04 May 2018 11:19:18 -0700 (PDT) MIME-Version: 1.0 From: Warren Kumari Date: Fri, 04 May 2018 18:18:43 +0000 Message-ID: To: IPv6 Operations , draft-ietf-v6ops-conditional-ras@ietf.org Content-Type: multipart/alternative; boundary="000000000000c3eb50056b655bae" Archived-At: Subject: [v6ops] AD Review of: draft-ietf-v6ops-conditional-ras X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2018 18:19:25 -0000 --000000000000c3eb50056b655bae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, Thank you to the editors and WG for your efforts on this document, it's a well written, useful and easy to understand draft. I do have a few comments that I=E2=80=99d like addressed before I start IETF LC. The majority of these are nits (and 2 substantive comments), but addressing these now will avoid issues later in the process. Please let me know LOUDLY AND EXPLICITLY once you've had a chance to address them and I'll kick off IETF LC. W Section: Abstract This document discusses most common scenarios of connecting an O: discusses most common P: discusses the most common enterprise network to multiple ISPs using an address space assigned by an ISP. The problem of enterprise multihoming without address translation of any form has not been solved yet as it requires both the network to select the correct egress ISP based on the packet source address and hosts to select the correct source address based on the desired egress ISP for that traffic. ... general problem and on covering various complex use cases, this document describes how the solution proposed in [I-D.ietf-rtgwg-enterprise-pa-multihoming] can be adopted for limited O: adopted for limited P: adopted for a limited number of common use cases. In particular, the focus is on scenarios where an enterprise network has two Internet uplinks used either in primary/backup mode or simultaneously and hosts in that network might not yet properly support multihoming as described in [RFC8028]. Section: 1. Introduction Using Provider Independent (PI) address space is not always an option as it requires running BGP between the enterprise network and the ISPs, not mentioning administrative overhead of obtaining and managing PI address space. As IPv6 host can, by O: Using Provider Independent (PI) address space is not always an option as it requires running BGP between the enterprise network and the ISPs, not mentioning administrative overhead of obtaining and managing PI address space. As IPv6 host can, by P: Using Provider Independent (PI) address space is not always an option, since it requires running BGP between the enterprise network and the ISPs. Administrative overhead of obtaining and managing PI address space can also be a concern. As IPv6 hosts can, by R: Readability design, have multiple addresses of the global scope, multihoming using provider address looks even easier for IPv6: each ISP assigns an IPv6 block (usually /48) and hosts in the enterprise network have addresses assigned from each ISP block. However using IPv6 PA blocks in multihoming scenario introduces some challenges, including but not limited to: ... The document [I-D.ietf-rtgwg-enterprise-pa-multihoming] discusses these and other related challenges in details in relation to the O: in details P: in detail general multihoming scenario for enterprise networks. Unfortunately the proposed solution heavily relies on the rule 5.5 of the default O: heavily relies P: relies heavily O: on the rule 5.5 [... P: maybe reference the rule more specifically, provide more detail, etc. This is an introductory section, it it unlikely that people will remember what rule 5.5 says. address selection algorithm ([RFC6724]) which has not been widely implemented at the moment this document was written. Therefore O: at the moment P: when network administrators in enterprise networks can't yet assume that all devices in their network support the rule 5.5, especially in the quite common BYOD ("Bring Your Own Device") scenario. However, while it does not seem feasible to solve all the possible multihoming scenarios without reliying on rule 5.5, it is possible to provide O: reliying P: relying IPv6 multihoming using provider-assigned (PA) address space for the most common use cases. This document discusses how the general solution described in [I-D.ietf-rtgwg-enterprise-pa-multihoming] can be applied to scenarios when: o An enterprise network has two or more ISP uplinks; o Those uplinks are used for Internet access in active/backup or load sharing mode w/o any soficticated traffic engineering O: soficticated P: sophisticated requirements; Section: 2.2. Two ISP Uplinks, Used for Load Balancing This scenario has the following key characteristics: o The enterprise network is using uplinks to two (or more) ISPs for Internet access; o Each ISP assigns an IPv6 PA address space; o All the uplinks may be used simultaneously, with the traffic flows being randomly (not nessesary equally) distributed between them; O: nessesary P: necessarily o Hosts in the enterprise network are not expected to support the Rule 5.5 of the default address selection algorithm ([RFC6724]). ... Section: 3.1.1. Uplink Selection While some work is being done in the Source Address Dependent Routing (SADR) area, the simplest way to implement the desired functionality currently is to apply a policy which selects a next-hop or an egress interface based on the packet source address. Most of the SMB/ O: Most of the P: Most Enterprise grade routers have such functionality available currently. 3.1.2. Source Address Selection and Conditional RAs Sending a router advertisement to change the preferred lifetime for a given prefix provides the following functionality: o deprecating addresses (by sending an RA with the preferred_lifetime set to 0 in the corresponding POI) to indicate O: POI R: POI? or PIO? -- also, need a POI reference. to hosts that that addresses from that prefix should not be used; ... The trigger is not only forcing the router to send an unsolicited RA to propagate the topology changes to all hosts. Obviously the RA fields values (like PIO Preferred Lifetime or DNS Server Lifetime) changed by the particular trigger MUST stay the same until another event happens causing the value to be updated. E.g. if the ISP_A uplink failure causes the prefix to be deprecated all solicited and O: to be deprecated all P: to be deprecated, all unsolicited RAs sent by the router MUST have the Preferred Lifetime for that POI set to 0 until the uplink comes back up. It should be noted that the proposed solution is quite similar to the existing requirement L-13 for IPv6 CPE routers ([RFC7084]) and the documented behaviour of homenet devices. It is using the same O: behaviour P: behavior mechanism of deprecating a prefix when the corresponding uplink is not operational, applying it to enterprise network scenario. Section: 3.2.1. Single Router, Primary/Backup Uplinks To ensure that packets with source addresses from ISP_A and ISP_B are only routed to ISP_A and ISP_B uplinks respectively, the network administrator needs to configure a policy on R1: if { packet_destination_address is not in 2001:db8:1::/48 or 2001:db8:2::/4= 8 packet_source_address is in 2001:db8:1::/48 } then { default next-hop is ISP_A_uplink } if { packet_destination_address is not in 2001:db8:1::/48 or 2001:db8:2::/4= 8 packet_source_address is in 2001:db8:2::/48 } then { default next-hop is ISP_B_uplink } C: Pseudocode is always tricky; it is hard to get the level of abstraction right. I think that this needs a bit more work / words / parenthesis... Is this: A: packet_destination_address is not in 2001:db8:1::/48 AND IS NOT IN 2001:db8:2::/48 or B: packet_destination_address is not in 2001:db8:1::/48 OR IS IN 2001:db8:2::/48 ? (The first is implied, but not really explicit) Also, is the "packet_source_address is in 2001:db8:1::/48" AND or OR with the first condition? I think: (packet_destination_address is not in (2001:db8:1::/48 or 2001:db8:2::/48)) and (packet_source_address is in 2001:db8:1::/48) is clearer, but not sure (same for other pseudocode too) .... ... 3.2.5. Topologies with Dedicated Border Routers For simplicity reasons all topologies below show the ISP uplinks O: For simplicity reasons P: For simplicity, terminated on the first-hop routers. Obviously, the proposed approach can be used in more complex topologies when dedicated devices are used for terminating ISP uplinks. In that case VRRP mastership or inteface status can not be used as a trigger for O: inteface P: interface conditional RAs and route presence as described above should be used instead. ... R1 and R2 policy: prefix 2001:db8:1:1::/64 { if ISP_A_uplink_route is present then preferred_lifetime =3D 604800 else preferred_lifetime =3D 0 } prefix 2001:db8:2:1::/64 { if ISP_A_uplink_route is present then preferred_lifetime =3D 0 else preferred_lifetime =3D 604800 } For load-balancing case the policy would look slightly different: O: For load-balancing case P: For the load balancing case ? each prefix has non-zero preferred_lifetime only if the correspoding ISP uplink route is present: Section: 3.2.6. Intra-Site Communication during Simultaneous Uplinks Outage Prefix deprecation as a result of an uplink status change might lead to a situation when all global prefixes are deprecated (all ISP uplinks are not operational for some reason). Even when there is no Internet connectivity it might be still desirable to have intra-site IPv6 connectivity (especially when the network in question is an IPv6-only one). However while an address is in a deprecated state, its use is discouraged, but not strictly forbidden ([RFC4862]). In such scenario all IPv6 source addresses in the candidate set O: such scenario P: such a scenario, ([RFC6724]) are deprecated which means that they still can be used O: deprecated which means P: deprecated, which means (as there is no preferred addresses available) and the source address selection algorith can pick up one of them, allowing the intra-site communication. However some OSes might just fall back to IPv4 if the network interface has no preferred IPv6 global addresses. Therefore if intra-site connectivity is vital during simultanious outages of multiple uplinks, administrators might consider using ULAs or provisioning additional backup uplinks to protect the network from double-failure cases. 3.2.7. Uplink Damping If an actively used uplink (primary one or one used in load balaning scenario) starts flapping, it might lead to undesirable situation of O: to undesirable situation P: to the undesirable situation flapping addresses on hosts (every time the uplink goes up hosts receive an RA with non-zerop preferred PIO lifetime, and every time O: non-zerop P: non-zero the uplink goes down all address in the affected prefix become O: all address P: all addresses deprecated). Undoubtedly it would negatively impact user experience, not mentioning spikes of DAD traffic every time an uplink comes back O: Undoubtedly it would negatively impact user experience, not mentioning spikes P: This would, undoubtedly, negatively impact the user experience, not to mention the impact of spikes up. Therefore it's recommended that router vendors implement some form of damping policy for conditional RAs and either postpone sending an RA with non-zero lifetime for a POI when the uplink comes up for a number of seconds or even introduce accumulated penalties/ exponential backoff algorithm for such delays. (In the case of multiple simultaneous uplink failure scenario, when all but one uplinks are down and the last remaining is flapping it might result in all addresses being deprecated for a while after the flapping uplink recovers.) O: (In the case of multiple simultaneous uplink failure scenario, when all but one uplinks are down and the last remaining is flapping it might result in all addresses being deprecated for a while after the flapping uplink recovers.) P: (In the case of a multiple simultaneous uplink failure scenario, when all but one uplink is down and the last remaining one is flapping, this might result in all addresses being deprecated for a while after the flapping uplink recovers.) 3.3. Solution Limitations It should be noted that the proposed approach is not a silver bullet for all possible multihoming scenarios. The main goal is to solve some common use cases so it would suit very well relatively simple topologies with straightforward policies. The more complex the O: so it would suit very well relatively simple topologies with straightforward policies. P: -- I don't know, but I am having trouble parsing the above. network topology and the corresponding routing policies more O: policies more P: policies, the more configuration would be required to implement the solution. Another limitation is related to the load balancing between the uplinks. In that scenario when both uplinks are active hosts would O: In that scenario when both uplinks are active hosts P: In the scenario in which both uplinks are active, hosts select the source prefix using the Default Address Selection algorithm ([RFC6724]) and therefore the load between two uplinks most O: algorithm ([RFC6724]) and therefore the load P: algorithm ([RFC6724]), and therefore the load likely would not be evenly distributed. (However the proposed O: However P: However, mechanism does allow a creative way of controlling uplinks load in SDN networks where controllers might selectively deprecate prefixes on some hosts but not others to move egress traffic between uplinks). Also the prefix selection does not take into account any other uplinks properties (such as RTT etc) so egress traffic might not be O: (such as RTT etc) so P: (such as RTT etc), so sent to the nearest uplink if the corresponding prefix is selected as a source. In general if not all uplinks are equal and some uplinks are expected to be preferred over others then the network O: In general if not all uplinks are equal and some uplinks are expected to be preferred over others then P: In general, if not all uplinks are equal and some uplinks are expected to be preferred over others, then adminitrator should ensure that prefixes from non-preferred ISP(s) O: adminitrator P: administrator are kept deprecated (so primary/backup setup is used). 3.3.1. Connections Preservation The proposed solution is not designed to preserve connections state O: connections P: connection after an uplink failure. If all uplinks to an ISP go down all O: If all uplinks to an ISP go down P: If all uplinks to an ISP go down, sessions to/from addresses from that ISP address space are interrupted as there is no egress path for those packets and there is not return path from Internet to the correspodning prefix. In this O: not return path from Internet to the correspodning prefix. P: no return path from the Internet to the corresponding prefix. regard it is similar to IPv4 multihoming using NAT, where an uplink failure and failover to another uplink means that a public IPv4 address changes and all existing connections are interrupted. An uplink recovery, however, does not nessesary leads to connections O: nessesary leads P: necessarily lead interruption. In the load sharing/balancing scenario an uplink recovery does not affect any existing connections at all. In the active/backup topology when the primary uplink recovers from the failure and the backup prefix is deprectaed, the existing sessions O: deprectaed P: deprecated (established to/from the backup ISP addresses) can be preserved if the routers are configured as described in Section 3.2.1 and send packets with the backup ISP source addresses to the backup uplink even when the primary one is operational. As a result, the primary uplink recovery makes the usage of the backup ISP addresses discouraged but still possible. --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --000000000000c3eb50056b655bae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
Hello,

Thank you =
to the editors and WG for your efforts on
this document, it's a well written, useful=C2=A0 and easy to u=
nderstand
draft.=C2=A0 I do have =
a few comments that I=E2=80=99d like addressed=C2=A0
before I start IETF LC.=C2=A0

The majorit=
y of these are nits (and 2 substantive comments), but addressing these now =
will avoid
issues later in the pr=
ocess.

Please let me know LOUDLY AND EXPLICITLY once you'=
ve had a chance to address them and I'll kick off IETF LC.=C2=A0=


W


  Section: Abstract
   This document discusses most common scenarios of connecting an
O: discusses most common
P: discusses=
 the most common

   enterprise network to multiple ISPs using an address space assigned
   by an ISP.  The problem of enterprise multihoming without address
   translation of any form has not been solved yet as it requires both
   the network to select the correct egress ISP based on the packet
   source address and hosts to select the correct source address based
   on the desired egress ISP for that traffic.
...
   general problem and on covering various complex use cases, this
   document describes how the solution proposed in
   [I-D.ietf-rtgwg-enterprise-pa-multihoming] can be adopted for limited
O: adopted for limited
P: adopted for a limited
   number of common use cases.  In particular, the =
focus is on scenarios
   where an enterprise network has two Internet uplinks used either in
   primary/backup mode or simultaneously and hosts in that network might
   not yet properly support multihoming as described in [RFC8028].

Section: 1.  Introduction
   Using Provider Independent (PI) address space is =
not
   always an option as it requires running BGP between the enterprise
   network and the ISPs, not mentioning administrative overhead of
   obtaining and managing PI address space.  As IPv6 host can, by
O: 
 Using Provider Independent (PI) address =
space is not
   always an option as it requires running BGP between the enterprise
   network and the ISPs, not mentioning administrative overhead of
   obtaining and managing PI address space.  As IPv6 host can, by

P: 
 Using Provider Independent (PI) address space is not
   always an option, since it requires running BGP between the enterprise
   network and the ISPs. Administrative overhead of
   obtaining and managing PI address space can also be a concern.  As IPv6 =
hosts can, by
R: Readability

   design, have multiple addresses of the global scope, multihoming
   using provider address looks even easier for IPv6: each ISP assigns
   an IPv6 block (usually /48) and hosts in the enterprise network have
   addresses assigned from each ISP block.  However using IPv6 PA blocks
   in multihoming scenario introduces some challenges, including but not
   limited to:

...
   The document [I-D.ietf-rtgwg-enterprise-pa-=
multihoming] discusses
   these and other related challenges in details in relation to the
O: in details

P: in detail

   general multihoming scenario for enterprise networks.  Unfortunately
   the proposed solution heavily relies on the rule 5.5 of the default
O: heavily relies
P: relies heavily
O: on the rule 5.5 [...
P: maybe reference the rule more specifically, provide more detail, etc. Th=
is is an introductory section, it it unlikely that people will remember wha=
t rule 5.5 says. 

   address selection algorithm ([RFC6724]) which has not been widely
   implemented at the moment this document was written.  Therefore
O: at the moment
P: when

   network administrators in enterprise networks can't yet assume that
   all devices in their network support the rule 5.5, especially in the
   quite common BYOD ("Bring Your Own Device") scenario.  However=
, while
   it does not seem feasible to solve all the possible multihoming
   scenarios without reliying on rule 5.5, it is possible to provide
<= pre style=3D"font-family:verdana,sans-serif;white-space:pre-wrap;font-size:= 13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:norm= al;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;t= ext-transform:none;word-spacing:0px;background-color:rgb(255,255,255);text-= decoration-style:initial;text-decoration-color:initial;color:rgb(0,0,0);wor= d-wrap:break-word">O: reliying P: relying
IPv6 multihoming using provider-assigned (PA) address space for the most common use cases. This document discusses how the general solution described in [I-D.ietf-rtgwg-enterprise-pa-multihoming] can be applied to scenarios when: o An enterprise network has two or more ISP uplinks; o Those uplinks are used for Internet access in active/backup or load sharing mode w/o any soficticated traffic engineering
O: soficticated
P: sophisticated
      requirements;


Section:  2.2. =
 Two ISP Uplinks, Used for Load Balancing

   This scenario has the following key characteristics:

   o  The enterprise network is using uplinks to two (or more) ISPs for
      Internet access;

   o  Each ISP assigns an IPv6 PA address space;

   o  All the uplinks may be used simultaneously, with the traffic flows
      being randomly (not nessesary equally) distributed between them;
O: nessesary
P: necessarily


   o  Hosts in the enterprise network are not expected to support the
      Rule 5.5 of the default address selection algorithm ([RFC6724]).


...

Section:  3.1.1.  Uplink Selection

   While some work is being done in the Source Address Dependent Routing
   (SADR) area, the simplest way to implement the desired functionality
   currently is to apply a policy which selects a next-hop or an egress
   interface based on the packet source address.  Most of the SMB/
O: Most of the
P: Most

   Enterprise grade routers have such functionality available currently.

3.1.2.  Source Address Selection and Conditional RAs

   Sending a
   router advertisement to change the preferred lifetime for a given
   prefix provides the following functionality:


   o  deprecating addresses (by sending an RA with the
      preferred_lifetime set to 0 in the corresponding POI) to indicate
O: POI
R: POI? or PIO? -- al=
so, need a POI reference.
      to hosts that that=
 addresses from that prefix should not be used;

...
 =20
   The trigger is not only forcing the router to send an unsolicited RA
   to propagate the topology changes to all hosts.  Obviously the RA
   fields values (like PIO Preferred Lifetime or DNS Server Lifetime)
   changed by the particular trigger MUST stay the same until another
   event happens causing the value to be updated.  E.g. if the ISP_A
   uplink failure causes the prefix to be deprecated all solicited and
O: to be deprecated all
P: to be deprecated, all
   unsolicited RAs sent b=
y the router MUST have the Preferred Lifetime
   for that POI set to 0 until the uplink comes back up.

   It should be noted that the proposed solution is quite similar to the
   existing requirement L-13 for IPv6 CPE routers ([RFC7084]) and the
   documented behaviour of homenet devices.  It is using the same

O: behaviour
P: behavior

   mecha=
nism of deprecating a prefix when the corresponding uplink is
   not operational, applying it to enterprise network scenario.


Section:  3.2.1.  Single Router, Primary/Back=
up Uplinks


   =20
   =20
   To ensure that packets with source addresses from ISP_A and ISP_B are
   only routed to ISP_A and ISP_B uplinks respectively, the network
   administrator needs to configure a policy on R1:


if {
     packet_destination_address is not in 2001:db8:1::/48 or 2001:db8:2::/4=
8
     packet_source_address is in 2001:db8:1::/48
} then {
       default next-hop is ISP_A_uplink
}
if {
     packet_destination_address is not in 2001:db8:1::/48 or 2001:db8:2::/4=
8
     packet_source_address is in 2001:db8:2::/48
}
then {
       default next-hop is ISP_B_uplink
}

C: Pseudocode is always tricky; it is hard to=
 get the level of abstraction right. I think that this needs a bit more wor=
k / words / parenthesis...
Is this:
A: packet_destination_address is not in 2001:db8:1::/48 AND IS NOT IN 2001:=
db8:2::/48
or
B: packet_destination=
_address is not in 2001:db8:1::/48 OR IS IN 2001:db8:2::/48 ? (The first is=
 implied, but not really explicit)

Also, is the "packet_source_address is in =
2001:db8:1::/48" AND or OR with the first condition?

I think:=20
(packet_destination_address is not in (2001:db8:1::/48 or 2001:db8:2::/48))=
 and (packet_source_address is in 2001:db8:1::/48)
is clearer, but not sure (same for other pseudocode too) ....
... 
3.2.5.  Topologies with Dedicated Border Routers

   For simplicity reasons all topologies below show the ISP uplinks
O: For simplicity reasons
P: For simplicity, terminated on the first-hop routers. Obviously, the pro= posed approach can be used in more complex topologies when dedicated devices are used for terminating ISP uplinks. In that case VRRP mastership or inteface status can not be used as a trigger forO: inteface P: interface
   conditional RAs and route presence=
 as described above should be used
   instead.

 ...

   R1 and R2 policy:

   prefix 2001:db8:1:1::/64 {
     if ISP_A_uplink_route is present then preferred_lifetime =3D 604800
     else preferred_lifetime =3D 0
     }
   prefix 2001:db8:2:1::/64 {
     if ISP_A_uplink_route is present then preferred_lifetime =3D 0
       else preferred_lifetime =3D 604800
    }

   For load-balancing case the policy would look slightly different:
<= pre style=3D"font-family:verdana,sans-serif;white-space:pre-wrap;font-size:= 13px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:norm= al;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;t= ext-transform:none;word-spacing:0px;background-color:rgb(255,255,255);text-= decoration-style:initial;text-decoration-color:initial;color:rgb(0,0,0);wor= d-wrap:break-word">
O: For load-balancing case
P: For the load balancing case ?
each prefix has non-zero preferred_lifetime only if the correspoding ISP uplink route is present: Section: 3.2.6. Intra-Site Communication during Simultaneous Uplinks Outag= e Prefix deprecation as a result of an uplink status change might lead to a situation when all global prefixes are deprecated (all ISP uplinks are not operational for some reason). Even when there is no Internet connectivity it might be still desirable to have intra-site IPv6 connectivity (especially when the network in question is an IPv6-only one). However while an address is in a deprecated state, its use is discouraged, but not strictly forbidden ([RFC4862]). In such scenario all IPv6 source addresses in the candidate set
O: such scenario
P: such a scenario,

   ([RFC6724]) are deprecated which means that they still can be used
= 
O: deprecated which means=20
P: deprecated, which means

   (as there is no preferred addresses available) and the source address
   selection algorith can pick up one of them, allowing the intra-site
   communication.  However some OSes might just fall back to IPv4 if the
   network interface has no preferred IPv6 global addresses.  Therefore
   if intra-site connectivity is vital during simultanious outages of
   multiple uplinks, administrators might consider using ULAs or
   provisioning additional backup uplinks to protect the network from
   double-failure cases.

3.2.7.  Uplink Damping

   If an actively used uplink (primary one or one used in load balaning
   scenario) starts flapping, it might lead to undesirable situation of
O: to undesirable situation
P: to the undesirable situation

   flapping addresses on hosts (every time the uplink goes up hosts
   receive an RA with non-zerop preferred PIO lifetime, and every time
O: non-zerop
P: non-zero
   the uplink goes down all address in=
 the affected prefix become
O: all =
address
P: all addresses
   deprecated).  Undoubtedly it would negatively impa=
ct user experience,
   not mentioning spikes of DAD traffic every time an uplink comes back
O: Undoubtedly it would negatively impact user experi=
ence,
   not mentioning spikes
P: This would, undoubtedl=
y, negatively impact the user experience, not to mention the impact of spik=
es

   up.  Therefore it's recommended that router vendors implement some
   form of damping policy for conditional RAs and either postpone
   sending an RA with non-zero lifetime for a POI when the uplink comes
   up for a number of seconds or even introduce accumulated penalties/
   exponential backoff algorithm for such delays.  (In the case of
   multiple simultaneous uplink failure scenario, when all but one
   uplinks are down and the last remaining is flapping it might result
   in all addresses being deprecated for a while after the flapping
   uplink recovers.)

O: (In the case of
   multiple simultaneous uplink failure sc=
enario, when all but one
   uplinks are down and the last remaining is flapping it might result
   in all addresses being deprecated for a while after the flapping
   uplink recovers.)
P: (In the case of a
   multiple si=
multaneous uplink failure scenario, when all but one
   uplink is down and the last remaining one is flapping, this might result
   in all addresses being deprecated for a while after the flapping
   uplink recovers.)

3.3.  Solution Limitatio=
ns

   It should be noted that the proposed approach is not a silver bullet
   for all possible multihoming scenarios.  The main goal is to solve
   some common use cases so it would suit very well relatively simple
   topologies with straightforward policies.  The more complex the
O: 
so it would suit very well relatively si=
mple
   topologies with straightforward policies.
P: -- I don't know, b=
ut I am having trouble parsing the above.
   netwo=
rk topology and the corresponding routing policies more
O: policies more
P: policies, the more

   configuration would be required to implement the solution.

   Another limitation is related to the load balancing between the
   uplinks.  In that scenario when both uplinks are active hosts would
O: In that scenario when both uplinks a=
re active hosts
P: In the scenario in which both uplinks are active, hosts

   select the source prefix using the Default Address Selection
   algorithm ([RFC6724]) and therefore the load between two uplinks most
O: algorithm ([RFC6724]) and therefor=
e the load
P: algorithm ([RFC6724]), and therefore the load

   likely would not be evenly distributed.  (However the proposed
O: However
P: However,
   mechanism does allow a creative way=
 of controlling uplinks load in
   SDN networks where controllers might selectively deprecate prefixes
   on some hosts but not others to move egress traffic between uplinks).
   Also the prefix selection does not take into account any other
   uplinks properties (such as RTT etc) so egress traffic might not be
O: (such as RTT etc) so
P: (such as RTT etc), so


   sent to the nearest uplink if the corresponding prefix is selected as
   a source.  In general if not all uplinks are equal and some uplinks
   are expected to be preferred over others then the network
O: In general if not all uplinks are equal and some uplinks
   are expected to be preferred over others then

P: In general, if not all uplinks are equal and some uplinks
   are expected to be preferred over others, then

   adminitrator should ensure that prefixes from non-preferred ISP(s)
=

O: adminitrator
P: administrator
   are kept deprecated (so primary/backup setup is used).

3.3.1.  Connections Preservation

   The proposed solution is not designed to preserve connections state
O: connections
P: connection
   after an uplink failure.  If all uplinks to an ISP go down all
O: If all uplinks to an ISP go down
P: If all uplinks to=
 an ISP go down,

   sessions to/from addresses from that ISP address space are
   interrupted as there is no egress path for those packets and there is
   not return path from Internet to the correspodning prefix.  In this
O: not return path from Internet to the=
 correspodning prefix.
P: no return path from the Internet to the corresponding prefix.

   regard it is similar to IPv4 multihoming using NAT, where an uplink
   failure and failover to another uplink means that a public IPv4
   address changes and all existing connections are interrupted.

   An uplink recovery, however, does not nessesary leads to connections
O: nessesary leads
P: necessarily lead

   interruption.  In the load sharing/balancing scenario an uplink
   recovery does not affect any existing connections at all.  In the
   active/backup topology when the primary uplink recovers from the
   failure and the backup prefix is deprectaed, the existing sessions
=

O: deprectaed
P: deprecated
   (established to/from the backup ISP addresses) can be preserved if
   the routers are configured as described in Section 3.2.1 and send
   packets with the backup ISP source addresses to the backup uplink
   even when the primary one is operational.  As a result, the primary
   uplink recovery makes the usage of the backup ISP addresses
   discouraged but still possible.

--
I don't think the execution is relevant when it was obviously a bad i= dea in the first place.
This is like putting rabid weasels in your pants= , and later expressing regret at having chosen those particular rabid wease= ls and that pair of pants.
=C2=A0 =C2=A0---maf
--000000000000c3eb50056b655bae-- From nobody Fri May 4 20:54:49 2018 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F15612DA53; Fri, 4 May 2018 20:54:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.79.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152549248336.20692.6153508366290631061@ietfa.amsl.com> Date: Fri, 04 May 2018 20:54:43 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2018 03:54:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : Using Conditional Router Advertisements for Enterprise Multihoming Authors : Jen Linkova Massimiliano Stucchi Filename : draft-ietf-v6ops-conditional-ras-04.txt Pages : 19 Date : 2018-05-04 Abstract: This document discusses the most common scenarios of connecting an enterprise network to multiple ISPs using an address space assigned by an ISP. The problem of enterprise multihoming without address translation of any form has not been solved yet as it requires both the network to select the correct egress ISP based on the packet source address and hosts to select the correct source address based on the desired egress ISP for that traffic. The "ietf-rtgwg- enterprise-pa-multihoming" document proposes a solution to this problem by introducing a new routing functionality (Source Address Dependent Routing) to solve the uplink selection issue and using Router Advertisements to influence the host source address selection. While the above-mentioned document focuses on solving the general problem and on covering various complex use cases, this document describes how the solution proposed in the "ietf-rtgwg-enterprise-pa- multihoming" draft can be adopted for a limited number of common use cases. In particular, the focus is on scenarios where an enterprise network has two Internet uplinks used either in primary/backup mode or simultaneously and hosts in that network might not yet properly support multihoming as described in RFC8028. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-conditional-ras/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-04 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-conditional-ras-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-conditional-ras-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 4 21:01:40 2018 Return-Path: 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 78D6512DA6F; Fri, 4 May 2018 21:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 2MN-KfdHvlO6; Fri, 4 May 2018 21:01:35 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 1D79812DA50; Fri, 4 May 2018 21:01:35 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id w8-v6so33598083lfe.3; Fri, 04 May 2018 21:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=HVuSjX/8agKOORsGC2efLEzRe9qZaxBjaNMQgINJX2g=; b=QaPBs9QMbA1ECOis9fQUeUW3hO6/AQkjvBOUYfwR4VKebi2lHt61ydQUbxSnFitDcK hTc5cnGgi8mW9tL53RRwFVqT8d+hOODp/LMNbYPvyEThvURsOJtqXWtoKOU0W2EJk0Gm YYP/taznClQY3t36Q7vKFXN+JP/gi3NDI4BUsR2Y5Vc4tH2W2uH5zrWCPCnvdY0zvEqJ PfYLYnkwJQx0h0Cejr4OJkZYttW7Ve1at6+1iFc+cKHj3FKrXTFR49McqRPIimzmpmxX pqSptpWFm7ngTzGBrjZZdbJPdQ52pl/sUuxcMhUdCBpVRX5rPXSy0VsRr05NVhR4Wnh3 jeUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=HVuSjX/8agKOORsGC2efLEzRe9qZaxBjaNMQgINJX2g=; b=bqgYY1jbCulDQsaRqv7MmUuqnvEZRZjh2WKlWWsP2SKVTQYnATxmp456gD2ooAyDgA zlX95RXvUaznobDJF/9r+5br2/0yZ3sSV6WBvs4X86y/pXN0a7sn+Uq37IyY0CxJyvFv bLmJP+zeNzv72aImxTEdHc1KMZi+Rjr2GM1VZsM+K1X5IrZ8cyHwOxEILT2VDoIEmkL1 zrAlf/gvuPFUXni3b8uaHhAqS7v+iE9k4kRAx7nvfAnyjZkzlgKq54bdaKxTpbxjJ2oS 9RGKbGqqlLPtjInwv/j0F1Czj9uKPrO6W8r5rDQNpi70pU9VRchVnXtpw97NXPabsnXd ugrA== X-Gm-Message-State: ALQs6tByVD+TaJDI5I7MXu+mTV9EyMZcWG5IjIbR1r++ltKjE0wQspGj Wtihu/fCRV8Fo60eH68/rG/1tJJO0glsxxI94ofNXlTz X-Google-Smtp-Source: AB8JxZrGd1Xmj84aZIB/yXU8uOTHxFlrkXdkqVDrRo1K/RzXjTzXUcNDj/Kc5fMfm0/RPvGstwEbmcTy+S7BI9EeqVM= X-Received: by 2002:a2e:8246:: with SMTP id j6-v6mr11225811ljh.72.1525492892926; Fri, 04 May 2018 21:01:32 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:5c04:0:0:0:0:0 with HTTP; Fri, 4 May 2018 21:01:12 -0700 (PDT) In-Reply-To: References: From: Jen Linkova Date: Sat, 5 May 2018 14:01:12 +1000 Message-ID: To: Warren Kumari Cc: IPv6 Operations , draft-ietf-v6ops-conditional-ras@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] AD Review of: draft-ietf-v6ops-conditional-ras X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2018 04:01:38 -0000 Thanks a lot for your review, Warren! (Especially for fixing the punctuation! ;) I've integrated the proposed changes and modified the pseudo-code, hopefully it's a bit more readable now. Please let me know if you still have concerns or suggestions on how it improve it further. Also I've fixed a few nits reported by the id-nit tool: - removed references from the abstract and replaced them with a plain text; - removed 'MUST' from the text. The -04 version: https://datatracker.ietf.org/doc/draft-ietf-v6ops-conditional-ras/ https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-conditional-ras-04 Thanks! On Sat, May 5, 2018 at 4:18 AM, Warren Kumari wrote: > Hello, > > Thank you to the editors and WG for your efforts on > this document, it's a well written, useful and easy to understand > draft. I do have a few comments that I=E2=80=99d like addressed > before I start IETF LC. > > The majority of these are nits (and 2 substantive comments), but addressi= ng > these now will avoid > issues later in the process. > > Please let me know LOUDLY AND EXPLICITLY once you've had a chance to addr= ess > them and I'll kick off IETF LC. > > W > > > Section: Abstract > > This document discusses most common scenarios of connecting an > > O: discusses most common > P: discusses the most common > > enterprise network to multiple ISPs using an address space assigned > by an ISP. The problem of enterprise multihoming without address > translation of any form has not been solved yet as it requires both > the network to select the correct egress ISP based on the packet > source address and hosts to select the correct source address based > on the desired egress ISP for that traffic. > .... > general problem and on covering various complex use cases, this > document describes how the solution proposed in > [I-D.ietf-rtgwg-enterprise-pa-multihoming] can be adopted for limited > > O: adopted for limited > P: adopted for a limited > > number of common use cases. In particular, the focus is on scenarios > where an enterprise network has two Internet uplinks used either in > primary/backup mode or simultaneously and hosts in that network might > not yet properly support multihoming as described in [RFC8028]. > > > Section: 1. Introduction > > Using Provider Independent (PI) address space is not > always an option as it requires running BGP between the enterprise > network and the ISPs, not mentioning administrative overhead of > obtaining and managing PI address space. As IPv6 host can, by > > O: > > Using Provider Independent (PI) address space is not > always an option as it requires running BGP between the enterprise > network and the ISPs, not mentioning administrative overhead of > obtaining and managing PI address space. As IPv6 host can, by > > P: > > Using Provider Independent (PI) address space is not > always an option, since it requires running BGP between the enterprise > network and the ISPs. Administrative overhead of > obtaining and managing PI address space can also be a concern. As IPv= 6 > hosts can, by > > R: Readability > > design, have multiple addresses of the global scope, multihoming > using provider address looks even easier for IPv6: each ISP assigns > an IPv6 block (usually /48) and hosts in the enterprise network have > addresses assigned from each ISP block. However using IPv6 PA blocks > in multihoming scenario introduces some challenges, including but not > limited to: > > .... > > The document [I-D.ietf-rtgwg-enterprise-pa-multihoming] discusses > these and other related challenges in details in relation to the > > O: in details > > P: in detail > > general multihoming scenario for enterprise networks. Unfortunately > the proposed solution heavily relies on the rule 5.5 of the default > > O: heavily relies > P: relies heavily > > O: on the rule 5.5 [... > P: maybe reference the rule more specifically, provide more detail, etc. > This is an introductory section, it it unlikely that people will remember > what rule 5.5 says. > > address selection algorithm ([RFC6724]) which has not been widely > implemented at the moment this document was written. Therefore > > O: at the moment > P: when > > network administrators in enterprise networks can't yet assume that > all devices in their network support the rule 5.5, especially in the > quite common BYOD ("Bring Your Own Device") scenario. However, while > it does not seem feasible to solve all the possible multihoming > scenarios without reliying on rule 5.5, it is possible to provide > > O: reliying > P: relying > > IPv6 multihoming using provider-assigned (PA) address space for the > most common use cases. This document discusses how the general > solution described in [I-D.ietf-rtgwg-enterprise-pa-multihoming] can > be applied to scenarios when: > > o An enterprise network has two or more ISP uplinks; > > o Those uplinks are used for Internet access in active/backup or > load sharing mode w/o any soficticated traffic engineering > > O: soficticated > P: sophisticated > > requirements; > > > Section: 2.2. Two ISP Uplinks, Used for Load Balancing > > This scenario has the following key characteristics: > > o The enterprise network is using uplinks to two (or more) ISPs for > Internet access; > > o Each ISP assigns an IPv6 PA address space; > > o All the uplinks may be used simultaneously, with the traffic flows > being randomly (not nessesary equally) distributed between them; > > O: nessesary > P: necessarily > > > o Hosts in the enterprise network are not expected to support the > Rule 5.5 of the default address selection algorithm ([RFC6724]). > > > .... > > Section: 3.1.1. Uplink Selection > > While some work is being done in the Source Address Dependent Routing > (SADR) area, the simplest way to implement the desired functionality > currently is to apply a policy which selects a next-hop or an egress > interface based on the packet source address. Most of the SMB/ > > O: Most of the > P: Most > > Enterprise grade routers have such functionality available currently. > > 3.1.2. Source Address Selection and Conditional RAs > > Sending a > router advertisement to change the preferred lifetime for a given > prefix provides the following functionality: > > > o deprecating addresses (by sending an RA with the > preferred_lifetime set to 0 in the corresponding POI) to indicate > > O: POI > > R: POI? or PIO? -- also, need a POI reference. > > to hosts that that addresses from that prefix should not be used; > > .... > > The trigger is not only forcing the router to send an unsolicited RA > to propagate the topology changes to all hosts. Obviously the RA > fields values (like PIO Preferred Lifetime or DNS Server Lifetime) > changed by the particular trigger MUST stay the same until another > event happens causing the value to be updated. E.g. if the ISP_A > uplink failure causes the prefix to be deprecated all solicited and > > O: to be deprecated all > P: to be deprecated, all > > unsolicited RAs sent by the router MUST have the Preferred Lifetime > for that POI set to 0 until the uplink comes back up. > > It should be noted that the proposed solution is quite similar to the > existing requirement L-13 for IPv6 CPE routers ([RFC7084]) and the > documented behaviour of homenet devices. It is using the same > > > O: behaviour > P: behavior > > > mechanism of deprecating a prefix when the corresponding uplink is > not operational, applying it to enterprise network scenario. > > > Section: 3.2.1. Single Router, Primary/Backup Uplinks > > > > > To ensure that packets with source addresses from ISP_A and ISP_B are > only routed to ISP_A and ISP_B uplinks respectively, the network > administrator needs to configure a policy on R1: > > > if { > packet_destination_address is not in 2001:db8:1::/48 or 2001:db8:2::= /48 > packet_source_address is in 2001:db8:1::/48 > } then { > default next-hop is ISP_A_uplink > } > if { > packet_destination_address is not in 2001:db8:1::/48 or 2001:db8:2::= /48 > packet_source_address is in 2001:db8:2::/48 > } > then { > default next-hop is ISP_B_uplink > } > > C: Pseudocode is always tricky; it is hard to get the level of abstractio= n > right. I think that this needs a bit more work / words / parenthesis... > > Is this: > A: packet_destination_address is not in 2001:db8:1::/48 AND IS NOT IN > 2001:db8:2::/48 > > or > > B: packet_destination_address is not in 2001:db8:1::/48 OR IS IN > 2001:db8:2::/48 ? (The first is implied, but not really explicit) > > > Also, is the "packet_source_address is in 2001:db8:1::/48" AND or OR with > the first condition? > > > I think: > (packet_destination_address is not in (2001:db8:1::/48 or 2001:db8:2::/48= )) > and (packet_source_address is in 2001:db8:1::/48) > is clearer, but not sure (same for other pseudocode too) .... > > ... > > 3.2.5. Topologies with Dedicated Border Routers > > For simplicity reasons all topologies below show the ISP uplinks > > O: For simplicity reasons > P: For simplicity, > > terminated on the first-hop routers. Obviously, the proposed > approach can be used in more complex topologies when dedicated > devices are used for terminating ISP uplinks. In that case VRRP > mastership or inteface status can not be used as a trigger for > > O: inteface > P: interface > > conditional RAs and route presence as described above should be used > instead. > > ... > > R1 and R2 policy: > > prefix 2001:db8:1:1::/64 { > if ISP_A_uplink_route is present then preferred_lifetime =3D 604800 > else preferred_lifetime =3D 0 > } > prefix 2001:db8:2:1::/64 { > if ISP_A_uplink_route is present then preferred_lifetime =3D 0 > else preferred_lifetime =3D 604800 > } > > For load-balancing case the policy would look slightly different: > > O: For load-balancing case > P: For the load balancing case ? > > each prefix has non-zero preferred_lifetime only if the correspoding > ISP uplink route is present: > > > > Section: 3.2.6. Intra-Site Communication during Simultaneous Uplinks Out= age > > Prefix deprecation as a result of an uplink status change might lead > to a situation when all global prefixes are deprecated (all ISP > uplinks are not operational for some reason). Even when there is no > Internet connectivity it might be still desirable to have intra-site > IPv6 connectivity (especially when the network in question is an > IPv6-only one). However while an address is in a deprecated state, > its use is discouraged, but not strictly forbidden ([RFC4862]). In > such scenario all IPv6 source addresses in the candidate set > > O: such scenario > P: such a scenario, > > ([RFC6724]) are deprecated which means that they still can be used > > O: deprecated which means > P: deprecated, which means > > (as there is no preferred addresses available) and the source address > selection algorith can pick up one of them, allowing the intra-site > communication. However some OSes might just fall back to IPv4 if the > network interface has no preferred IPv6 global addresses. Therefore > if intra-site connectivity is vital during simultanious outages of > multiple uplinks, administrators might consider using ULAs or > provisioning additional backup uplinks to protect the network from > double-failure cases. > > 3.2.7. Uplink Damping > > If an actively used uplink (primary one or one used in load balaning > scenario) starts flapping, it might lead to undesirable situation of > > O: to undesirable situation > P: to the undesirable situation > > flapping addresses on hosts (every time the uplink goes up hosts > receive an RA with non-zerop preferred PIO lifetime, and every time > > O: non-zerop > P: non-zero > > the uplink goes down all address in the affected prefix become > > O: all address > P: all addresses > > deprecated). Undoubtedly it would negatively impact user experience, > not mentioning spikes of DAD traffic every time an uplink comes back > > O: Undoubtedly it would negatively impact user experience, > > not mentioning spikes > > P: This would, undoubtedly, negatively impact the user experience, not to > mention the impact of spikes > > up. Therefore it's recommended that router vendors implement some > form of damping policy for conditional RAs and either postpone > sending an RA with non-zero lifetime for a POI when the uplink comes > up for a number of seconds or even introduce accumulated penalties/ > exponential backoff algorithm for such delays. (In the case of > multiple simultaneous uplink failure scenario, when all but one > uplinks are down and the last remaining is flapping it might result > in all addresses being deprecated for a while after the flapping > uplink recovers.) > > O: (In the case of > > multiple simultaneous uplink failure scenario, when all but one > uplinks are down and the last remaining is flapping it might result > in all addresses being deprecated for a while after the flapping > uplink recovers.) > > P: (In the case of a > > multiple simultaneous uplink failure scenario, when all but one > uplink is down and the last remaining one is flapping, this might resu= lt > in all addresses being deprecated for a while after the flapping > uplink recovers.) > > > 3.3. Solution Limitations > > It should be noted that the proposed approach is not a silver bullet > for all possible multihoming scenarios. The main goal is to solve > some common use cases so it would suit very well relatively simple > topologies with straightforward policies. The more complex the > > O: > > so it would suit very well relatively simple > topologies with straightforward policies. > > P: -- I don't know, but I am having trouble parsing the above. > > network topology and the corresponding routing policies more > > O: policies more > P: policies, the more > > configuration would be required to implement the solution. > > Another limitation is related to the load balancing between the > uplinks. In that scenario when both uplinks are active hosts would > > O: In that scenario when both uplinks are active hosts > P: In the scenario in which both uplinks are active, hosts > > select the source prefix using the Default Address Selection > algorithm ([RFC6724]) and therefore the load between two uplinks most > > O: algorithm ([RFC6724]) and therefore the load > P: algorithm ([RFC6724]), and therefore the load > > likely would not be evenly distributed. (However the proposed > > O: However > P: However, > > mechanism does allow a creative way of controlling uplinks load in > SDN networks where controllers might selectively deprecate prefixes > on some hosts but not others to move egress traffic between uplinks). > Also the prefix selection does not take into account any other > uplinks properties (such as RTT etc) so egress traffic might not be > > O: (such as RTT etc) so > P: (such as RTT etc), so > > > sent to the nearest uplink if the corresponding prefix is selected as > a source. In general if not all uplinks are equal and some uplinks > are expected to be preferred over others then the network > > O: In general if not all uplinks are equal and some uplinks > are expected to be preferred over others then > > P: In general, if not all uplinks are equal and some uplinks > are expected to be preferred over others, then > > adminitrator should ensure that prefixes from non-preferred ISP(s) > > O: adminitrator > P: administrator > > are kept deprecated (so primary/backup setup is used). > > 3.3.1. Connections Preservation > > The proposed solution is not designed to preserve connections state > > O: connections > P: connection > after an uplink failure. If all uplinks to an ISP go down all > > O: If all uplinks to an ISP go down > P: If all uplinks to an ISP go down, > > sessions to/from addresses from that ISP address space are > interrupted as there is no egress path for those packets and there is > not return path from Internet to the correspodning prefix. In this > > O: not return path from Internet to the correspodning prefix. > P: no return path from the Internet to the corresponding prefix. > > regard it is similar to IPv4 multihoming using NAT, where an uplink > failure and failover to another uplink means that a public IPv4 > address changes and all existing connections are interrupted. > > An uplink recovery, however, does not nessesary leads to connections > > O: nessesary leads > P: necessarily lead > > interruption. In the load sharing/balancing scenario an uplink > recovery does not affect any existing connections at all. In the > active/backup topology when the primary uplink recovers from the > failure and the backup prefix is deprectaed, the existing sessions > > O: deprectaed > P: deprecated > > (established to/from the backup ISP addresses) can be preserved if > the routers are configured as described in Section 3.2.1 and send > packets with the backup ISP source addresses to the backup uplink > even when the primary one is operational. As a result, the primary > uplink recovery makes the usage of the backup ISP addresses > discouraged but still possible. > > > -- > I don't think the execution is relevant when it was obviously a bad idea = in > the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair of > pants. > ---maf > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 SY, Jen Linkova aka Furry From nobody Mon May 7 09:59:36 2018 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 445E41270AE; Mon, 7 May 2018 09:59:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.79.1 Auto-Submitted: auto-generated Precedence: bulk CC: v6ops@ietf.org, russ@riw.us, v6ops-chairs@ietf.org, draft-ietf-v6ops-conditional-ras@ietf.org, Russ White , warren@kumari.net Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <152571236823.1423.10999011273035268040.idtracker@ietfa.amsl.com> Date: Mon, 07 May 2018 09:59:28 -0700 Archived-At: Subject: [v6ops] Last Call: (Using Conditional Router Advertisements for Enterprise Multihoming) to Informational RFC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2018 16:59:28 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Using Conditional Router Advertisements for Enterprise Multihoming' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-05-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document discusses the most common scenarios of connecting an enterprise network to multiple ISPs using an address space assigned by an ISP. The problem of enterprise multihoming without address translation of any form has not been solved yet as it requires both the network to select the correct egress ISP based on the packet source address and hosts to select the correct source address based on the desired egress ISP for that traffic. The "ietf-rtgwg- enterprise-pa-multihoming" document proposes a solution to this problem by introducing a new routing functionality (Source Address Dependent Routing) to solve the uplink selection issue and using Router Advertisements to influence the host source address selection. While the above-mentioned document focuses on solving the general problem and on covering various complex use cases, this document describes how the solution proposed in the "ietf-rtgwg-enterprise-pa- multihoming" draft can be adopted for a limited number of common use cases. In particular, the focus is on scenarios where an enterprise network has two Internet uplinks used either in primary/backup mode or simultaneously and hosts in that network might not yet properly support multihoming as described in RFC8028. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-v6ops-conditional-ras/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-v6ops-conditional-ras/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Sun May 13 19:03:38 2018 Return-Path: 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 1AF2A12778E for ; Sun, 13 May 2018 19:03:37 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 AHtKFtsmmQh5 for ; Sun, 13 May 2018 19:03:35 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (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 94A10127863 for ; Sun, 13 May 2018 19:03:35 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id n1-v6so4785409pgs.2 for ; Sun, 13 May 2018 19:03:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:subject:message-id:to; bh=MpfstVsgsVpD2Zdbp+MVFGrsW7mNsUa+ds4Udt4tUAE=; b=OaJsigl02SxwEmqsQ8djJYhoYCFq7CDOABdJFiCP3bPNnhNC15NJgfdspjvlzeLhc/ xmw5Do7RIKoQuXtCV4saZU8lsLEwvXXgNMNT7Icny+DLREmshoZtcs83ZXZ7mvQzje+0 QDmDid5gMiNyLnSPYjzREkrDUuXtQbpD9OXF7MZsSHWIyCzZx58t7FYbSzzEpdmCi93U SCW4s4XNxQOHiBDYIcA0qEN7aJ2TlkDnVBCins80kFx1WuDDCt3OQOH8j/rpMpQ09PH2 G3ZqdgYTDxLRxU/VJOWQEKDJm7dEpPHFa8/zhOxd+RiTAPDakUFiSK71a6Ey9FKPygQt vcWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:subject:message-id:to; bh=MpfstVsgsVpD2Zdbp+MVFGrsW7mNsUa+ds4Udt4tUAE=; b=VrA1QlDD8Vs0ze9+VPm3KG4cf5NDs4IXiMxva5xPLAmgHTVvT/NkDQVhC3/i4aUKPu fXHkd+9eJYhaJ6zfY/zVVK25ZgG09MYf3jaypHxc3VFdLXQajC6in24Ha0HjnRxKrs8A uNeuQo0or3piwDSYzUM1V0Ewgu8H3Qz0f8/dUj47/8aA+2cnZckXSG95NKL12qyS+kQv VzXXApjG9IfbXrUhO9B7jcAJ6qW20xWVzZk2wzdauEn9mN8yNrkLbwyHhswiNeFsSTXB WKUteklSCo8RWx54uaS5httsPmLJJ0dhQEd3zyboC5tIKurO2JJ8hsBkn23xOZ7SMw3B Sr9A== X-Gm-Message-State: ALKqPwcqQPuGEizDWQUsj77bbOn8pmtUQrbOGIVZWGsinc2BAL8KUA50 pvC2oOEMdmxLeZSDRuFzTeKdBuse X-Google-Smtp-Source: AB8JxZpPkIojcyKj2b5kRBgiRAbj1nZw7E7jQW4jqGzSDF4BPkHpHS96ZUyeaNRbHf+TaOzxv2Z+qg== X-Received: by 2002:a63:2547:: with SMTP id l68-v6mr7018651pgl.40.1526263415067; Sun, 13 May 2018 19:03:35 -0700 (PDT) Received: from ?IPv6:2600:8801:d004:600:6ced:8aef:8c5b:85c0? ([2600:8801:d004:600:6ced:8aef:8c5b:85c0]) by smtp.gmail.com with ESMTPSA id q75-v6sm16728042pfj.94.2018.05.13.19.03.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 May 2018 19:03:34 -0700 (PDT) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_0B05ED3C-4CFD-46E3-A264-832F8629C3B3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Sun, 13 May 2018 19:03:32 -0700 Message-Id: <51BAEA39-F43B-4D5F-8712-F8B83F5B36C7@gmail.com> To: V6 Ops List X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [v6ops] Time to get your drafts in X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 02:03:37 -0000 --Apple-Mail=_0B05ED3C-4CFD-46E3-A264-832F8629C3B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The draft cut-off for IETF 102 is July 2 at 23:59 UTC. Getting on the = agenda calls for list discussion before the event. That argues for you = getting your drafts in *now*, and then asking the list to comment on = your draft. --Apple-Mail=_0B05ED3C-4CFD-46E3-A264-832F8629C3B3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlr47nQACgkQEhdRnd2G P+DnbA/9HadOAxxP1gyvZCp+IVPQy2Xd0o1lvzXBivW/Bf9OAGIx16eBP1whbJFw GfCgrf3qdIRkGZKEFHlYjoFYLh01NfU3bbTIf75RbEXBzI5VsmAar1wnreBlMUTK d5nMdKHFK0o0jylevnEh2N1LVMczKhyKnDK2YpQihh12QXraXlM4YeLNMQRttLNn L8GvTPTt0OZcemzlHqNxAuVpQ/MuzXXvOkNybxPd/l9keDoOWGteb8LQus1uFO5y mEb3p2HkQnYZY6YjVPrspabe3Ly5RpF6wO0qEZMLz2Q6HwSY0Ds5NHMw8DCDDhfb FG5M+c3A4Z0kSSU1nrv4Np/26k3Zs1j4VM0kj2hWVZYfg07ZkFtXTodpvPT2HDBO 7zZhXuEDo9Qr2lewWgDI9LfE5/loddqvYErev+qW5Hs2MhbS/TuUq4KkHIenI1S3 vz8Of0mIeCrSbhqt9ghDwToMKxmMVFvoJ8S250Qcb4OWNsVZMxdC8qD2Wi7PntSV kJLLfJPBaNSo7YDbwhb5+srl6MaaQIUMEVrV8+4KP3mNpmQ4VKQM6Pc4GhkA1kzC yajCNPz0rZVG+b29YQX+1ZjQbImZ4kepAK3HLN9xbhn2TkMF19135YXxqjer4Cz7 hDTpvElhmgVLuILJAS4FQwmXX05OKg5mjSQBVD17RlolveAkDT0= =4vZM -----END PGP SIGNATURE----- --Apple-Mail=_0B05ED3C-4CFD-46E3-A264-832F8629C3B3-- From nobody Sun May 13 19:07:24 2018 Return-Path: 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 16F0E127863 for ; Sun, 13 May 2018 19:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001] autolearn=ham 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 j1ZhHw_hp3Bc for ; Sun, 13 May 2018 19:07:21 -0700 (PDT) Received: from mail-pl0-x22b.google.com (mail-pl0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) (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 480E412778E for ; Sun, 13 May 2018 19:07:21 -0700 (PDT) Received: by mail-pl0-x22b.google.com with SMTP id az12-v6so6409930plb.8 for ; Sun, 13 May 2018 19:07:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:subject:message-id:to; bh=gbLZO4gcN+vqCbZ7uUIzU873u4WKj1Jfr9wL+MzedrA=; b=twRxTOajb/AsnThWQYQHStngD6UQoWp7KHMONe43mMujyU7DfTq8My+vUfISZhOiQa pCKf05O7LNo7aQ78H9W29+VG2QxS8IaWQzA1ZGp5xLUzsqHe5q+7FLlz5kn3MojjhjhR k/A4P4i5tXRT98uvAorH067zn8t3holV+SSrODC14O4fOhPLVmo6HC/MAYajKdQVQO+4 zY5p3EnOHZg2xlS1i2ARIt6cZUkFoLOK2wsJ05Dm2+x6XnwXynYpEW2ZSwFCzl+Dpipi 1DrBHG6B9Ezrwr5Z3XbeFDPECgzdkYuEL3oW6rPdknPGze6iVmZR+G9KmHst+wlYS/OZ R62w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:subject:message-id:to; bh=gbLZO4gcN+vqCbZ7uUIzU873u4WKj1Jfr9wL+MzedrA=; b=E9WgqWTPOjlw+WKdTiyEGau5mE4j4IkvsdEMG4hQpMcKA7VBgw7VFJ8/qYAwXQkjrG jiwS6MarsCJsHRvWp7ga03D5YsSFZkbpCPknHjRfQckyJ+FMo2wpwOSaEXJsGq+rr4Hj 3Mrok2iA9pP2pyZLm1DHi4GHjA1iUfuM7vmqF5tdaKg/i56SwEPgurG10tKwVNjUSIzA JxqBPE6LRtROuBdLZBQPpXeFR9FrW0JYBrm53mZHMYL8yUR0lnLLJg5dl40rMK3mJOBn 0H6Vj7kmh6k40FUttuyp7NliwDP9g6Va/jDeS5X5wotEBG6Aq9JopcmemUA4V7XrXYMM iQlw== X-Gm-Message-State: ALKqPwc0oEKzsV4eIhIQKh/e73IVFxghBG2pkHOJ+nZxr08SkUagxU5D 3oNk3co1qlR5gMRblqEOfMHXuRGb X-Google-Smtp-Source: AB8JxZpWnOdlNPmgJFc2rQIR84JUM/l1iF9L005tIVdDJ4rtI71SF1Q7xOY86e7n3PJHdD8Ns4H7fw== X-Received: by 2002:a17:902:8217:: with SMTP id x23-v6mr7641915pln.380.1526263640849; Sun, 13 May 2018 19:07:20 -0700 (PDT) Received: from ?IPv6:2600:8801:d004:600:6ced:8aef:8c5b:85c0? ([2600:8801:d004:600:6ced:8aef:8c5b:85c0]) by smtp.gmail.com with ESMTPSA id x3-v6sm16996950pff.87.2018.05.13.19.07.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 May 2018 19:07:20 -0700 (PDT) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_09C333AD-C463-4F29-8995-02D72B00130D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Sun, 13 May 2018 19:07:18 -0700 Message-Id: To: V6 Ops List X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [v6ops] draft-palet-v6ops-nat64-deployment discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 02:07:23 -0000 --Apple-Mail=_09C333AD-C463-4F29-8995-02D72B00130D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Considering = https://tools.ietf.org/html/draft-palet-v6ops-nat64-deployment-00, = discussed at IETF 101 using the slides at = https://datatracker.ietf.org/meeting/101/materials/slides-101-v6ops-nat64-= deployment-guidelines-in-operator-and-enterprise-networks-00. I'd like = to invite discussion on the list. What thoughts do folks have on this = draft? --Apple-Mail=_09C333AD-C463-4F29-8995-02D72B00130D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlr471YACgkQEhdRnd2G P+Apaw/+JvR27uIdwdJzP6oHVDY5EKHvXg/vQpfQQ+UgkAgkVrFdoXqpxgv/BPrn dIY0h79VIujQ/R5a4u4yt+7wh1m2ZgkKebisC8u+Sp0qYqnLxMQ/vM5ihXcqGuw+ YYwwYewxnqPHrALJathTtrW/hzeyRGS9jx4WBuHyt04UXAn54K2yMsM6yUCZpRte z3GUV22DfLWijB7zAsqC9TagMw/S8nQ7bkwO/FbnXViRPKWPYs6iSc/rScgfkHSb GSTRJA6QflQD1BZ3o9rqyp1S98Op+UUaII9A/uOUV+/XNpxtwKH/JSK/7jSWlZp2 /C7VuwZQ3kj9pPI8YVmvL6zGOPHGg4uEJ9DZ6FOFI7Pu4cLoRQTB/cuDMZqsj4tR BtOIfssuKqw+N6XBeQdl9du21zju5erL7bQz9gdoPtSNLKXwp0lMqdraNyOHTGod EYJK2Zrgm2ekZDl91liSmDTsp7Y7Vu2oqC0YHXpRHmeVHaZKNnEVRDhIsFxMFRFl i8m5NnDnaIlqjBdth2YcQRYVUY6b5jiONQchkQYMts4mLNOz0faivlVh0xPc5bf1 cuRlFT66OScA22e8L0qJZICffIlW8cUMMvy+IRiyMsj5q6knKIjam0scsRVnZ7B9 pf4T/JJbwdBUQDndP4hd5b+XxyewUrolESwgC1CFVBkRf9MIH9Q= =S9hM -----END PGP SIGNATURE----- --Apple-Mail=_09C333AD-C463-4F29-8995-02D72B00130D-- From nobody Mon May 14 02:08:53 2018 Return-Path: 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 CD52A129C53 for ; Mon, 14 May 2018 02:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 xMQRcvSPPh68 for ; Mon, 14 May 2018 02:08:44 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07432127058 for ; Mon, 14 May 2018 02:08:43 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w4E98fNJ141363; Mon, 14 May 2018 11:08:41 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 8AD0E20125E; Mon, 14 May 2018 11:08:41 +0200 (CEST) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 7B4C3200C56; Mon, 14 May 2018 11:08:41 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w4E98f3F005074; Mon, 14 May 2018 11:08:41 +0200 To: v6ops@ietf.org References: <48952_1526263441_5AF8EE91_48952_3773_1_51BAEA39-F43B-4D5F-8712-F8B83F5B36C7@gmail.com> Cc: Michael Richardson From: Alexandre Petrescu Message-ID: <3fc0dcca-4b00-cb07-d530-a38453626311@gmail.com> Date: Mon, 14 May 2018 11:08:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <48952_1526263441_5AF8EE91_48952_3773_1_51BAEA39-F43B-4D5F-8712-F8B83F5B36C7@gmail.com> Content-Type: multipart/mixed; boundary="------------4EC242539396B3BE40B193D7" Content-Language: fr Archived-At: Subject: Re: [v6ops] Time to get your drafts in X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2018 09:08:52 -0000 This is a multi-part message in MIME format. --------------4EC242539396B3BE40B193D7 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Le 14/05/2018 à 04:03, Fred Baker a écrit : [...] > The draft cut-off for IETF 102 is July 2 at 23:59 UTC. Getting on the > agenda calls for list discussion before the event. That argues for > you getting your drafts in *now*, and then asking the list to comment > on your draft. Hi, I posted an Internet Draft about the GTP protocol. This protocol is used in cellular networks. To access this draft one needs IPv6. http://petrescu.sandelman.ca/ Alex > > > > > _______________________________________________ v6ops mailing list > v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops > --------------4EC242539396B3BE40B193D7 Content-Type: text/plain; charset=UTF-8; name="draft-petrescu-5gangip-gtp-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-petrescu-5gangip-gtp-00.txt" Network Working Group A. Petrescu Internet-Draft CEA Intended status: Standards Track D. von Hugo Expires: November 8, 2018 Telekom Innovation Laboratories May 7, 2018 The GTP Protocol draft-petrescu-5gangip-gtp-00.txt Abstract The GPRS Tunnelling Protocol (GTP in short, GPRS - Generalized Packet Radio Service) is a message format and computer algorithm specified by 3GPP. This document is on IETF aspects of GTP. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 8, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Petrescu & von Hugo Expires November 8, 2018 [Page 1] Internet-Draft nextgenprot May 2018 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 2 3. Implementation Overview . . . . . . . . . . . . . . . . . . . 3 4. Detailed Protocol Operation . . . . . . . . . . . . . . . . . 3 5. Multicast Support . . . . . . . . . . . . . . . . . . . . . . 3 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 7. Security Considerations . . . . . . . . . . . . . . . . . . . 3 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 9.1. Normative References . . . . . . . . . . . . . . . . . . 4 9.2. Informative References . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction The spec is in document 3GPP TS 29.060 V15.0.0 (2017-09). It is an UDP/IP protocol, because the spec says "UDP/IP is the only path protocol defined to transfer GTP messages in the version 1 of GTP. A User Datagram Protocol (UDP) compliant with IETF RFC 768 [13] shall be used." The computer algorithm is executed on PGW and on SGW. (the protocol is executed on ...). The behaviour: when a smartphone connects, a tunnel is put up. The smartphone connects using protocol PDP. PDP will not be described here, but PDP triggers GTP. The PDP is executed on the modem part of the smartphone, not on the ARM part of it. The figure of entities is the following: smartphone ---- eNodeB ---- SGW ----- PGW ---- Internet The smartphone is further detailed as: ARM --- modem ------> eNodeB The GTP header format is the following: "GTP Header" from 3GPP spec. 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Petrescu & von Hugo Expires November 8, 2018 [Page 2] Internet-Draft nextgenprot May 2018 3. Implementation Overview There is no open source available for the PDP protocol implementation on the modem in the smartphone, although it runs as a miniVM virtual machine on linux. Hexagon miniVM efforts may lead to an open source port. Many cellular operators implement GTP. Some cellular operators offer IPv6 access to the smartphone. But among these operators most transport UDP on IPv4 in order to transport that IPv6. It is the case with T-Mobile, Orange, BT, Bouygues, SFR. It may be that operator Reliance JIO transports IPv6 in UDP/IPv6, but should be confirmed. Bouygues and Orange Poland do also IPv6 for smartphones but it is not known whether they transport it on UDP/IPv6 or UDP/ IPv4. The packet capture of a GTP message carrying a DHCPv6 Solicit sent by ARM to PGW is: > INBOUND>>>>> 15:47:48:883 Eventid:142004(3) > GTPU Rx PDU, from [IPv4-address]:2152 to [IPv4-address-2]:2152 (129) > TEID: 0x80072183, Message type: GTP_TPDU_MSG (0xFF) > Sequence Number:: NA > GTP HEADER FOLLOWS: > [snip] > GTP HEADER ENDS. > Payload protocol: IPv6 > PROTOCOL PAYLOAD FOLLOWS: > fe80::b9d9:c10a:2c2d:3c3b.546 > ff02::2.546: [udp sum ok] > IPv6 Header Follows: > [snip] > PROTOCOL PAYLOAD ENDS. Figure 1: GTP packet containing DHCPv6 Solicit 4. Detailed Protocol Operation 5. Multicast Support 6. IANA Considerations TBD. 7. Security Considerations Petrescu & von Hugo Expires November 8, 2018 [Page 3] Internet-Draft nextgenprot May 2018 8. Acknowledgements 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, DOI 10.17487/RFC3633, December 2003, . 9.2. Informative References [RFC7333] Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J. Korhonen, "Requirements for Distributed Mobility Management", RFC 7333, DOI 10.17487/RFC7333, August 2014, . Authors' Addresses Alex Petrescu CEA Email: alexandre.petrescu@cea.fr Dirk von Hugo Telekom Innovation Laboratories Deutsche-Telekom-Allee 7 D-64295 Darmstadt Germany Email: Dirk.von-Hugo@telekom.de Petrescu & von Hugo Expires November 8, 2018 [Page 4] --------------4EC242539396B3BE40B193D7-- From nobody Mon May 21 01:24:00 2018 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A1112E87B; Mon, 21 May 2018 01:23:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sheng Jiang To: Cc: draft-ietf-v6ops-conditional-ras.all@ietf.org, v6ops@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152689102802.23045.6041887435563645658@ietfa.amsl.com> Date: Mon, 21 May 2018 01:23:48 -0700 Archived-At: Subject: [v6ops] Opsdir last call review of draft-ietf-v6ops-conditional-ras-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2018 08:23:48 -0000 Reviewer: Sheng Jiang Review result: Has Issues Reviewer: Sheng Jiang Review result: Has Issues I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This Informational document describes a mechanism that uses the conditional Router Advertisements for Enterprise Multihoming in which an enterprise network up-links to multiple ISPs using an address space assigned by an ISP. Major issue: no. Minor issue: There are many unused reference. However, they are not simple Nits and cannot be fixed by deleting them from reference list. Many of these unused reference are really relevant and should have some content to describe the relationship with the mechanism or scenario of the document, such as RFC6296 NAT66, etc. Regards, Sheng From nobody Mon May 21 16:25:34 2018 Return-Path: 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 CEC0C12D96A; Mon, 21 May 2018 16:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net 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 wQQLTf_yNWwT; Mon, 21 May 2018 16:25:23 -0700 (PDT) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BEC512D967; Mon, 21 May 2018 16:25:23 -0700 (PDT) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4LNPNN3000304; Mon, 21 May 2018 16:25:23 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=wHVti40DfqZSNNIjvJumxeJvUlDhUiGOtAo09EK+3b0=; b=Mn07Iw/XV5rZMiU+4UFrFDOD/0wbaIE1Qu3vA/YwvdUHmKLsa6RnbClNrffX8OsvCSdK QX/gIGOfDPQEP85fMr0Z3uHCYT+Z1dWO/Aa9Trvn3+wwrG+nbzFWeu9UZThVjQQ0j9uM 7Z6jWvcHDvWnHAFZLDeppf6xhuD167OXIlNYPFhr4jxiE2Hsy/1heM3Gn/cr6VO4b6IV eWiK4+CA1gSipdQlVUNXv7mfv9XlFTqaUS/IAi5fAX3v13XqP1B/n3BTbHqZlKbhimsM /CruQokh4M4K6Ym+ym6FlJVvsJ0+t4TFvgkAHUKv9RiHT4fz7y7+e4QzoX7YKaAndvvw 5g== Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0080.outbound.protection.outlook.com [207.46.163.80]) by mx0a-00273201.pphosted.com with ESMTP id 2j43f2geq0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 21 May 2018 16:25:23 -0700 Received: from MWHPR05MB3200.namprd05.prod.outlook.com (10.173.229.143) by MWHPR05MB3536.namprd05.prod.outlook.com (10.174.250.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.797.5; Mon, 21 May 2018 23:25:16 +0000 Received: from MWHPR05MB3200.namprd05.prod.outlook.com ([fe80::c0e1:ed47:68c:376f]) by MWHPR05MB3200.namprd05.prod.outlook.com ([fe80::c0e1:ed47:68c:376f%11]) with mapi id 15.20.0797.011; Mon, 21 May 2018 23:25:16 +0000 From: Ravi Singh To: "rtg-ads@ietf.org" CC: "rtg-dir@ietf.org" , "draft-ietf-v6ops-conditional-ras@ietf.org" , "v6ops@ietf.org" Thread-Topic: RtgDir review: draft-ietf-v6ops-conditional-ras Thread-Index: AdPxWdYhiDZAt4tdT0u33w6T+4L0MQ== Date: Mon, 21 May 2018 23:25:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR05MB3536; 7:Qv92Nvk/n8DICTvMjB1HznP62Vxs7cW6LuBRUA5cwpa/UFTtvSOSiagrtCTydDuBgow71CM7hRyDsFqL5KTX6xspfyej8zwG5ppPlqBbaFzWt6fl1fet52hEZgh4vdUtoWeDqFL3xDkmiL7Qnnymc/8ZrH5go+om7pBZL31b8BTby2NI1zLCKNxKE/G0lp541uXa6BChQTBdhEmpPcdKYqK5wImPVbzxxwVHXKWaZ/xrEsepHQRErEyixexKYJ8X x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:MWHPR05MB3536; x-ms-traffictypediagnostic: MWHPR05MB3536: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:MWHPR05MB3536; BCL:0; PCL:0; RULEID:; SRVR:MWHPR05MB3536; x-forefront-prvs: 06793E740F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(396003)(39380400002)(346002)(39860400002)(199004)(189003)(26005)(5660300001)(102836004)(6506007)(3660700001)(186003)(2906002)(7696005)(54906003)(6116002)(316002)(99286004)(53936002)(106356001)(105586002)(59450400001)(3280700002)(476003)(478600001)(33656002)(6436002)(4326008)(2351001)(486006)(74316002)(97736004)(25786009)(450100002)(305945005)(1720100001)(68736007)(8936002)(2501003)(9686003)(6916009)(7736002)(2900100001)(3846002)(81156014)(81166006)(8676002)(5250100002)(5640700003)(66066001)(86362001)(55016002)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB3536; H:MWHPR05MB3200.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: E/ZUukVhHIcm+qj4r/WZ3SQju6Y0PwrgMRiaiRG/cQm/RPJ2ecXERPcjhSf6oN1mYyWDAhs02S2KPwEHOXAMLFvYHf43MAmYMNjB7UMicu3mQj8D40gwvcME3wT3J4UFUd+31vEqJnyJO9Gv4fkjRJk4shsUPnnff6iTwIZ25hzcH9pyrfhxDVWw5DdSvv4O spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 605c12e6-756f-4844-5780-08d5bf721c39 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 605c12e6-756f-4844-5780-08d5bf721c39 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 May 2018 23:25:16.2729 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB3536 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-21_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805210267 Archived-At: Subject: [v6ops] RtgDir review: draft-ietf-v6ops-conditional-ras X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2018 23:25:26 -0000 SGVsbG8sIA0KSSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUg cmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtzIHRv IHJldmlldyBhbGwgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkgcGFz cyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJRVNHIHJldmlldywgYW5kIHNvbWV0aW1lcyBv biBzcGVjaWFsIHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gcHJvdmlk ZSBhc3Npc3RhbmNlIHRvIHRoZSBSb3V0aW5nIEFEcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gYWJv dXQgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUsIHBsZWFzZSBzZWUg4oCLaHR0cDovL3RyYWMudG9v bHMuaWV0Zi5vcmcvYXJlYS9ydGcvdHJhYy93aWtpL1J0Z0RpciANCkFsdGhvdWdoIHRoZXNlIGNv bW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURzLCBpdCB3 b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55 IG90aGVyIElFVEYgTGFzdCBDYWxsIGNvbW1lbnRzIHRoYXQgeW91IHJlY2VpdmUsIGFuZCBzdHJp dmUgdG8gcmVzb2x2ZSB0aGVtIHRocm91Z2ggZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUg ZHJhZnQuIA0KDQpEb2N1bWVudDogZHJhZnQtaWV0Zi12Nm9wcy1jb25kaXRpb25hbC1yYXMNClJl dmlld2VyOiBSYXZpIFNpbmdoDQpSZXZpZXcgRGF0ZTogTWF5IDIxLCAyMDE4DQpJbnRlbmRlZCBT dGF0dXM6IEluZm9ybWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KU3Vt bWFyeTogVGhpcyBkb2N1bWVudCBpcyBiYXNpY2FsbHkgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLCBi dXQgaGFzIG5pdHMgdGhhdCBzaG91bGQgYmUgY29uc2lkZXJlZCBwcmlvciB0byBwdWJsaWNhdGlv bi4NCg0KTml0czoNCjEuIEZvciByZWFkYWJpbGl0eSBzYWtlIGZvciB3aWRlciBhdWRpZW5jZXMs IGZpcnN0IHVzYWdlIG9mIGFjcm9ueW0gaW4gdGhlIGRyYWZ0IHNob3VsZCBleHBhbmQgdGhlIGFj cm9ueW0gZXZlbiB0aG91Z2ggdGhlIHVzYWdlIG9mIG1hbnkgb2YgdGhlc2UgYWNyb255bXMgaXMg cHJldHR5IGNvbW1vbjoNCiAgICAgIGEuIFNlY3Rpb24gMy4xLjI6IFJETlNTLCBTTEFBQywgQ1BF DQogICAgICBiLiAzLjIuNjogVUxBDQogICAgICBjLiAzLjIuNzogREFEDQogICAgICBkLiAzLjM6 IFNETiwgUlRUDQoNCjIuIFR5cG8gY29ycmVjdGlvbnM6ICANCiAgICAgYS4gUE9JIC0+IFBJTw0K ICAgICAgICAgICAgICAgIDMuMS4yOiAyIG9jY3VycmVuY2VzDQogICAgICAgICAgICAgICAgMy4y LjQgJiAzLjIuNzogMiBvY2N1cnJlbmNlcyBlYWNoDQogICAgYi4gM1NlY3Rpb24gLjIuNjogDQog ICAgICAgICAgICAgICAiYWxnb3JpdGgiIC0gPiAiYWxnb3JpdGhtIg0KDQogICAgYy4gSW4gc2Vj dGlvbiAzLjEuMjogIA0KDQogICAgICAgICAiYWRkcmVzcyBzZWxlY3RlZCBieSBhIGhvc3QgYXMg ZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4xLjIuICBIb3dldmVyLCIgLT4gDQogICAgICAgICAiYWRk cmVzcyBzZWxlY3RlZCBieSBhIGhvc3QgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4xLjEuICBI b3dldmVyLCINCsKgDQogICBkLiBTZWN0aW9uIDMuMi4zOiB0eXBvOiBxdW90ZWQgc2VjdGlvbiAj IG5lZWRzIGNvcnJlY3Rpb24uDQogICAgICAgICAgIiBjb3JyZWN0IHVwbGluayBiYXNlZCBvbiB0 aGUgc291cmNlIGFkZHJlc3MgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4yLjEuIg0KICAgICAg ICAgICAtPg0KICAgICAgICAgImNvcnJlY3QgdXBsaW5rIGJhc2VkIG9uIHRoZSBzb3VyY2UgYWRk cmVzcyBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjEuMS4iDQoNCjMuICBTZWN0aW9uIDMuMi41 Og0KICAgICAiRm9yIHNpbXBsaWNpdHksIGFsbCB0b3BvbG9naWVzIGJlbG93IHNob3cgdGhlIElT UCB1cGxpbmtzIHRlcm1pbmF0ZWQiDQogICAgIC0+DQogICAgICJGb3Igc2ltcGxpY2l0eSwgYWxs IHRvcG9sb2dpZXMgYWJvdmUgc2hvdyB0aGUgSVNQIHVwbGlua3MgdGVybWluYXRlZCIgPw0KDQo0 LiBTZWN0aW9uIDMuMyAmIDMuNDogdGhlIHRleHQgc2VlbXMgdG8gaW5kaWNhdGUgdGhhdCB0aGlz IGRyYWZ0IGlmIHByb3Bvc2luZyBzb21lIHNvbHV0aW9uLCBldmVuIHRob3VnaCBhcyBpbmRpY2F0 ZWQgaW4gdGhpcyBkcmFmdCdzIGFic3RyYWN04oCmLnRoZSBzb2x1dGlvbiBiZWluZyByZWZlcmVu Y2VkIGlzIGluIGlldGYtcnRnd2ctZW50ZXJwcmlzZS1wYS1tdWx0aWhvbWluZyBhbmQgdGhpcyBk cmFmdCBpZiBkZXNjcmliaW5nIHRoZSB1c2Ugb2YgdGhhdCBzb2x1dGlvbiBpbiBzYW1wbGUgc2Nl bmFyaW9zLiBTbGlnaHQgcmV3b3JkaW5nIG9mIHRleHQgc2hvdWxkIGhlbHAgdG8gYWRkcmVzcyB0 aGlzLg0KDQoNClJlZ2FyZHMNClJhdmkNCg0K From nobody Tue May 22 07:02:17 2018 Return-Path: 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 2AD5112EB4D for ; Tue, 22 May 2018 07:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 PfnKWC9Os1Wu for ; Tue, 22 May 2018 07:02:07 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 4671E12EB40 for ; Tue, 22 May 2018 07:02:07 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id z4-v6so18594401iof.5 for ; Tue, 22 May 2018 07:02:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=w8vX6uJZgTakCrxYe2gcfmCDv7NNpCtKsMvRSRKOO0I=; b=uK4VWc06VL+fP6IkuqP9+0MN11y8OaV7Smr+0fA9ujNzwkRGRfU5q9q0bGDyxFx4E4 eslIcZRDzTiqw1ya6H+uOzrfEzfB7RBlcWRtaoxCLJ7jDAC0ua7xKUPbEX4zxj4d7klY V9BRaNo2fwjeyi2qfY1HGPy8wQUYcfYjKZy/3eYtwiPAn+7vsGyt5MRem8lzw7LYawgD NMrpBcIFPDY5wxAXb62I2McCXpOHn5RvnMsb5u2B/8Z2TZ+VtjjP2jv5UsESU/AC20wS /Fwz/jIn2VMB5IiqHHJBkYAPNtFgKX7LFx+g7HEHVnBf1Aegochuvoh885wAxN5NOMxJ vVKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=w8vX6uJZgTakCrxYe2gcfmCDv7NNpCtKsMvRSRKOO0I=; b=aGbV4Tpdt7xS0kaTO+r5Br0W4Z+kmhkFI0CsiMMlj5ykrNHUvmwMIQ8DeS6Yq4CoGr tjuHd7zrqiNX5/DjeQ7+0K5Z5Ax2M35snVxxbTMnPR6raiDf2enxKc6f1evkflRlAw66 y3VGSb9rd4IfjJJJnJlZvt2g9DCso94ZMb0aIdY0G+40mOlooILJ7iqnZyZVakLVY+mS h4PYCpp/zkFNbarPnt6bwlWCTFxviADilh0RxVd2kou1IsoFyuLbZAdba/vnsDlZNXQ0 ImFuJj3FsWc3h5bfxqGbdAfyh4N8bGhuhaZZgZdi0XIobWgOOVMkcQlHaNdCBzTJ1q/2 ZaXA== X-Gm-Message-State: ALKqPweO+2vkWYWCXAHdwF3LvYSMMgOMVLJ0nXABf8ZmZuWq75N/xIJ6 2awuy+CmydnJiwEIX212SN817VMPJQAlXZohxoKFsA== X-Google-Smtp-Source: AB8JxZoR2sPdpWTBtjNGabz+JzmM6cKVzV2qNhJ9ojxcZkhzA0bXMSDOd/twwAFTdE2Z8UPHIxFPDYXSqL5T8sb6wHo= X-Received: by 2002:a6b:248e:: with SMTP id k136-v6mr24297949iok.270.1526997724446; Tue, 22 May 2018 07:02:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.232.12 with HTTP; Tue, 22 May 2018 07:01:43 -0700 (PDT) In-Reply-To: References: From: Jen Linkova Date: Wed, 23 May 2018 00:01:43 +1000 Message-ID: To: Ravi Singh Cc: "rtg-ads@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-v6ops-conditional-ras@ietf.org" , "v6ops@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] RtgDir review: draft-ietf-v6ops-conditional-ras X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 14:02:15 -0000 Thanks a lot for your review, Ravi! I'll post the updated version to address your comments later on this week or at the beginning of the next week. On Tue, May 22, 2018 at 9:25 AM, Ravi Singh wrote: > Hello, > I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related draf= ts as they pass through IETF last call and IESG review, and sometimes on sp= ecial request. The purpose of the review is to provide assistance to the Ro= uting ADs. For more information about the Routing Directorate, please see h= ttp://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF Last = Call comments that you receive, and strive to resolve them through discussi= on or by updating the draft. > > Document: draft-ietf-v6ops-conditional-ras > Reviewer: Ravi Singh > Review Date: May 21, 2018 > Intended Status: Informational > Summary: This document is basically ready for publication, but has nits t= hat should be considered prior to publication. > > Nits: > 1. For readability sake for wider audiences, first usage of acronym in th= e draft should expand the acronym even though the usage of many of these ac= ronyms is pretty common: > a. Section 3.1.2: RDNSS, SLAAC, CPE > b. 3.2.6: ULA > c. 3.2.7: DAD > d. 3.3: SDN, RTT > > 2. Typo corrections: > a. POI -> PIO > 3.1.2: 2 occurrences > 3.2.4 & 3.2.7: 2 occurrences each > b. 3Section .2.6: > "algorith" - > "algorithm" > > c. In section 3.1.2: > > "address selected by a host as described in Section 3.1.2. Howe= ver," -> > "address selected by a host as described in Section 3.1.1. Howe= ver," > > d. Section 3.2.3: typo: quoted section # needs correction. > " correct uplink based on the source address as described in Se= ction 3.2.1." > -> > "correct uplink based on the source address as described in Sect= ion 3.1.1." > > 3. Section 3.2.5: > "For simplicity, all topologies below show the ISP uplinks terminate= d" > -> > "For simplicity, all topologies above show the ISP uplinks terminate= d" ? > > 4. Section 3.3 & 3.4: the text seems to indicate that this draft if propo= sing some solution, even though as indicated in this draft's abstract=E2=80= =A6.the solution being referenced is in ietf-rtgwg-enterprise-pa-multihomin= g and this draft if describing the use of that solution in sample scenarios= . Slight rewording of text should help to address this. > > > Regards > Ravi > --=20 sincerely yours, Jen Linkova a.k.a Furry Network Engineer From nobody Tue May 22 07:08:51 2018 Return-Path: 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 CDDBD12EB71; Tue, 22 May 2018 07:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, 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 0bts4wDqCwXG; Tue, 22 May 2018 07:08:36 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (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 BC84812EB4C; Tue, 22 May 2018 07:08:23 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id p3-v6so1659528wrn.7; Tue, 22 May 2018 07:08:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UG00YUYnfLGJ16exrLcRoNo5UUS1e1ilcgi9zH/exZY=; b=lReMIm7DCtYgWq9GllANR1RpjjWwQ7NoP4eve3zAHgpFVGAVq1fFAqSdmHC/+bO952 t2lZ1r/NmhjkUL2CiFt6De59OcuJANYQ30mwsKHuk3u4wI+BIF68M2JwvcmGtog2gHJE e8Xjzw6Sg0It+fXbuEB2/wd7NNERjFpmW8H2ltD6OBErXwbgI69cKHSqCH9jfXEdbbBN ce3vakF+O6mHrBdVpSm0jNz+w57LIFIEB0JyURYFStADnw4rk5O7PNQrgmg3mEnm5251 f8TznwtllTCjZpV5okks3eHrrxvpp+Ye7rnlNGBcjZTsXTkn+GsjEwnVFS6/qV5YIdPJ 0pNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UG00YUYnfLGJ16exrLcRoNo5UUS1e1ilcgi9zH/exZY=; b=p69G/viwQgsX1/cquFN0WrbwzduSjNWeh/qzjyyrCJNr3W5GNL35d2NJj2FITcKq1j QmyaR3jRy/jjFca1WKRSazQEWUFD+xHkTJ8SwddRI13iejQTk9/YJ99dWgdC04UKJnUr OvmzHbjP3H6d7D15leJoyyTNat0z9fk8PVDULpwlWNhuYatKkjUzPAOf7GidgufcTAbX pkiIaCvLeHihQdOMJIdsYS2SB9vnzYE9H1KpjWx2unCPR7S4Ceg4+bdVmtTqAmHIO8Xp F+iT6acKkU5X0kXmzjD4Bvr3lvxv/c80NHJ5Vte/mvk3BKcKqgMXDUC9MCWkSBqIo+9U ZT3Q== X-Gm-Message-State: ALKqPwf9lvqpInjf9b/6QoBxD0eswdERrYG5qqPWXBss2KU0B51yjF5j NFeoi5OH5yf9fHgnd1AyKFah6EFbroVj1P2LCZs= X-Google-Smtp-Source: AB8JxZoxTTyGFGgboP+jmQbqzEI0GFgNqktQOT9IEjcltKbAUn9asr6tKzuYIZaDA2/4jO5ZtTwKAnu3Gy+rNdBAMbI= X-Received: by 2002:a19:fc0d:: with SMTP id a13-v6mr6107343lfi.66.1526998101956; Tue, 22 May 2018 07:08:21 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:1dd0:0:0:0:0:0 with HTTP; Tue, 22 May 2018 07:08:01 -0700 (PDT) In-Reply-To: <152689102802.23045.6041887435563645658@ietfa.amsl.com> References: <152689102802.23045.6041887435563645658@ietfa.amsl.com> From: Jen Linkova Date: Wed, 23 May 2018 00:08:01 +1000 Message-ID: To: Sheng Jiang Cc: ops-dir@ietf.org, draft-ietf-v6ops-conditional-ras.all@ietf.org, V6 Ops List , IETF Rinse Repeat Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Opsdir last call review of draft-ietf-v6ops-conditional-ras-04 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2018 14:08:39 -0000 Hi Sheng, On Mon, May 21, 2018 at 6:23 PM, Sheng Jiang wrote: > Minor issue: There are many unused reference. However, they are not simple Nits > and cannot be fixed by deleting them from reference list. Many of these unused > reference are really relevant and should have some content to describe the > relationship with the mechanism or scenario of the document, such as RFC6296 > NAT66, etc. Thanks a lot for your review. I'll update the draft to address this issue - the new version will be posted later on this week. -- SY, Jen Linkova aka Furry From nobody Wed May 23 13:04:04 2018 Return-Path: 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 419D4127978 for ; Wed, 23 May 2018 13:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-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 1vpapRiK_hii for ; Wed, 23 May 2018 13:03:59 -0700 (PDT) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F90D127010 for ; Wed, 23 May 2018 13:03:59 -0700 (PDT) Received: from [192.168.1.120] (host-79-121-41-125.kabelnet.hu [79.121.41.125]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id w4NK3me4067187 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 23 May 2018 22:03:53 +0200 (CEST) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-41-125.kabelnet.hu [79.121.41.125] claimed to be [192.168.1.120] To: v6ops@ietf.org References: From: =?UTF-8?Q?Lencse_G=c3=a1bor?= Message-ID: <59246385-2673-e235-d625-0520edce457c@hit.bme.hu> Date: Wed, 23 May 2018 22:03:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0A5D4CCBCFFC5E0A9DF3B69B" Content-Language: en-US X-Virus-Scanned: clamav-milter 0.100.0 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=79.121.41.125; helo=[192.168.1.120]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2018 20:04:03 -0000 This is a multi-part message in MIME format. --------------0A5D4CCBCFFC5E0A9DF3B69B Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Dear Fred and Jordi, I have read the draft and I think it is useful. If I my put my two cents in, I would like to point out that we have come to a very similar conclusion in Section 4.9 (titled "DNS and DNSSEC") of our paper below to the one presented in Section 2 of the draft. G. Lencse and Y. Kadobayashi, "Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 and stateful NAT64", /Computers & Security/ (Elsevier), vol. 77, no. 1, pp. 397-411, September 1, 2018, DOI: 10.1016/j.cose.2018.04.012 Free access link valid until June 30: https://authors.elsevier.com/a/1X1K5c43ukegl Revised version is available freely (as green open access) from my list of publications: http://www.hit.bme.hu/~lencse/publications/ Perhaps ISPs can use our benchmarking results when selecting DNS64 or NAT64 implementations. As for DNS64, we have up to date performance information, which may be somewhat surprising concerning the performance problems of BIND. If you are interested, please check our results concerning the DNS64 performance of BIND, PowerDNS and Unbound: G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theory and Practice", /Computer Communications/ (Elsevier), to be published Revised version is available freely (as green open access) from my list of publications: http://www.hit.bme.hu/~lencse/publications/ As for stateful NAT64, we have only very old measurement results showing that OpenBSD PF outperformed TAYGA+iptables, which was not surprising at all, but those measurements were not RFC 8219 compliant, as RFC 8219 did not exist yet. Best regards, Gábor On 5/14/2018 4:07 AM, Fred Baker wrote: > Considering https://tools.ietf.org/html/draft-palet-v6ops-nat64-deployment-00, discussed at IETF 101 using the slides at https://datatracker.ietf.org/meeting/101/materials/slides-101-v6ops-nat64-deployment-guidelines-in-operator-and-enterprise-networks-00. I'd like to invite discussion on the list. What thoughts do folks have on this draft? > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------0A5D4CCBCFFC5E0A9DF3B69B Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Dear Fred and Jordi,

I have read the draft and I think it is useful.

If I my put my two cents in, I would like to point out that we have come to a very similar conclusion in Section 4.9 (titled "DNS and DNSSEC") of our paper below to the one presented in Section 2 of the draft.

G. Lencse and Y. Kadobayashi, "Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 and stateful NAT64", Computers & Security (Elsevier), vol. 77, no. 1, pp. 397-411, September 1, 2018, DOI: 10.1016/j.cose.2018.04.012
Free access link valid until June 30: https://authors.elsevier.com/a/1X1K5c43ukegl
Revised version is available freely (as green open access) from my list of publications: http://www.hit.bme.hu/~lencse/publications/

Perhaps ISPs can use our benchmarking results when selecting DNS64 or NAT64 implementations.

As for DNS64, we have up to date performance information, which may be somewhat surprising concerning the performance problems of BIND. If you are interested, please check our results concerning the DNS64 performance of BIND, PowerDNS and Unbound:

G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theory and Practice", Computer Communications (Elsevier), to be published

Revised version is available freely (as green open access) from my list of publications: http://www.hit.bme.hu/~lencse/publications/

As for stateful NAT64, we have only very old measurement results showing that OpenBSD PF outperformed TAYGA+iptables, which was not surprising at all, but those measurements were not RFC 8219 compliant, as RFC 8219 did not exist yet.

Best regards,

Gábor




On 5/14/2018 4:07 AM, Fred Baker wrote:
Considering https://tools.ietf.org/html/draft-palet-v6ops-nat64-deployment-00, discussed at IETF 101 using the slides at https://datatracker.ietf.org/meeting/101/materials/slides-101-v6ops-nat64-deployment-guidelines-in-operator-and-enterprise-networks-00. I'd like to invite discussion on the list. What thoughts do folks have on this draft?





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

--------------0A5D4CCBCFFC5E0A9DF3B69B-- From nobody Sat May 26 08:59:16 2018 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0171200C5; Sat, 26 May 2018 08:59:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152735034746.25245.14893810226501972026@ietfa.amsl.com> Date: Sat, 26 May 2018 08:59:07 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2018 15:59:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : Requirements for IPv6 Routers Authors : Zaid Ali Kahn John Brzozowski Russ White Filename : draft-ietf-v6ops-ipv6rtr-reqs-04.txt Pages : 32 Date : 2018-05-26 Abstract: The Internet is not one network, but rather a collection of networks. The interconnected nature of these networks, and the nature of the interconnected systems that make up these networks, is often more fragile than it appears. Perhaps "robust but fragile" is an overstatement, but the actions of each vendor, implementor, and operator in such an interconnected environment can have a major impact on the stability of the overall Internet (as a system). The widespread adoption of IPv6 could, particularly, disrupt network operations, in a way that impacts the entire system. This time of transition is an opportune time to take stock of lessons learned through the operation of large-scale networks on IPv4, and consider how to apply these lessons to IPv6. This document provides an overview of the design and architectural decisions that attend IPv6 deployment, and a set of IPv6 requirements for routers, switches, and middleboxes deployed in IPv6 networks. The hope of the editors and contributors is to provide the necessary background to guide equipment manufacturers, protocol implementors, and network operators in effective IPv6 deployment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6rtr-reqs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-ipv6rtr-reqs-04 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6rtr-reqs-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6rtr-reqs-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat May 26 14:05:29 2018 Return-Path: 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 693C812E8C3 for ; Sat, 26 May 2018 14:05:28 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 F56ULDa7kGkQ for ; Sat, 26 May 2018 14:05:26 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (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 EDF2D12E8B1 for ; Sat, 26 May 2018 14:05:25 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id p9-v6so3676069pgc.9 for ; Sat, 26 May 2018 14:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=U0U3JWQzjJuSVISuW3Xf2UM8cUcOZU/Ysbvs7XL5ZEY=; b=vB3JwgxZe7PgWmUc4UXRPknruGhM+KhyD+d7V5CcixR9dxAmVHGTj+5u5aqjYwdLaI xeIK7ys6JuiKYKPzH5SsRtI/HXg3XIznzSb5bG0IcUJUySam2Q/bqDpOCwyFMDpOEnNY F5K4HqHxfpgaB0DVefVMAWEBnj2sLxfFgOzW+7+Og3pztdIaL5onK5u6+Kj/EXgCn5XU Q0GV+FX5pwaogIhuH9nli2OXOLmho4v2cqDx9ZmCAL61FYy03f0iSTj84Ijs7ygq7BCR rmxGa+ql6zOxKGn5b0/LXlSs3GOfVgdDBGkeD7akWNYQR15k6qEbHcMVnbyV7nA/CmYc z2jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=U0U3JWQzjJuSVISuW3Xf2UM8cUcOZU/Ysbvs7XL5ZEY=; b=E7vzTTroffMXwKzhqzgFiSK9kyERDiz+Y/og5klzmz+Tfk96pw6z5Nsci3sDAkKzM/ U3tizik9sWkY01w07ZSbVQ4ZDPm0NLwC3G+xiQa38OB7dp83dK19z2Nsy0P8k+PaVify hq/yoKxEUvZoDWdY9O1bw/5TMIHqiPsTptjB9zLcVDzyoz4uX6kBrd5z22ut/AyDA/ek Fi6rMloqBvb1It6eyUEnnBxTyqp5qWF7/vPK3I0TKYQf5/t/Ow8CoS4HokZb7Z9HXSKA 6dmZnu6SUu2lxijifVNcxGqjNZqHc41oaIIYgxZ64/OKxCHcxXrnMl6DihiV+zn6awMR Wbyg== X-Gm-Message-State: ALKqPwdIv9jUC2NYU7zrJs0P2gKKvFz8V3jDAwLaY3nKJ4PTasL2+hr+ R/NU6XTLrlEeR3tOSPpH3Be5pA== X-Google-Smtp-Source: ADUXVKKZM2vWlXjaai6KFidkG5AkixsAp6/6mu/hlQKpHJJqGIry25wMQl5r9u7CdfL5z0Np/bwtcg== X-Received: by 2002:a62:3994:: with SMTP id u20-v6mr2691278pfj.95.1527368725277; Sat, 26 May 2018 14:05:25 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id g68-v6sm46277764pfk.53.2018.05.26.14.05.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 26 May 2018 14:05:24 -0700 (PDT) To: v6ops@ietf.org References: <152735034746.25245.14893810226501972026@ietfa.amsl.com> From: Brian E Carpenter Message-ID: Date: Sun, 27 May 2018 09:05:20 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <152735034746.25245.14893810226501972026@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6rtr-reqs-04.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2018 21:05:28 -0000 A couple of points (almost nits) in section 2.1, and then a more basic comment. (1) Another citation for the Postel principle is RFC1958, whose wording was approved by Jon: > 3.9 Be strict when sending and tolerant when receiving. > Implementations must follow specifications precisely when sending to > the network, and tolerate faulty input from the network. When in > doubt, discard faulty input silently, without returning an error > message unless this is required by the specification. (2) > ...[RFC1918] describes > several points in conjunction with this principle I don't think you mean RFC1918!!! RFC5218 perhaps. (3) > Protocols and implementations change over time. True. Consider citing RFC6709 on issues around extensions. My basic comment is that the whole of sections 2.1, 2.2 and 2.3 is interesting stuff, but I seriously question whether it should be here at all. Yes, I've read the first paragraph of section 2, but I'm not at all sure the typical reader will agree. Regards Brian From nobody Sun May 27 11:04:52 2018 Return-Path: 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 AFD8D12F4E5 for ; Sun, 27 May 2018 11:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001] 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 zSn7O1BViaVm for ; Sun, 27 May 2018 11:04:47 -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 28B951270AE for ; Sun, 27 May 2018 11:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1527444284; x=1528049084; 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; bh=ZQP1gIBoXKMGfYQDPy97wyblc8digg2lNN Ig7SM65uk=; b=l8HREjDn/eLRlLTf6tw0z90hmLCLq3w0tw3seRc7Wiig31x3wN JOce5LGz4dG8rvKG0Q98/p/vIAAmjB/dEBxHlWwpRQB6I0QpmjkMZ5+hTNKnRQqF 24xJVluda/PHfCLodxn3X0/sgAG6giZ2Z7oJ9WtxN62mtjmmVXD4UN0y8= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sun, 27 May 2018 20:04:44 +0200 X-Spam-Processed: mail.consulintel.es, Sun, 27 May 2018 20:04:43 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005777789.msg for ; Sun, 27 May 2018 20:04:43 +0200 X-MDRemoteIP: 2001:470:1f09:495:3c45:1420:4320:4ecb X-MDHelo: [10.10.10.129] X-MDArrival-Date: Sun, 27 May 2018 20:04:43 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1685515181=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Sun, 27 May 2018 20:04:39 +0200 From: JORDI PALET MARTINEZ To: Message-ID: Thread-Topic: [v6ops] draft-palet-v6ops-nat64-deployment discussion References: <59246385-2673-e235-d625-0520edce457c@hit.bme.hu> In-Reply-To: <59246385-2673-e235-d625-0520edce457c@hit.bme.hu> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3610296279_1349641346" Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 May 2018 18:04:50 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3610296279_1349641346 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Lencse, =20 Thanks a lot for your inputs. =20 I=E2=80=99ve read all your papers. Nice job. =20 Do you feel I=E2=80=99m missing anything in the document? =20 I=E2=80=99m planning a revised version of this document in 2-3 days, so it = will be nice if the WG can provide any additional inputs. Regards, Jordi =20 =20 =20 De: v6ops en nombre de Lencse G=C3=A1bor Fecha: mi=C3=A9rcoles, 23 de mayo de 2018, 22:04 Para: Asunto: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion =20 Dear Fred and Jordi, I have read the draft and I think it is useful.=20 If I my put my two cents in, I would like to point out that we have come to= a very similar conclusion in Section 4.9 (titled "DNS and DNSSEC") of our = paper below to the one presented in Section 2 of the draft.=20 G. Lencse and Y. Kadobayashi, "Methodology for the identification of potent= ial security issues of different IPv6 transition technologies: Threat analy= sis of DNS64 and stateful NAT64", Computers & Security (Elsevier), vol. 77,= no. 1, pp. 397-411, September 1, 2018, DOI: 10.1016/j.cose.2018.04.012 Free access link valid until June 30: https://authors.elsevier.com/a/1X1K5c= 43ukegl Revised version is available freely (as green open access) from my list of = publications: http://www.hit.bme.hu/~lencse/publications/ Perhaps ISPs can use our benchmarking results when selecting DNS64 or NAT64= implementations. As for DNS64, we have up to date performance information, which may be some= what surprising concerning the performance problems of BIND. If you are int= erested, please check our results concerning the DNS64 performance of BIND,= PowerDNS and Unbound: G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theory a= nd Practice", Computer Communications (Elsevier), to be published Revised version is available freely (as green open access) from my list of = publications: http://www.hit.bme.hu/~lencse/publications/ As for stateful NAT64, we have only very old measurement results showing th= at OpenBSD PF outperformed TAYGA+iptables, which was not surprising at all,= but those measurements were not RFC 8219 compliant, as RFC 8219 did not ex= ist yet. Best regards, G=C3=A1bor =20 =20 =20 On 5/14/2018 4:07 AM, Fred Baker wrote: Considering https://tools.ietf.org/html/draft-palet-v6ops-nat64-deployment-= 00, discussed at IETF 101 using the slides at https://datatracker.ietf.org/= meeting/101/materials/slides-101-v6ops-nat64-deployment-guidelines-in-opera= tor-and-enterprise-networks-00. I'd like to invite discussion on the list. = What thoughts do folks have on this draft? =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** 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 con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3610296279_1349641346 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Lencse,

 

Thanks a lot for your inputs.

 

I=E2=80=99ve read all your papers. Nice job.

 

Do you feel I=E2=80=99m missing anyth= ing in the document?

 

<= p class=3DMsoNormal>I=E2=80=99m planning a revised version of this document in 2-3 days, so it= will be nice if the WG can provide any additional inputs.


Regards,

Jordi

 

 

 

De: v6ops <v6ops-bounces@ietf.org> en nombre de Lencse G=C3=A1b= or <lencse@hit.bme.hu>
Fecha: mi=C3=A9rcoles, 23 de mayo de= 2018, 22:04
Para: <v6ops@ietf.org>
Asunto: Re: [= v6ops] draft-palet-v6ops-nat64-deployment discussion

<= /div>

 

Dear Fred and Jordi,=

I have read the draft and I think it is= useful.

If I my put my two = cents in, I would like to point out that we have come to a very similar con= clusion in Section 4.9 (titled "DNS and DNSSEC") of our paper bel= ow to the one presented in Section 2 of the draft.

G. Lencse and Y. Kadobayashi, "Methodology for= the identification of potential security issues of different IPv6 transiti= on technologies: Threat analysis of DNS64 and stateful NAT64", Comp= uters & Security (Elsevier), vol. 77, no. 1, pp. 397-411, September= 1, 2018, DOI: 10.1016/j.cose.2018.04.012
Free access link valid until J= une 30: https://authors.elsevier.com/a/1X1K5c= 43ukegl
Revised version is available freely (as green open ac= cess) from my list of publications: http://www.hit.bme.hu/~lencse/publications/=

Perhaps ISPs can use our benchmarking r= esults when selecting DNS64 or NAT64 implementations.

As for DNS64, we have up to date performance infor= mation, which may be somewhat surprising concerning the performance problem= s of BIND. If you are interested, please check our results concerning the D= NS64 performance of BIND, PowerDNS and Unbound:

G. Lencse and Y. Kadobayashi, "= ;Benchmarking DNS64 Implementations: Theory and Practice", Computer= Communications (Elsevier), to be published

Revised version is available freely (as green open acces= s) from my list of publications: http://www.hit.bme.hu/~lencse/publications/

As for stateful NAT64, we have only very o= ld measurement results showing that OpenBSD PF outperformed TAYGA+iptables,= which was not surprising at all, but those measurements were not RFC 8219 = compliant, as RFC 8219 did not exist yet.

Best regards,

G= =C3=A1bor

 

 

 

On 5/14/2018 4:07 AM, Fred Baker wrote:=

= 
Considering https://tools.ietf.org/htm=
l/draft-palet-v6ops-nat64-deployment-00, discussed at IETF 101 using th=
e slides at https://datatracker.ietf.org/meeting/101/materials/slides-101-v6op=
s-nat64-deployment-guidelines-in-operator-and-enterprise-networks-00. I=
'd like to invite discussion on the list. What thoughts do folks have on th=
is draft?
 
 




_______________________________________________=

v6ops mailing list<=
/o:p>
v6ops@ietf.org
https://www.ietf.org/=
mailman/listinfo/v6ops


________________________________________= _______ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/list= info/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 con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3610296279_1349641346-- From nobody Mon May 28 01:57:46 2018 Return-Path: X-Original-To: v6ops@ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6CF126C22; Mon, 28 May 2018 01:57:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.80.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152749785803.4883.5078833393543247359@ietfa.amsl.com> Date: Mon, 28 May 2018 01:57:38 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 08:57:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations WG of the IETF. Title : Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity as-a-Service Authors : Jordi Palet Martinez Hans M.-H. Liu Masanobu Kawashima Filename : draft-ietf-v6ops-transition-ipv4aas-01.txt Pages : 19 Date : 2018-05-28 Abstract: This document specifies the IPv4 service continuity requirements for an IPv6 Customer Edge (CE) router, either provided by the service provider or thru the retail market. Specifically, this document extends the "Basic Requirements for IPv6 Customer Edge Routers" in order to allow the provisioning of IPv6 transition services for the support of "IPv4 as-a-Service" (IPv4aaS) by means of new transition mechanisms. The document only covers transition technologies for delivering IPv4 in IPv6-only access networks, commonly called "IPv4 as-a-Service" (IPv4aaS), as required in a world where IPv4 addresses are no longer available, so hosts in the customer LANs with IPv4-only or IPv6-only applications or devices, requiring to communicate with IPv4-only services at the Internet, are still able to do so. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-transition-ipv4aas-01 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-ipv4aas-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-transition-ipv4aas-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon May 28 02:07:06 2018 Return-Path: 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 78E49126579 for ; Mon, 28 May 2018 02:07:05 -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 Hk1mOqwqZrvl for ; Mon, 28 May 2018 02:07:02 -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 533781241F3 for ; Mon, 28 May 2018 02:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1527498420; x=1528103220; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:Mime-version: Content-type:Content-transfer-encoding; bh=OqDGnerkJIw8YLEt87kMb 5+a1agepy+etMhuIDrxfdw=; b=c1ca6pQnvIXsKsk+FaxmZ7vDkdoqQ9FjIzcrt Xx4YHY5d+VWuEF6hWbUTcnNs93EqS5QCmGe19M5F7SqL5wgQtuIxFvD/BS2mCeY8 G+juzh4jdEFmBytPBYLDO1SXzm7R/dbH3rx8J0AsIVG3u2SpuYh/fWvsZdbSz21p E2G+rs= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 28 May 2018 11:07:00 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 28 May 2018 11:07:00 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005778011.msg for ; Mon, 28 May 2018 11:06:59 +0200 X-MDRemoteIP: 2001:470:1f09:495:89fa:173c:3df6:bba6 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Mon, 28 May 2018 11:06:59 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1686b21113=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Mon, 28 May 2018 11:06:55 +0200 From: JORDI PALET MARTINEZ To: "STARK, BARBARA H" , V6 Ops List Message-ID: <82CAB96F-B0FB-4E6F-A8FB-094C424F514F@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 09:07:06 -0000 Hi Barbara, Sorry the late answer, last few weeks had been a non-stop traveling in 3 co= ntinents and too much work ... I see what you mean and we have discussed about this among the coauthors an= d amended the document, including some other comments received in the list. The new version has been published a few minutes ago: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/?inclu= de_text=3D1 Basically, we are keeping a MUST for retail product versions, but not for s= pecific ISP versions. I hope you agree with this, as we believe it makes se= nse. We don't update anymore the RFC7084, and we just use the same style to add = the requirements for an IPv6 Transition CE Router (and we use this terminol= ogy across all the document). The main changes are summarized in the Annex C: 1. ID-Nits: IANA section. 2. ID-Nits: RFC7084 reference removed from Abstract. 3. This document no longer updates RFC7084. 4. UPnP section reworded. 5. "CE Router" changed to "IPv6 Transition CE Router". 6. Reduced text in Annex A. Hopefully everybody agrees now with this version, and in any case, will be = very helpful if we can get any inputs. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de "STARK, BARBARA H" Fecha: lunes, 30 de abril de 2018, 19:20 Para: V6 Ops List Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-00.txt Hi Jordi, I was having a hard time understanding where you were headed with propo= sed changes, by following the email thread. So I was waiting for this updat= e. My company's email server also refuses to deliver to me some emails sent= to this list without telling me. That probably adds to my difficulty. =20 My suggestion related to making requirements "MUST" were tied to also *= not* making this an update to RFC 7084. =20 Here is the problem: If this is an update to RFC 7084, then I cannot support any "MUST" stat= ements. My employer makes use of RFC 7084. As is. Updating RFC 7084 with additi= onal "MUST" statements impacts my employer's ability to use and reference R= FC 7084 to get the CE routers it wants. An RFC 7084 update with "MUST" stat= ements (that are not needed by many current deployments) would be harmful t= o the existing IPv6 ecosystem. =20 For a device profile to be usable by the vendor and ISP community, it m= ust contain "MUST" statements for all items that need to be required to ach= ieve the profile's goal. Trying to get vendors to implement lots of "SHOULD= " statements is futile. As an individual contributor, I do not support IETF= publishing a futile device profile document with many "SHOULD" statements. =20 The solution I have proposed is to create a brand new device profile. A= device profile for something called an "IPv6 Transition CE Router". This d= evice profile is not an update to RFC 7084. It is its own thing. It is free= to make use of RFC 7084 any way it wants -- not at all, in whole, or by re= ferencing sections it does or doesn't want to require as part of the "IPv6 = Transition CE Router" device profile. Barbara =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** 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 con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Mon May 28 12:14:45 2018 Return-Path: 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 2E38D12D864 for ; Mon, 28 May 2018 12:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-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 vVstLxSx6igt for ; Mon, 28 May 2018 12:14:38 -0700 (PDT) Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E15CB12D77D for ; Mon, 28 May 2018 12:14:37 -0700 (PDT) Received: from [192.168.1.114] (host-79-121-42-83.kabelnet.hu [79.121.42.83]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id w4SJEJ5x036217 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 28 May 2018 21:14:27 +0200 (CEST) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-42-83.kabelnet.hu [79.121.42.83] claimed to be [192.168.1.114] From: =?UTF-8?Q?Lencse_G=c3=a1bor?= To: v6ops@ietf.org References: <59246385-2673-e235-d625-0520edce457c@hit.bme.hu> Message-ID: <0771c2f6-278d-fc8b-c6cc-b8139c54db42@hit.bme.hu> Date: Mon, 28 May 2018 21:14:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F376DC61BA0AB71EED233411" X-Virus-Scanned: clamav-milter 0.100.0 at frogstar.hit.bme.hu X-Virus-Status: Clean Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=79.121.42.83; helo=[192.168.1.114]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10; X-DCC--Metrics: frogstar.hit.bme.hu; whitelist X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44 Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 19:14:43 -0000 This is a multi-part message in MIME format. --------------F376DC61BA0AB71EED233411 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Dear Jordi, I would not say that anything is missing, but perhaps including some of our results about DNS64 would strengthen your draft. More specifically, I would suggest the following ones. You wrote in Section 2: [...] So, the recursive name server actually lie to the client device, however in most of the cases, the client will not notice it, because generally they don't perform validation themselves as instead rely on their recursive name servers. If the client device performs DNSSEC validation on the AAAA record, it will fail as it is a synthesized record. Here you may want to add something like: The best possible scenario from DNSSEC point of view is when the client requests the DNS64 server to perform the DNSSEC validation (by setting the DO bit to 1 and the CD bit to 0). In this case, the DNS64 server validates the data thus tampering may only happen inside the DNS64 server (which is considered as a trusted part, thus its likelihood is low) or between the DNS64 server and the client; all other parts of the system (including transmission and caching) are protected by DNSSEC. [1] And just one nit. You wrote in at the end of Section 2: [...] Previous data seems to indicate, that the figures of DNSSEC broken by using DNS64 will be around 1.7% (information 2 years old). It would be worth mentioning the source of this information. I think it is [2]. (We have taken the same information from there.) IMHO, the 100%-1.7%=98.3% of the domains with no DNSSEC also deserve some discussion. We have performed the threat analysis of a system, which uses DNS64 [1]. From the many identified threats, cache poisoning is perhaps the most important one. It was a hot issue about 10 years ago [3]. Fortunately, the major DNS servers implemented the countermeasures against cache poisoning recommended by RFC 5452. We have also confirmed it regarding BIND, PowerDNS and Unbound [1]. I think the readers of the future RFC would benefit from benchmarking results of different NAT64 implementations. We are planning to compare the performances of the following ones: - OpenBSD PF - TAYGA+iptables - Jool - Ecdysis We are going to start their stateless tests according to the dual DUT setup of RFC 8219 using an RFC 2544 compliant tester in June. We are also planning to benchmark them according to the single DUT setup of RFC 8219, but we need to wait for implementation of the Tester. (Unfortunately, I have no guarantee, when it will be ready, as it is done by one of my PhD students.) What is the planned time frame of your draft? I hope that our DNS64 server benchmarking results of BIND, PowerDNS and Unbound published in [4] may also be useful. (Perhaps the main performance numbers, the different scale up behaviors and the performance problem of BIND would be worth mentioning.) And the references are: [1] G. Lencse and Y. Kadobayashi, "Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 and stateful NAT64", /Computers & Security/ (Elsevier), vol. 77, no. 1, pp. 397-411, September 1, 2018, DOI: 10.1016/j.cose.2018.04.012 [2] J. Linkova, "Let’s talk about IPv6 DNS64 & DNSSEC", APNIC Blog (2016). https://blog.apnic.net/2016/06/09/lets-talk-ipv6-dns64-dnssec/ [3] CERT, “Multiple DNS implementations vulnerable to cache poisoning”, Vulnerability Note VU#800113 [Online]. Available: http://www.kb.cert.org/vuls/id/800113 [4] G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theory and Practice", /Computer Communications/ (Elsevier), in press, DOI: 10.1016/j.comcom.2018.05.005 So, what do you think of them? And I would be happy to receive some feedback from various operators, whether they can use our results. Or perhaps what else should we measure, examine, analyze concerning the IPv6 transition technologies? Best regards, Gábor 5/27/2018 8:04 PM keltezéssel, JORDI PALET MARTINEZ írta: > > Hi Lencse, > > Thanks a lot for your inputs. > > I’ve read all your papers. Nice job. > > Do you feel I’m missing anything in the document? > > I’m planning a revised version of this document in 2-3 days, so it > will be nice if the WG can provide any additional inputs. > > > Regards, > > Jordi > > *De: *v6ops en nombre de Lencse Gábor > > *Fecha: *miércoles, 23 de mayo de 2018, 22:04 > *Para: * > *Asunto: *Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion > > Dear Fred and Jordi, > > I have read the draft and I think it is useful. > > If I my put my two cents in, I would like to point out that we have > come to a very similar conclusion in Section 4.9 (titled "DNS and > DNSSEC") of our paper below to the one presented in Section 2 of the > draft. > > G. Lencse and Y. Kadobayashi, "Methodology for the identification of > potential security issues of different IPv6 transition technologies: > Threat analysis of DNS64 and stateful NAT64", /Computers & Security/ > (Elsevier), vol. 77, no. 1, pp. 397-411, September 1, 2018, DOI: > 10.1016/j.cose.2018.04.012 > Free access link valid until June 30: > https://authors.elsevier.com/a/1X1K5c43ukegl > Revised version is available freely (as green open access) from my > list of publications: http://www.hit.bme.hu/~lencse/publications/ > > > Perhaps ISPs can use our benchmarking results when selecting DNS64 or > NAT64 implementations. > > As for DNS64, we have up to date performance information, which may be > somewhat surprising concerning the performance problems of BIND. If > you are interested, please check our results concerning the DNS64 > performance of BIND, PowerDNS and Unbound: > > G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: > Theory and Practice", /Computer Communications/ (Elsevier), to be > published > > Revised version is available freely (as green open access) from my > list of publications: http://www.hit.bme.hu/~lencse/publications/ > > > As for stateful NAT64, we have only very old measurement results > showing that OpenBSD PF outperformed TAYGA+iptables, which was not > surprising at all, but those measurements were not RFC 8219 compliant, > as RFC 8219 did not exist yet. > > Best regards, > > Gábor > > On 5/14/2018 4:07 AM, Fred Baker wrote: > > Consideringhttps://tools.ietf.org/html/draft-palet-v6ops-nat64-deployment-00 > , discussed at IETF 101 using the slides athttps://datatracker.ietf.org/meeting/101/materials/slides-101-v6ops-nat64-deployment-guidelines-in-operator-and-enterprise-networks-00. I'd like to invite discussion on the list. What thoughts do folks have on this draft? > > > > > _______________________________________________ > > 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 --------------F376DC61BA0AB71EED233411 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Dear Jordi,

I would not say that anything is missing, but perhaps including some of our results about DNS64 would strengthen your draft. More specifically, I would suggest the following ones.

You wrote in Section 2:

   [...] So, the recursive name server actually
   lie to the client device, however in most of the cases, the client
   will not notice it, because generally they don't perform validation
   themselves as instead rely on their recursive name servers.

   If the client device performs DNSSEC validation on the AAAA record,
   it will fail as it is a synthesized record.

Here you may want to add something like:

The best possible scenario from DNSSEC point of view is when the client requests the DNS64 server to perform the DNSSEC validation (by setting the DO bit to 1 and the CD bit to 0). In this case, the DNS64 server validates the data thus tampering may only happen inside the DNS64 server (which is considered as a trusted part, thus its likelihood is low) or between the DNS64 server and the client; all other parts of the system (including transmission and caching)  are protected by DNSSEC. [1]


And just one nit. You wrote in at the end of Section 2:

   [...] Previous data seems to indicate, that
   the figures of DNSSEC broken by using DNS64 will be around 1.7%
   (information 2 years old).

It would be worth mentioning the source of this information. I think it is [2]. (We have taken the same information from there.)


IMHO, the 100%-1.7%=98.3% of the domains with no DNSSEC also deserve some discussion. We have performed the threat analysis of a system, which uses DNS64 [1]. From the many identified threats, cache poisoning is perhaps the most important one. It was a hot issue about 10 years ago [3]. Fortunately, the major DNS servers implemented the countermeasures against cache poisoning recommended by RFC 5452. We have also confirmed it regarding BIND, PowerDNS and Unbound [1].


I think the readers of the future RFC would benefit from benchmarking results of different NAT64 implementations. We are planning to compare the performances of the following ones:
- OpenBSD PF
- TAYGA+iptables
- Jool
- Ecdysis
We are going to start their stateless tests according to the dual DUT setup of RFC 8219 using an RFC 2544 compliant tester in June.
We are also planning to benchmark them  according to the single DUT setup of RFC 8219, but we need to wait for implementation of the Tester. (Unfortunately, I have no guarantee, when it will be ready, as it is done by one of my PhD students.)

What is the planned time frame of your draft?


I hope that our DNS64 server benchmarking results of BIND, PowerDNS and Unbound published in [4] may also be useful. (Perhaps the main performance numbers, the different scale up behaviors and the performance problem of BIND would be worth mentioning.)

And the references are:
 
[1] G. Lencse and Y. Kadobayashi, "Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 and stateful NAT64", Computers & Security (Elsevier), vol. 77, no. 1, pp. 397-411, September 1, 2018, DOI: 10.1016/j.cose.2018.04.012

[2] J. Linkova, "Let’s talk about IPv6 DNS64 & DNSSEC", APNIC Blog (2016). https://blog.apnic.net/2016/06/09/lets-talk-ipv6-dns64-dnssec/

[3] CERT, “Multiple DNS implementations vulnerable to cache poisoning”, Vulnerability Note VU#800113 [Online].
Available: http://www.kb.cert.org/vuls/id/800113

[4] G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theory and Practice", Computer Communications (Elsevier), in press, DOI: 10.1016/j.comcom.2018.05.005


So, what do you think of them?


And I would be happy to receive some feedback from various operators, whether they can use our results. Or perhaps what else should we measure, examine, analyze concerning the IPv6 transition technologies?

Best regards,

Gábor


5/27/2018 8:04 PM keltezéssel, JORDI PALET MARTINEZ írta:

Hi Lencse,

 

Thanks a lot for your inputs.

 

I’ve read all your papers. Nice job.

 

Do you feel I’m missing anything in the document?

 

I’m planning a revised version of this document in 2-3 days, so it will be nice if the WG can provide any additional inputs.


Regards,

Jordi

 

 

 

De: v6ops <v6ops-bounces@ietf.org> en nombre de Lencse Gábor <lencse@hit.bme.hu>
Fecha: miércoles, 23 de mayo de 2018, 22:04
Para: <v6ops@ietf.org>
Asunto: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion

 

Dear Fred and Jordi,

I have read the draft and I think it is useful.

If I my put my two cents in, I would like to point out that we have come to a very similar conclusion in Section 4.9 (titled "DNS and DNSSEC") of our paper below to the one presented in Section 2 of the draft.

G. Lencse and Y. Kadobayashi, "Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 and stateful NAT64", Computers & Security (Elsevier), vol. 77, no. 1, pp. 397-411, September 1, 2018, DOI: 10.1016/j.cose.2018.04.012
Free access link valid until June 30: https://authors.elsevier.com/a/1X1K5c43ukegl
Revised version is available freely (as green open access) from my list of publications: http://www.hit.bme.hu/~lencse/publications/

Perhaps ISPs can use our benchmarking results when selecting DNS64 or NAT64 implementations.

As for DNS64, we have up to date performance information, which may be somewhat surprising concerning the performance problems of BIND. If you are interested, please check our results concerning the DNS64 performance of BIND, PowerDNS and Unbound:

G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theory and Practice", Computer Communications (Elsevier), to be published

Revised version is available freely (as green open access) from my list of publications: http://www.hit.bme.hu/~lencse/publications/

As for stateful NAT64, we have only very old measurement results showing that OpenBSD PF outperformed TAYGA+iptables, which was not surprising at all, but those measurements were not RFC 8219 compliant, as RFC 8219 did not exist yet.

Best regards,

Gábor

 

 

 

On 5/14/2018 4:07 AM, Fred Baker wrote:

Considering https://tools.ietf.org/html/draft-palet-v6ops-nat64-deployment-00, discussed at IETF 101 using the slides at https://datatracker.ietf.org/meeting/101/materials/slides-101-v6ops-nat64-deployment-guidelines-in-operator-and-enterprise-networks-00. I'd like to invite discussion on the list. What thoughts do folks have on this draft?
 
 




_______________________________________________
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

--------------F376DC61BA0AB71EED233411-- From nobody Tue May 29 08:04:08 2018 Return-Path: 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 884BF1200E5; Tue, 29 May 2018 08:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 vb38Phm6uvAt; Tue, 29 May 2018 08:04:04 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B932127876; Tue, 29 May 2018 08:04:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1438; q=dns/txt; s=iport; t=1527606243; x=1528815843; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=zFe5qNGMYL97xmmr4WUZHxuN7cUONV0TnWgY09sArno=; b=dpWVA7sy9YAHkl8WqOAz4psbXy2TGU4RkWpPFSHhskSIo4ZtxKs3GXPM zxel3tGGp+ulnTWmjcZPFzjN+PzvL3AV363rEAPa97fMZKopq69xxxYqP kh+ihpGGmvshoN63YedAtg8XD5TRsSnX95yC9EqiJxFjgNBQ4t9J4AzW1 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BwAQDlag1b/4ENJK1bGwEBAQEDAQE?= =?us-ascii?q?BCQEBAYNEYn8oCoNtiASMa4MIkzuBeAsjhEkZggAhNBgBAgEBAQEBAQJsHAy?= =?us-ascii?q?FKQYjETcDHQEIGgImAgQwFQYBBgUEARKDIgKBfw+lOIIciD2BYwWBCYctgVQ?= =?us-ascii?q?/gQ8kgmmDEQIDAYFzgmkwgiQCmGIJAoVqiHSBO4Nvgl+EfYlshngCERMBgSQ?= =?us-ascii?q?dOIFScBU7KgGCGIsQhT5vjk6BGQEB?= X-IronPort-AV: E=Sophos;i="5.49,456,1520899200"; d="scan'208";a="400579283" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 May 2018 15:04:01 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id w4TF41oq005250 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 29 May 2018 15:04:01 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 29 May 2018 11:04:00 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Tue, 29 May 2018 11:04:00 -0400 From: "Eric Vyncke (evyncke)" To: "opsec@ietf.org" , "v6ops@ietf.org" , "ipv6@ietf.org" Thread-Topic: IETF WG state changed for draft-ietf-opsec-ipv6-eh-filtering for 2 weeks Thread-Index: AQHT915GWqTo08UY5EiI+u6439n7Ow== Date: Tue, 29 May 2018 15:04:00 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.56.3] Content-Type: text/plain; charset="utf-8" Content-ID: <122F888D35948D479CB1FDC9E2C70EC6@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [v6ops] FW: IETF WG state changed for draft-ietf-opsec-ipv6-eh-filtering for 2 weeks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 15:04:07 -0000 W1NlbnQgdG8gT1BTRUMsIDZNQU4gYW5kIFY2T1BTIG1haWxpbmcgbGlzdF0NCg0KQXMgZGlzY3Vz c2VkIGF0IG91ciBsYXN0IE9TUEVDIFdHIG1lZXRpbmcsIHRoaXMgaXMgdG8gb3BlbiBhIHR3by13 ZWVrIFdHTEMgZm9yOg0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtb3BzZWMtaXB2Ni1laC1maWx0ZXJpbmcvDQoNCklmIHlvdSBoYXZlIG5vdCByZWFkIGl0 LCBwbGVhc2UgZG8gc28gbm93LiBZb3UgbWF5IHNlbmQgbml0cyB0byB0aGUgYXV0aG9yLCBidXQg c3Vic3RhbnRpdmUgZGlzY3Vzc2lvbiBzaG91bGQgZ28gdG8gdGhlIG9wc2VjQGlldGYub3JnIGxp c3QuDQoNCihXaGlsZSBWNk9QUyAmIDZNQU4gV0cgYXJlIGluIGNjIGJlY2F1c2Ugb2YgY2xvc2Ug YWxpZ25tZW50IHdpdGggdGhlIFdHIGV4cGVydGlzZSBhcmVhLCBtYXkgd2UgYXNrIHRvIHNlbmQg ZmVlZGJhY2sgYW5kIGNvbW1lbnRzIGluIHRoZSBPUFNFQyBXRyA/KQ0KIA0KV2Ugd2lsbCBjbG9z ZSB0aGUgY2FsbCBvbiAxMiBKdW5lIDIwMTguDQoNCkJlc3QgcmVnYXJkcywNCg0KLcOpcmljICYg LXJvbiAoT1BTRUMgV0cgY28tY2hhaXJzKQ0KDQpPbiAyOS8wNS8xOCAxNjoyMSwgIklFVEYgU2Vj cmV0YXJpYXQiIDxpZXRmLXNlY3JldGFyaWF0LXJlcGx5QGlldGYub3JnPiB3cm90ZToNCg0KICAg IA0KICAgIFRoZSBJRVRGIFdHIHN0YXRlIG9mIGRyYWZ0LWlldGYtb3BzZWMtaXB2Ni1laC1maWx0 ZXJpbmcgaGFzIGJlZW4gY2hhbmdlZCB0bw0KICAgICJJbiBXRyBMYXN0IENhbGwiIGZyb20gIldH IERvY3VtZW50IiBieSDDiXJpYyBWeW5ja2U6DQogICAgDQogICAgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vcHNlYy1pcHY2LWVoLWZpbHRlcmluZy8NCiAgICAN CiAgICBDb21tZW50Og0KICAgIFRoZSBjb25zZW5zdXMgYXQgSUVURi0xMDEgbWVldGluZyB3YXMg dGhhdCB0aGUgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIFdHTEMuDQogICAgU28sIGxldCdzIG9wZW4g YSAyLXdlZWsgV0dMQy4NCiAgICANCg0K From nobody Tue May 29 09:37:51 2018 Return-Path: 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 66009126C25 for ; Tue, 29 May 2018 09:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, URIBL_BLOCKED=0.001] 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 cHMO8wGcqy7r for ; Tue, 29 May 2018 09:37:46 -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 D77261200FC for ; Tue, 29 May 2018 09:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1527611862; x=1528216662; 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; bh=GtW0WGjoEfq00T2QTyuGqdIFC8M0n0wjlI EbARncf80=; b=TBWPp0XuhF5X3F1vn2Yi3VBn4XEt65OtopdgEyPxKmRZP2ahpB T9kfDgZCKBSdxeVeGPTniB/GyOyOUTaInaJUGGCmy4Qy1X5irNCNqPV7q8AcLkfg KyzB5rotCIgR7Zy100iWyvz9rrkbSVao8fVSvAQEXSaGP3wLAOEYmu4uk= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 29 May 2018 18:37:42 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 29 May 2018 18:37:40 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005778845.msg for ; Tue, 29 May 2018 18:37:40 +0200 X-MDRemoteIP: 2001:470:1f09:495:1460:3c71:b029:a129 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Tue, 29 May 2018 18:37:40 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=168717744b=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Tue, 29 May 2018 18:37:36 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <848D8244-7726-4152-B6B0-0AC8A80C56E6@consulintel.es> Thread-Topic: [v6ops] draft-palet-v6ops-nat64-deployment discussion References: <59246385-2673-e235-d625-0520edce457c@hit.bme.hu> <0771c2f6-278d-fc8b-c6cc-b8139c54db42@hit.bme.hu> In-Reply-To: <0771c2f6-278d-fc8b-c6cc-b8139c54db42@hit.bme.hu> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3610463856_136514311" Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 16:37:50 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3610463856_136514311 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Gabor, =20 I=E2=80=99ve included your suggested text for section 2 and the references = 1 & 2. Thanks! =20 I=E2=80=99m trying to finish today a new version as I=E2=80=99m also taking= care of some ID-Nits that will announce to the list. =20 See below, in line some more responses. Saludos, Jordi =20 =20 =20 De: v6ops en nombre de Lencse G=C3=A1bor Fecha: lunes, 28 de mayo de 2018, 21:15 Para: Asunto: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion =20 Dear Jordi, I would not say that anything is missing, but perhaps including some of our= results about DNS64 would strengthen your draft. More specifically, I woul= d suggest the following ones. You wrote in Section 2: =C2=A0=C2=A0 [...] So, the recursive name server actually =C2=A0=C2=A0lie to the client device, however in most of the cases, the cl= ient =C2=A0=C2=A0 will not notice it, because generally they don't perform valid= ation =C2=A0=C2=A0 themselves as instead rely on their recursive name servers. =20 =C2=A0=C2=A0 If the client device performs DNSSEC validation on the AAAA re= cord, =C2=A0=C2=A0 it will fail as it is a synthesized record. Here you may want to add something like: The best possible scenario from DNSSEC point of view is when the client req= uests the DNS64 server to perform the DNSSEC validation (by setting the DO = bit to 1 and the CD bit to 0). In this case, the DNS64 server validates the= data thus tampering may only happen inside the DNS64 server (which is cons= idered as a trusted part, thus its likelihood is low) or between the DNS64 = server and the client; all other parts of the system (including transmissio= n and caching) are protected by DNSSEC. [1] And just one nit. You wrote in at the end of Section 2: =C2=A0=C2=A0 [...] Previous data seems to indicate, that =C2=A0=C2=A0 the figures of DNSSEC broken by using DNS64 will be around 1.7= % =C2=A0=C2=A0 (information 2 years old). It would be worth mentioning the source of this information. I think it is = [2]. (We have taken the same information from there.) IMHO, the 100%-1.7%=3D98.3% of the domains with no DNSSEC also deserve some= discussion. We have performed the threat analysis of a system, which uses = DNS64 [1]. From the many identified threats, cache poisoning is perhaps the= most important one. It was a hot issue about 10 years ago [3]. Fortunately= , the major DNS servers implemented the countermeasures against cache poiso= ning recommended by RFC 5452. We have also confirmed it regarding BIND, Pow= erDNS and Unbound [1]. [Jordi] I think it will make sense to have one specific RFC based in your = =E2=80=9CThreat analysis of DNS64 and stateful NAT64=E2=80=9D. Probably als= o one more with the benchmarking. It has been done in IETF many times, but = not for NAT64 and DNS64. I think the readers of the future RFC would benefit from benchmarking resul= ts of different NAT64 implementations. We are planning to compare the perfo= rmances of the following ones: - OpenBSD PF - TAYGA+iptables - Jool - Ecdysis We are going to start their stateless tests according to the dual DUT setup= of RFC 8219 using an RFC 2544 compliant tester in June.=20 We are also planning to benchmark them according to the single DUT setup o= f RFC 8219, but we need to wait for implementation of the Tester. (Unfortun= ately, I have no guarantee, when it will be ready, as it is done by one of = my PhD students.) What is the planned time frame of your draft?=20 [Jordi] Agree, it will be good to have the benchmarking. I=E2=80=99m using = mainly Jool with either Ubuntu or OpenWRT, and very happy. Regarding the ID= timing, is really difficult to say. As you know, only you actually said pu= blicly that this is something useful, and this means is difficult to get it= adopted as WG item, which will be the first step =E2=80=A6 If you have res= ults that we can include in the document I will be happy to consider it, bu= t do not worry too much because you can always work in a new specific ID. I hope that our DNS64 server benchmarking results of BIND, PowerDNS and Unb= ound published in [4] may also be useful. (Perhaps the main performance num= bers, the different scale up behaviors and the performance problem of BIND = would be worth mentioning.) And the references are: =20 [1] G. Lencse and Y. Kadobayashi, "Methodology for the identification of po= tential security issues of different IPv6 transition technologies: Threat a= nalysis of DNS64 and stateful NAT64", Computers & Security (Elsevier), vol.= 77, no. 1, pp. 397-411, September 1, 2018, DOI: 10.1016/j.cose.2018.04.012 [2] J. Linkova, "Let=E2=80=99s talk about IPv6 DNS64 & DNSSEC", APNIC Blog = (2016). https://blog.apnic.net/2016/06/09/lets-talk-ipv6-dns64-dnssec/ [3] CERT, =E2=80=9CMultiple DNS implementations vulnerable to cache poisoni= ng=E2=80=9D, Vulnerability Note VU#800113 [Online].=20 Available: http://www.kb.cert.org/vuls/id/800113=20 [4] G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theo= ry and Practice", Computer Communications (Elsevier), in press, DOI: 10.101= 6/j.comcom.2018.05.005 So, what do you think of them? [Jordi] I=E2=80=99ve read all your documents, a quick read at the moment, a= nd definitively I will invest more time during the weekend to read them. And I would be happy to receive some feedback from various operators, wheth= er they can use our results. Or perhaps what else should we measure, examin= e, analyze concerning the IPv6 transition technologies? [Jordi] I will suggest that you open a new thread in v6ops to encourage peo= ple to read your documents (When you ask them to contribute at the end of a= n email about my ID, probably the end of your email is not being read =E2= =80=A6), I think they are really useful, and may be look for people interes= ted in contributing to that work as well, or even possible co-authors for I= Ds (I will be happy to contribute depending on my workload =E2=80=A6). We n= eed to check if this is in the scope of v6ops or if there are other more ap= propriate WGs. Best regards, G=C3=A1bor 5/27/2018 8:04 PM keltez=C3=A9ssel, JORDI PALET MARTINEZ =C3=ADrta: Hi Lencse, =20 Thanks a lot for your inputs. =20 I=E2=80=99ve read all your papers. Nice job. =20 Do you feel I=E2=80=99m missing anything in the document? =20 I=E2=80=99m planning a revised version of this document in 2-3 days, so it = will be nice if the WG can provide any additional inputs. Regards, Jordi =20 =20 =20 De: v6ops en nombre de Lencse G=C3=A1bor Fecha: mi=C3=A9rcoles, 23 de mayo de 2018, 22:04 Para: Asunto: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion =20 Dear Fred and Jordi, I have read the draft and I think it is useful.=20 If I my put my two cents in, I would like to point out that we have come to= a very similar conclusion in Section 4.9 (titled "DNS and DNSSEC") of our = paper below to the one presented in Section 2 of the draft.=20 G. Lencse and Y. Kadobayashi, "Methodology for the identification of potent= ial security issues of different IPv6 transition technologies: Threat analy= sis of DNS64 and stateful NAT64", Computers & Security (Elsevier), vol. 77,= no. 1, pp. 397-411, September 1, 2018, DOI: 10.1016/j.cose.2018.04.012 Free access link valid until June 30: https://authors.elsevier.com/a/1X1K5c= 43ukegl Revised version is available freely (as green open access) from my list of = publications: http://www.hit.bme.hu/~lencse/publications/ Perhaps ISPs can use our benchmarking results when selecting DNS64 or NAT64= implementations. As for DNS64, we have up to date performance information, which may be some= what surprising concerning the performance problems of BIND. If you are int= erested, please check our results concerning the DNS64 performance of BIND,= PowerDNS and Unbound: G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theory a= nd Practice", Computer Communications (Elsevier), to be published Revised version is available freely (as green open access) from my list of = publications: http://www.hit.bme.hu/~lencse/publications/ As for stateful NAT64, we have only very old measurement results showing th= at OpenBSD PF outperformed TAYGA+iptables, which was not surprising at all,= but those measurements were not RFC 8219 compliant, as RFC 8219 did not ex= ist yet. Best regards, G=C3=A1bor =20 =20 =20 On 5/14/2018 4:07 AM, Fred Baker wrote: Considering https://tools.ietf.org/html/draft-palet-v6ops-nat64-deployment-= 00, discussed at IETF 101 using the slides at https://datatracker.ietf.org/= meeting/101/materials/slides-101-v6ops-nat64-deployment-guidelines-in-opera= tor-and-enterprise-networks-00. I'd like to invite discussion on the list. = What thoughts do folks have on this draft? =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** 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 con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ie= tf.org https://www.ietf.org/mailman/listinfo/v6ops=20 ********************************************** 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 con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. --B_3610463856_136514311 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Gabor,

 

I=E2=80=99ve included your suggested text for sec= tion 2 and the references 1 & 2. Thanks!

&= nbsp;

I=E2=80=99m trying to finish today a new version as= I=E2=80=99m also taking care of some ID-Nits that will announce to the lis= t.

 

= See below, in line = some more responses.


Saludos,

Jordi

 

 

 

De: v6ops <v6ops-bounces@ietf= .org> en nombre de Lencse G=C3=A1bor <lencse@hit.bme.hu>
Fec= ha: lunes, 28 de mayo de 2018, 21:15
Para: <v6ops@ietf.org= >
Asunto: Re: [v6ops] draft-palet-v6ops-nat64-deployment discu= ssion

 

Dear Jordi,

I would not say that anything is missing, but perhaps i= ncluding some of our results about DNS64 would strengthen your draft. More = specifically, I would suggest the following ones.

You wrote in Secti= on 2:

=C2=A0=C2=A0 [...] So=
, the recursive name server actually
 =C2=A0=C2=A0lie to the client device, however in most of the c=
ases, the client
=C2=A0=
=C2=A0 will not notice it, because generally they don't perform validation<=
o:p>
=C2=A0=C2=A0 themselves a=
s instead rely on their recursive name servers.

 

=C2=A0=C2=A0 If the client device performs DNSSEC valida=
tion on the AAAA record,
=
=C2=A0=C2=A0 it will fail as it is a synthesized record.

Here you may want to add something li= ke:

The best possible scenario from DNSSEC point of view is when the= client requests the DNS64 server to perform the DNSSEC validation (by sett= ing the DO bit to 1 and the CD bit to 0). In this case, the DNS64 server va= lidates the data thus tampering may only happen inside the DNS64 server (wh= ich is considered as a trusted part, thus its likelihood is low) or between= the DNS64 server and the client; all other parts of the system (including = transmission and caching)  are protected by DNSSEC. [1]


And= just one nit. You wrote in at the end of Section 2:

=C2=A0=C2=A0 [...] Previous data seems to indicate, that
=C2=A0=C2=A0 the figures of DNSSE=
C broken by using DNS64 will be around 1.7%
=C2=A0=C2=A0 (information 2 years old).
=


It would be worth mentioning the so= urce of this information. I think it is [2]. (We have taken the same inform= ation from there.)


IMHO, the 100%-1.7%=3D98.3% of the domains wi= th no DNSSEC also deserve some discussion. We have performed the threat ana= lysis of a system, which uses DNS64 [1]. From the many identified threats, = cache poisoning is perhaps the most important one. It was a hot issue about= 10 years ago [3]. Fortunately, the major DNS servers implemented the count= ermeasures against cache poisoning recommended by RFC 5452. We have also co= nfirmed it regarding BIND, PowerDNS and Unbound [1].

[Jordi] I th= ink it will make sense to have one specific RFC based in your =E2=80=9CThre= at analysis of DNS64 and stateful NAT64=E2=80=9D. Probably also one more wi= th the benchmarking. It has been done in IETF many times, but not for NAT64= and DNS64.



I think the readers of the future RFC would benefit fr= om benchmarking results of different NAT64 implementations. We are p= lanning to compare the performances of the following ones:
- OpenBSD PF<= br>- TAYGA+iptables
- Jool
- Ecdysis
We are going to start their s= tateless tests according to the dual DUT setup of RFC 8219 using an RFC 254= 4 compliant tester in June.
We are also planning to benchmark them = ; according to the single DUT setup of RFC 8219, but we need to wait for im= plementation of the Tester. (Unfortunately, I have no guarantee, when it wi= ll be ready, as it is done by one of my PhD students.)

What is the p= lanned time frame of your draft?

[Jordi] Agree, it will = be good to have the benchmarking. I=E2=80=99m using mainly Jool with either= Ubuntu or OpenWRT, and very happy. Regarding the ID timing, is really diff= icult to say. As you know, only you actually said publicly that this is som= ething useful, and this means is difficult to get it adopted as WG item, wh= ich will be the first step =E2=80=A6 If you have results that we can includ= e in the document I will be happy to consider it, but do not worry too much= because you can always work in a new specific ID.



I hope that our= DNS64 server benchmarking results of BIND, PowerDNS and Unbound published = in [4] may also be useful. (Perhaps the main performance numbers, th= e different scale up behaviors and the performance problem of BIND would be= worth mentioning.)

And the references are:
 
[1] G. Len= cse and Y. Kadobayashi, "Methodology for the identification of potenti= al security issues of different IPv6 transition technologies: Threat analys= is of DNS64 and stateful NAT64", Computers & Security (Else= vier), vol. 77, no. 1, pp. 397-411, September 1, 2018, DOI: 10.1016/j.cose.= 2018.04.012

[2] J. Linkova, "Let=E2=80=99s talk about IPv6 DNS6= 4 & DNSSEC", APNIC Blog (2016). https://blog.apnic.net/2016/06/09/= lets-talk-ipv6-dns64-dnssec/

[3] CERT, =E2=80=9CMultiple DNS imp= lementations vulnerable to cache poisoning=E2=80=9D, Vulnerability Note VU#= 800113 [Online].
Available: http://www.kb.cert.org/vuls/id/800113

[4] G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theory and Pra= ctice", Computer Communications (Elsevier), in press, DOI: 10.1= 016/j.comcom.2018.05.005


So, what do you think of them?

<= br>

[Jordi] I=E2=80=99ve read all your documents, a quick read at= the moment, and definitively I will invest more time during the weekend to= read them.


And I would be happy to receive some feedback from various= operators, whether they can use our results. Or perhaps what else s= hould we measure, examine, analyze concerning the IPv6 transition technolog= ies?

[Jordi] I will suggest that you open a new thread in= v6ops to encourage people to read your documents (When you ask them to con= tribute at the end of an email about my ID, probably the end of your email = is not being read =E2=80=A6), I think they are really useful, and may be lo= ok for people interested in contributing to that work as well, or even poss= ible co-authors for IDs (I will be happy to contribute depending on my work= load =E2=80=A6). We need to check if this is in the scope of v6ops or if th= ere are other more appropriate WGs.


Best regards,

G=C3= =A1bor

5/27/2018 8:04 PM keltez=C3=A9ssel, JORDI PALET MARTINEZ =C3=ADrta= :

Hi Lencse,

 

Thanks a lot for your inputs.

 

I=E2=80=99ve read all your papers. Nice job.

 

Do you feel I=E2=80=99m missing anything in the document?=

 

<= p class=3DMsoNormal style=3D'margin-left:35.4pt'>I=E2=80=99m planning a revised version of t= his document in 2-3 days, so it will be nice if the WG can provide any addi= tional inputs.

<= br>Regar= ds,

Jo= rdi

 <= /o:p>

 

 

De: v6ops <v6ops-bounces@ietf.org> en no= mbre de Lencse G=C3=A1bor <lencse@h= it.bme.hu>
Fecha: mi=C3=A9rcoles, 23 de mayo de 2018, 22:0= 4
Para: <v6ops@ietf.org><= /a>
Asunto: Re: [v6ops] draft-palet-v6ops-nat64-deployment discus= sion

Dear= Fred and Jordi,

I have read = the draft and I think it is useful.

If I my put my two cents in, I would like to point out that we have= come to a very similar conclusion in Section 4.9 (titled "DNS and DNS= SEC") of our paper below to the one presented in Section 2 of the draf= t.

G. Lencse and Y. Kadobaya= shi, "Methodology for the identification of potential security issues = of different IPv6 transition technologies: Threat analysis of DNS64 and sta= teful NAT64", Computers & Security (Elsevier), vol. 77, no.= 1, pp. 397-411, September 1, 2018, DOI: 10.1016/j.cose.2018.04.012
Free= access link valid until June 30: https://aut= hors.elsevier.com/a/1X1K5c43ukegl
Revised version is availabl= e freely (as green open access) from my list of publications: http://www.hit.bme.hu/~lencse/= publications/

Perhaps ISP= s can use our benchmarking results when selecting DNS64 or NAT64 implementa= tions.

As for DNS64, we have = up to date performance information, which may be somewhat surprising concer= ning the performance problems of BIND. If you are interested, please check = our results concerning the DNS64 performance of BIND, PowerDNS and Unbound:=

G. Lencse and Y. Kadobayashi= , "Benchmarking DNS64 Implementations: Theory and Practice", C= omputer Communications (Elsevier), to be published

Revised version is available freely (as green ope= n access) from my list of publications: http://www.hit.bme.hu/~lencse/publications/=

As for stateful NAT64, we have on= ly very old measurement results showing that OpenBSD PF outperformed TAYGA+= iptables, which was not surprising at all, but those measurements were not = RFC 8219 compliant, as RFC 8219 did not exist yet.

Best regards,

G=C3=A1bor

 

 

 

On 5/14/2018 4:07 AM, Fred Baker= wrote:

Considering https://tools=
.ietf.org/html/draft-palet-v6ops-nat64-deployment-00, discussed at IETF=
 101 using the slides at https://datatracker.ietf.org/meeting/101/materials/sl=
ides-101-v6ops-nat64-deployment-guidelines-in-operator-and-enterprise-netwo=
rks-00. I'd like to invite discussion on the list. What thoughts do fol=
ks have on this draft?
 
 

<= br>


___________=
____________________________________
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 th= e new Internet ?
http://www.consul= intel.es
The IPv6 Company

This electronic message contains in= formation which may be privileged or confidential. The information is inten= ded to be for the exclusive use of the individual(s) named above and furthe= r 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 a= re not the intended recipient be aware that any disclosure, copying, distri= bution or use of the contents of this information, even if partially, inclu= ding attached files, is strictly prohibited, will be considered a criminal = offense, so you must reply to the original sender to inform about this comm= unication and delete it.




_______________________________________________
v6ops mailing list
v6ops@=
ietf.org
https://www.ietf.org/mailman/li=
stinfo/v6ops


_______________________________________________ v6= ops 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 con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it.

--B_3610463856_136514311-- From nobody Tue May 29 10:27:46 2018 Return-Path: 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 0235E126B6E for ; Tue, 29 May 2018 10:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] 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 k3IvL2XnugDM for ; Tue, 29 May 2018 10:27:43 -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 F0DF712DA22 for ; Tue, 29 May 2018 10:27:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1527614861; x=1528219661; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:Mime-version: Content-type:Content-transfer-encoding; bh=bd93rMchw+oI0dAU1auLM CycZhBn+GbRQcnfI44cRCc=; b=cInpRflPUrfiZa0XxKVulCXJsgJRvLbyQKBV4 QTfRjOZYy/E1oGpomlFklebniRw3OYYvyzOakszWYJuNYdawfKiS1d3OeToBPkVo IsK7mQ/pIvOSaZfRLqr7pc2v6KTuK95lT/LDh1inodPo9Jc5CnDV6JVIv7iEeIA3 MIZ0qA= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 29 May 2018 19:27:41 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 29 May 2018 19:27:41 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005778867.msg for ; Tue, 29 May 2018 19:27:40 +0200 X-MDRemoteIP: 2001:470:1f09:495:1460:3c71:b029:a129 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Tue, 29 May 2018 19:27:40 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=168717744b=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Tue, 29 May 2018 19:27:37 +0200 From: JORDI PALET MARTINEZ To: V6 Ops List Message-ID: <2570737B-B16A-481B-BD06-C81A4FAAA90C@consulintel.es> Thread-Topic: new version of draft-palet-v6ops-nat64-deployment Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: [v6ops] new version of draft-palet-v6ops-nat64-deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 17:27:45 -0000 Hi all, I've updated this document. Main changes are ID-Nits, updated a couple of reference and suggestions by = Gabor. Hopefully some other folks can read it and contribute. https://datatracker.ietf.org/doc/draft-palet-v6ops-nat64-deployment/?includ= e_text=3D1=EF=BB=BF Regards, Jordi =20 =20 ********************************************** 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 con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Tue May 29 10:50:47 2018 Return-Path: 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 336F012EB54 for ; Tue, 29 May 2018 10:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] 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 gvNGg9g1fN57 for ; Tue, 29 May 2018 10:50:18 -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 EC2BC12EBC2 for ; Tue, 29 May 2018 10:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1527616216; x=1528221016; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:Mime-version: Content-type:Content-transfer-encoding; bh=kfUqVAvKjbhNJpzDaaRTB mkocB2diGt1pjWe0rFb3BM=; b=rCynCGaGWTlrEHAFcwrXTVUNmzRVNbKvGWrKj 0BYgf51W88HX776ol0J294hTMpMnRtJhA6CWa3cgf6Oh89Vv6L/TvanPZiqaUR+U psnzNqhYJXKP7+sC06tyjO1zhbdzzD1mRiwtuHUXru4MQffzwBPdLTL1fKlbvYpR uWYBNo= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 29 May 2018 19:50:16 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 29 May 2018 19:50:16 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005778879.msg for ; Tue, 29 May 2018 19:50:15 +0200 X-MDRemoteIP: 2001:470:1f09:495:1460:3c71:b029:a129 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Tue, 29 May 2018 19:50:15 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=168717744b=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Tue, 29 May 2018 19:50:12 +0200 From: JORDI PALET MARTINEZ To: V6 Ops List Message-ID: <6C1F4805-8E6B-48F8-AC14-1DD67E14399E@consulintel.es> Thread-Topic: draft-palet-v6ops-p2p-links Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: [v6ops] draft-palet-v6ops-p2p-links X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 17:50:37 -0000 Hi, I've updated this document: https://datatracker.ietf.org/doc/draft-palet-v6ops-p2p-links/?include_text= =3D1 =EF=BB=BF It will be nice to get some inputs. Regards, Jordi =20 =20 ********************************************** 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 con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Tue May 29 10:57:54 2018 Return-Path: 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 3DC41126B6D for ; Tue, 29 May 2018 10:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=EGU2Yo9y; dkim=pass (1024-bit key) header.d=yitter.info header.b=jelxWfoM 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 ZlrMWeFYvH3N for ; Tue, 29 May 2018 10:57:49 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D757120047 for ; Tue, 29 May 2018 10:57:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id A1608BDEF9 for ; Tue, 29 May 2018 17:57:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1527616638; bh=amWTD07WT1m9g2xs2u+KeKqQ1HODgw8mT6+nfWLav3U=; h=Date:From:To:Subject:References:In-Reply-To:From; b=EGU2Yo9y2RgjurOMaAVOJIEjupbC+Cr4pygFsIO7oQlmuHljUj5LDfnm2L7vSphsj KQQloOc7cUOxfmZYyuxyo1R4AGwS5MxR4SaWQp57A09kwYEqGVRACy2J4hLp17txiG 7eU9DAtpdGWAvvW3ml8XjEcHBWvUAahjRAS8Lang= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wY3t0jQBZc6n for ; Tue, 29 May 2018 17:57:12 +0000 (UTC) Date: Tue, 29 May 2018 13:57:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1527616631; bh=amWTD07WT1m9g2xs2u+KeKqQ1HODgw8mT6+nfWLav3U=; h=Date:From:To:Subject:References:In-Reply-To:From; b=jelxWfoMjPqTreEZctEq+OChL+FOmhxa8WHFLOEJhf525kIm+PsGYmfpdMZfJ9+B2 /25G3xOJ6fdHTTs0GYXNpb1h0E2UdTVOKQVOV/5bPoQrSV2HNlEASE6U/kHeDzK0QD viYu1fmdKuZaJER+bBVwfea3JtqFJ7x3Ngj/Jjfs= From: Andrew Sullivan To: v6ops@ietf.org Message-ID: <20180529175709.GI19425@mx4.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 17:57:52 -0000 Hi, On Sun, May 13, 2018 at 07:07:18PM -0700, Fred Baker wrote: > Considering https://tools.ietf.org/html/draft-palet-v6ops-nat64-deployment-00, discussed at IETF 101 using the slides at https://datatracker.ietf.org/meeting/101/materials/slides-101-v6ops-nat64-deployment-guidelines-in-operator-and-enterprise-networks-00. I'd like to invite discussion on the list. What thoughts do folks have on this draft? > Thanks for asking. I have read the draft. In section 2, I find this claim bizarre: If a device connected to an IPv6-only WAN queries for a domain name in a signed zone, by means of a recursive name server that supports DNS64, and the result is a synthesized AAAA record, and the recursive name server is configured to perform DNSSEC validation and has a valid chain of trust to the zone in question, it will cryptographically validate the negative response from the authoritative name server. So, the recursive name server actually lie to the client device, Of course they are "lying" to the client: that's literally the feature. What the DNS64 mechanism does is give you answers for a AAAA record when you otherwise wouldn't get one. And indeed, a validating DNS64 resolver can give you that synthetic AAAA with greater confidence, having validated that the AAAA really for sure doesn't exist. Similarly, If the client device performs DNSSEC validation on the AAAA record, it will fail as it is a synthesized record. This is only true if the "client device" is NAT64-oblivious. That point is made at some length in RFC 6147, in sections 3, 5.5, and 6.2. It isn't like we didn't think about this. Essentially all of section 2 is covered at length in RFC 6147; and the "obvious solution" contained in this section is rather non-obvious to me, given that such a requirement is both beyond the means of the person who has the problem and also, in fact, the very problem NAT64/DNS64 is trying to mitigate. Indeed, if the solution were just, "Everyone should deploy IPv6," we wouldn't need NAT64/DNS64 at all. When we wrote DNS64, we made the assumption (which I think we made clear in RFC 6147) that it was sufficiently early in the validator-deployment curve that it would be ok to break certain DNSSEC assumptions for people who were really stuck in a NAT64/DNS64-needing world. Validators could come to know about NAT64, could perform the necessary discovery, and could do their own synthesis. This is why we overloaded the CD bit. (I am aware that Mark Andrews hated that decision, but it was the only one on offer unless we wanted to do multiple round trips for every one of these cases -- something I still think would have been a bad idea. And it was the WG consensus; Mark was in the rough.) In section 3, there are some arguments for deployment scenarios that are explicitly ruled out by NAT64/DNS64. In particular, if 3.a. is true then the validating resolvers need to be DNS64-aware too (as RFC 6147 pointed out); if not, then they can't validate. 3.b. was always a known issue with NAT64/DNS64, and my position then (and now) was that we weren't trying to make this perfect, we were trying to mitigate pain. I have been pleasantly surprised by the success of RFC 6877, which seems to me to be a partial answer to the limitations of NAT64/DNS64. But I did not believe then, and I do not believe now, that we should make the transition services perfect. We need to make them just good enough that most things mostly work, and rely on commercial pressure (particularly from lousy performance) to ensure that people who are IPv4 only get the message. Section 3.1 describes a case that simply doesn't work: the whole point of publishing NAT64 and DNS64 together was to make complementary things that worked together. I am struggling to imagine what conceivable value this would be (or in what world random authoritative servers on the Internet are going to configure synthetic records for everyone else). In general, I find the use cases to be improbable. Anyone who is willing to go to the effort of deploying NAT64 or 464XLAT is going to be able to deploy DNS64 too. Virtually nobody is doing DNSSEC validation in endpoints even today, and virtually everyone who is has the capacity to do synthesis themselves as well. So, I don't really understand what the document is trying to do. I think it would be useful to tell people, "If you're going to deploy NAT64, you need DNS64, and here are some limitations." This document seems instead to pretend that there are some sorts of mitigations for most of these issues, some of which appear to involve getting other people on the Internet to do things. I don't see how it helps any transition, and I don't see how it helps people trying to deploy NAT64+DNS64 to cloud the water with a bunch of scenarios that won't work and were never expected to work. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue May 29 11:27:39 2018 Return-Path: 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 72899126B6D for ; Tue, 29 May 2018 11:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] 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 22PNJ5nrVhER for ; Tue, 29 May 2018 11:27:35 -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 E306712EAF8 for ; Tue, 29 May 2018 11:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1527618452; x=1528223252; 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=/TDh1yGx KuZk6Ek50pHGaQTtpcdsHGC8eJldhrfoOv8=; b=YQ1fGpz+t3Df/snwkWojVygI 92UMcOp0Yvkgd9w2kxMZ5uqCmdALeEW1y7yCLtO4vodJTkEX4sUFwThKILj5Q4yC LLxSqYri4kVJdmtgi9o4fi0RNLCA9qZyFu9Q+kq898hk7ZYs6eg1yt7g6xQ4U+4M Ok22Z2JJIy08+kuEgto= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 29 May 2018 20:27:32 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 29 May 2018 20:27:31 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005778903.msg for ; Tue, 29 May 2018 20:27:30 +0200 X-MDRemoteIP: 2001:470:1f09:495:1460:3c71:b029:a129 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Tue, 29 May 2018 20:27:30 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=168717744b=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Tue, 29 May 2018 20:27:29 +0200 From: JORDI PALET MARTINEZ To: Andrew Sullivan , Message-ID: <2D818599-B204-4F0E-9C49-CFCD9636654F@consulintel.es> Thread-Topic: [v6ops] draft-palet-v6ops-nat64-deployment discussion References: <20180529175709.GI19425@mx4.yitter.info> In-Reply-To: <20180529175709.GI19425@mx4.yitter.info> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 18:27:39 -0000 Hi Andrew, Thanks for reading and contributing. Let me provide some background of this document. It started as "464XLAT Deployment Guidelines in Operator Networks" (draft-p= alet-v6ops-464xlat-deployment-00), because we have many deployments, as you= mention of 464XLAT, but not clear guidelines, and even we had a discussion= in the IETF general area about offering only NAT64 in our network by defau= lt, etc., while I was suggesting 464XLAT. Also, unfortunately, I realized t= hat being the transition mechanism that has been more successful is only in= formational. When I presented it in the WG (I think it was in Singapore), the WG told me= that what we need is a similar document for NAT64 scenarios ... and here w= e are. I understand your point that NAT64 was meant to be "imperfect", but this is= something that is not valid for operators. Operators need to support exist= ing customers with existing devices and apps, that only have IPv4 support, = and this is only possible with NAT64 + CLAT. Also, most of the actual usages of 464XLAT are still using DNS64 (except a = few like Orange in Poland if I recall correctly), so the point is to explai= n that you can also solve the DNSSEC issue, when using CLAT (not using DNS6= 4), etc. So, the goal of the document is to find what is the "best" possible way to = deploy NAT64, which in my opinion, in the real world is by using it combine= d with CLAT. Of course, Section 3.1 (now 4.1 in v1) is not a credible case, but I wanted= to do the exercise of looking into all possible cases, just to make sure t= hat somebody using the document see what is possible and what is not, inste= ad of making the exercise by themselves. I recall having seen other IETF do= cuments doing the same (looking into all the possible cases and then discar= ding some). Same for your comments about section 3, etc. What I disagree with you is in your comment that anyone who is willing to d= eploy (let's concentrate in) 464XLAT, will do DNS64 too. This is actually n= ot needed in that case. I've no problem to add text, to more explicitly say "If you're going to dep= loy NAT64, you need DNS64, and here are some limitations". Maybe if you see the point that an operator will not be able to provide ser= vices without the CLAT, you have a better understanding on the document now= . Would you agree that if an operator deploying IPv6-only access want to make= sure that the customers using some IPv4-only devices work fine, the only w= ay is using NAT64+CLAT, and that using NAT64+DNS64 will not work? Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Andrew Sullivan Fecha: martes, 29 de mayo de 2018, 19:58 Para: Asunto: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion Hi, =20 On Sun, May 13, 2018 at 07:07:18PM -0700, Fred Baker wrote: > Considering https://tools.ietf.org/html/draft-palet-v6ops-nat64-deplo= yment-00, discussed at IETF 101 using the slides at https://datatracker.iet= f.org/meeting/101/materials/slides-101-v6ops-nat64-deployment-guidelines-in= -operator-and-enterprise-networks-00. I'd like to invite discussion on the = list. What thoughts do folks have on this draft? >=20 =20 Thanks for asking. =20 I have read the draft. =20 In section 2, I find this claim bizarre: =20 If a device connected to an IPv6-only WAN queries for a domain name in a signed zone, by means of a recursive name server that supports DNS64, and the result is a synthesized AAAA record, and the recursiv= e name server is configured to perform DNSSEC validation and has a valid chain of trust to the zone in question, it will cryptographically validate the negative response from the authoritative name server. So, the recursive name server actually lie to the client device, =20 Of course they are "lying" to the client: that's literally the feature. What the DNS64 mechanism does is give you answers for a AAAA record when you otherwise wouldn't get one. And indeed, a validating DNS64 resolver can give you that synthetic AAAA with greater confidence, having validated that the AAAA really for sure doesn't exist. =20 Similarly, =20 If the client device performs DNSSEC validation on the AAAA record, it will fail as it is a synthesized record. =20 This is only true if the "client device" is NAT64-oblivious. That point is made at some length in RFC 6147, in sections 3, 5.5, and 6.2. It isn't like we didn't think about this. Essentially all of section 2 is covered at length in RFC 6147; and the "obvious solution" contained in this section is rather non-obvious to me, given that such a requirement is both beyond the means of the person who has the problem and also, in fact, the very problem NAT64/DNS64 is trying to mitigate. Indeed, if the solution were just, "Everyone should deploy IPv6," we wouldn't need NAT64/DNS64 at all. =20 When we wrote DNS64, we made the assumption (which I think we made clear in RFC 6147) that it was sufficiently early in the validator-deployment curve that it would be ok to break certain DNSSEC assumptions for people who were really stuck in a NAT64/DNS64-needing world. Validators could come to know about NAT64, could perform the necessary discovery, and could do their own synthesis. This is why we overloaded the CD bit. (I am aware that Mark Andrews hated that decision, but it was the only one on offer unless we wanted to do multiple round trips for every one of these cases -- something I still think would have been a bad idea. And it was the WG consensus; Mark was in the rough.) =20 In section 3, there are some arguments for deployment scenarios that are explicitly ruled out by NAT64/DNS64. In particular, if 3.a. is true then the validating resolvers need to be DNS64-aware too (as RFC 6147 pointed out); if not, then they can't validate. 3.b. was always a known issue with NAT64/DNS64, and my position then (and now) was that we weren't trying to make this perfect, we were trying to mitigate pain. I have been pleasantly surprised by the success of RFC 6877, which seems to me to be a partial answer to the limitations of NAT64/DNS64. But I did not believe then, and I do not believe now, that we should make the transition services perfect. We need to make them just good enough that most things mostly work, and rely on commercial pressure (particularly from lousy performance) to ensure that people who are IPv4 only get the message. =20 Section 3.1 describes a case that simply doesn't work: the whole point of publishing NAT64 and DNS64 together was to make complementary things that worked together. I am struggling to imagine what conceivable value this would be (or in what world random authoritative servers on the Internet are going to configure synthetic records for everyone else). =20 In general, I find the use cases to be improbable. Anyone who is willing to go to the effort of deploying NAT64 or 464XLAT is going to be able to deploy DNS64 too. Virtually nobody is doing DNSSEC validation in endpoints even today, and virtually everyone who is has the capacity to do synthesis themselves as well. =20 So, I don't really understand what the document is trying to do. I think it would be useful to tell people, "If you're going to deploy NAT64, you need DNS64, and here are some limitations." This document seems instead to pretend that there are some sorts of mitigations for most of these issues, some of which appear to involve getting other people on the Internet to do things. I don't see how it helps any transition, and I don't see how it helps people trying to deploy NAT64+DNS64 to cloud the water with a bunch of scenarios that won't work and were never expected to work. =20 Best regards, =20 A =20 --=20 Andrew Sullivan ajs@anvilwalrusden.com =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** 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 con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Tue May 29 12:14:16 2018 Return-Path: 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 3178F12EC7D for ; Tue, 29 May 2018 12:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 BI6_dO7NbvVL for ; Tue, 29 May 2018 12:14:02 -0700 (PDT) Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 782CF12EC52 for ; Tue, 29 May 2018 12:14:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id w4TJE0Wq013986; Tue, 29 May 2018 12:14:01 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w4TJDxFA013656 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK) for ; Tue, 29 May 2018 12:13:59 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 29 May 2018 12:13:58 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1365.000; Tue, 29 May 2018 12:13:58 -0700 From: "Templin (US), Fred L" To: v6ops list Thread-Topic: IPv6 Prefix Delegation Models ('draft-templin-v6ops-pdhost') - draft update Thread-Index: AdP3gG5+uFo5RHF/RMmMgf6+VRvj7Q== Date: Tue, 29 May 2018 19:13:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: [v6ops] IPv6 Prefix Delegation Models ('draft-templin-v6ops-pdhost') - draft update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 19:14:15 -0000 See below for a draft update to "IPv6 Prefix Delegation Models ('draft-temp= lin-v6ops-pdhost'). This version (-20) updates figure 1 and adds informative text on the relati= on to multi-addressing (RFC7934 and RFC8273). Please review and comment. Fred -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Tuesday, May 29, 2018 12:02 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-templin-v6ops-pdhost-20.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : IPv6 Prefix Delegation Models Author : Fred L. Templin Filename : draft-templin-v6ops-pdhost-20.txt Pages : 14 Date : 2018-05-29 Abstract: IPv6 prefixes are typically delegated to requesting routers which assign them to their downstream-attached links and networks. The requesting node can provision the prefix according to whether it acts as a router on behalf of any downstream networks and/or as a host on behalf of its local applications. In the latter case, the requesting node can use portions of the delegated prefix for its own multi- addressing purposes. This document therefore considers prefix delegation models for both the classic routing and multi-addressing use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-templin-v6ops-pdhost-20 https://datatracker.ietf.org/doc/html/draft-templin-v6ops-pdhost-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-templin-v6ops-pdhost-20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Tue May 29 12:37:46 2018 Return-Path: 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 7F38512EC02 for ; Tue, 29 May 2018 12:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=nfgk1Vws; dkim=pass (1024-bit key) header.d=yitter.info header.b=iEfy+Ilm 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 imqFCCVFlpnb for ; Tue, 29 May 2018 12:37:42 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF69C126B6D for ; Tue, 29 May 2018 12:37:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 342C5BDEF9 for ; Tue, 29 May 2018 19:37:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1527622661; bh=XGZdi/N/Juwn3r1kEbbCfOPwTE2dJ75IAbfCW55bA+s=; h=Date:From:To:Subject:References:In-Reply-To:From; b=nfgk1VwsqT4oXXC7TKyFjA6Dm98JZfplBzZMU8xa5Ixik0dFzDYOpoMexI3QRFugc j5HLTvztvGpek1KVLDhfqeqNwet/5gPPOFYkvW/2N2/bbeHSVK5rcp+axrlxgsClPu c9I6tXaxnmy5BdaV8sdrT6VitLuHOQ7DjfciEm9Y= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jxb0_mpt9jpf for ; Tue, 29 May 2018 19:37:39 +0000 (UTC) Date: Tue, 29 May 2018 15:37:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1527622659; bh=XGZdi/N/Juwn3r1kEbbCfOPwTE2dJ75IAbfCW55bA+s=; h=Date:From:To:Subject:References:In-Reply-To:From; b=iEfy+Ilm0L4XFjoggMlY/+gA3i38Mtn0SJHZ0MwP0SD0AeaYZxqi82/DzI834JV+1 IzgyZhHGk5I4j3TYtv1W+5ueQ1FjXPKpjctSQiDBPMqIqjg/qrtglT8LdMG2hhTg5k RsH165+y18rMvkH/IYBAFC81+8/P8nsJ5mp8OgwQ= From: Andrew Sullivan To: v6ops@ietf.org Message-ID: <20180529193736.GA8084@mx4.yitter.info> References: <20180529175709.GI19425@mx4.yitter.info> <2D818599-B204-4F0E-9C49-CFCD9636654F@consulintel.es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D818599-B204-4F0E-9C49-CFCD9636654F@consulintel.es> Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 19:37:45 -0000 Hi, On Tue, May 29, 2018 at 08:27:29PM +0200, JORDI PALET MARTINEZ wrote: > I understand your point that NAT64 was meant to be "imperfect", but this is something that is not valid for operators. Operators need to support existing customers with existing devices and apps, that only have IPv4 support, and this is only possible with NAT64 + CLAT. > Obviously, operators have customers and need to support whatever they need to support. It appears that there are people who are using 464XLAT with DNS64 where that works for them. I certainly have no trouble with something that wants to outline (for instance) how one would make a determination about whether anyone downstream is doing their own validation. What I think is wrong here is a generic claim that one or another approach is the only right answer, because the CLAT in many cases requires more translation (which means more overhead and more work that the operator has to do). > Also, most of the actual usages of 464XLAT are still using DNS64 (except a few like Orange in Poland if I recall correctly), so the point is to explain that you can also solve the DNSSEC issue, when using CLAT (not using DNS64), etc. > Well, you can indeed. I think there is nothing wrong with making this point, but the document as it is appears to be suggesting that the trade-off is not clear in DNS64. I think RFC 6147 is crystal clear about it, so I don't get why this document (which has a much less comprehensive treatment of what fails and why) is an improvement. > So, the goal of the document is to find what is the "best" possible > way to deploy NAT64, which in my opinion, in the real world is by > using it combined with CLAT. I don't observe that the document is called "Jordi's opinion on best NAT64 deployment scenarios". If the WG is supposed to work on this, then I think it would be better to outline the various trade-offs and allow people to make their own choices, fully informed. > Of course, Section 3.1 (now 4.1 in v1) is not a credible case, but I > wanted to do the exercise of looking into all possible cases, just > to make sure that somebody using the document see what is possible > and what is not, instead of making the exercise by themselves. I see. Such a section could be massively improved, then, by calling out the scenarios that are known not to work, that are broken on purpose, and so on. At the moment, it reads as though these alternatives are all live possibilities, but some of them simply aren't, were never intended to be, and are not a real problem anyone should have. > What I disagree with you is in your comment that anyone who is willing to deploy (let's concentrate in) 464XLAT, will do DNS64 too. This is actually not needed in that case. > I think what I said is that they're going to _be able_ to, not that they would. I do not claim that DNS64 ought to be deployed by anyone. It's just a mechanism that is available if it happens to fit a need, and each network operator needs to evaluate that. I claim that the I-D as written doesn't actually help people do such an evaluation, and that in fact it leaves out some of the necessary analysis. > Maybe if you see the point that an operator will not be able to provide services without the CLAT, you have a better understanding on the document now. > It's simply false that an operator will not be able to provide service without the CLAT, but it is true that _some_ operators will find such a service inadequate. I believe that's why 464XLAT was invented, in fact. > Would you agree that if an operator deploying IPv6-only access want to make sure that the customers using some IPv4-only devices work fine, the only way is using NAT64+CLAT, and that using NAT64+DNS64 will not work? > No. But I believe that there are operators for whom that will be true. I also believe there are operators for whom 464XLAT with DNS64 is a viable and useful option in some scenarios, particularly having to do with the costs of double translation. I'm not opposed to a document that attempts to lay out the trade-offs. I am very much opposed to a document that attempts to say there's only one way that works, because it isn't true. Indeed, for some values of "works", _none_ of this qualifies, and the only real answer is native ipv6. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue May 29 13:03:47 2018 Return-Path: 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 72E6E12EC8B for ; Tue, 29 May 2018 13:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no 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 TdbG_NGG0d_N for ; Tue, 29 May 2018 13:03:34 -0700 (PDT) Received: from atl4mhob21.registeredsite.com (atl4mhob21.registeredsite.com [209.17.115.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5655212EBDF for ; Tue, 29 May 2018 13:03:34 -0700 (PDT) Received: from mailpod.hostingplatform.com (atl4qobmail01pod6.registeredsite.com [10.30.71.209]) by atl4mhob21.registeredsite.com (8.14.4/8.14.4) with ESMTP id w4TK3Vot034205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 29 May 2018 16:03:31 -0400 Received: (qmail 8578 invoked by uid 0); 29 May 2018 20:03:31 -0000 X-TCPREMOTEIP: 68.100.68.25 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.135?) (lee@asgard.org@68.100.68.25) by 0 with ESMTPA; 29 May 2018 20:03:31 -0000 To: v6ops@ietf.org References: <20180529175709.GI19425@mx4.yitter.info> <2D818599-B204-4F0E-9C49-CFCD9636654F@consulintel.es> From: Lee Howard Message-ID: <847afa59-3eef-8bf1-488f-11bbd2898d9e@asgard.org> Date: Tue, 29 May 2018 16:03:30 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <2D818599-B204-4F0E-9C49-CFCD9636654F@consulintel.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 20:03:46 -0000 On 05/29/2018 02:27 PM, JORDI PALET MARTINEZ wrote: > I understand your point that NAT64 was meant to be "imperfect", but this is something that is not valid for operators. Operators need to support existing customers with existing devices and apps, that only have IPv4 support, and this is only possible with NAT64 + CLAT. This statement is too broad in several ways. "Operators" may use 2G, 3G, LTE, fixed wireless, DSL, FTTH, DOCSIS, PON, Wi-Fi, or local Ethernet. They may serve different kinds of customers, including their enterprise users, homes, businesses, mobile handsets, mobile tablets, hospitality, retail Wi-Fi. Some of those cases may not require IPv4 at the host, or even the app. Even in a heterogeneous network, an operator may prefer to offer NAT64 only to some customers, and native dual-stack to others, rather than requiring a CLAT of all of them. To say that existing customers have IPv4-only requirements is true for a specific subset of the kinds of networks and the endpoints served. IPv6-only may work, or NAT64 may work. Further, as far as I can tell, MAP solves as many use cases, with as much scale, as 464xlat. DS-Lite also solves the use cases, but maybe not at the same scale. And so on. For the sake of this document, I agree that NAT64 is the focus, and CLAT provides a useful reference, but it is not the only way to deploy NAT64. > What I disagree with you is in your comment that anyone who is willing to deploy (let's concentrate in) 464XLAT, will do DNS64 too. This is actually not needed in that case. > > I've no problem to add text, to more explicitly say "If you're going to deploy NAT64, you need DNS64, and here are some limitations". That would be better. Experience suggests that anyone deploying NAT64 and/or 464xlat will deploy DNS64 too, so explicit exceptions would be nice. > Would you agree that if an operator deploying IPv6-only access want to make sure that the customers using some IPv4-only devices work fine, the only way is using NAT64+CLAT, and that using NAT64+DNS64 will not work? I don't agree with that, as I said above. > > Regards, > Jordi > > Lee From nobody Tue May 29 13:27:29 2018 Return-Path: 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 96FDE12FACA for ; Tue, 29 May 2018 13:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] 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 h0tkobhc1bbl for ; Tue, 29 May 2018 13:27:12 -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 EA89A12FACE for ; Tue, 29 May 2018 13:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1527625629; x=1528230429; 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=b6wEnniL rHOVpm8Z03F5dudG2VqnqmOT+CzkQzWtZkY=; b=r8dZXdfJ8STHj2okqi3wxSCn mJRdfuccxlaYgQBw+WOGzGjeCLo9Ku8rRUDds1RKMdNJ+RRpgOalmkHPtyWKPLih mAx86s8PqWeZpoXqcLjvbIUTXj0rDySan7saLMn8JRUNfvxZcDICbxI5zxMjnlmQ G9YIB+hTwnCZMBGj7c0= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 29 May 2018 22:27:09 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 29 May 2018 22:27:08 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005778974.msg for ; Tue, 29 May 2018 22:27:07 +0200 X-MDRemoteIP: 2001:470:1f09:495:7d90:7c58:9f18:46a9 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Tue, 29 May 2018 22:27:07 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=168717744b=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Tue, 29 May 2018 22:26:48 +0200 From: JORDI PALET MARTINEZ To: Andrew Sullivan , Message-ID: Thread-Topic: [v6ops] draft-palet-v6ops-nat64-deployment discussion References: <20180529175709.GI19425@mx4.yitter.info> <2D818599-B204-4F0E-9C49-CFCD9636654F@consulintel.es> <20180529193736.GA8084@mx4.yitter.info> In-Reply-To: <20180529193736.GA8084@mx4.yitter.info> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 20:27:27 -0000 Thanks again for your detailed responses. I will work in the next few days = in a very in-depth review, this has been very helpful. See below, in-line. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Andrew Sullivan Fecha: martes, 29 de mayo de 2018, 21:38 Para: Asunto: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion Hi, =20 On Tue, May 29, 2018 at 08:27:29PM +0200, JORDI PALET MARTINEZ wrote: =20 > I understand your point that NAT64 was meant to be "imperfect", but t= his is something that is not valid for operators. Operators need to support= existing customers with existing devices and apps, that only have IPv4 sup= port, and this is only possible with NAT64 + CLAT. >=20 =20 Obviously, operators have customers and need to support whatever they need to support. It appears that there are people who are using 464XLAT with DNS64 where that works for them. I certainly have no trouble with something that wants to outline (for instance) how one would make a determination about whether anyone downstream is doing their own validation. What I think is wrong here is a generic claim that one or another approach is the only right answer, because the CLAT in many cases requires more translation (which means more overhead and more work that the operator has to do). I see your point. The question is the operators want to avoid, at all means= , user complains, so if you want to make it "perfect", you may prefer more = translations, but not breaking DNSSEC. Anyway, I will try to find a way to = suggest that you need to determine in your own case if DNSSEC is going to b= e a problem for your customers and possible alternatives such ACL for speci= fic customers, etc. =20 > Also, most of the actual usages of 464XLAT are still using DNS64 (exc= ept a few like Orange in Poland if I recall correctly), so the point is to = explain that you can also solve the DNSSEC issue, when using CLAT (not usin= g DNS64), etc. >=20 =20 Well, you can indeed. I think there is nothing wrong with making this point, but the document as it is appears to be suggesting that the trade-off is not clear in DNS64. I think RFC 6147 is crystal clear about it, so I don't get why this document (which has a much less comprehensive treatment of what fails and why) is an improvement. =20 > So, the goal of the document is to find what is the "best" possible > way to deploy NAT64, which in my opinion, in the real world is by > using it combined with CLAT. =20 I don't observe that the document is called "Jordi's opinion on best NAT64 deployment scenarios". If the WG is supposed to work on this, then I think it would be better to outline the various trade-offs and allow people to make their own choices, fully informed. Your review is the first "complete" one. A couple of people provided inputs= in specific sections ... Definitively I'm going to work in a new version carefully observing all you= r inputs. Thanks again. I wish having so many inputs in every document that= we have in v6ops, but unfortunately is not happening. =20 > Of course, Section 3.1 (now 4.1 in v1) is not a credible case, but I > wanted to do the exercise of looking into all possible cases, just > to make sure that somebody using the document see what is possible > and what is not, instead of making the exercise by themselves. =20 I see. Such a section could be massively improved, then, by calling out the scenarios that are known not to work, that are broken on purpose, and so on. At the moment, it reads as though these alternatives are all live possibilities, but some of them simply aren't, were never intended to be, and are not a real problem anyone should have. Right, I will clasify them in different "sub-sections" to make it very clea= r. Probably will use some tables to make a summary. =20 > What I disagree with you is in your comment that anyone who is willin= g to deploy (let's concentrate in) 464XLAT, will do DNS64 too. This is actu= ally not needed in that case. >=20 =20 I think what I said is that they're going to _be able_ to, not that they would. I do not claim that DNS64 ought to be deployed by anyone. It's just a mechanism that is available if it happens to fit a need, and each network operator needs to evaluate that. I claim that the I-D as written doesn't actually help people do such an evaluation, and that in fact it leaves out some of the necessary analysis. =20 > Maybe if you see the point that an operator will not be able to provi= de services without the CLAT, you have a better understanding on the docume= nt now. >=20 =20 It's simply false that an operator will not be able to provide service without the CLAT, but it is true that _some_ operators will find such a service inadequate. I believe that's why 464XLAT was invented, in fact. =20 =20 > Would you agree that if an operator deploying IPv6-only access want t= o make sure that the customers using some IPv4-only devices work fine, the = only way is using NAT64+CLAT, and that using NAT64+DNS64 will not work? >=20 =20 No. But I believe that there are operators for whom that will be true. I also believe there are operators for whom 464XLAT with DNS64 is a viable and useful option in some scenarios, particularly having to do with the costs of double translation. I'm not opposed to a document that attempts to lay out the trade-offs. I am very much opposed to a document that attempts to say there's only one way that works, because it isn't true. Indeed, for some values of "works", _none_ of this qualifies, and the only real answer is native ipv6. I didn't write correctly the best example for you to answer this question. = Basically, what I wanted to ask is NAT64+DNS64 vs NAT64+DNS64+CLAT. =20 Best regards, =20 A =20 --=20 Andrew Sullivan ajs@anvilwalrusden.com =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** 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 con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Tue May 29 13:44:22 2018 Return-Path: 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 EDE7312D94D for ; Tue, 29 May 2018 13:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] 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 mQW_IeFxjKLf for ; Tue, 29 May 2018 13:44:17 -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 46EBD12E8D7 for ; Tue, 29 May 2018 13:44:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1527626654; x=1528231454; 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=BYC/FEOx U0HQsYWC9j6uhGjGPrE0AR/vLNer5gm69uU=; b=dBI35VXyndvpEXqTY5MxS+OJ 0iuHYgI4CN5P1zkk02xPZ6Zx5THdN6hOElk+8g46e/TKa+25PHJLTv4PM62MwGSP M5l9zJWSee7mGgXiDMa5wwboiTqK7TyioqHsY7irpT42lBaY8tUzB2hQ1rt6kPAP fjZrhXLomo3pXhwQMiw= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 29 May 2018 22:44:14 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 29 May 2018 22:44:13 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005778979.msg for ; Tue, 29 May 2018 22:44:12 +0200 X-MDRemoteIP: 2001:470:1f09:495:7d90:7c58:9f18:46a9 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Tue, 29 May 2018 22:44:12 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=168717744b=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Tue, 29 May 2018 22:44:09 +0200 From: JORDI PALET MARTINEZ To: Message-ID: <737B4FD7-863D-4947-B79C-2130706F1BAC@consulintel.es> Thread-Topic: [v6ops] draft-palet-v6ops-nat64-deployment discussion References: <20180529175709.GI19425@mx4.yitter.info> <2D818599-B204-4F0E-9C49-CFCD9636654F@consulintel.es> <847afa59-3eef-8bf1-488f-11bbd2898d9e@asgard.org> In-Reply-To: <847afa59-3eef-8bf1-488f-11bbd2898d9e@asgard.org> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2018 20:44:20 -0000 Hi Lee, Responses below in-line. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Lee Howard Fecha: martes, 29 de mayo de 2018, 22:06 Para: Asunto: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion =20 =20 On 05/29/2018 02:27 PM, JORDI PALET MARTINEZ wrote: > I understand your point that NAT64 was meant to be "imperfect", but t= his is something that is not valid for operators. Operators need to support= existing customers with existing devices and apps, that only have IPv4 sup= port, and this is only possible with NAT64 + CLAT. =20 This statement is too broad in several ways. "Operators" may use 2G, 3G, LTE, fixed wireless, DSL, FTTH, DOCSIS, PON= ,=20 Wi-Fi, or local Ethernet. They may serve different kinds of customers, including their enterprise= =20 users, homes, businesses, mobile handsets, mobile tablets, hospitality,= =20 retail Wi-Fi. Some of those cases may not require IPv4 at the host, or= =20 even the app. Even in a heterogeneous network, an operator may prefer t= o=20 offer NAT64 only to some customers, and native dual-stack to others,=20 rather than requiring a CLAT of all of them. If the CE supports CLAT, but is getting dual stack in the WAN, then CLAT sh= ould not be used, so the operator will make sure that those customers have = a different information by means of the provisioning or whatever. Neverthel= ess, I think this is out of the scope of this document (draft-ietf-v6ops-tr= ansition-ipv4aas is probably the most appropriate for that). To say that existing customers have IPv4-only requirements is true for = a=20 specific subset of the kinds of networks and the endpoints served.=20 IPv6-only may work, or NAT64 may work. =20 Further, as far as I can tell, MAP solves as many use cases, with as=20 much scale, as 464xlat. DS-Lite also solves the use cases, but maybe no= t=20 at the same scale. And so on. =20 Agree, but my comment was in the scope of "if you want to use NAT64, you be= tter do 464XLAT". But still yes, this need to be better qualified, as that = sentence only makes sense if you still need to provide "dual-stack" inside = the customer CE. =20 =20 For the sake of this document, I agree that NAT64 is the focus, and CLA= T=20 provides a useful reference, but it is not the only way to deploy NAT64= . Today I believe is difficult to find cases that differ from "if you want to= use NAT64, you better do 464XLAT ": almost every residential and business = customer of every ISP in the world still has the need to have support for I= Pv4-only devices and apps. This will change in the next years? Yes, for sur= e. =20 > What I disagree with you is in your comment that anyone who is willin= g to deploy (let's concentrate in) 464XLAT, will do DNS64 too. This is actu= ally not needed in that case. > > I've no problem to add text, to more explicitly say "If you're going = to deploy NAT64, you need DNS64, and here are some limitations". =20 That would be better. Experience suggests that anyone deploying NAT64= =20 and/or 464xlat will deploy DNS64 too, so explicit exceptions would be n= ice. =20 > Would you agree that if an operator deploying IPv6-only access want t= o make sure that the customers using some IPv4-only devices work fine, the = only way is using NAT64+CLAT, and that using NAT64+DNS64 will not work? =20 I don't agree with that, as I said above. > > Regards, > Jordi > =20 > =20 Lee =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** 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 con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Tue May 29 18:10:47 2018 Return-Path: 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 6EB3C12FA8E for ; Tue, 29 May 2018 18:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 9KOlpOTE6Wl5 for ; Tue, 29 May 2018 18:10:40 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 55A1D12F24E for ; Tue, 29 May 2018 18:10:37 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id 18-v6so39082625wml.2 for ; Tue, 29 May 2018 18:10:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EbmUR7UvIIzDXzPyF+diUfe6EsXoTsotY9WxlnAjew8=; b=I48kHFu4x8Hy8pA1z6y7nFAL7Ge2RhUC39HMELQ3KFTp5l3N054tLhYMP9TkN2uF0Q TEVou1lqPSJ05jGkEAmet546EDkCmjY+G2vizKFxNAEL5RdB1ioa6uBuWq6K0eza+NXN urveUjAXMoqeOWOYSPQMhfjKQqTB8TI+P4bVwz2KC4XtNSqoTtHkK0kBEe4zNJgRQeZ0 EbOFuskyuLIH/x0sayEVx0wCIVI1koUCE3fH4Bw7wa99P1upZp/s0SNre5MIxMLdqAA8 ZcTyw7evX0Z/p95x+r/vd0pKItVw9WRRBj7VeVJdH0ZNsj70O863Xtqs05C//cbV/zz4 irRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EbmUR7UvIIzDXzPyF+diUfe6EsXoTsotY9WxlnAjew8=; b=Nd6s54wPF9NRaODs4xp7lg/aM+r3V23cFJXIszWy8poZ4iELhlIFTqxeLewKNI4dMk mqdUEvqAG4JFwqgVcCTOOWir0T4mi7DaR3vzBP6GoAv5B0Dh4nvHVV2E7aAEEorn47/6 Qr4IXYZP1k4PuxeeUyo63Cg/CqrKNQsnlY5Jh35YUx6lJKVqX5WEjooyEzndRUaKcq6s 0PDH4reytwjmndrGWgupYfKXGSkU6yC3bXdDhkxIHfm3C7iMRY0OHLpoE/6rI7+oIKug v8wNVg3DAYcMPRayCDGD2XFfdBSTHuhR55TTLjlsod/ual+/v72rXY1gTgbFS7VwgAjw r1Uw== X-Gm-Message-State: ALKqPwfqDyRs2MKre22S0S/UjKqsiXgB8f28dA4VyejTG/70SteyCzY9 sTaE1dRbTOAySTSlfpN6IM5zWCBx X-Google-Smtp-Source: ADUXVKKFjCgE5WDDRNI+QaTYOda9nKB7uROyBT3AzUlyVZf93Y3bigUCPkfqKYn3qKt4cYtFh782nQ== X-Received: by 2002:a50:ac53:: with SMTP id w19-v6mr1032211edc.51.1527642635880; Tue, 29 May 2018 18:10:35 -0700 (PDT) Received: from 211.66.20.149.in-addr.arpa (211.66.20.149.in-addr.arpa. [149.20.66.211]) by smtp.gmail.com with ESMTPSA id t9-v6sm19310067edb.14.2018.05.29.18.10.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 May 2018 18:10:34 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Fred Baker In-Reply-To: Date: Wed, 30 May 2018 03:10:29 +0200 Cc: V6 Ops List , JORDI PALET MARTINEZ Content-Transfer-Encoding: quoted-printable Message-Id: <615ED6E7-5CDB-48EA-A945-E13BD6615497@gmail.com> References: <20180529175709.GI19425@mx4.yitter.info> <2D818599-B204-4F0E-9C49-CFCD9636654F@consulintel.es> <20180529193736.GA8084@mx4.yitter.info> To: Andrew Sullivan , Lee Howard X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [v6ops] draft-palet-v6ops-nat64-deployment discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 01:10:43 -0000 Lee, Andrew, others... Question for you. Jordi is working to make this a useful document. Your = comments tell me that while at one level you disagree with statements he = is making, at another level it is important to get the statements right = and *say*them* as a body. Which is to say, treat this as a working group = document. Are you, specifically, in favor of adopting this as a working group = document (e.g., working on it to get it right and publishing it)? More = generally, is that our view as a working group?=20 > On May 29, 2018, at 10:26 PM, JORDI PALET MARTINEZ = wrote: >=20 > Thanks again for your detailed responses.=20 From nobody Tue May 29 18:14:53 2018 Return-Path: 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 69F6F12E85E for ; Tue, 29 May 2018 18:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 fVUNRZwAAp3r for ; Tue, 29 May 2018 18:14:50 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 C8E8E12DA13 for ; Tue, 29 May 2018 18:14:49 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id f8-v6so44671487wmc.4 for ; Tue, 29 May 2018 18:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=pcdZIjtdefdpmwxpXPZ9OAjy2a/o+pMnorYXuAeR4h8=; b=DH3ktvxQWQqYFIJHhc9M1GKlcWshJSFAwpJ52/v33OBc1P+SNNk3VJ39rwE/8Mq8QG nOGyDdlW43fFngrmC4O094WMJ42Y2knLQDmjoG7IPYzvvYXma4QTQ/os2iqONwnTTILC JVuCbvNMrh+hyjwxoF6jV+xamfj5/3Yf9SMBvBV9ml3xUbdogCWInC4buc5bL3f5ExdV qUYb/g5EsiIzm9Q38w8NNoncueNdZj5tJE+VhYNbn+17n2wtx5O0Sj8e0oNxXjDO2iai nOamel7tWFDyKvVcFwVuBcSsOV6UcdGIm16qoTEqWag0NN+N6BxuhlP1gMM9yLJRrL74 nRkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=pcdZIjtdefdpmwxpXPZ9OAjy2a/o+pMnorYXuAeR4h8=; b=o9LVHJZ6agm9TGpkmTJoSnN2Bhl7ho3nBt5s9w9HyrdcGMqz5X2QCNhiCGCtgR7Q3V hi4ZO3ZNj4H3EhosvqiOyuDVv0WtiT07zz8A/IoqiMjEOAsZBIHJ2qndTFCsM0y3pdhN ws9WO1wjembN5aFOKtHepOiVh6ZIR/eAUaTr8APbTzogkjrk6Wqy8Mc6p5Hfqm8CG2b1 HULyFxF+hCwSKIn/L4TJ/gotlwoxgpJxvNiz1MMU0A7zVE5T6R36Vb3oNJXWtqoWqqaQ fsPefAlvTHSmmfaqsNwPUii2KiQUD9eKRLKVkvIOe8J2l7rASd01TkiX12U1KcLiUlfS Xi3w== X-Gm-Message-State: ALKqPwdmYcN/n85lwj2MJWJjybUfRavhiGVp+kOkVepnc7R38WtiA8gK 9i4L2Ci7NtRYdePRT0pSDOUrRWBZ X-Google-Smtp-Source: ADUXVKKU911QuZkQEdYt5LcLFKVxtABMMeuruZCgaOewtZTGhWxZXBzPjoxx+anyLwnINftVpR9q4g== X-Received: by 2002:a50:9ecf:: with SMTP id a73-v6mr1090772edf.92.1527642888155; Tue, 29 May 2018 18:14:48 -0700 (PDT) Received: from 211.66.20.149.in-addr.arpa (211.66.20.149.in-addr.arpa. [149.20.66.211]) by smtp.gmail.com with ESMTPSA id m31-v6sm19249406edc.94.2018.05.29.18.14.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 May 2018 18:14:47 -0700 (PDT) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Wed, 30 May 2018 03:14:42 +0200 References: To: v6ops list In-Reply-To: Message-Id: <06CBD4DE-9E00-4501-92C4-1E2E1784B923@gmail.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [v6ops] IPv6 Prefix Delegation Models ('draft-templin-v6ops-pdhost') - draft update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 01:14:52 -0000 General question to those who commented on the draft when we discussed = it a few weeks ago: do you agree that this update addresses the issues = you raised? Do you have further comments on it? On May 29, 2018, at 9:13 PM, Templin (US), Fred L = wrote: > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-templin-v6ops-pdhost-20 > https://datatracker.ietf.org/doc/html/draft-templin-v6ops-pdhost-20 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-templin-v6ops-pdhost-20 >=20 From nobody Wed May 30 06:41:19 2018 Return-Path: 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 EECC512E8CF for ; Wed, 30 May 2018 06:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 xmn2QsitMgoD for ; Wed, 30 May 2018 06:41:10 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 224FA12E8A9 for ; Wed, 30 May 2018 06:41:08 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w4UDf6kA023840 for ; Wed, 30 May 2018 15:41:06 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 68635203BC7 for ; Wed, 30 May 2018 15:41:06 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 5D03B201D51 for ; Wed, 30 May 2018 15:41:06 +0200 (CEST) Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w4UDf60C002355 for ; Wed, 30 May 2018 15:41:06 +0200 To: v6ops@ietf.org References: <06CBD4DE-9E00-4501-92C4-1E2E1784B923@gmail.com> From: Alexandre Petrescu Message-ID: <6b5005f8-b1d3-0da6-6744-47f5cbe2e25e@gmail.com> Date: Wed, 30 May 2018 15:41:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <06CBD4DE-9E00-4501-92C4-1E2E1784B923@gmail.com> Content-Type: multipart/alternative; boundary="------------DC88F5ECC538E958A93B521C" Content-Language: fr Archived-At: Subject: Re: [v6ops] IPv6 Prefix Delegation Models ('draft-templin-v6ops-pdhost') - draft update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 13:41:17 -0000 This is a multi-part message in MIME format. --------------DC88F5ECC538E958A93B521C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I propose this figure as well, in which an IoT router 'R' does not form any address A on any of its interfaces, out of the delegated prefix P, even though it _does_ request and obtain a prefix P and does RA it to other nodes in the network in controls. x | upstream link | | +----------+----------+ | upstream interface | +--+-+--+-+--+-----+--+ | | | requesting node 'R' | | | +---------------------+ For comparison, the figures present now in -20 are these: x | upstream link | | +----------+----------+ | upstream Interface | +---------------------+ | | | requesting node 'R' | | | +--+-+--+-+--+-----+--+ |A1| |A2| |A3| ... |An| +--+-+--+-+--+-----+--+ | virtual Interface | +---------------------+ Figure 2: Weak End System Model x | upstream link | | +----------+----------+ | upstream interface | +--+-+--+-+--+-----+--+ |A1| |A2| |A3| ... |An| +--+-+--+-+--+-----+--+ | | | requesting node 'R' | | | +---------------------+ | virtual interface | +---------------------+ Figure 3: Strong End System Model Le 30/05/2018 à 03:14, Fred Baker a écrit : > General question to those who commented on the draft when we discussed it a few weeks ago: do you agree that this update addresses the issues you raised? Do you have further comments on it? > > On May 29, 2018, at 9:13 PM, Templin (US), Fred L wrote: >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-templin-v6ops-pdhost-20 >> https://datatracker.ietf.org/doc/html/draft-templin-v6ops-pdhost-20 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-templin-v6ops-pdhost-20 >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --------------DC88F5ECC538E958A93B521C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I propose this figure as well, in which an IoT router 'R' does not form any address A on any of its interfaces, out of the delegated prefix P,
even though it _does_ request and obtain a prefix P and does RA it to other nodes in the network in controls.
 
                                   x
                                   |
                     upstream link |
                                   |
                        +----------+----------+
                        |  upstream interface |
                        +--+-+--+-+--+-----+--+
                        |                     |
                        | requesting node 'R' |
                        |                     |
                        +---------------------+




For comparison, the figures present now in -20 are these:

                                   x
                                   |
                     upstream link |
                                   |
                        +----------+----------+
                        |  upstream Interface |
                        +---------------------+
                        |                     |
                        | requesting node 'R' |
                        |                     |
                        +--+-+--+-+--+-----+--+
                        |A1| |A2| |A3| ... |An|
                        +--+-+--+-+--+-----+--+
                        |  virtual Interface  |
                        +---------------------+

                      Figure 2: Weak End System Model


                                   x
                                   |
                     upstream link |
                                   |
                        +----------+----------+
                        |  upstream interface |
                        +--+-+--+-+--+-----+--+
                        |A1| |A2| |A3| ... |An|
                        +--+-+--+-+--+-----+--+
                        |                     |
                        | requesting node 'R' |
                        |                     |
                        +---------------------+
                        |   virtual interface |
                        +---------------------+
                      Figure 3: Strong End System Model

Le 30/05/2018 à 03:14, Fred Baker a écrit :
General question to those who commented on the draft when we discussed it a few weeks ago: do you agree that this update addresses the issues you raised? Do you have further comments on it?

On May 29, 2018, at 9:13 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-templin-v6ops-pdhost-20
https://datatracker.ietf.org/doc/html/draft-templin-v6ops-pdhost-20

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-templin-v6ops-pdhost-20


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

--------------DC88F5ECC538E958A93B521C-- From nobody Wed May 30 08:44:03 2018 Return-Path: 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 210931243F6 for ; Wed, 30 May 2018 08:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 0fXABkipooML for ; Wed, 30 May 2018 08:43:58 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8794712D7E2 for ; Wed, 30 May 2018 08:43:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id w4UFhvwt005210; Wed, 30 May 2018 08:43:57 -0700 Received: from XCH15-06-07.nw.nos.boeing.com (xch15-06-07.nw.nos.boeing.com [137.136.238.213]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w4UFhnDQ005017 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 30 May 2018 08:43:49 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-07.nw.nos.boeing.com (2002:8988:eed5::8988:eed5) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 30 May 2018 08:43:48 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1365.000; Wed, 30 May 2018 08:43:48 -0700 From: "Templin (US), Fred L" To: Alexandre Petrescu , "v6ops@ietf.org" Thread-Topic: [v6ops] IPv6 Prefix Delegation Models ('draft-templin-v6ops-pdhost') - draft update Thread-Index: AdP3gG5+uFo5RHF/RMmMgf6+VRvj7QAbdRgAABoRVgAACn8+YA== Date: Wed, 30 May 2018 15:43:48 +0000 Message-ID: <226862c69bcb48c9ac2abb87b4c7de59@XCH15-06-08.nw.nos.boeing.com> References: <06CBD4DE-9E00-4501-92C4-1E2E1784B923@gmail.com> <6b5005f8-b1d3-0da6-6744-47f5cbe2e25e@gmail.com> In-Reply-To: <6b5005f8-b1d3-0da6-6744-47f5cbe2e25e@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: multipart/alternative; boundary="_000_226862c69bcb48c9ac2abb87b4c7de59XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] IPv6 Prefix Delegation Models ('draft-templin-v6ops-pdhost') - draft update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2018 15:44:01 -0000 --_000_226862c69bcb48c9ac2abb87b4c7de59XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxleCwNCg0KR29vZCBwb2ludCwgYnV0IEkgdGhpbmsgdGhlIG5ldyBmaWd1cmUgeW91IGFy ZSBwcm9wb3NpbmcgaXMgYWxyZWFkeSBjb3ZlcmVkIHVuZGVyDQpmaWd1cmUgMS4gRmlndXJlIDEg aXMgYW4gSW9UIHJvdXRlciB0aGF0IGRvZXMgUkEgdG8gb3RoZXIgbm9kZXMgaW4gdGhlIG5ldHdv cmtzIGl0DQpjb250cm9scyDigJMgd2hldGhlciB0aGUgbmV0d29ya3MgYXJlIGludGVybmFsIHZp cnR1YWwgbmV0d29ya3Mgb3IgZXh0ZXJuYWwNCnBoeXNpY2FsIG5ldHdvcmtzLiBQZXJoYXBzIHNv bWUgZXh0cmEgdGV4dCB0byBleHBsYWluIHRoZSBJb1QgYW5kIGRvd25zdGVhbQ0KbmV0d29yayBS QSB1c2UgY2FzZSBpbiBjb25qdW5jdGlvbiB3aXRoIEZpZ3VyZSAxIHdvdWxkIGhlbHA/IEFueSBz dWdnZXN0aW9ucz8NCg0KVGhhbmtzIC0gRnJlZA0KDQpGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3Bz LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGV4YW5kcmUgUGV0cmVzY3UNClNlbnQ6 IFdlZG5lc2RheSwgTWF5IDMwLCAyMDE4IDY6NDEgQU0NClRvOiB2Nm9wc0BpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFt2Nm9wc10gSVB2NiBQcmVmaXggRGVsZWdhdGlvbiBNb2RlbHMgKCdkcmFmdC10 ZW1wbGluLXY2b3BzLXBkaG9zdCcpIC0gZHJhZnQgdXBkYXRlDQoNCkkgcHJvcG9zZSB0aGlzIGZp Z3VyZSBhcyB3ZWxsLCBpbiB3aGljaCBhbiBJb1Qgcm91dGVyICdSJyBkb2VzIG5vdCBmb3JtIGFu eSBhZGRyZXNzIEEgb24gYW55IG9mIGl0cyBpbnRlcmZhY2VzLCBvdXQgb2YgdGhlIGRlbGVnYXRl ZCBwcmVmaXggUCwNCmV2ZW4gdGhvdWdoIGl0IF9kb2VzXyByZXF1ZXN0IGFuZCBvYnRhaW4gYSBw cmVmaXggUCBhbmQgZG9lcyBSQSBpdCB0byBvdGhlciBub2RlcyBpbiB0aGUgbmV0d29yayBpbiBj b250cm9scy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB4DQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KDQogICAgICAgICAgICAgICAgICAgICB1 cHN0cmVhbSBsaW5rIHwNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQoN CiAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tKy0tLS0tLS0tLS0rDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgIHwgIHVwc3RyZWFtIGludGVyZmFjZSB8DQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICstLSstKy0tKy0rLS0rLS0tLS0rLS0rDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8DQoNCiAgICAgICAgICAgICAgICAgICAgICAg IHwgcmVxdWVzdGluZyBub2RlICdSJyB8DQoNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICB8DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0t LS0tLS0tLS0tLS0rDQoNCg0KDQoNCg0KDQoNCg0KDQpGb3IgY29tcGFyaXNvbiwgdGhlIGZpZ3Vy ZXMgcHJlc2VudCBub3cgaW4gLTIwIGFyZSB0aGVzZToNCg0KDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgeA0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwNCg0KICAgICAgICAgICAgICAgICAgICAgdXBzdHJlYW0gbGluayB8DQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfA0KDQogICAgICAgICAgICAgICAgICAgICAgICArLS0t LS0tLS0tLSstLS0tLS0tLS0tKw0KDQogICAgICAgICAgICAgICAgICAgICAgICB8ICB1cHN0cmVh bSBJbnRlcmZhY2UgfA0KDQogICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0t LS0tLS0tKw0KDQogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAg fA0KDQogICAgICAgICAgICAgICAgICAgICAgICB8IHJlcXVlc3Rpbmcgbm9kZSAnUicgfA0KDQog ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfA0KDQogICAgICAg ICAgICAgICAgICAgICAgICArLS0rLSstLSstKy0tKy0tLS0tKy0tKw0KDQogICAgICAgICAgICAg ICAgICAgICAgICB8QTF8IHxBMnwgfEEzfCAuLi4gfEFufA0KDQogICAgICAgICAgICAgICAgICAg ICAgICArLS0rLSstLSstKy0tKy0tLS0tKy0tKw0KDQogICAgICAgICAgICAgICAgICAgICAgICB8 ICB2aXJ0dWFsIEludGVyZmFjZSAgfA0KDQogICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0t LS0tLS0tLS0tLS0tLS0tKw0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAyOiBX ZWFrIEVuZCBTeXN0ZW0gTW9kZWwNCg0KDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHgNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQoNCiAg ICAgICAgICAgICAgICAgICAgIHVwc3RyZWFtIGxpbmsgfA0KDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwNCg0KICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0r LS0tLS0tLS0tLSsNCg0KICAgICAgICAgICAgICAgICAgICAgICAgfCAgdXBzdHJlYW0gaW50ZXJm YWNlIHwNCg0KICAgICAgICAgICAgICAgICAgICAgICAgKy0tKy0rLS0rLSstLSstLS0tLSstLSsN Cg0KICAgICAgICAgICAgICAgICAgICAgICAgfEExfCB8QTJ8IHxBM3wgLi4uIHxBbnwNCg0KICAg ICAgICAgICAgICAgICAgICAgICAgKy0tKy0rLS0rLSstLSstLS0tLSstLSsNCg0KICAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwNCg0KICAgICAgICAgICAgICAg ICAgICAgICAgfCByZXF1ZXN0aW5nIG5vZGUgJ1InIHwNCg0KICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgIHwNCg0KICAgICAgICAgICAgICAgICAgICAgICAgKy0t LS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0KICAgICAgICAgICAgICAgICAgICAgICAgfCAgIHZpcnR1 YWwgaW50ZXJmYWNlIHwNCg0KICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0t LS0tLS0tLSsNCg0KICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAzOiBTdHJvbmcgRW5kIFN5 c3RlbSBNb2RlbA0KDQoNCg0KDQoNCkxlIDMwLzA1LzIwMTggw6AgMDM6MTQsIEZyZWQgQmFrZXIg YSDDqWNyaXQgOg0KDQpHZW5lcmFsIHF1ZXN0aW9uIHRvIHRob3NlIHdobyBjb21tZW50ZWQgb24g dGhlIGRyYWZ0IHdoZW4gd2UgZGlzY3Vzc2VkIGl0IGEgZmV3IHdlZWtzIGFnbzogZG8geW91IGFn cmVlIHRoYXQgdGhpcyB1cGRhdGUgYWRkcmVzc2VzIHRoZSBpc3N1ZXMgeW91IHJhaXNlZD8gRG8g eW91IGhhdmUgZnVydGhlciBjb21tZW50cyBvbiBpdD8NCg0KDQoNCk9uIE1heSAyOSwgMjAxOCwg YXQgOToxMyBQTSwgVGVtcGxpbiAoVVMpLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5j b20+PG1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPiB3cm90ZToNCg0KVGhlIElFVEYg ZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQoNCmh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0Lw0KDQoNCg0K VGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KDQpodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGVtcGxpbi12Nm9wcy1wZGhvc3QtMjANCg0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC10ZW1wbGluLXY2b3BzLXBk aG9zdC0yMA0KDQoNCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxh YmxlIGF0Og0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtdGVtcGxp bi12Nm9wcy1wZGhvc3QtMjANCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KDQp2Nm9wcyBtYWlsaW5nIGxpc3QNCg0KdjZvcHNAaWV0Zi5v cmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Y2b3BzDQoNCg0KDQo= --_000_226862c69bcb48c9ac2abb87b4c7de59XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ29uc29s YXMiLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdj b2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgQWxleCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkdvb2QgcG9pbnQsIGJ1dCBJIHRoaW5rIHRoZSBuZXcgZmlndXJlIHlv dSBhcmUgcHJvcG9zaW5nIGlzIGFscmVhZHkgY292ZXJlZCB1bmRlcjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5maWd1cmUgMS4gRmlndXJlIDEgaXMgYW4gSW9UIHJvdXRlciB0aGF0IGRvZXMgUkEgdG8gb3Ro ZXIgbm9kZXMgaW4gdGhlIG5ldHdvcmtzIGl0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmNvbnRyb2xzIOKA kyB3aGV0aGVyIHRoZSBuZXR3b3JrcyBhcmUgaW50ZXJuYWwgdmlydHVhbCBuZXR3b3JrcyBvciBl eHRlcm5hbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5waHlzaWNhbCBuZXR3b3Jrcy4gUGVyaGFwcyBzb21l IGV4dHJhIHRleHQgdG8gZXhwbGFpbiB0aGUgSW9UIGFuZCBkb3duc3RlYW08bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+bmV0d29yayBSQSB1c2UgY2FzZSBpbiBjb25qdW5jdGlvbiB3aXRoIEZpZ3VyZSAxIHdv dWxkIGhlbHA/IEFueSBzdWdnZXN0aW9ucz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlRoYW5rcyAtIEZyZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0Ij4gdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+ T24gQmVoYWxmIE9mIDwvYj5BbGV4YW5kcmUgUGV0cmVzY3U8YnI+DQo8Yj5TZW50OjwvYj4gV2Vk bmVzZGF5LCBNYXkgMzAsIDIwMTggNjo0MSBBTTxicj4NCjxiPlRvOjwvYj4gdjZvcHNAaWV0Zi5v cmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gSVB2NiBQcmVmaXggRGVsZWdhdGlv biBNb2RlbHMgKCdkcmFmdC10ZW1wbGluLXY2b3BzLXBkaG9zdCcpIC0gZHJhZnQgdXBkYXRlPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkkg cHJvcG9zZSB0aGlzIGZpZ3VyZSBhcyB3ZWxsLCBpbiB3aGljaCBhbiBJb1Qgcm91dGVyICdSJyBk b2VzIG5vdCBmb3JtIGFueSBhZGRyZXNzIEEgb24gYW55IG9mIGl0cyBpbnRlcmZhY2VzLCBvdXQg b2YgdGhlIGRlbGVnYXRlZCBwcmVmaXggUCw8YnI+DQpldmVuIHRob3VnaCBpdCBfZG9lc18gcmVx dWVzdCBhbmQgb2J0YWluIGEgcHJlZml4IFAgYW5kIGRvZXMgUkEgaXQgdG8gb3RoZXIgbm9kZXMg aW4gdGhlIG5ldHdvcmsgaW4gY29udHJvbHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHByZT4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgeDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHVwc3RyZWFtIGxpbmsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLSYjNDM7PG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgdXBz dHJlYW0gaW50ZXJmYWNlIHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7JiM0MzstLSYjNDM7LSYjNDM7LS0mIzQzOy0mIzQzOy0tJiM0MzstLS0tLSYjNDM7 LS0mIzQzOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCByZXF1ZXN0aW5nIG5vZGUgJ1InIHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPHByZT5Gb3IgY29tcGFyaXNvbiwgdGhlIGZpZ3VyZXMgcHJlc2VudCBu b3cgaW4gLTIwIGFyZSB0aGVzZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgeDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVwc3RyZWFtIGxpbmsgfDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLSYjNDM7 LS0tLS0tLS0tLSYjNDM7PG86cD48L286cD48L3ByZT4NCjxwcmU+ICZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwO3wmbmJzcDsgdXBzdHJlYW0gSW50ZXJmYWNlIHw8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQz OzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCByZXF1 ZXN0aW5nIG5vZGUgJ1InIHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyYjNDM7LS0mIzQzOy0mIzQzOy0tJiM0MzstJiM0MzstLSYjNDM7LS0tLS0mIzQz Oy0tJiM0Mzs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fEExfCB8QTJ8IHxBM3wgLi4uIHxBbnw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJiM0MzstLSYjNDM7LSYjNDM7LS0mIzQzOy0mIzQzOy0tJiM0MzstLS0t LSYjNDM7LS0mIzQzOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7IHZpcnR1YWwgSW50ZXJmYWNlJm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tLS0tLS0m IzQzOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBGaWd1cmUgMjogV2VhayBFbmQgU3lzdGVtIE1vZGVsPG86cD48L286cD48 L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHg8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1cHN0cmVhbSBsaW5rIHw8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0mIzQzOy0t LS0tLS0tLS0mIzQzOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7IHVwc3RyZWFtIGludGVyZmFjZSB8PG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0mIzQzOy0mIzQzOy0tJiM0MzstJiM0Mzst LSYjNDM7LS0tLS0mIzQzOy0tJiM0Mzs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfEExfCB8QTJ8IHxBM3wgLi4uIHxBbnw8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLSYjNDM7LSYjNDM7LS0mIzQzOy0m IzQzOy0tJiM0MzstLS0tLSYjNDM7LS0mIzQzOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfCByZXF1ZXN0aW5nIG5vZGUgJ1InIHw8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0t LS0tLS0tJiM0Mzs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyB2aXJ0dWFsIGludGVyZmFjZSB8PG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0 Mzs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRmlndXJlIDM6IFN0cm9uZyBF bmQgU3lzdGVtIE1vZGVsPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48 L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxlIDMw LzA1LzIwMTggw6AgMDM6MTQsIEZyZWQgQmFrZXIgYSDDqWNyaXQmbmJzcDs6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHByZT5HZW5lcmFsIHF1ZXN0aW9uIHRvIHRob3NlIHdobyBjb21tZW50 ZWQgb24gdGhlIGRyYWZ0IHdoZW4gd2UgZGlzY3Vzc2VkIGl0IGEgZmV3IHdlZWtzIGFnbzogZG8g eW91IGFncmVlIHRoYXQgdGhpcyB1cGRhdGUgYWRkcmVzc2VzIHRoZSBpc3N1ZXMgeW91IHJhaXNl ZD8gRG8geW91IGhhdmUgZnVydGhlciBjb21tZW50cyBvbiBpdD88bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5PbiBNYXkgMjksIDIwMTgsIGF0IDk6 MTMgUE0sIFRlbXBsaW4gKFVTKSwgRnJlZCBMIDxhIGhyZWY9Im1haWx0bzpGcmVkLkwuVGVtcGxp bkBib2VpbmcuY29tIj4mbHQ7RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSZndDs8L2E+IHdyb3Rl OjxvOnA+PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBh Z2UgZm9yIHRoaXMgZHJhZnQgaXM6PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGVtcGxpbi12Nm9wcy1wZGhvc3Qv Ij5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10ZW1wbGluLXY2b3BzLXBk aG9zdC88L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4N CjxwcmU+VGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0OjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC10ZW1wbGluLXY2b3BzLXBkaG9zdC0yMCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0LTIwPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtdGVt cGxpbi12Nm9wcy1wZGhvc3QtMjAiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0 bWwvZHJhZnQtdGVtcGxpbi12Nm9wcy1wZGhvc3QtMjA8L2E+PG86cD48L286cD48L3ByZT4NCjxw cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+QSBkaWZmIGZyb20gdGhlIHByZXZpb3Vz IHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC10ZW1wbGluLXY2b3BzLXBk aG9zdC0yMCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXRlbXBsaW4t djZvcHMtcGRob3N0LTIwPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8 cHJlPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48 L286cD48L3ByZT4NCjxwcmU+djZvcHMgbWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxw cmU+PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Y2b3BzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2 b3BzPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8 L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_226862c69bcb48c9ac2abb87b4c7de59XCH150608nwnosboeingcom_-- From nobody Wed May 30 20:51:41 2018 Return-Path: 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 D625612EC52 for ; Wed, 30 May 2018 20:51:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 BwF2UHFX393o for ; Wed, 30 May 2018 20:51:33 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (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 BC81D12E865 for ; Wed, 30 May 2018 20:51:33 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id p9-v6so9066582pgc.9 for ; Wed, 30 May 2018 20:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:from:organization:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=+t/ezNosZpKrxrLI6fjpuvEYJT8mMktyEGvF3LP8YZY=; b=uwB5HzBnyAMdEy2SBxpuMqmmZ3ULctr2EicqFAVi0IyDP0zenTREvNZTkHj3l1mEfx I3MthBPyMeFh494U0e42YqQiK6wCOX58DScIU/7Df5RcZR4W/prltq4zLVgiB4Aqo6d6 48NPy7qx4q5BV10VgHG2r1xXcWcn1wYAoR4QnLklVdgwf3ve2QlXWxN4E9R0+bxxQOXo 9MOLBUYQ882pPk2AKZMQm3Y12S4wIN4XkXDpnP+ioV38T+xcusn14mAkgWoJiCWJfAFk N8Nz+wF91qKHJgcDsErw4duXWQVcHtdLISvZY+jvHpTLeo+BGOcoUDkUZKCz24g4xzTf Mh5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:from:organization:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=+t/ezNosZpKrxrLI6fjpuvEYJT8mMktyEGvF3LP8YZY=; b=I8MtpaK67AuDpJr4vz6KCsZQ4zoAwEea9KqddrJ6HgTK0tqxYqd9DVvo+/HXZX7jRs k8n9OZ/oHWDNJ8JDQ/CbXtOadAsLNhW+TP0YXw/ztt4eAieP53EE07B9z1g1m3Yqet9W l9TVt9LuBGoUejBBKk7jqm13TDRWrjeoHPpanL3RaMmeFiuRORXy8uAFPEX1ddYRPUxz g6KeTkgDaEz+mWoj74nLLsO/puc8zPBahC+wU+boVTcTO70HYh+IBYbe95jLYKJk9XL2 EOQT9UOOf2fwoNyjiHG3HXaidmbn7hvL6xWvQ+/o0fAJr6q7Cx/08y6fWWsQyuVuXPCE Jh9w== X-Gm-Message-State: ALKqPwf4zWiGjwMeFoKxCRG4kbUFeV9OXgEeWoPBCJyxAoGq9qrCEW2J spmWt4Xidocn2SqunJRhZ3WI7w== X-Google-Smtp-Source: ADUXVKKIaYoFxuEYDFW0sDBIwOXAV2F6fRLmtu2xO0LxRutyQwt57J50gSjhOCptw3Yw1+jEiOvIfA== X-Received: by 2002:a62:a89:: with SMTP id 9-v6mr5190287pfk.112.1527738692880; Wed, 30 May 2018 20:51:32 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id z82-v6sm981691pfk.30.2018.05.30.20.51.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 May 2018 20:51:31 -0700 (PDT) To: IPv6 Operations From: Brian E Carpenter Organization: University of Auckland Message-ID: <17a0f0e1-c822-21e8-31e0-41c96ae1b2a5@gmail.com> Date: Thu, 31 May 2018 15:51:34 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] =?utf-8?q?Internet_engineers_tear_into_United_Nations=27_?= =?utf-8?q?plan_to_move_us_all_to_IPv6_=E2=80=A2_The_Register?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 03:51:39 -0000 Ignoring the journalistic exaggerations in the article (2nd link below), do we have a liaison comment going to the ITU about this draft? https://regmedia.co.uk/2018/05/30/itu-ipv6-may18.pdf It seems to be an excellent recipe for burning up address space. The due date appears to be now. http://www.theregister.co.uk/2018/05/30/internet_engineers_united_nations_ipv6/ Regards Brian From nobody Wed May 30 23:42:01 2018 Return-Path: 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 E055C12D779 for ; Wed, 30 May 2018 23:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] 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 hNp1QcVgo7T1 for ; Wed, 30 May 2018 23:41:57 -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 17B3A12EC7A for ; Wed, 30 May 2018 23:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1527748915; x=1528353715; 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=6DHgXPte tEYVJ3ZnS10/JnJryoui3lpkoCiJPJg9D3k=; b=OXyevJhBaMpJFFfNq8kc3nbD 8JoKOYG4uAe/MwI2bIgAl/CCXU2rj+b9m2SenGI6ttZiqzyi/Y3bAW1CzyxIZfJb W51lZyrS/shfiwOrsSFwAn/BDoRwOA2KOWV6ku0E2Uz8StKE1Qqo+iF4jdprJLZJ TX3p1CPy7mLlscSCGC8= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 31 May 2018 08:41:55 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 31 May 2018 08:41:54 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005779934.msg for ; Thu, 31 May 2018 08:41:54 +0200 X-MDRemoteIP: 2001:470:1f09:495:b8:8d45:6342:1bd6 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Thu, 31 May 2018 08:41:54 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1689f535b5=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Thu, 31 May 2018 08:41:53 +0200 From: JORDI PALET MARTINEZ To: IPv6 Operations Message-ID: Thread-Topic: [v6ops] Internet engineers tear into United Nations' plan to move us all to IPv6 =?UTF-8?B?4oCi?= The Register References: <17a0f0e1-c822-21e8-31e0-41c96ae1b2a5@gmail.com> In-Reply-To: <17a0f0e1-c822-21e8-31e0-41c96ae1b2a5@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] =?utf-8?q?Internet_engineers_tear_into_United_Nations=27?= =?utf-8?q?_plan_to_move_us_all_to_IPv6_=E2=80=A2_The_Register?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 06:42:00 -0000 It was presented two weeks ago in the IPv6 WG of the RIPE meeting in Marsei= lle, with a strong opposition. You can track also the comments in the mailing list archive. I explicitly suggested that this is topic of IETF, and they should come to = v6ops or 6man or one of the IoT WGs if they really believe this is right. RIRs also have liaison and are working to tell them that this is really bro= ken. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Brian E Carpenter Organizaci=C3=B3n: University of Auckland Fecha: jueves, 31 de mayo de 2018, 5:52 Para: IPv6 Operations Asunto: [v6ops] Internet engineers tear into United Nations' plan to move u= s all to IPv6 =E2=80=A2 The Register Ignoring the journalistic exaggerations in the article (2nd link below)= , do we have a liaison comment going to the ITU about this draft? https://regmedia.co.uk/2018/05/30/itu-ipv6-may18.pdf It seems to be an excellent recipe for burning up address space. The due date appears to be now. =20 http://www.theregister.co.uk/2018/05/30/internet_engineers_united_natio= ns_ipv6/ =20 Regards Brian =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** 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 con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed May 30 23:48:18 2018 Return-Path: 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 5C68A12E870 for ; Wed, 30 May 2018 23:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] 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 6hiLZGccUuXc for ; Wed, 30 May 2018 23:48:16 -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 E88A5127333 for ; Wed, 30 May 2018 23:48:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1527749291; x=1528354091; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:Mime-version: Content-type:Content-transfer-encoding; bh=2k4Ho793ryRbxW7PRMcb3 L9rbIvMg8i0Y5UnaU30vn8=; b=rGS8MQTduDFUnO42tm00pRT49No4i0yVQ3wTA rITHC28jAt+liVGwm2VTsLZJvvDX4hcfRkN4eNsKmZC1k3sfXM8nRYRo+2HRT++3 Rcoi2GDVuhii/8FmJJSwVJ8yKhsYecl9tVj/UCJvbKzXUi+4ntI2UIbA8XFZXb1R Yq6Le0= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 31 May 2018 08:48:11 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 31 May 2018 08:48:10 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005779937.msg for ; Thu, 31 May 2018 08:48:09 +0200 X-MDRemoteIP: 2001:470:1f09:495:b8:8d45:6342:1bd6 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Thu, 31 May 2018 08:48:09 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1689f535b5=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Thu, 31 May 2018 08:48:08 +0200 From: JORDI PALET MARTINEZ To: IPv6 Operations Message-ID: <59AC1E5C-31FF-4D74-B15F-76EBDD3D9362@consulintel.es> Thread-Topic: [v6ops] Internet engineers tear into United Nations' plan to move us all to IPv6 =?UTF-8?B?4oCi?= The Register Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] =?utf-8?q?Internet_engineers_tear_into_United_Nations=27?= =?utf-8?q?_plan_to_move_us_all_to_IPv6_=E2=80=A2_The_Register?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 06:48:17 -0000 Just realized, you have even the video of the presentation and what was sai= d after ... https://ripe76.ripe.net/programme/meeting-plan/ipv6-wg/ Also, the mail archive is here: https://www.ripe.net/ripe/mail/archives/ipv6-wg/ Saludos, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de JORDI PALET MARTINEZ Fecha: jueves, 31 de mayo de 2018, 8:42 Para: IPv6 Operations Asunto: Re: [v6ops] Internet engineers tear into United Nations' plan to m= ove us all to IPv6 =E2=80=A2 The Register It was presented two weeks ago in the IPv6 WG of the RIPE meeting in Ma= rseille, with a strong opposition. =20 You can track also the comments in the mailing list archive. =20 I explicitly suggested that this is topic of IETF, and they should come= to v6ops or 6man or one of the IoT WGs if they really believe this is righ= t. =20 RIRs also have liaison and are working to tell them that this is really= broken. =20 Regards, Jordi =20 =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Brian E Carpenter Organizaci=C3=B3n: University of Auckland Fecha: jueves, 31 de mayo de 2018, 5:52 Para: IPv6 Operations Asunto: [v6ops] Internet engineers tear into United Nations' plan to mo= ve us all to IPv6 =E2=80=A2 The Register =20 Ignoring the journalistic exaggerations in the article (2nd link be= low), do we have a liaison comment going to the ITU about this draft? https://regmedia.co.uk/2018/05/30/itu-ipv6-may18.pdf It seems to be an excellent recipe for burning up address space. The due date appears to be now. =20 http://www.theregister.co.uk/2018/05/30/internet_engineers_united_n= ations_ipv6/ =20 Regards Brian =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company =20 This electronic message contains information which may be privileged or= confidential. The information is intended to be for the exclusive use of t= he individual(s) named above and further non-explicilty authorized disclosu= re, 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 awa= re that any disclosure, copying, distribution or use of the contents of thi= s information, even if partially, including attached files, is strictly pro= hibited, will be considered a criminal offense, so you must reply to the or= iginal sender to inform about this communication and delete it. =20 =20 =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** 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 con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu May 31 01:17:16 2018 Return-Path: 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 52D5E12DA4A for ; Thu, 31 May 2018 01:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.21 X-Spam-Level: X-Spam-Status: No, score=-18.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 xRFZi7ZUFW24 for ; Thu, 31 May 2018 01:17:10 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 9FBD812EB22 for ; Thu, 31 May 2018 01:17:09 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id q4-v6so1869876wmq.1 for ; Thu, 31 May 2018 01:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GCb5/Ue7ZTrN1wcnDGf6AlOPYMn188cIA4a1JsWf+eE=; b=D8iV4lhPeTJasuV3QC3FeALj2jObDOg2StcBegBNW1BAKCEECf+eMptbL3hRAlbnFp CiBmOj/zHjMnXlKiE7k2MUuBxEGwnmVggF+qBqwz+R7bsKgISSePQ2ASvDkYp3cgE7ck G2HU5aG+eTmkPq9cXnRDQhzH7Tjx7+xvChBdeZnYI7L8cniGUOWT5BPDvBJpnM2fe5bS Yf6NNVc9CL9oFel1PPdHWBc/A2cfi7IT/MxUeyMP+bW8POEha60G7/81w/Ipp9eSMgIF hM29AT2t/Xobl2ShQMxZrnyDIso2CXQNiNUhbxT19upIZFyC79d2P7RgczyG04HZg8bU d9dw== 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=GCb5/Ue7ZTrN1wcnDGf6AlOPYMn188cIA4a1JsWf+eE=; b=KPJ1zr5deRK8O4mWNQgbD2Leo7aDaAxBr0j2OUMfBtnC0XOK342bzTrm/3XmsxmScX q3i6xhdsci/029tqejIkVWPEzSipvKLfHmaTuBkDwHWBUGEOss2fP+gIHD3Bz7TWoRPg ixpxXxEdpLAkGcuuZTDtWZqJDdfCllct1Vz5VV4QjAQijg8AjP0oPd3vuxI6a7f423R6 aepCeqRmKVk5Q+f80hYlhJyVgvBxLk4FcghDwPtrz7f4MK8wVuZhjm74u6GBtNKiMKSv b1/cGG5xnQnfcbT7p9mwMm2YbxLfzetEOIYtfb/tfzvuInjFbCW2mwY21mVm/7EG3J+3 6/Ng== X-Gm-Message-State: ALKqPwd4n8RdOtiZCyDvP/VBTjn4321DU81DcQojU4aBx3ZJ9GD6Xj3O mpwDenc1mQA2JgFjyn17cwY3wRAMRoSS5h03szT/vA== X-Google-Smtp-Source: ADUXVKLPgbl1amzzNIxWEH4Ib5oCVo/aUMGWjwgzbOxOfk5wZmz/flbZDp3F+UeaqU4zccuPiOnfnOGa6+d2gtnoZ2g= X-Received: by 2002:a1c:911:: with SMTP id 17-v6mr3371192wmj.5.1527754627907; Thu, 31 May 2018 01:17:07 -0700 (PDT) MIME-Version: 1.0 References: <59AC1E5C-31FF-4D74-B15F-76EBDD3D9362@consulintel.es> In-Reply-To: <59AC1E5C-31FF-4D74-B15F-76EBDD3D9362@consulintel.es> From: Erik Kline Date: Thu, 31 May 2018 17:16:53 +0900 Message-ID: To: jordi.palet=40consulintel.es@dmarc.ietf.org Cc: "v6ops@ietf.org WG" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000ed03e3056d7c1781" Archived-At: Subject: Re: [v6ops] =?utf-8?q?Internet_engineers_tear_into_United_Nations=27?= =?utf-8?q?_plan_to_move_us_all_to_IPv6_=E2=80=A2_The_Register?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 08:17:15 -0000 --000000000000ed03e3056d7c1781 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My reading of the doc was that's is mostly "if you have a {/56,/48,...} here's how you might carve it up to provide sub-networks of different service types". I don't see any strong "requirements" language that leads me to think this is anything other than one possible network layout. On Thu, 31 May 2018 at 15:48, JORDI PALET MARTINEZ wrote: > > Just realized, you have even the video of the presentation and what was s= aid after ... > > https://ripe76.ripe.net/programme/meeting-plan/ipv6-wg/ > > Also, the mail archive is here: > > https://www.ripe.net/ripe/mail/archives/ipv6-wg/ > > > Saludos, > Jordi > > > > =EF=BB=BF-----Mensaje original----- > De: v6ops en nombre de JORDI PALET MARTINEZ > Fecha: jueves, 31 de mayo de 2018, 8:42 > Para: IPv6 Operations > Asunto: Re: [v6ops] Internet engineers tear into United Nations' plan to= move us all to IPv6 =E2=80=A2 The Register > > It was presented two weeks ago in the IPv6 WG of the RIPE meeting in = Marseille, with a strong opposition. > > You can track also the comments in the mailing list archive. > > I explicitly suggested that this is topic of IETF, and they should co= me to v6ops or 6man or one of the IoT WGs if they really believe this is ri= ght. > > RIRs also have liaison and are working to tell them that this is real= ly broken. > > Regards, > Jordi > > > > =EF=BB=BF-----Mensaje original----- > De: v6ops en nombre de Brian E Carpenter > Organizaci=C3=B3n: University of Auckland > Fecha: jueves, 31 de mayo de 2018, 5:52 > Para: IPv6 Operations > Asunto: [v6ops] Internet engineers tear into United Nations' plan to = move us all to IPv6 =E2=80=A2 The Register > > Ignoring the journalistic exaggerations in the article (2nd link = below), > do we have a liaison comment going to the ITU about this draft? > https://regmedia.co.uk/2018/05/30/itu-ipv6-may18.pdf > It seems to be an excellent recipe for burning up address space. > The due date appears to be now. > > http://www.theregister.co.uk/2018/05/30/internet_engineers_united= _nations_ipv6/ > > Regards > Brian > > > _______________________________________________ > 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 disclo= sure, copying, distribution or use of the contents of this information, eve= n if partially, including attached files, is strictly prohibited and will b= e considered a criminal offense. If you are not the intended recipient be a= ware that any disclosure, copying, distribution or use of the contents of t= his information, even if partially, including attached files, is strictly p= rohibited, 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 c= onfidential. 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 co= nsidered 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 prohi= bited, will be considered a criminal offense, so you must reply to the orig= inal sender to inform about this communication and delete it. > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --000000000000ed03e3056d7c1781 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMfg1wtYggohADxbT3MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MDIxNTA2MzcxNVoXDTE4MDgx NDA2MzcxNVowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANinyejqC3lpuuurPEnTTJsSB+LPui3CT4Cg4PEUVzKZf9l4ircMhwI8 LZmiRwWqg1CReYbVM1JTiQ6gJpWdGaiEdylfMEcCm6RMnuHA8k97/AqBUZti6ZGbtl77UEblK2Ok Qwai1Kza2k2CkjfnzfugTdF/XzOCF9BOYrW/B+fM2MGf7e48qKtoA2FGlTOOaitLYJJBaixBWQUZ oVO6XVPC7mhSoW1Wc7uwD85Yvuf1Qq0MXkxqgAXxJ1xBSS7KVJAIPPlXS3vtxFwmeqDlFIqNB9lY KwU08whM2akO03ENo0ixPJL3kSEafnFiQzVhXTLsgqbCA0lrfH2j4F8/wrMCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBS6wTowyOTvuUJ3LG0j/H1PWoaTrjAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAavJqbhv0cDn0rYD5aMbNL6cvp5a2 9oeeMhRGx55RMI7YywkO91RBJjzKAHWvb9Q2sdoQ/5PBmzEsFyYRhK68AnDE/h/GMhZPqK0p9JMe e1OSiWYexcjPi4ibnMkIBO+GMeTYQPweBfiD4pTwDPaKib+29SM5520Ba6C88h2wNEabdWj9EypL i/utAs30iZ97nKVXDFAgYvOORj5bQAnGAIZHIqSw2xAUu0l59uxdqW3mcZs/6JPrWEGjDh2enVmp BIiQJzNtVktT+lQInKeeJQM4jt+s/RE1m/GacTJZ63MNk9mE5Xn/hbmTkEgBSPu6/6gl1JnrIdTf Aex0alwnMTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDH4NcLWIIKIQA8W09zAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgnZwcKnpaqxG4X1W7CdK4UwafECI4ZXAi 2tFuismjLWswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwNTMx MDgxNzA4WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBADxJDQqOt250a6okZCUHleuif5u/Sz37vLjC20o+ooHzuJ9ZoXSv 9btE/AUGK2Z29Hl+viNicAGzLmRwGg646i8m/KWcpY+bdq7zRhWKmJkpl1zEBWMieH2wSNDbMBw1 YvFpENw/ljOtka+BkLyNVVOxSRW/Ka9MiEFkNch7mpOH+vMMNUdjQNM+TrQxFjxB1rlDL8y0FKiv wwnnUIO+h31NrjPEx2VWMKkdVPpEdAzOS5DWMafd1FSZn0Awjcf37q//mcdXScrLQbfQ5AEEUyj+ OPSP4MJRv7NU+XnIbZlqEqgC/EZ73si2wMQK57AaVOW5SHvSFFDos5PEu63wpAE= --000000000000ed03e3056d7c1781-- From nobody Thu May 31 01:46:32 2018 Return-Path: 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 9156B12F3D3 for ; Thu, 31 May 2018 01:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable 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 JfTHZjLqwQAb for ; Thu, 31 May 2018 01:46:29 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1CDD12F3D6 for ; Thu, 31 May 2018 01:46:28 -0700 (PDT) X-Envelope-To: v6ops@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id w4V8kOXf087949 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 May 2018 09:46:24 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local To: JORDI PALET MARTINEZ Cc: IPv6 Operations References: <17a0f0e1-c822-21e8-31e0-41c96ae1b2a5@gmail.com> From: Nick Hilliard Message-ID: Date: Thu, 31 May 2018 09:46:23 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 PostboxApp/6.0.10 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] =?utf-8?q?Internet_engineers_tear_into_United_Nations=27?= =?utf-8?q?_plan_to_move_us_all_to_IPv6_=E2=80=A2_The_Register?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 08:46:30 -0000 JORDI PALET MARTINEZ wrote on 31/05/2018 07:41: > RIRs also have liaison and are working to tell them that this is really broken. the principal problem with that work item is not that it's broken and arbitrary (which it is), it's that this is out of scope for the ITU. IP resource number models are simply not their business and they should refrain from scope creep like this. Nick From nobody Thu May 31 02:00:56 2018 Return-Path: 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 1DD0912EC79 for ; Thu, 31 May 2018 02:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] 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 nyW5Rb1aFQ7J for ; Thu, 31 May 2018 02:00:52 -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 F30A712EBE9 for ; Thu, 31 May 2018 02:00:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1527757250; x=1528362050; 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=4GN4HPYt M0zC6bAJFW+s0Qf3DsepuF4QPZIbtlVtpmo=; b=l1W6dkzQMKAQswpXmdIjAoN5 fASRzVqsB0EZHWHqgLcieW4Stz6Cm48BOihlbs56zSQbZD65K6qyVFRWyaAFru4d reH4OIMy4vvUHISLOFJP37LChYv9x4ByFLJSFN8xvkOyecej8HNWWcl3N5LWakua Qd74ENEEn3rX+jqM5rs= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 31 May 2018 11:00:50 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 31 May 2018 11:00:50 +0200 Received: from [10.10.10.129] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005780034.msg for ; Thu, 31 May 2018 11:00:50 +0200 X-MDRemoteIP: 2001:470:1f09:495:b8:8d45:6342:1bd6 X-MDHelo: [10.10.10.129] X-MDArrival-Date: Thu, 31 May 2018 11:00:50 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1689f535b5=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.d.1.180523 Date: Thu, 31 May 2018 11:00:47 +0200 From: JORDI PALET MARTINEZ To: IPv6 Operations Message-ID: <04B55F4D-E875-4C6F-994C-DB7C3023516C@consulintel.es> Thread-Topic: [v6ops] Internet engineers tear into United Nations' plan to move us all to IPv6 =?UTF-8?B?4oCi?= The Register References: <17a0f0e1-c822-21e8-31e0-41c96ae1b2a5@gmail.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] =?utf-8?q?Internet_engineers_tear_into_United_Nations=27?= =?utf-8?q?_plan_to_move_us_all_to_IPv6_=E2=80=A2_The_Register?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 09:00:55 -0000 I think we all know (my "broken" was not only in the technical sense ...), = and even if we solve the political issues, the right scope is IETF and/or R= IRs, which I said during the meeting and in the RIPE IPv6 WG mailing list. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Nick Hilliard Fecha: jueves, 31 de mayo de 2018, 10:47 Para: JORDI PALET MARTINEZ CC: IPv6 Operations Asunto: Re: [v6ops] Internet engineers tear into United Nations' plan to m= ove us all to IPv6 =E2=80=A2 The Register JORDI PALET MARTINEZ wrote on 31/05/2018 07:41: > RIRs also have liaison and are working to tell them that this is real= ly broken. =20 the principal problem with that work item is not that it's broken and= =20 arbitrary (which it is), it's that this is out of scope for the ITU. =20 IP resource number models are simply not their business and they should= =20 refrain from scope creep like this. =20 Nick =20 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ********************************************** 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 con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Thu May 31 02:23:16 2018 Return-Path: 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 098B1127419 for ; Thu, 31 May 2018 02:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk 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 aEDEkuQTQZ4o for ; Thu, 31 May 2018 02:23:09 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99B1A12D87E for ; Thu, 31 May 2018 02:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1527758587; h=from:subject:date:message-id:to:cc:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=HvQoDExvQKbfpGZ3tUnobnEOPwkurkxag1smd0oNa3o=; b=Wpn5NmgC3fpr4zYV4soH3qieZlVO5Vjrra0dFzYwzKalMPBWu0dqtQtIQUU99iaOS2BozXseZW0B5/ffUgjaS6LD8WYvJ20k4EC2P4YNv9YLJnYku7Yz4WcrAH6qIoFUnPdaIofcTjLWUhavrR+Lx0frMGni28Wk2m0V03W8qaE= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0243.outbound.protection.outlook.com [213.199.154.243]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-134-uStgwNfbOj2vnl4D-dKn8A-1; Thu, 31 May 2018 10:23:05 +0100 Received: from AM0PR07MB4177.eurprd07.prod.outlook.com (52.133.59.156) by AM0PR07MB4228.eurprd07.prod.outlook.com (52.133.60.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.820.5; Thu, 31 May 2018 09:23:04 +0000 Received: from AM0PR07MB4177.eurprd07.prod.outlook.com ([fe80::40e2:b716:ed5:7175]) by AM0PR07MB4177.eurprd07.prod.outlook.com ([fe80::40e2:b716:ed5:7175%2]) with mapi id 15.20.0820.007; Thu, 31 May 2018 09:23:04 +0000 From: Tim Chown To: JORDI PALET MARTINEZ CC: IPv6 Operations Thread-Topic: =?utf-8?B?W3Y2b3BzXSAgSW50ZXJuZXQgZW5naW5lZXJzIHRlYXIgaW50byBVbml0ZWQg?= =?utf-8?B?TmF0aW9ucycgcGxhbiB0byBtb3ZlIHVzIGFsbCB0byBJUHY2IOKAoiBUaGUg?= =?utf-8?Q?Register?= Thread-Index: AQHT+Kt1WOmO7h+g8UKerolOPCCkKKRJkJyA Date: Thu, 31 May 2018 09:23:04 +0000 Message-ID: <07CD18BD-283D-4281-8657-3A26CADEC205@jisc.ac.uk> References: <59AC1E5C-31FF-4D74-B15F-76EBDD3D9362@consulintel.es> In-Reply-To: <59AC1E5C-31FF-4D74-B15F-76EBDD3D9362@consulintel.es> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.6.18) x-originating-ip: [2001:a88:d510:1101:4087:ed7c:2910:370b] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM0PR07MB4228; 7:cXlOLOOh9JGgKHl7cvJO6mr63JBa7aSv13XBP5hCxsWEWdILntbkVPjRUckSFKL0edaJzOFdGMW1dR2F47thMjkgLlntCS5JqQB144WFlYcgyMO7K2lbC57j8prFqBLF0ai3FolHjS+v58ojttuAZhDJgTvvaK6Sk1hmuAW9K0wDo34bO1/nxPh1r/elfBTChFjpXG8fBfkSF6X+zfkSKXH5b8q+4m2+MdE9417UDvSgxl6NSjHiPQbtbrJWDPDo; 20:Bpm7vh51bhINxtF/QNKRDtVVI8m/uwn9qF6KJKJRsPtTGB3mk5rCT276UUZBwThNHRznX3S3r2T6V38qmw327PVAeEmJa499E+rOJjCmR1UfnVvnFR0F4h9DuNXOGsGluaB9Q33qfYa1Y8j7T2tP5/f/F11yIaa9SGVLHB39Lrg= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:AM0PR07MB4228; x-ms-traffictypediagnostic: AM0PR07MB4228: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231254)(944501410)(52105095)(149027)(150027)(6041310)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:AM0PR07MB4228; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB4228; x-forefront-prvs: 06891E23FB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(376002)(39850400004)(39380400002)(396003)(59124004)(199004)(189003)(122424002)(83716003)(486006)(68736007)(53546011)(59450400001)(6506007)(3660700001)(3280700002)(4326008)(551964002)(6436002)(11346002)(446003)(5660300001)(476003)(2616005)(102836004)(6486002)(229853002)(57306001)(99286004)(5890100001)(5250100002)(81156014)(81166006)(36756003)(46003)(50226002)(7736002)(186003)(6116002)(2906002)(8936002)(76176011)(305945005)(316002)(786003)(86362001)(97736004)(561944003)(72206003)(478600001)(2900100001)(14454004)(53936002)(6246003)(33656002)(966005)(82746002)(105586002)(6512007)(6306002)(53386004)(106356001)(74482002)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB4228; H:AM0PR07MB4177.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-microsoft-antispam-message-info: tKp+KU2gTjYkQI9Xm+DFs3Whed1aPFVij0DbSqwZZyftHl1/t+oGduLfnzAsDIrryUXzm3FKTZ2AoGi8kBWbcU1HNm26G1W8lm2RG//CPifhkkF/qGbY/aLFnfLAmu6nPcPV5m2qIzj7hMadrHRiScsXoWwAy+vVNDKuZoWCUC535+Txf3/pjyZvXTo+prZY spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <2E4B3016D6040548A271736EC8E362BC@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: c8db92d0-0f42-4bd8-dc38-08d5c6d81d28 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: c8db92d0-0f42-4bd8-dc38-08d5c6d81d28 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2018 09:23:04.6777 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4228 X-MC-Unique: uStgwNfbOj2vnl4D-dKn8A-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] =?utf-8?q?Internet_engineers_tear_into_United_Nations=27?= =?utf-8?q?_plan_to_move_us_all_to_IPv6_=E2=80=A2_The_Register?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 09:23:14 -0000 SGksDQoNCj4gT24gMzEgTWF5IDIwMTgsIGF0IDA3OjQ4LCBKT1JESSBQQUxFVCBNQVJUSU5FWiA8 am9yZGkucGFsZXQ9NDBjb25zdWxpbnRlbC5lc0BkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQo+IA0K PiBKdXN0IHJlYWxpemVkLCB5b3UgaGF2ZSBldmVuIHRoZSB2aWRlbyBvZiB0aGUgcHJlc2VudGF0 aW9uIGFuZCB3aGF0IHdhcyBzYWlkIGFmdGVyIC4uLg0KPiANCj4gaHR0cHM6Ly9yaXBlNzYucmlw ZS5uZXQvcHJvZ3JhbW1lL21lZXRpbmctcGxhbi9pcHY2LXdnLw0KDQpUaGUgYXVkaW8gaXMgcmVh bGx5IHBvb3IgcXVhbGl0eSwgbGFyZ2VseSBpbmF1ZGlibGUuDQoNCj4gQWxzbywgdGhlIG1haWwg YXJjaGl2ZSBpcyBoZXJlOg0KPiANCj4gaHR0cHM6Ly93d3cucmlwZS5uZXQvcmlwZS9tYWlsL2Fy Y2hpdmVzL2lwdjYtd2cvDQoNCkZyb20gdGhlIHNsaWRlIGRlY2sgaXQgc2VlbXMgdGhlcmUgaXMg bm8gcHJvcG9zYWwgdG8gYWxsb2NhdGUgYWRkcmVzcyBzcGFjZSB0aHJvdWdoIGFueSBtZWFucyBv dGhlciB0aGFuIHRoZSBSSVJzOyB0aGUgZGVjayBvbmx5IGdpdmVzIHN1Z2dlc3Rpb25zIGZvciBo b3cgYW4gImVuZCB1c2VyIiBtaWdodCBmb3JtIGFuIGFkZHJlc3MgcGxhbiBnaXZlbiB0aGF0IGFs bG9jYXRpb24uICBJc24ndCB0aGF0IHRoZSBjYXNlLCBvciBhbSBJIG1pc3JlYWRpbmcgaXQ/ICBJ IGRvbid0IHRoaW5rIHRoZWlyIGFkZHJlc3MgcGxhbm5pbmcgcmVjb21tZW5kYXRpb24gaXMgcGFy dGljdWxhcmx5IHBydWRlbnQsIGJ1dCBhbnlvbmUgaXMgYWJsZSB0byB3cml0ZSBzdWNoIGRvY3Vt ZW50cywgYW5kIG1hbnkgcGVvcGxlIGhhdmUgZG9uZSBzbyENCg0KSSByZWd1bGFybHkgcG9pbnQg cGVvcGxlIGF0IHRoZSBSSVBFIGFkZHJlc3MgcGxhbm5pbmcgZG9jdW1lbnQgd2hpY2ggSSByZWNh bGwgd2FzIG9yaWdpbmFsbHkgd3JpdHRlbiBieSBTVVJGbmV0LCBhbW9uZ3N0IG90aGVyczsgdGhl cmUncyBsb3RzIG9mIGJldHRlciBtYXRlcmlhbCBhbHJlYWR5IG91dCB0aGVyZS4NCg0KVGltDQoN Cj4gDQo+IFNhbHVkb3MsDQo+IEpvcmRpDQo+IA0KPiANCj4gDQo+IO+7vy0tLS0tTWVuc2FqZSBv cmlnaW5hbC0tLS0tDQo+IERlOiB2Nm9wcyA8djZvcHMtYm91bmNlc0BpZXRmLm9yZz4gZW4gbm9t YnJlIGRlIEpPUkRJIFBBTEVUIE1BUlRJTkVaIDxqb3JkaS5wYWxldD00MGNvbnN1bGludGVsLmVz QGRtYXJjLmlldGYub3JnPg0KPiBGZWNoYToganVldmVzLCAzMSBkZSBtYXlvIGRlIDIwMTgsIDg6 NDINCj4gUGFyYTogSVB2NiBPcGVyYXRpb25zIDx2Nm9wc0BpZXRmLm9yZz4NCj4gQXN1bnRvOiBS ZTogW3Y2b3BzXSAgSW50ZXJuZXQgZW5naW5lZXJzIHRlYXIgaW50byBVbml0ZWQgTmF0aW9ucycg cGxhbiB0byBtb3ZlIHVzIGFsbCB0byBJUHY2IOKAoiBUaGUgUmVnaXN0ZXINCj4gDQo+ICAgIEl0 IHdhcyBwcmVzZW50ZWQgdHdvIHdlZWtzIGFnbyBpbiB0aGUgSVB2NiBXRyBvZiB0aGUgUklQRSBt ZWV0aW5nIGluIE1hcnNlaWxsZSwgd2l0aCBhIHN0cm9uZyBvcHBvc2l0aW9uLg0KPiANCj4gICAg WW91IGNhbiB0cmFjayBhbHNvIHRoZSBjb21tZW50cyBpbiB0aGUgbWFpbGluZyBsaXN0IGFyY2hp dmUuDQo+IA0KPiAgICBJIGV4cGxpY2l0bHkgc3VnZ2VzdGVkIHRoYXQgdGhpcyBpcyB0b3BpYyBv ZiBJRVRGLCBhbmQgdGhleSBzaG91bGQgY29tZSB0byB2Nm9wcyBvciA2bWFuIG9yIG9uZSBvZiB0 aGUgSW9UIFdHcyBpZiB0aGV5IHJlYWxseSBiZWxpZXZlIHRoaXMgaXMgcmlnaHQuDQo+IA0KPiAg ICBSSVJzIGFsc28gaGF2ZSBsaWFpc29uIGFuZCBhcmUgd29ya2luZyB0byB0ZWxsIHRoZW0gdGhh dCB0aGlzIGlzIHJlYWxseSBicm9rZW4uDQo+IA0KPiAgICBSZWdhcmRzLA0KPiAgICBKb3JkaQ0K PiANCj4gDQo+IA0KPiAgICDvu78tLS0tLU1lbnNhamUgb3JpZ2luYWwtLS0tLQ0KPiAgICBEZTog djZvcHMgPHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc+IGVuIG5vbWJyZSBkZSBCcmlhbiBFIENhcnBl bnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPg0KPiAgICBPcmdhbml6YWNpw7NuOiBV bml2ZXJzaXR5IG9mIEF1Y2tsYW5kDQo+ICAgIEZlY2hhOiBqdWV2ZXMsIDMxIGRlIG1heW8gZGUg MjAxOCwgNTo1Mg0KPiAgICBQYXJhOiBJUHY2IE9wZXJhdGlvbnMgPHY2b3BzQGlldGYub3JnPg0K PiAgICBBc3VudG86IFt2Nm9wc10gSW50ZXJuZXQgZW5naW5lZXJzIHRlYXIgaW50byBVbml0ZWQg TmF0aW9ucycgcGxhbiB0byBtb3ZlIHVzIGFsbCB0byBJUHY2IOKAoiBUaGUgUmVnaXN0ZXINCj4g DQo+ICAgICAgICBJZ25vcmluZyB0aGUgam91cm5hbGlzdGljIGV4YWdnZXJhdGlvbnMgaW4gdGhl IGFydGljbGUgKDJuZCBsaW5rIGJlbG93KSwNCj4gICAgICAgIGRvIHdlIGhhdmUgYSBsaWFpc29u IGNvbW1lbnQgZ29pbmcgdG8gdGhlIElUVSBhYm91dCB0aGlzIGRyYWZ0Pw0KPiAgICAgICAgaHR0 cHM6Ly9yZWdtZWRpYS5jby51ay8yMDE4LzA1LzMwL2l0dS1pcHY2LW1heTE4LnBkZg0KPiAgICAg ICAgSXQgc2VlbXMgdG8gYmUgYW4gZXhjZWxsZW50IHJlY2lwZSBmb3IgYnVybmluZyB1cCBhZGRy ZXNzIHNwYWNlLg0KPiAgICAgICAgVGhlIGR1ZSBkYXRlIGFwcGVhcnMgdG8gYmUgbm93Lg0KPiAN Cj4gICAgICAgIGh0dHA6Ly93d3cudGhlcmVnaXN0ZXIuY28udWsvMjAxOC8wNS8zMC9pbnRlcm5l dF9lbmdpbmVlcnNfdW5pdGVkX25hdGlvbnNfaXB2Ni8NCj4gDQo+ICAgICAgICBSZWdhcmRzDQo+ ICAgICAgICAgICBCcmlhbg0KPiANCj4gDQo+ICAgICAgICBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgICAgICAgdjZvcHMgbWFpbGluZyBsaXN0DQo+ ICAgICAgICB2Nm9wc0BpZXRmLm9yZw0KPiAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby92Nm9wcw0KPiANCj4gDQo+IA0KPiANCj4gICAgKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiAgICBJUHY0IGlzIG92ZXINCj4gICAg QXJlIHlvdSByZWFkeSBmb3IgdGhlIG5ldyBJbnRlcm5ldCA/DQo+ICAgIGh0dHA6Ly93d3cuY29u c3VsaW50ZWwuZXMNCj4gICAgVGhlIElQdjYgQ29tcGFueQ0KPiANCj4gICAgVGhpcyBlbGVjdHJv bmljIG1lc3NhZ2UgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQg b3IgY29uZmlkZW50aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRo ZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsKHMpIG5hbWVkIGFib3ZlIGFuZCBmdXJ0 aGVyIG5vbi1leHBsaWNpbHR5IGF1dGhvcml6ZWQgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJp YnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgZXZlbiBp ZiBwYXJ0aWFsbHksIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgc3RyaWN0bHkgcHJvaGli aXRlZCBhbmQgd2lsbCBiZSBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2ZmZW5zZS4gSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2FyZSB0aGF0IGFueSBkaXNjbG9zdXJl LCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGlu Zm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBp cyBzdHJpY3RseSBwcm9oaWJpdGVkLCB3aWxsIGJlIGNvbnNpZGVyZWQgYSBjcmltaW5hbCBvZmZl bnNlLCBzbyB5b3UgbXVzdCByZXBseSB0byB0aGUgb3JpZ2luYWwgc2VuZGVyIHRvIGluZm9ybSBh Ym91dCB0aGlzIGNvbW11bmljYXRpb24gYW5kIGRlbGV0ZSBpdC4NCj4gDQo+IA0KPiANCj4gICAg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgdjZv cHMgbWFpbGluZyBsaXN0DQo+ICAgIHY2b3BzQGlldGYub3JnDQo+ICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCj4gDQo+IA0KPiANCj4gDQo+ICoqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4gSVB2NCBpcyBvdmVyDQo+ IEFyZSB5b3UgcmVhZHkgZm9yIHRoZSBuZXcgSW50ZXJuZXQgPw0KPiBodHRwOi8vd3d3LmNvbnN1 bGludGVsLmVzDQo+IFRoZSBJUHY2IENvbXBhbnkNCj4gDQo+IFRoaXMgZWxlY3Ryb25pYyBtZXNz YWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yIGNvbmZp ZGVudGlhbC4gVGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVkIHRvIGJlIGZvciB0aGUgZXhjbHVz aXZlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbChzKSBuYW1lZCBhYm92ZSBhbmQgZnVydGhlciBub24t ZXhwbGljaWx0eSBhdXRob3JpemVkIGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBv ciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24sIGV2ZW4gaWYgcGFydGlh bGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5k IHdpbGwgYmUgY29uc2lkZXJlZCBhIGNyaW1pbmFsIG9mZmVuc2UuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQgYmUgYXdhcmUgdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWlu ZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlv biwgZXZlbiBpZiBwYXJ0aWFsbHksIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgc3RyaWN0 bHkgcHJvaGliaXRlZCwgd2lsbCBiZSBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2ZmZW5zZSwgc28g eW91IG11c3QgcmVwbHkgdG8gdGhlIG9yaWdpbmFsIHNlbmRlciB0byBpbmZvcm0gYWJvdXQgdGhp cyBjb21tdW5pY2F0aW9uIGFuZCBkZWxldGUgaXQuDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHY2b3BzIG1haWxpbmcgbGlz dA0KPiB2Nm9wc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3Y2b3BzDQoNCg== From nobody Thu May 31 02:34:19 2018 Return-Path: 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 B4D2D12EAB2 for ; Thu, 31 May 2018 02:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, T_KAM_HTML_FONT_INVALID=0.01, 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 p5ZbHJve5YtU for ; Thu, 31 May 2018 02:34:13 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D964D12E855 for ; Thu, 31 May 2018 02:34:12 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w4V9Y5kf023321; Thu, 31 May 2018 11:34:05 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 309642049BC; Thu, 31 May 2018 11:34:05 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1FC1F204ADE; Thu, 31 May 2018 11:34:05 +0200 (CEST) Received: from [132.166.84.124] ([132.166.84.124]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w4V9Y4B5003652; Thu, 31 May 2018 11:34:04 +0200 To: "Templin (US), Fred L" References: <06CBD4DE-9E00-4501-92C4-1E2E1784B923@gmail.com> <6b5005f8-b1d3-0da6-6744-47f5cbe2e25e@gmail.com> <226862c69bcb48c9ac2abb87b4c7de59@XCH15-06-08.nw.nos.boeing.com> From: Alexandre Petrescu Cc: "v6ops@ietf.org" Message-ID: <002e2af1-603c-2e39-6aff-5b3cdcbe8514@gmail.com> Date: Thu, 31 May 2018 11:34:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <226862c69bcb48c9ac2abb87b4c7de59@XCH15-06-08.nw.nos.boeing.com> Content-Type: multipart/alternative; boundary="------------4A5616D475CFEF26D6511576" Content-Language: fr Archived-At: Subject: Re: [v6ops] IPv6 Prefix Delegation Models ('draft-templin-v6ops-pdhost') - draft update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 09:34:17 -0000 This is a multi-part message in MIME format. --------------4A5616D475CFEF26D6511576 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Fred, But Figure 1 has Addresses allocated on the downstream interfaces, whereas I am talking about not put any Address on them be they virtual or real. Alex Le 30/05/2018 à 17:43, Templin (US), Fred L a écrit : > > Hi Alex, > > Good point, but I think the new figure you are proposing is already > covered under > > figure 1. Figure 1 is an IoT router that does RA to other nodes in the > networks it > > controls – whether the networks are internal virtual networks or external > > physical networks. Perhaps some extra text to explain the IoT and > downsteam > > network RA use case in conjunction with Figure 1 would help? Any > suggestions? > > Thanks - Fred > > *From:*v6ops [mailto:v6ops-bounces@ietf.org] *On Behalf Of *Alexandre > Petrescu > *Sent:* Wednesday, May 30, 2018 6:41 AM > *To:* v6ops@ietf.org > *Subject:* Re: [v6ops] IPv6 Prefix Delegation Models > ('draft-templin-v6ops-pdhost') - draft update > > I propose this figure as well, in which an IoT router 'R' does not > form any address A on any of its interfaces, out of the delegated > prefix P, > even though it _does_ request and obtain a prefix P and does RA it to > other nodes in the network in controls. > >                                    x >                                    | >                      upstream link | >                                    | >                         +----------+----------+ >                         |  upstream interface | >                         +--+-+--+-+--+-----+--+ >                         |                     | >                         | requesting node 'R' | >                         |                     | >                         +---------------------+ > For comparison, the figures present now in -20 are these: >                                    x >                                    | >                      upstream link | >                                    | >                         +----------+----------+ >                        |  upstream Interface | >                         +---------------------+ >                         |                     | >                         | requesting node 'R' | >                         |                     | >                         +--+-+--+-+--+-----+--+ >                         |A1| |A2| |A3| ... |An| >                         +--+-+--+-+--+-----+--+ >                         |  virtual Interface  | >                         +---------------------+ >                       Figure 2: Weak End System Model >                                    x >                                    | >                      upstream link | >                                    | >                         +----------+----------+ >                         |  upstream interface | >                         +--+-+--+-+--+-----+--+ >                         |A1| |A2| |A3| ... |An| >                         +--+-+--+-+--+-----+--+ >                         |                     | >                         | requesting node 'R' | >                         |                     | >                         +---------------------+ >                         |   virtual interface | >                         +---------------------+ >                       Figure 3: Strong End System Model > > Le 30/05/2018 à 03:14, Fred Baker a écrit : > > General question to those who commented on the draft when we discussed it a few weeks ago: do you agree that this update addresses the issues you raised? Do you have further comments on it? > > On May 29, 2018, at 9:13 PM, Templin (US), Fred L wrote: > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/ > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-templin-v6ops-pdhost-20 > > https://datatracker.ietf.org/doc/html/draft-templin-v6ops-pdhost-20 > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-templin-v6ops-pdhost-20 > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > --------------4A5616D475CFEF26D6511576 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Fred,

But Figure 1 has Addresses allocated on the downstream interfaces, whereas I am talking about not put any Address on them be they virtual or real.

Alex


Le 30/05/2018 à 17:43, Templin (US), Fred L a écrit :

Hi Alex,

 

Good point, but I think the new figure you are proposing is already covered under

figure 1. Figure 1 is an IoT router that does RA to other nodes in the networks it

controls – whether the networks are internal virtual networks or external

physical networks. Perhaps some extra text to explain the IoT and downsteam

network RA use case in conjunction with Figure 1 would help? Any suggestions?

 

Thanks - Fred

 

From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petrescu
Sent: Wednesday, May 30, 2018 6:41 AM
To: v6ops@ietf.org
Subject: Re: [v6ops] IPv6 Prefix Delegation Models ('draft-templin-v6ops-pdhost') - draft update

 

I propose this figure as well, in which an IoT router 'R' does not form any address A on any of its interfaces, out of the delegated prefix P,
even though it _does_ request and obtain a prefix P and does RA it to other nodes in the network in controls.

                                   x
                                   |
                     upstream link |
                                   |
                        +----------+----------+
                        |  upstream interface |
                        +--+-+--+-+--+-----+--+
                        |                     |
                        | requesting node 'R' |
                        |                     |
                        +---------------------+
 
 
 
 
For comparison, the figures present now in -20 are these:
 
                                   x
                                   |
                     upstream link |
                                   |
                        +----------+----------+
                        |  upstream Interface |
                        +---------------------+
                        |                     |
                        | requesting node 'R' |
                        |                     |
                        +--+-+--+-+--+-----+--+
                        |A1| |A2| |A3| ... |An|
                        +--+-+--+-+--+-----+--+
                        |  virtual Interface  |
                        +---------------------+
 
                      Figure 2: Weak End System Model
 
 
                                   x
                                   |
                     upstream link |
                                   |
                        +----------+----------+
                        |  upstream interface |
                        +--+-+--+-+--+-----+--+
                        |A1| |A2| |A3| ... |An|
                        +--+-+--+-+--+-----+--+
                        |                     |
                        | requesting node 'R' |
                        |                     |
                        +---------------------+
                        |   virtual interface |
                        +---------------------+
                      Figure 3: Strong End System Model
 
 

 

Le 30/05/2018 à 03:14, Fred Baker a écrit :

General question to those who commented on the draft when we discussed it a few weeks ago: do you agree that this update addresses the issues you raised? Do you have further comments on it?
 
On May 29, 2018, at 9:13 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/
 
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-templin-v6ops-pdhost-20
https://datatracker.ietf.org/doc/html/draft-templin-v6ops-pdhost-20
 
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-templin-v6ops-pdhost-20
 
 
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
 

 


--------------4A5616D475CFEF26D6511576-- From nobody Thu May 31 02:45:47 2018 Return-Path: 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 3578D12EC8F for ; Thu, 31 May 2018 02:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, 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 J6gDdbLc_Vnc for ; Thu, 31 May 2018 02:45:44 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48D2112EC39 for ; Thu, 31 May 2018 02:45:43 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w4V9jeYJ027253 for ; Thu, 31 May 2018 11:45:41 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0C745204AFA for ; Thu, 31 May 2018 11:45:41 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 01556201610 for ; Thu, 31 May 2018 11:45:41 +0200 (CEST) Received: from [132.166.84.124] ([132.166.84.124]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w4V9jesN011742 for ; Thu, 31 May 2018 11:45:40 +0200 To: v6ops@ietf.org References: <17a0f0e1-c822-21e8-31e0-41c96ae1b2a5@gmail.com> From: Alexandre Petrescu Message-ID: Date: Thu, 31 May 2018 11:45:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <17a0f0e1-c822-21e8-31e0-41c96ae1b2a5@gmail.com> Content-Type: multipart/alternative; boundary="------------DF19F2DF27C91540B7D889B3" Content-Language: fr Archived-At: Subject: Re: [v6ops] =?utf-8?q?Internet_engineers_tear_into_United_Nations=27?= =?utf-8?q?_plan_to_move_us_all_to_IPv6_=E2=80=A2_The_Register?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 09:45:47 -0000 This is a multi-part message in MIME format. --------------DF19F2DF27C91540B7D889B3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit The ITU recommendation should be discussed here. We should update that recommendation at least in one point: the 64bit limit.  It too much reckons the IIDs to be of length 64; this can block Internet growth.   On another hand, at least RFC7277 "Opaque IIDs" and its BSD SLAAC implementation permits it to be 65, and at least one large cellular operator uses DHCPv6 Prefix Delegation for prefixes of length e.g. 56 (not 64). Does ITU SG20 know this? Alex Le 31/05/2018 à 05:51, Brian E Carpenter a écrit : > Ignoring the journalistic exaggerations in the article (2nd link below), > do we have a liaison comment going to the ITU about this draft? > https://regmedia.co.uk/2018/05/30/itu-ipv6-may18.pdf > It seems to be an excellent recipe for burning up address space. > The due date appears to be now. > > http://www.theregister.co.uk/2018/05/30/internet_engineers_united_nations_ipv6/ > > Regards > Brian > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --------------DF19F2DF27C91540B7D889B3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

The ITU recommendation should be discussed here.

We should update that recommendation at least in one point: the 64bit limit.  It too much reckons the IIDs to be of length 64; this can block Internet growth.   On another hand, at least RFC7277 "Opaque IIDs" and its BSD SLAAC implementation permits it to be 65, and at least one large cellular operator uses DHCPv6 Prefix Delegation for prefixes of length e.g. 56 (not 64).

Does ITU SG20 know this?

Alex


Le 31/05/2018 à 05:51, Brian E Carpenter a écrit :
Ignoring the journalistic exaggerations in the article (2nd link below),
do we have a liaison comment going to the ITU about this draft?
https://regmedia.co.uk/2018/05/30/itu-ipv6-may18.pdf
It seems to be an excellent recipe for burning up address space.
The due date appears to be now.

http://www.theregister.co.uk/2018/05/30/internet_engineers_united_nations_ipv6/

Regards
   Brian


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

--------------DF19F2DF27C91540B7D889B3-- From nobody Thu May 31 08:05:15 2018 Return-Path: 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 0DDC912EC68 for ; Thu, 31 May 2018 08:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 quRaSlZXStOx for ; Thu, 31 May 2018 08:04:56 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E94D312EBE0 for ; Thu, 31 May 2018 08:04:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id w4VF4qVL055261; Thu, 31 May 2018 08:04:52 -0700 Received: from XCH15-06-10.nw.nos.boeing.com (xch15-06-10.nw.nos.boeing.com [137.136.239.219]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w4VF4luK055199 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 31 May 2018 08:04:47 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-10.nw.nos.boeing.com (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 31 May 2018 08:04:46 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1365.000; Thu, 31 May 2018 08:04:46 -0700 From: "Templin (US), Fred L" To: Alexandre Petrescu CC: "v6ops@ietf.org" Thread-Topic: [v6ops] IPv6 Prefix Delegation Models ('draft-templin-v6ops-pdhost') - draft update Thread-Index: AdP3gG5+uFo5RHF/RMmMgf6+VRvj7QAbdRgAABoRVgAACn8+YAAfKmkAAANOe6A= Date: Thu, 31 May 2018 15:04:46 +0000 Message-ID: <0a4bfb51c3634a9fa05e4b584ab0c647@XCH15-06-08.nw.nos.boeing.com> References: <06CBD4DE-9E00-4501-92C4-1E2E1784B923@gmail.com> <6b5005f8-b1d3-0da6-6744-47f5cbe2e25e@gmail.com> <226862c69bcb48c9ac2abb87b4c7de59@XCH15-06-08.nw.nos.boeing.com> <002e2af1-603c-2e39-6aff-5b3cdcbe8514@gmail.com> In-Reply-To: <002e2af1-603c-2e39-6aff-5b3cdcbe8514@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: multipart/alternative; boundary="_000_0a4bfb51c3634a9fa05e4b584ab0c647XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] IPv6 Prefix Delegation Models ('draft-templin-v6ops-pdhost') - draft update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 15:05:14 -0000 --_000_0a4bfb51c3634a9fa05e4b584ab0c647XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxleCwNCg0KSSBkb27igJl0IHF1aXRlIGZvbGxvdyDigJMgZG8geW91IHdhbnQgdXMgdG8gZG9j dW1lbnQgdGhlIGNhc2Ugd2hlcmUgdGhlDQpyZXF1ZXN0aW5nIG5vZGUgcmVjZWl2ZXMgYSBkZWxl Z2F0ZWQgcHJlZml4IGFuZCB0aGVuIGRvZXMgbm90aGluZw0Kd2l0aCBpdCBhdCBhbGw/DQoNClRo ZSBub2RlIG5lZWRzIGF0IGxlYXN0IG9uZSBnbG9iYWxseS11bmlxdWUgYWRkcmVzcyBhc3NpZ25l ZCB0byBzb21lDQppbnRlcmZhY2Ugc28gdGhhdCBpdCBjYW4gc291cmNlIElDTVAgbWVzc2FnZXMg dGhhdCBuZWVkIHRvIHRyYXZlbCBtb3JlDQp0aGFuIG9uZSBob3AuIEl0IGlzIHRydWUgdGhhdCB0 aGF0IGFkZHJlc3MgY291bGQgY29tZSBmcm9tIFNMQUFDIHVzaW5nDQphbiBSQSBQSU8gaW5zdGVh ZCBvZiBmcm9tIHRoZSBkZWxlZ2F0ZWQgcHJlZml4LiBCdXQgaXMgdGhlIGNhc2Ugb2Ygbm90DQpk b2luZyBhbnl0aGluZyBhdCBhbGwgd2l0aCB0aGUgZGVsZWdhdGVkIHByZWZpeCBpbnRlcmVzdGlu Zz8NCg0KVGhhbmtzIC0gRnJlZA0KDQpGcm9tOiBBbGV4YW5kcmUgUGV0cmVzY3UgW21haWx0bzph bGV4YW5kcmUucGV0cmVzY3VAZ21haWwuY29tXQ0KU2VudDogVGh1cnNkYXksIE1heSAzMSwgMjAx OCAyOjM0IEFNDQpUbzogVGVtcGxpbiAoVVMpLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWlu Zy5jb20+DQpDYzogdjZvcHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdjZvcHNdIElQdjYgUHJl Zml4IERlbGVnYXRpb24gTW9kZWxzICgnZHJhZnQtdGVtcGxpbi12Nm9wcy1wZGhvc3QnKSAtIGRy YWZ0IHVwZGF0ZQ0KDQoNCkhpIEZyZWQsDQoNCkJ1dCBGaWd1cmUgMSBoYXMgQWRkcmVzc2VzIGFs bG9jYXRlZCBvbiB0aGUgZG93bnN0cmVhbSBpbnRlcmZhY2VzLCB3aGVyZWFzIEkgYW0gdGFsa2lu ZyBhYm91dCBub3QgcHV0IGFueSBBZGRyZXNzIG9uIHRoZW0gYmUgdGhleSB2aXJ0dWFsIG9yIHJl YWwuDQoNCkFsZXgNCg0KTGUgMzAvMDUvMjAxOCDDoCAxNzo0MywgVGVtcGxpbiAoVVMpLCBGcmVk IEwgYSDDqWNyaXQgOg0KSGkgQWxleCwNCg0KR29vZCBwb2ludCwgYnV0IEkgdGhpbmsgdGhlIG5l dyBmaWd1cmUgeW91IGFyZSBwcm9wb3NpbmcgaXMgYWxyZWFkeSBjb3ZlcmVkIHVuZGVyDQpmaWd1 cmUgMS4gRmlndXJlIDEgaXMgYW4gSW9UIHJvdXRlciB0aGF0IGRvZXMgUkEgdG8gb3RoZXIgbm9k ZXMgaW4gdGhlIG5ldHdvcmtzIGl0DQpjb250cm9scyDigJMgd2hldGhlciB0aGUgbmV0d29ya3Mg YXJlIGludGVybmFsIHZpcnR1YWwgbmV0d29ya3Mgb3IgZXh0ZXJuYWwNCnBoeXNpY2FsIG5ldHdv cmtzLiBQZXJoYXBzIHNvbWUgZXh0cmEgdGV4dCB0byBleHBsYWluIHRoZSBJb1QgYW5kIGRvd25z dGVhbQ0KbmV0d29yayBSQSB1c2UgY2FzZSBpbiBjb25qdW5jdGlvbiB3aXRoIEZpZ3VyZSAxIHdv dWxkIGhlbHA/IEFueSBzdWdnZXN0aW9ucz8NCg0KVGhhbmtzIC0gRnJlZA0KDQpGcm9tOiB2Nm9w cyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbGV4YW5kcmUg UGV0cmVzY3UNClNlbnQ6IFdlZG5lc2RheSwgTWF5IDMwLCAyMDE4IDY6NDEgQU0NClRvOiB2Nm9w c0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBJ UHY2IFByZWZpeCBEZWxlZ2F0aW9uIE1vZGVscyAoJ2RyYWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0 JykgLSBkcmFmdCB1cGRhdGUNCg0KSSBwcm9wb3NlIHRoaXMgZmlndXJlIGFzIHdlbGwsIGluIHdo aWNoIGFuIElvVCByb3V0ZXIgJ1InIGRvZXMgbm90IGZvcm0gYW55IGFkZHJlc3MgQSBvbiBhbnkg b2YgaXRzIGludGVyZmFjZXMsIG91dCBvZiB0aGUgZGVsZWdhdGVkIHByZWZpeCBQLA0KZXZlbiB0 aG91Z2ggaXQgX2RvZXNfIHJlcXVlc3QgYW5kIG9idGFpbiBhIHByZWZpeCBQIGFuZCBkb2VzIFJB IGl0IHRvIG90aGVyIG5vZGVzIGluIHRoZSBuZXR3b3JrIGluIGNvbnRyb2xzLg0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHgNCg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8DQoNCiAgICAgICAgICAgICAgICAgICAgIHVwc3RyZWFtIGxpbmsgfA0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCg0KICAgICAgICAgICAgICAgICAg ICAgICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLSsNCg0KICAgICAgICAgICAgICAgICAgICAgICAg fCAgdXBzdHJlYW0gaW50ZXJmYWNlIHwNCg0KICAgICAgICAgICAgICAgICAgICAgICAgKy0tKy0r LS0rLSstLSstLS0tLSstLSsNCg0KICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgIHwNCg0KICAgICAgICAgICAgICAgICAgICAgICAgfCByZXF1ZXN0aW5nIG5vZGUg J1InIHwNCg0KICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwN Cg0KICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0KDQoN Cg0KDQoNCg0KDQoNCkZvciBjb21wYXJpc29uLCB0aGUgZmlndXJlcyBwcmVzZW50IG5vdyBpbiAt MjAgYXJlIHRoZXNlOg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB4 DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KDQogICAgICAgICAgICAg ICAgICAgICB1cHN0cmVhbSBsaW5rIHwNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tKy0tLS0tLS0tLS0r DQoNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgIHVwc3RyZWFtIEludGVyZmFjZSB8DQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8DQoNCiAgICAgICAgICAgICAg ICAgICAgICAgIHwgcmVxdWVzdGluZyBub2RlICdSJyB8DQoNCiAgICAgICAgICAgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICB8DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICst LSstKy0tKy0rLS0rLS0tLS0rLS0rDQoNCiAgICAgICAgICAgICAgICAgICAgICAgIHxBMXwgfEEy fCB8QTN8IC4uLiB8QW58DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICstLSstKy0tKy0rLS0r LS0tLS0rLS0rDQoNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgIHZpcnR1YWwgSW50ZXJmYWNl ICB8DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoN Cg0KDQogICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDI6IFdlYWsgRW5kIFN5c3RlbSBNb2Rl bA0KDQoNCg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgeA0KDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCg0KICAgICAgICAgICAgICAgICAgICAg dXBzdHJlYW0gbGluayB8DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K DQogICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLSstLS0tLS0tLS0tKw0KDQogICAg ICAgICAgICAgICAgICAgICAgICB8ICB1cHN0cmVhbSBpbnRlcmZhY2UgfA0KDQogICAgICAgICAg ICAgICAgICAgICAgICArLS0rLSstLSstKy0tKy0tLS0tKy0tKw0KDQogICAgICAgICAgICAgICAg ICAgICAgICB8QTF8IHxBMnwgfEEzfCAuLi4gfEFufA0KDQogICAgICAgICAgICAgICAgICAgICAg ICArLS0rLSstLSstKy0tKy0tLS0tKy0tKw0KDQogICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgfA0KDQogICAgICAgICAgICAgICAgICAgICAgICB8IHJlcXVlc3Rp bmcgbm9kZSAnUicgfA0KDQogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg ICAgICAgfA0KDQogICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0t Kw0KDQogICAgICAgICAgICAgICAgICAgICAgICB8ICAgdmlydHVhbCBpbnRlcmZhY2UgfA0KDQog ICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KDQogICAgICAg ICAgICAgICAgICAgICAgRmlndXJlIDM6IFN0cm9uZyBFbmQgU3lzdGVtIE1vZGVsDQoNCg0KDQoN Cg0KTGUgMzAvMDUvMjAxOCDDoCAwMzoxNCwgRnJlZCBCYWtlciBhIMOpY3JpdCA6DQoNCkdlbmVy YWwgcXVlc3Rpb24gdG8gdGhvc2Ugd2hvIGNvbW1lbnRlZCBvbiB0aGUgZHJhZnQgd2hlbiB3ZSBk aXNjdXNzZWQgaXQgYSBmZXcgd2Vla3MgYWdvOiBkbyB5b3UgYWdyZWUgdGhhdCB0aGlzIHVwZGF0 ZSBhZGRyZXNzZXMgdGhlIGlzc3VlcyB5b3UgcmFpc2VkPyBEbyB5b3UgaGF2ZSBmdXJ0aGVyIGNv bW1lbnRzIG9uIGl0Pw0KDQoNCg0KT24gTWF5IDI5LCAyMDE4LCBhdCA5OjEzIFBNLCBUZW1wbGlu IChVUyksIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT48bWFpbHRvOkZyZWQuTC5U ZW1wbGluQGJvZWluZy5jb20+IHdyb3RlOg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMg cGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtdGVtcGxpbi12Nm9wcy1wZGhvc3QvDQoNCg0KDQpUaGVyZSBhcmUgYWxzbyBodG1s aXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC10ZW1wbGluLXY2b3BzLXBkaG9zdC0yMA0KDQpodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9odG1sL2RyYWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0LTIwDQoNCg0KDQpBIGRp ZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQoNCmh0dHBzOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC10ZW1wbGluLXY2b3BzLXBkaG9zdC0yMA0K DQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoNCnY2b3BzIG1haWxpbmcgbGlzdA0KDQp2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0 Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0K DQoNCg0K --_000_0a4bfb51c3634a9fa05e4b584ab0c647XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcHJlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4u SFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCWNvbG9yOmJsYWNrO30NCnNw YW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BbGV4LDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBkb27igJl0IHF1aXRlIGZvbGxvdyDigJMgZG8g eW91IHdhbnQgdXMgdG8gZG9jdW1lbnQgdGhlIGNhc2Ugd2hlcmUgdGhlPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPnJlcXVlc3Rpbmcgbm9kZSByZWNlaXZlcyBhIGRlbGVnYXRlZCBwcmVmaXggYW5kIHRoZW4g ZG9lcyBub3RoaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPndpdGggaXQgYXQgYWxsPzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIG5vZGUgbmVlZHMgYXQgbGVhc3Qg b25lIGdsb2JhbGx5LXVuaXF1ZSBhZGRyZXNzIGFzc2lnbmVkIHRvIHNvbWU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+aW50ZXJmYWNlIHNvIHRoYXQgaXQgY2FuIHNvdXJjZSBJQ01QIG1lc3NhZ2VzIHRoYXQg bmVlZCB0byB0cmF2ZWwgbW9yZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj50aGFuIG9uZSBob3AuIEl0IGlz IHRydWUgdGhhdCB0aGF0IGFkZHJlc3MgY291bGQgY29tZSBmcm9tIFNMQUFDIHVzaW5nPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPmFuIFJBIFBJTyBpbnN0ZWFkIG9mIGZyb20gdGhlIGRlbGVnYXRlZCBwcmVm aXguIEJ1dCBpcyB0aGUgY2FzZSBvZiBub3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ZG9pbmcgYW55dGhp bmcgYXQgYWxsIHdpdGggdGhlIGRlbGVnYXRlZCBwcmVmaXggaW50ZXJlc3Rpbmc/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgLSBGcmVkPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IEFsZXhhbmRyZSBQZXRyZXNjdSBb bWFpbHRvOmFsZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4g VGh1cnNkYXksIE1heSAzMSwgMjAxOCAyOjM0IEFNPGJyPg0KPGI+VG86PC9iPiBUZW1wbGluIChV UyksIEZyZWQgTCAmbHQ7RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSZndDs8YnI+DQo8Yj5DYzo8 L2I+IHY2b3BzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIElQdjYg UHJlZml4IERlbGVnYXRpb24gTW9kZWxzICgnZHJhZnQtdGVtcGxpbi12Nm9wcy1wZGhvc3QnKSAt IGRyYWZ0IHVwZGF0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlm Ij5IaSBGcmVkLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj5CdXQg RmlndXJlIDEgaGFzIEFkZHJlc3NlcyBhbGxvY2F0ZWQgb24gdGhlIGRvd25zdHJlYW0gaW50ZXJm YWNlcywgd2hlcmVhcyBJIGFtIHRhbGtpbmcgYWJvdXQgbm90IHB1dCBhbnkgQWRkcmVzcyBvbiB0 aGVtIGJlIHRoZXkgdmlydHVhbCBvciByZWFsLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7LHNlcmlmIj5BbGV4PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ TGUgMzAvMDUvMjAxOCDDoCAxNzo0MywgVGVtcGxpbiAoVVMpLCBGcmVkIEwgYSDDqWNyaXQmbmJz cDs6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEFsZXgsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5Hb29kIHBvaW50LCBidXQgSSB0aGluayB0aGUgbmV3IGZpZ3Vy ZSB5b3UgYXJlIHByb3Bvc2luZyBpcyBhbHJlYWR5IGNvdmVyZWQgdW5kZXI8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+ZmlndXJlIDEuIEZpZ3VyZSAxIGlzIGFuIElvVCByb3V0ZXIgdGhhdCBkb2VzIFJBIHRv IG90aGVyIG5vZGVzIGluIHRoZSBuZXR3b3JrcyBpdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5jb250cm9s cyDigJMgd2hldGhlciB0aGUgbmV0d29ya3MgYXJlIGludGVybmFsIHZpcnR1YWwgbmV0d29ya3Mg b3IgZXh0ZXJuYWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+cGh5c2ljYWwgbmV0d29ya3MuIFBlcmhhcHMg c29tZSBleHRyYSB0ZXh0IHRvIGV4cGxhaW4gdGhlIElvVCBhbmQgZG93bnN0ZWFtPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPm5ldHdvcmsgUkEgdXNlIGNhc2UgaW4gY29uanVuY3Rpb24gd2l0aCBGaWd1cmUg MSB3b3VsZCBoZWxwPyBBbnkgc3VnZ2VzdGlvbnM/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5UaGFua3MgLSBGcmVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6d2luZG93dGV4dCI+IHY2b3BzIFs8YSBocmVmPSJtYWlsdG86djZvcHMtYm91bmNlc0Bp ZXRmLm9yZyI+bWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxm IE9mIDwvYj5BbGV4YW5kcmUgUGV0cmVzY3U8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBN YXkgMzAsIDIwMTggNjo0MSBBTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnY2b3Bz QGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2 Nm9wc10gSVB2NiBQcmVmaXggRGVsZWdhdGlvbiBNb2RlbHMgKCdkcmFmdC10ZW1wbGluLXY2b3Bz LXBkaG9zdCcpIC0gZHJhZnQgdXBkYXRlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPkkgcHJvcG9zZSB0aGlzIGZpZ3VyZSBhcyB3 ZWxsLCBpbiB3aGljaCBhbiBJb1Qgcm91dGVyICdSJyBkb2VzIG5vdCBmb3JtIGFueSBhZGRyZXNz IEEgb24gYW55IG9mIGl0cyBpbnRlcmZhY2VzLCBvdXQgb2YgdGhlIGRlbGVnYXRlZCBwcmVmaXgg UCw8YnI+DQpldmVuIHRob3VnaCBpdCBfZG9lc18gcmVxdWVzdCBhbmQgb2J0YWluIGEgcHJlZml4 IFAgYW5kIGRvZXMgUkEgaXQgdG8gb3RoZXIgbm9kZXMgaW4gdGhlIG5ldHdvcmsgaW4gY29udHJv bHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgeDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVwc3RyZWFtIGxpbmsg fDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7 LS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLSYjNDM7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgdXBzdHJlYW0gaW50ZXJmYWNlIHw8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JiM0MzstLSYjNDM7LSYj NDM7LS0mIzQzOy0mIzQzOy0tJiM0MzstLS0tLSYjNDM7LS0mIzQzOzxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCByZXF1ZXN0aW5nIG5vZGUgJ1InIHw8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0t LS0tLS0tLS0tLS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Gb3Ig Y29tcGFyaXNvbiwgdGhlIGZpZ3VyZXMgcHJlc2VudCBub3cgaW4gLTIwIGFyZSB0aGVzZTo8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgeDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHVwc3RyZWFtIGxpbmsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLSYjNDM7PG86cD48L286 cD48L3ByZT4NCjxwcmU+ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbmJzcDsgdXBzdHJlYW0g SW50ZXJmYWNlIHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCByZXF1ZXN0aW5nIG5vZGUgJ1InIHw8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyYjNDM7LS0mIzQzOy0m IzQzOy0tJiM0MzstJiM0MzstLSYjNDM7LS0tLS0mIzQzOy0tJiM0Mzs8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfEExfCB8QTJ8IHxBM3wgLi4uIHxBbnw8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLSYj NDM7LSYjNDM7LS0mIzQzOy0mIzQzOy0tJiM0MzstLS0tLSYjNDM7LS0mIzQzOzxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHZpcnR1YWwgSW50 ZXJmYWNlJm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOzxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGaWd1cmUgMjog V2VhayBFbmQgU3lzdGVtIE1vZGVsPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48 L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHg8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB1cHN0cmVhbSBsaW5rIHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0mIzQzOzxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHVwc3RyZWFtIGlu dGVyZmFjZSB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICYjNDM7LS0mIzQzOy0mIzQzOy0tJiM0MzstJiM0MzstLSYjNDM7LS0tLS0mIzQzOy0tJiM0Mzs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfEExfCB8QTJ8 IHxBM3wgLi4uIHxBbnw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJiM0MzstLSYjNDM7LSYjNDM7LS0mIzQzOy0mIzQzOy0tJiM0MzstLS0tLSYjNDM7LS0m IzQzOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBy ZXF1ZXN0aW5nIG5vZGUgJ1InIHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyB2aXJ0dWFs IGludGVyZmFjZSB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgRmlndXJlIDM6IFN0cm9uZyBFbmQgU3lzdGVtIE1vZGVsPG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48 L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxlIDMwLzA1LzIwMTggw6AgMDM6MTQsIEZyZWQg QmFrZXIgYSDDqWNyaXQmbmJzcDs6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5HZW5l cmFsIHF1ZXN0aW9uIHRvIHRob3NlIHdobyBjb21tZW50ZWQgb24gdGhlIGRyYWZ0IHdoZW4gd2Ug ZGlzY3Vzc2VkIGl0IGEgZmV3IHdlZWtzIGFnbzogZG8geW91IGFncmVlIHRoYXQgdGhpcyB1cGRh dGUgYWRkcmVzc2VzIHRoZSBpc3N1ZXMgeW91IHJhaXNlZD8gRG8geW91IGhhdmUgZnVydGhlciBj b21tZW50cyBvbiBpdD88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5PbiBNYXkgMjksIDIwMTgsIGF0IDk6MTMgUE0sIFRlbXBsaW4gKFVTKSwgRnJl ZCBMIDxhIGhyZWY9Im1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tIj4mbHQ7RnJlZC5M LlRlbXBsaW5AYm9laW5nLmNvbSZndDs8L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9wcmU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw cmU+VGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PG86 cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtdGVtcGxpbi12Nm9wcy1wZGhvc3QvIj5odHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC10ZW1wbGluLXY2b3BzLXBkaG9zdC88L2E+PG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+VGhlcmUgYXJlIGFsc28gaHRt bGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10ZW1wbGluLXY2b3BzLXBkaG9z dC0yMCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXRlbXBsaW4tdjZvcHMtcGRo b3N0LTIwPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtdGVtcGxpbi12Nm9wcy1wZGhvc3QtMjAiPmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtdGVtcGxpbi12Nm9wcy1w ZGhvc3QtMjA8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3By ZT4NCjxwcmU+QSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0 OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC10ZW1wbGluLXY2b3BzLXBkaG9zdC0yMCI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0LTIwPC9hPjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+ DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+djZvcHMg bWFpbGluZyBsaXN0PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOnY2b3Bz QGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPC9hPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_0a4bfb51c3634a9fa05e4b584ab0c647XCH150608nwnosboeingcom_-- From nobody Thu May 31 08:35:12 2018 Return-Path: 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 2378E12E88A for ; Thu, 31 May 2018 08:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 48HspVz0vATv for ; Thu, 31 May 2018 08:35:08 -0700 (PDT) Received: from atl4mhob22.registeredsite.com (atl4mhob22.registeredsite.com [209.17.115.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFD9F12DA44 for ; Thu, 31 May 2018 08:35:07 -0700 (PDT) Received: from mailpod.hostingplatform.com (atl4qobmail02pod6.registeredsite.com [10.30.71.210]) by atl4mhob22.registeredsite.com (8.14.4/8.14.4) with ESMTP id w4VFZ4N3002685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 31 May 2018 11:35:05 -0400 Received: (qmail 14125 invoked by uid 0); 31 May 2018 15:35:04 -0000 X-TCPREMOTEIP: 68.100.68.25 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.1.135?) (lee@asgard.org@68.100.68.25) by 0 with ESMTPA; 31 May 2018 15:35:04 -0000 To: v6ops@ietf.org References: <17a0f0e1-c822-21e8-31e0-41c96ae1b2a5@gmail.com> From: Lee Howard Message-ID: <89a7eb01-e22f-f518-491a-822adae19003@asgard.org> Date: Thu, 31 May 2018 11:35:04 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <17a0f0e1-c822-21e8-31e0-41c96ae1b2a5@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [v6ops] =?utf-8?q?Internet_engineers_tear_into_United_Nations=27?= =?utf-8?q?_plan_to_move_us_all_to_IPv6_=E2=80=A2_The_Register?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 15:35:10 -0000 I note that the IAB had a measured response: https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-04-04-iab-itu-t-sg-20-response-to-liaison-1546-attachment-1.pdf I support that statement. Bearing in mind that I have no official position, and therefore any opinions expressed below are mine only: The IETF, and any working group in it, has only one way to make a statement: an RFC from the IETF stream. No other kind of document requires IETF consensus, which is the only way to reflect an IETF statement. I am skeptical that we can generate a timely consensus document. We don't need to say, "Stay out of our sandbox." Turf wars are stupid: as engineers, we don't care who does the work, we care about the quality of the work. Getting defensive is a sign that we care more about protecting some interest than about making the Internet work better. Comments about the technical problems with the proposed model are appropriate. I would include implementation considerations, such as the potential for people to think the model is compulsory, or overrides other local network considerations. However, I have no reason to believe that comments on v6ops or other IETF mailing lists will be received by SG20. On those bases, RIPE may be a more effective place for discussion. Lee On 05/30/2018 11:51 PM, Brian E Carpenter wrote: > Ignoring the journalistic exaggerations in the article (2nd link below), > do we have a liaison comment going to the ITU about this draft? > https://regmedia.co.uk/2018/05/30/itu-ipv6-may18.pdf > It seems to be an excellent recipe for burning up address space. > The due date appears to be now. > > http://www.theregister.co.uk/2018/05/30/internet_engineers_united_nations_ipv6/ > > Regards > Brian > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu May 31 08:36:49 2018 Return-Path: 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 08D1812EB3D for ; Thu, 31 May 2018 08:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, T_KAM_HTML_FONT_INVALID=0.01, 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 7m2ABktesiRQ for ; Thu, 31 May 2018 08:36:32 -0700 (PDT) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68F10126DFB for ; Thu, 31 May 2018 08:36:32 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w4VFaQIF030851; Thu, 31 May 2018 17:36:26 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AF09120854E; Thu, 31 May 2018 17:36:26 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 9D5452083D0; Thu, 31 May 2018 17:36:26 +0200 (CEST) Received: from [132.166.84.194] ([132.166.84.194]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id w4VFaPwi029821; Thu, 31 May 2018 17:36:25 +0200 To: "Templin (US), Fred L" Cc: "v6ops@ietf.org" References: <06CBD4DE-9E00-4501-92C4-1E2E1784B923@gmail.com> <6b5005f8-b1d3-0da6-6744-47f5cbe2e25e@gmail.com> <226862c69bcb48c9ac2abb87b4c7de59@XCH15-06-08.nw.nos.boeing.com> <002e2af1-603c-2e39-6aff-5b3cdcbe8514@gmail.com> <0a4bfb51c3634a9fa05e4b584ab0c647@XCH15-06-08.nw.nos.boeing.com> From: Alexandre Petrescu Message-ID: <51cb40fd-bd91-a32a-7f66-acfdd4f62c5e@gmail.com> Date: Thu, 31 May 2018 17:36:22 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <0a4bfb51c3634a9fa05e4b584ab0c647@XCH15-06-08.nw.nos.boeing.com> Content-Type: multipart/alternative; boundary="------------10F0E010726EFF98A5F25CB2" Content-Language: fr Archived-At: Subject: Re: [v6ops] IPv6 Prefix Delegation Models ('draft-templin-v6ops-pdhost') - draft update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 15:36:40 -0000 This is a multi-part message in MIME format. --------------10F0E010726EFF98A5F25CB2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Le 31/05/2018 à 17:04, Templin (US), Fred L a écrit : > > Alex, > > I don’t quite follow – do you want us to document the case where the > > requesting node receives a delegated prefix and then does nothing > > with it at all? > No, I do not want to express such a case. In this particular little case the node reveives a delegated prefix _and_ advertises it in RA further down.  YEt it does not use it to form any address for itself. In order to form an address for itself the node uses the prefix received in the RA from the cellular network (not from DHCP PD). > The node needs at least one globally-unique address assigned to some > > interface so that it can source ICMP messages that need to travel more > > than one hop. It is true that that address could come from SLAAC using > > an RA PIO instead of from the delegated prefix. > I agree. > But is the case of not > > doing anything at all with the delegated prefix interesting? > It is not "not doing anything at all with the delegated prefix".  It does several things with the delegated prefix: - derives sub-prefixes out of it, making seveal /64s out of a /56. That is already an operation that must be specified. - inserts routes in its routing table for these prefixes. - advertises these prefixes in RA. - when the delegated prefix changes all the above must be updated. From a software point of view that is a lof of operations. From an interoperability standpoint: forming a /65 out of the /56, and putting in RA, could be reasonable, yet only BSD interoperates (not linux). Alex > Thanks - Fred > > *From:*Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com] > *Sent:* Thursday, May 31, 2018 2:34 AM > *To:* Templin (US), Fred L > *Cc:* v6ops@ietf.org > *Subject:* Re: [v6ops] IPv6 Prefix Delegation Models > ('draft-templin-v6ops-pdhost') - draft update > > Hi Fred, > > But Figure 1 has Addresses allocated on the downstream interfaces, > whereas I am talking about not put any Address on them be they virtual > or real. > > Alex > > Le 30/05/2018 à 17:43, Templin (US), Fred L a écrit : > > Hi Alex, > > Good point, but I think the new figure you are proposing is > already covered under > > figure 1. Figure 1 is an IoT router that does RA to other nodes in > the networks it > > controls – whether the networks are internal virtual networks or > external > > physical networks. Perhaps some extra text to explain the IoT and > downsteam > > network RA use case in conjunction with Figure 1 would help? Any > suggestions? > > Thanks - Fred > > *From:*v6ops [mailto:v6ops-bounces@ietf.org] *On Behalf Of > *Alexandre Petrescu > *Sent:* Wednesday, May 30, 2018 6:41 AM > *To:* v6ops@ietf.org > *Subject:* Re: [v6ops] IPv6 Prefix Delegation Models > ('draft-templin-v6ops-pdhost') - draft update > > I propose this figure as well, in which an IoT router 'R' does not > form any address A on any of its interfaces, out of the delegated > prefix P, > even though it _does_ request and obtain a prefix P and does RA it > to other nodes in the network in controls. > >                                    x > >                                    | > >                      upstream link | > >                                    | > >                         +----------+----------+ > >                         |  upstream interface | > >                         +--+-+--+-+--+-----+--+ > >                         |                     | > >                         | requesting node 'R' | > >                         |                     | > >                         +---------------------+ > > > > > > > > > > For comparison, the figures present now in -20 are these: > > > >                                    x > >                                    | > >                      upstream link | > >                                    | > >                         +----------+----------+ > >                        |  upstream Interface | > >                         +---------------------+ > >                         |                     | > >                         | requesting node 'R' | > >                         |                     | > >                         +--+-+--+-+--+-----+--+ > >                         |A1| |A2| |A3| ... |An| > >                         +--+-+--+-+--+-----+--+ > >                         |  virtual Interface  | > >                         +---------------------+ > > > >                       Figure 2: Weak End System Model > > > > > >                                    x > >                                    | > >                      upstream link | > >                                    | > >                         +----------+----------+ > >                         |  upstream interface | > >                         +--+-+--+-+--+-----+--+ > >                         |A1| |A2| |A3| ... |An| > >                         +--+-+--+-+--+-----+--+ > >                         |                     | > >                         | requesting node 'R' | > >                         |                     | > >                         +---------------------+ > >                         |   virtual interface | > >                         +---------------------+ > >                       Figure 3: Strong End System Model > > > > > > Le 30/05/2018 à 03:14, Fred Baker a écrit : > > General question to those who commented on the draft when we discussed it a few weeks ago: do you agree that this update addresses the issues you raised? Do you have further comments on it? > > > > On May 29, 2018, at 9:13 PM, Templin (US), Fred L wrote: > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-templin-v6ops-pdhost-20 > > https://datatracker.ietf.org/doc/html/draft-templin-v6ops-pdhost-20 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-templin-v6ops-pdhost-20 > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > --------------10F0E010726EFF98A5F25CB2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



Le 31/05/2018 à 17:04, Templin (US), Fred L a écrit :

Alex,

 

I don’t quite follow – do you want us to document the case where the

requesting node receives a delegated prefix and then does nothing

with it at all?


No, I do not want to express such a case.

In this particular little case the node reveives a delegated prefix _and_ advertises it in RA further down.  YEt it does not use it to form any address for itself.
In order to form an address for itself the node uses the prefix received in the RA from the cellular network (not from DHCP PD).

 

The node needs at least one globally-unique address assigned to some

interface so that it can source ICMP messages that need to travel more

than one hop. It is true that that address could come from SLAAC using

an RA PIO instead of from the delegated prefix.


I agree.

But is the case of not

doing anything at all with the delegated prefix interesting?


It is not "not doing anything at all with the delegated prefix".  It does several things with the delegated prefix:
- derives sub-prefixes out of it, making seveal /64s out of a /56.  That is already an operation that must be specified.
- inserts routes in its routing table for these prefixes.
- advertises these prefixes in RA.
- when the delegated prefix changes all the above must be updated.

From a software point of view that is a lof of operations.

From an interoperability standpoint: forming a /65 out of the /56, and putting in RA, could be reasonable, yet only BSD interoperates (not linux).

Alex

 

Thanks - Fred

 

From: Alexandre Petrescu [mailto:alexandre.petrescu@gmail.com]
Sent: Thursday, May 31, 2018 2:34 AM
To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] IPv6 Prefix Delegation Models ('draft-templin-v6ops-pdhost') - draft update

 

Hi Fred,

But Figure 1 has Addresses allocated on the downstream interfaces, whereas I am talking about not put any Address on them be they virtual or real.

Alex

 

Le 30/05/2018 à 17:43, Templin (US), Fred L a écrit :

Hi Alex,

 

Good point, but I think the new figure you are proposing is already covered under

figure 1. Figure 1 is an IoT router that does RA to other nodes in the networks it

controls – whether the networks are internal virtual networks or external

physical networks. Perhaps some extra text to explain the IoT and downsteam

network RA use case in conjunction with Figure 1 would help? Any suggestions?

 

Thanks - Fred

 

From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Alexandre Petrescu
Sent: Wednesday, May 30, 2018 6:41 AM
To: v6ops@ietf.org
Subject: Re: [v6ops] IPv6 Prefix Delegation Models ('draft-templin-v6ops-pdhost') - draft update

 

I propose this figure as well, in which an IoT router 'R' does not form any address A on any of its interfaces, out of the delegated prefix P,
even though it _does_ request and obtain a prefix P and does RA it to other nodes in the network in controls.

                                   x
                                   |
                     upstream link |
                                   |
                        +----------+----------+
                        |  upstream interface |
                        +--+-+--+-+--+-----+--+
                        |                     |
                        | requesting node 'R' |
                        |                     |
                        +---------------------+
 
 
 
 
For comparison, the figures present now in -20 are these:
 
                                   x
                                   |
                     upstream link |
                                   |
                        +----------+----------+
                        |  upstream Interface |
                        +---------------------+
                        |                     |
                        | requesting node 'R' |
                        |                     |
                        +--+-+--+-+--+-----+--+
                        |A1| |A2| |A3| ... |An|
                        +--+-+--+-+--+-----+--+
                        |  virtual Interface  |
                        +---------------------+
 
                      Figure 2: Weak End System Model
 
 
                                   x
                                   |
                     upstream link |
                                   |
                        +----------+----------+
                        |  upstream interface |
                        +--+-+--+-+--+-----+--+
                        |A1| |A2| |A3| ... |An|
                        +--+-+--+-+--+-----+--+
                        |                     |
                        | requesting node 'R' |
                        |                     |
                        +---------------------+
                        |   virtual interface |
                        +---------------------+
                      Figure 3: Strong End System Model
 
 

 

Le 30/05/2018 à 03:14, Fred Baker a écrit :

General question to those who commented on the draft when we discussed it a few weeks ago: do you agree that this update addresses the issues you raised? Do you have further comments on it?
 
On May 29, 2018, at 9:13 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/
 
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-templin-v6ops-pdhost-20
https://datatracker.ietf.org/doc/html/draft-templin-v6ops-pdhost-20
 
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-templin-v6ops-pdhost-20
 
 
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
 

 

 


--------------10F0E010726EFF98A5F25CB2-- From nobody Thu May 31 09:37:01 2018 Return-Path: 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 AF86B12EB66 for ; Thu, 31 May 2018 09:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 ASktdD5o0gLq for ; Thu, 31 May 2018 09:36:55 -0700 (PDT) Received: from phx-mbsout-01.mbs.boeing.net (phx-mbsout-01.mbs.boeing.net [130.76.184.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAB0312D9FF for ; Thu, 31 May 2018 09:36:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id w4VGarVJ020300; Thu, 31 May 2018 09:36:53 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (xch15-06-08.nw.nos.boeing.com [137.136.238.222]) by phx-mbsout-01.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w4VGajtV020197 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 31 May 2018 09:36:45 -0700 Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 31 May 2018 09:36:44 -0700 Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1365.000; Thu, 31 May 2018 09:36:44 -0700 From: "Templin (US), Fred L" To: Alexandre Petrescu CC: "v6ops@ietf.org" Thread-Topic: [v6ops] IPv6 Prefix Delegation Models ('draft-templin-v6ops-pdhost') - draft update Thread-Index: AdP3gG5+uFo5RHF/RMmMgf6+VRvj7QAbdRgAABoRVgAACn8+YAAfKmkAAANOe6AACVkIAAANJ4Vg Date: Thu, 31 May 2018 16:36:44 +0000 Message-ID: References: <06CBD4DE-9E00-4501-92C4-1E2E1784B923@gmail.com> <6b5005f8-b1d3-0da6-6744-47f5cbe2e25e@gmail.com> <226862c69bcb48c9ac2abb87b4c7de59@XCH15-06-08.nw.nos.boeing.com> <002e2af1-603c-2e39-6aff-5b3cdcbe8514@gmail.com> <0a4bfb51c3634a9fa05e4b584ab0c647@XCH15-06-08.nw.nos.boeing.com> <51cb40fd-bd91-a32a-7f66-acfdd4f62c5e@gmail.com> In-Reply-To: <51cb40fd-bd91-a32a-7f66-acfdd4f62c5e@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [137.137.12.6] Content-Type: multipart/alternative; boundary="_000_b8bfcf73fa404259a7284c846a07abc0XCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: Subject: Re: [v6ops] IPv6 Prefix Delegation Models ('draft-templin-v6ops-pdhost') - draft update X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 16:36:59 -0000 --_000_b8bfcf73fa404259a7284c846a07abc0XCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SEkgQWxleCwNCg0KT0ssIGJ1dCB3aGF0IHlvdSBhcmUgYXJ0aWN1bGF0aW5nIHN0aWxsIGZhbGxz IHVuZGVyIHRoZSBDbGFzc2ljIFJvdXRpbmcgTW9kZWwNCmluIEZpZ3VyZSAxLiBUaGUgc3VwcG9y dGluZyB0ZXh0IHRoZXJlIGN1cnJlbnRseSBzYXlzOg0KDQogICDigJwgJ1InIGFzc2lnbnMgYWRk cmVzc2VzICdBKCopJyB0YWtlbiBmcm9tICdQJyB0byBkb3duc3RyZWFtIGludGVyZmFjZXMsIGFu ZCBob3N0cyAnSChpKScNCiAgICBvbiBkb3duc3RyZWFtIG5ldHdvcmtzIGFzc2lnbiBhZGRyZXNz ZXMgJ0EoKiknIHRha2VuIGZyb20gJ1AnIHRvIHRoZWlyIGludGVyZmFjZQ0KICAgIGF0dGFjaG1l bnRzIHRvIHRoZSBkb3duc3RyZWFtIGxpbmsuICdSJyB0aGVuIGFjdHMgYXMgYSByb3V0ZXIgZm9y IGhvc3RzICdIKGkpJyBvbg0KICAgIGRvd25zdHJlYW0gbmV0d29ya3MgYW5kIGFzIGEgaG9zdCBv biBiZWhhbGYgb2YgaXRzIGxvY2FsIGFwcGxpY2F0aW9ucywgaS5lLiwgdGhlIHNhbWUNCiAgICBh cyBmb3IgYW55IHJvdXRlci4gKFRoaXMgbW9kZWwgYWRkaXRpb25hbHkgc3VwcG9ydHMgcmVjdXJz aXZlIHByZWZpeCBzdWItZGVsZWdhdGlvbiB0bw0KICAgIG90aGVyIHJlcXVlc3Rpbmcgcm91dGVy cyBtb3JlIGRlZXBseSBlbWJlZGRlZCBpbiB0aGUgZG93bnN0cmVhbSBuZXR3b3JrLCBlLmcuLA0K ICAgc3ViLWRlbGVnYXRpb24gb2YgYSAvNDggaW50byBtdWx0aXBsZSAvNTYgcHJlZml4ZXMsIHN1 Yi1kZWxlZ2F0aW9uIG9mIGEgLzU2IGludG8gbXVsdGlwbGUNCiAgICAvNjAgcHJlZml4ZXMsIGV0 Yy4pLuKAnQ0KDQpJdCBzZWVtcyB0byBtZSB0aGF0IHRoZSBmaW5hbCBzZW50ZW5jZSBhbHJlYWR5 IGFydGljdWxhdGVzIHdoYXQgeW91IGFyZSBsb29raW5nDQpmb3IgaW4gdGVybXMgb2YgcHJlZml4 IHN1Yi1kZWxlZ2F0aW9uLCBidXQgdGhlIGluaXRpYWwgc2VudGVuY2Ugc2VlbXMgdG8gcmVxdWly ZQ0KdGhlIHJvdXRlciB0byBhc3NpZ24gYWRkcmVzc2VzIHRha2VuIGZyb20g4oCYUOKAmSB0byBv bmUgb2YgaXRzIGludGVyZmFjZXMgYW5kIHRoaXMNCmlzIHdoZXJlIHlvdXIgY29tbWVudCBhcHBs aWVzLg0KDQpIb3cgZG9lcyB0aGlzIGxvb2sgZm9yIGEgcHJvcG9zZWQgcmV3cml0ZToNCg0KICAg 4oCcICdSJyBhc3NpZ25zIGF0IGxlYXN0IG9uZSBnbG9iYWxseS11bmlxdWUgYWRkcmVzcyB0byBh biBpbnRlcmZhY2UgKGUuZy4sIHRvIHN1cHBvcnQgZXJyb3INCiAgICByZXBvcnRpbmcsIG5ldHdv cmsgbWFuYWdlbWVudCwgZXRjLiksIHdoZXJlIHRoZSBhZGRyZXNzKGVzKSBtYXkgYmUgdGFrZW4g ZnJvbSDigJhQ4oCZLA0KICAgIGNvbmZpZ3VyZWQgdmlhIFNMQUFDIGZyb20gYSBQSU8gcmVjZWl2 ZWQgaW4gYW4gUkEgbWVzc2FnZSByZWNlaXZlZCBvbiBhbiB1cHN0cmVhbQ0KICAgIGludGVyZmFj ZSwgbWFudWFsbHkgY29uZmlndXJlZCwgZXRjLiDigJhS4oCZIHRoZW4gYXNzaWducyB6ZXJvIG9y IG1vcmUgYWRkcmVzc2VzICdBKCopJyB0YWtlbg0KICAgIGZyb20gJ1AnIHRvIGRvd25zdHJlYW0g aW50ZXJmYWNlcywgYW5kIGFkdmVydGlzZXMgc3ViLXByZWZpeGVzIHRha2VuIGZyb20g4oCYUOKA mSBpbiBSQQ0KICAgIG1lc3NhZ2UgUElPIG9wdGlvbnMgdG8gaG9zdHMgJ0goaSknIG9uIGRvd25z dHJlYW0gbmV0d29ya3MuICdSJyB0aGVuIGFjdHMgYXMgYSByb3V0ZXINCiAgICBmb3IgaG9zdHMg J0goaSknIG9uIGRvd25zdHJlYW0gbmV0d29ya3MgYW5kIGFzIGEgaG9zdCBvbiBiZWhhbGYgb2Yg aXRzIGxvY2FsIGFwcGxpY2F0aW9ucywNCiAgICBpLmUuLCB0aGUgc2FtZSBhcyBmb3IgYW55IHJv dXRlci4gKFRoaXMgbW9kZWwgYWRkaXRpb25hbHkgc3VwcG9ydHMgcmVjdXJzaXZlIHByZWZpeCBz dWItDQogICAgZGVsZWdhdGlvbiB0byBvdGhlciByZXF1ZXN0aW5nIHJvdXRlcnMgbW9yZSBkZWVw bHkgZW1iZWRkZWQgaW4gdGhlIGRvd25zdHJlYW0NCiAgICBuZXR3b3JrLCBlLmcuLCBzdWItZGVs ZWdhdGlvbiBvZiBhIC80OCBpbnRvIG11bHRpcGxlIC81NiBwcmVmaXhlcywgc3ViLWRlbGVnYXRp b24gb2YgYQ0KICAgIC81NiBpbnRvIG11bHRpcGxlIC82MCBwcmVmaXhlcywgZXRjLiku4oCdDQoN CkNvbW1lbnRzPw0KDQpUaGFua3MgLSBGcmVkDQoNCkZyb206IEFsZXhhbmRyZSBQZXRyZXNjdSBb bWFpbHRvOmFsZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb21dDQpTZW50OiBUaHVyc2RheSwgTWF5 IDMxLCAyMDE4IDg6MzYgQU0NClRvOiBUZW1wbGluIChVUyksIEZyZWQgTCA8RnJlZC5MLlRlbXBs aW5AYm9laW5nLmNvbT4NCkNjOiB2Nm9wc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFt2Nm9wc10g SVB2NiBQcmVmaXggRGVsZWdhdGlvbiBNb2RlbHMgKCdkcmFmdC10ZW1wbGluLXY2b3BzLXBkaG9z dCcpIC0gZHJhZnQgdXBkYXRlDQoNCg0KDQoNCkxlIDMxLzA1LzIwMTggw6AgMTc6MDQsIFRlbXBs aW4gKFVTKSwgRnJlZCBMIGEgw6ljcml0IDoNCkFsZXgsDQoNCkkgZG9u4oCZdCBxdWl0ZSBmb2xs b3cg4oCTIGRvIHlvdSB3YW50IHVzIHRvIGRvY3VtZW50IHRoZSBjYXNlIHdoZXJlIHRoZQ0KcmVx dWVzdGluZyBub2RlIHJlY2VpdmVzIGEgZGVsZWdhdGVkIHByZWZpeCBhbmQgdGhlbiBkb2VzIG5v dGhpbmcNCndpdGggaXQgYXQgYWxsPw0KDQpObywgSSBkbyBub3Qgd2FudCB0byBleHByZXNzIHN1 Y2ggYSBjYXNlLg0KDQpJbiB0aGlzIHBhcnRpY3VsYXIgbGl0dGxlIGNhc2UgdGhlIG5vZGUgcmV2 ZWl2ZXMgYSBkZWxlZ2F0ZWQgcHJlZml4IF9hbmRfIGFkdmVydGlzZXMgaXQgaW4gUkEgZnVydGhl ciBkb3duLiAgWUV0IGl0IGRvZXMgbm90IHVzZSBpdCB0byBmb3JtIGFueSBhZGRyZXNzIGZvciBp dHNlbGYuDQpJbiBvcmRlciB0byBmb3JtIGFuIGFkZHJlc3MgZm9yIGl0c2VsZiB0aGUgbm9kZSB1 c2VzIHRoZSBwcmVmaXggcmVjZWl2ZWQgaW4gdGhlIFJBIGZyb20gdGhlIGNlbGx1bGFyIG5ldHdv cmsgKG5vdCBmcm9tIERIQ1AgUEQpLg0KDQoNCg0KVGhlIG5vZGUgbmVlZHMgYXQgbGVhc3Qgb25l IGdsb2JhbGx5LXVuaXF1ZSBhZGRyZXNzIGFzc2lnbmVkIHRvIHNvbWUNCmludGVyZmFjZSBzbyB0 aGF0IGl0IGNhbiBzb3VyY2UgSUNNUCBtZXNzYWdlcyB0aGF0IG5lZWQgdG8gdHJhdmVsIG1vcmUN CnRoYW4gb25lIGhvcC4gSXQgaXMgdHJ1ZSB0aGF0IHRoYXQgYWRkcmVzcyBjb3VsZCBjb21lIGZy b20gU0xBQUMgdXNpbmcNCmFuIFJBIFBJTyBpbnN0ZWFkIG9mIGZyb20gdGhlIGRlbGVnYXRlZCBw cmVmaXguDQoNCkkgYWdyZWUuDQoNCg0KQnV0IGlzIHRoZSBjYXNlIG9mIG5vdA0KZG9pbmcgYW55 dGhpbmcgYXQgYWxsIHdpdGggdGhlIGRlbGVnYXRlZCBwcmVmaXggaW50ZXJlc3Rpbmc/DQoNCkl0 IGlzIG5vdCAibm90IGRvaW5nIGFueXRoaW5nIGF0IGFsbCB3aXRoIHRoZSBkZWxlZ2F0ZWQgcHJl Zml4Ii4gIEl0IGRvZXMgc2V2ZXJhbCB0aGluZ3Mgd2l0aCB0aGUgZGVsZWdhdGVkIHByZWZpeDoN Ci0gZGVyaXZlcyBzdWItcHJlZml4ZXMgb3V0IG9mIGl0LCBtYWtpbmcgc2V2ZWFsIC82NHMgb3V0 IG9mIGEgLzU2LiAgVGhhdCBpcyBhbHJlYWR5IGFuIG9wZXJhdGlvbiB0aGF0IG11c3QgYmUgc3Bl Y2lmaWVkLg0KLSBpbnNlcnRzIHJvdXRlcyBpbiBpdHMgcm91dGluZyB0YWJsZSBmb3IgdGhlc2Ug cHJlZml4ZXMuDQotIGFkdmVydGlzZXMgdGhlc2UgcHJlZml4ZXMgaW4gUkEuDQotIHdoZW4gdGhl IGRlbGVnYXRlZCBwcmVmaXggY2hhbmdlcyBhbGwgdGhlIGFib3ZlIG11c3QgYmUgdXBkYXRlZC4N Cg0KRnJvbSBhIHNvZnR3YXJlIHBvaW50IG9mIHZpZXcgdGhhdCBpcyBhIGxvZiBvZiBvcGVyYXRp b25zLg0KDQpGcm9tIGFuIGludGVyb3BlcmFiaWxpdHkgc3RhbmRwb2ludDogZm9ybWluZyBhIC82 NSBvdXQgb2YgdGhlIC81NiwgYW5kIHB1dHRpbmcgaW4gUkEsIGNvdWxkIGJlIHJlYXNvbmFibGUs IHlldCBvbmx5IEJTRCBpbnRlcm9wZXJhdGVzIChub3QgbGludXgpLg0KDQpBbGV4DQoNCg0KDQpU aGFua3MgLSBGcmVkDQoNCkZyb206IEFsZXhhbmRyZSBQZXRyZXNjdSBbbWFpbHRvOmFsZXhhbmRy ZS5wZXRyZXNjdUBnbWFpbC5jb21dDQpTZW50OiBUaHVyc2RheSwgTWF5IDMxLCAyMDE4IDI6MzQg QU0NClRvOiBUZW1wbGluIChVUyksIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT48 bWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+DQpDYzogdjZvcHNAaWV0Zi5vcmc8bWFp bHRvOnY2b3BzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFt2Nm9wc10gSVB2NiBQcmVmaXggRGVs ZWdhdGlvbiBNb2RlbHMgKCdkcmFmdC10ZW1wbGluLXY2b3BzLXBkaG9zdCcpIC0gZHJhZnQgdXBk YXRlDQoNCg0KSGkgRnJlZCwNCg0KQnV0IEZpZ3VyZSAxIGhhcyBBZGRyZXNzZXMgYWxsb2NhdGVk IG9uIHRoZSBkb3duc3RyZWFtIGludGVyZmFjZXMsIHdoZXJlYXMgSSBhbSB0YWxraW5nIGFib3V0 IG5vdCBwdXQgYW55IEFkZHJlc3Mgb24gdGhlbSBiZSB0aGV5IHZpcnR1YWwgb3IgcmVhbC4NCg0K QWxleA0KDQpMZSAzMC8wNS8yMDE4IMOgIDE3OjQzLCBUZW1wbGluIChVUyksIEZyZWQgTCBhIMOp Y3JpdCA6DQpIaSBBbGV4LA0KDQpHb29kIHBvaW50LCBidXQgSSB0aGluayB0aGUgbmV3IGZpZ3Vy ZSB5b3UgYXJlIHByb3Bvc2luZyBpcyBhbHJlYWR5IGNvdmVyZWQgdW5kZXINCmZpZ3VyZSAxLiBG aWd1cmUgMSBpcyBhbiBJb1Qgcm91dGVyIHRoYXQgZG9lcyBSQSB0byBvdGhlciBub2RlcyBpbiB0 aGUgbmV0d29ya3MgaXQNCmNvbnRyb2xzIOKAkyB3aGV0aGVyIHRoZSBuZXR3b3JrcyBhcmUgaW50 ZXJuYWwgdmlydHVhbCBuZXR3b3JrcyBvciBleHRlcm5hbA0KcGh5c2ljYWwgbmV0d29ya3MuIFBl cmhhcHMgc29tZSBleHRyYSB0ZXh0IHRvIGV4cGxhaW4gdGhlIElvVCBhbmQgZG93bnN0ZWFtDQpu ZXR3b3JrIFJBIHVzZSBjYXNlIGluIGNvbmp1bmN0aW9uIHdpdGggRmlndXJlIDEgd291bGQgaGVs cD8gQW55IHN1Z2dlc3Rpb25zPw0KDQpUaGFua3MgLSBGcmVkDQoNCkZyb206IHY2b3BzIFttYWls dG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsZXhhbmRyZSBQZXRyZXNj dQ0KU2VudDogV2VkbmVzZGF5LCBNYXkgMzAsIDIwMTggNjo0MSBBTQ0KVG86IHY2b3BzQGlldGYu b3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdjZvcHNdIElQdjYgUHJl Zml4IERlbGVnYXRpb24gTW9kZWxzICgnZHJhZnQtdGVtcGxpbi12Nm9wcy1wZGhvc3QnKSAtIGRy YWZ0IHVwZGF0ZQ0KDQpJIHByb3Bvc2UgdGhpcyBmaWd1cmUgYXMgd2VsbCwgaW4gd2hpY2ggYW4g SW9UIHJvdXRlciAnUicgZG9lcyBub3QgZm9ybSBhbnkgYWRkcmVzcyBBIG9uIGFueSBvZiBpdHMg aW50ZXJmYWNlcywgb3V0IG9mIHRoZSBkZWxlZ2F0ZWQgcHJlZml4IFAsDQpldmVuIHRob3VnaCBp dCBfZG9lc18gcmVxdWVzdCBhbmQgb2J0YWluIGEgcHJlZml4IFAgYW5kIGRvZXMgUkEgaXQgdG8g b3RoZXIgbm9kZXMgaW4gdGhlIG5ldHdvcmsgaW4gY29udHJvbHMuDQoNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgeA0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwNCg0KICAgICAgICAgICAgICAgICAgICAgdXBzdHJlYW0gbGluayB8DQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KDQogICAgICAgICAgICAgICAgICAgICAgICAr LS0tLS0tLS0tLSstLS0tLS0tLS0tKw0KDQogICAgICAgICAgICAgICAgICAgICAgICB8ICB1cHN0 cmVhbSBpbnRlcmZhY2UgfA0KDQogICAgICAgICAgICAgICAgICAgICAgICArLS0rLSstLSstKy0t Ky0tLS0tKy0tKw0KDQogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgfA0KDQogICAgICAgICAgICAgICAgICAgICAgICB8IHJlcXVlc3Rpbmcgbm9kZSAnUicgfA0K DQogICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgfA0KDQogICAg ICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KDQoNCg0KDQoNCg0K DQoNCg0KRm9yIGNvbXBhcmlzb24sIHRoZSBmaWd1cmVzIHByZXNlbnQgbm93IGluIC0yMCBhcmUg dGhlc2U6DQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHgNCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQoNCiAgICAgICAgICAgICAgICAgICAg IHVwc3RyZWFtIGxpbmsgfA0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwN Cg0KICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0rLS0tLS0tLS0tLSsNCg0KICAg ICAgICAgICAgICAgICAgICAgICAgfCAgdXBzdHJlYW0gSW50ZXJmYWNlIHwNCg0KICAgICAgICAg ICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0KICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgIHwNCg0KICAgICAgICAgICAgICAgICAgICAg ICAgfCByZXF1ZXN0aW5nIG5vZGUgJ1InIHwNCg0KICAgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgIHwNCg0KICAgICAgICAgICAgICAgICAgICAgICAgKy0tKy0rLS0r LSstLSstLS0tLSstLSsNCg0KICAgICAgICAgICAgICAgICAgICAgICAgfEExfCB8QTJ8IHxBM3wg Li4uIHxBbnwNCg0KICAgICAgICAgICAgICAgICAgICAgICAgKy0tKy0rLS0rLSstLSstLS0tLSst LSsNCg0KICAgICAgICAgICAgICAgICAgICAgICAgfCAgdmlydHVhbCBJbnRlcmZhY2UgIHwNCg0K ICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0KDQoNCiAg ICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMjogV2VhayBFbmQgU3lzdGVtIE1vZGVsDQoNCg0K DQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB4DQoNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfA0KDQogICAgICAgICAgICAgICAgICAgICB1cHN0cmVh bSBsaW5rIHwNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tKy0tLS0tLS0tLS0rDQoNCiAgICAgICAgICAg ICAgICAgICAgICAgIHwgIHVwc3RyZWFtIGludGVyZmFjZSB8DQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICstLSstKy0tKy0rLS0rLS0tLS0rLS0rDQoNCiAgICAgICAgICAgICAgICAgICAgICAg IHxBMXwgfEEyfCB8QTN8IC4uLiB8QW58DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICstLSst Ky0tKy0rLS0rLS0tLS0rLS0rDQoNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICAgICAgICB8DQoNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgcmVxdWVzdGluZyBub2Rl ICdSJyB8DQoNCiAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICB8 DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgIHwgICB2aXJ0dWFsIGludGVyZmFjZSB8DQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCiAgICAgICAgICAgICAg ICAgICAgICBGaWd1cmUgMzogU3Ryb25nIEVuZCBTeXN0ZW0gTW9kZWwNCg0KDQoNCg0KDQpMZSAz MC8wNS8yMDE4IMOgIDAzOjE0LCBGcmVkIEJha2VyIGEgw6ljcml0IDoNCg0KR2VuZXJhbCBxdWVz dGlvbiB0byB0aG9zZSB3aG8gY29tbWVudGVkIG9uIHRoZSBkcmFmdCB3aGVuIHdlIGRpc2N1c3Nl ZCBpdCBhIGZldyB3ZWVrcyBhZ286IGRvIHlvdSBhZ3JlZSB0aGF0IHRoaXMgdXBkYXRlIGFkZHJl c3NlcyB0aGUgaXNzdWVzIHlvdSByYWlzZWQ/IERvIHlvdSBoYXZlIGZ1cnRoZXIgY29tbWVudHMg b24gaXQ/DQoNCg0KDQpPbiBNYXkgMjksIDIwMTgsIGF0IDk6MTMgUE0sIFRlbXBsaW4gKFVTKSwg RnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPjxtYWlsdG86RnJlZC5MLlRlbXBsaW5A Ym9laW5nLmNvbT4gd3JvdGU6DQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZv ciB0aGlzIGRyYWZ0IGlzOg0KDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC10ZW1wbGluLXY2b3BzLXBkaG9zdC8NCg0KDQoNClRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZl cnNpb25zIGF2YWlsYWJsZSBhdDoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXRlbXBsaW4tdjZvcHMtcGRob3N0LTIwDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2h0bWwvZHJhZnQtdGVtcGxpbi12Nm9wcy1wZGhvc3QtMjANCg0KDQoNCkEgZGlmZiBmcm9t IHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0LTIwDQoNCg0KDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KdjZv cHMgbWFpbGluZyBsaXN0DQoNCnY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4N Cg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQoNCg0KDQoN Cg== --_000_b8bfcf73fa404259a7284c846a07abc0XCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyBcLHNlcmlmIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0K YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCglt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXpl OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsNCgljb2xvcjpi bGFjazt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJ Y29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFt ZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SEkgQWxleCw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PGJyPg0KT0ssIGJ1dCB3aGF0IHlvdSBhcmUgYXJ0aWN1bGF0aW5nIHN0aWxs IGZhbGxzIHVuZGVyIHRoZSBDbGFzc2ljIFJvdXRpbmcgTW9kZWw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ aW4gRmlndXJlIDEuIFRoZSBzdXBwb3J0aW5nIHRleHQgdGhlcmUgY3VycmVudGx5IHNheXM6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsg4oCc ICdSJyBhc3NpZ25zIGFkZHJlc3NlcyAnQSgqKScgdGFrZW4gZnJvbSAnUCcgdG8gZG93bnN0cmVh bSBpbnRlcmZhY2VzLCBhbmQgaG9zdHMgJ0goaSknPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyZuYnNwOyBvbiBkb3duc3RyZWFtIG5ldHdvcmtzIGFzc2lnbiBhZGRyZXNzZXMgJ0EoKikn IHRha2VuIGZyb20gJ1AnIHRvIHRoZWlyIGludGVyZmFjZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJz cDsmbmJzcDsmbmJzcDsgYXR0YWNobWVudHMgdG8gdGhlIGRvd25zdHJlYW0gbGluay4gJ1InIHRo ZW4gYWN0cyBhcyBhIHJvdXRlciBmb3IgaG9zdHMgJ0goaSknIG9uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOyZuYnNwOyZuYnNwOyBkb3duc3RyZWFtIG5ldHdvcmtzIGFuZCBhcyBhIGhvc3Qgb24g YmVoYWxmIG9mIGl0cyBsb2NhbCBhcHBsaWNhdGlvbnMsIGkuZS4sIHRoZSBzYW1lPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyBhcyBmb3IgYW55IHJvdXRlci4gKFRoaXMgbW9k ZWwgYWRkaXRpb25hbHkgc3VwcG9ydHMgcmVjdXJzaXZlIHByZWZpeCBzdWItZGVsZWdhdGlvbiB0 bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsgb3RoZXIgcmVxdWVzdGluZyBy b3V0ZXJzIG1vcmUgZGVlcGx5IGVtYmVkZGVkIGluIHRoZSBkb3duc3RyZWFtIG5ldHdvcmssIGUu Zy4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyAmbmJzcDtzdWItZGVsZWdhdGlvbiBvZiBhIC80 OCBpbnRvIG11bHRpcGxlIC81NiBwcmVmaXhlcywgc3ViLWRlbGVnYXRpb24gb2YgYSAvNTYgaW50 byBtdWx0aXBsZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsgLzYwIHByZWZp eGVzLCBldGMuKS7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi Pkl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlIGZpbmFsIHNlbnRlbmNlIGFscmVhZHkgYXJ0aWN1bGF0 ZXMgd2hhdCB5b3UgYXJlIGxvb2tpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Zm9yIGluIHRlcm1zIG9m IHByZWZpeCBzdWItZGVsZWdhdGlvbiwgYnV0IHRoZSBpbml0aWFsIHNlbnRlbmNlIHNlZW1zIHRv IHJlcXVpcmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dGhlIHJvdXRlciB0byBhc3NpZ24gYWRkcmVzc2Vz IHRha2VuIGZyb20g4oCYUOKAmSB0byBvbmUgb2YgaXRzIGludGVyZmFjZXMgYW5kIHRoaXM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+aXMgd2hlcmUgeW91ciBjb21tZW50IGFwcGxpZXMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Ib3cgZG9lcyB0aGlzIGxvb2sgZm9yIGEg cHJvcG9zZWQgcmV3cml0ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyDigJwgJ1InIGFzc2lnbnMgYXQgbGVhc3Qgb25lIGdsb2JhbGx5LXVu aXF1ZSBhZGRyZXNzIHRvIGFuIGludGVyZmFjZSAoZS5nLiwgdG8gc3VwcG9ydCBlcnJvcjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsgcmVwb3J0aW5nLCBuZXR3b3JrIG1hbmFn ZW1lbnQsIGV0Yy4pLCB3aGVyZSB0aGUgYWRkcmVzcyhlcykgbWF5IGJlIHRha2VuIGZyb20g4oCY UOKAmSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbmZpZ3VyZWQgdmlh IFNMQUFDIGZyb20gYSBQSU8gcmVjZWl2ZWQgaW4gYW4gUkEgbWVzc2FnZSByZWNlaXZlZCBvbiBh biB1cHN0cmVhbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsgaW50ZXJmYWNl LCBtYW51YWxseSBjb25maWd1cmVkLCBldGMuIOKAmFLigJkgdGhlbiBhc3NpZ25zIHplcm8gb3Ig bW9yZSBhZGRyZXNzZXMgJ0EoKiknIHRha2VuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw OyZuYnNwOyBmcm9tICdQJyB0byBkb3duc3RyZWFtIGludGVyZmFjZXMsIGFuZCBhZHZlcnRpc2Vz IHN1Yi1wcmVmaXhlcyB0YWtlbiBmcm9tIOKAmFDigJkgaW4gUkE8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1lc3NhZ2UgUElPIG9wdGlvbnMgdG8gaG9zdHMgJ0goaSknIG9u IGRvd25zdHJlYW0gbmV0d29ya3MuICdSJyB0aGVuIGFjdHMgYXMgYSByb3V0ZXI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZvciBob3N0cyAnSChpKScgb24gZG93bnN0cmVh bSBuZXR3b3JrcyBhbmQgYXMgYSBob3N0IG9uIGJlaGFsZiBvZiBpdHMgbG9jYWwgYXBwbGljYXRp b25zLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsgaS5lLiwgdGhlIHNhbWUg YXMgZm9yIGFueSByb3V0ZXIuIChUaGlzIG1vZGVsIGFkZGl0aW9uYWx5IHN1cHBvcnRzIHJlY3Vy c2l2ZSBwcmVmaXggc3ViLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsgZGVs ZWdhdGlvbiB0byBvdGhlciByZXF1ZXN0aW5nIHJvdXRlcnMgbW9yZSBkZWVwbHkgZW1iZWRkZWQg aW4gdGhlIGRvd25zdHJlYW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5l dHdvcmssIGUuZy4sIHN1Yi1kZWxlZ2F0aW9uIG9mIGEgLzQ4IGludG8gbXVsdGlwbGUgLzU2IHBy ZWZpeGVzLCBzdWItZGVsZWdhdGlvbiBvZiBhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNw OyZuYnNwOyAvNTYgaW50byBtdWx0aXBsZSAvNjAgcHJlZml4ZXMsIGV0Yy4pLuKAnTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q29tbWVudHM/PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgLSBGcmVkPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBw dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IEFsZXhhbmRyZSBQZXRyZXNjdSBbbWFp bHRvOmFsZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1 cnNkYXksIE1heSAzMSwgMjAxOCA4OjM2IEFNPGJyPg0KPGI+VG86PC9iPiBUZW1wbGluIChVUyks IEZyZWQgTCAmbHQ7RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+ IHY2b3BzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIElQdjYgUHJl Zml4IERlbGVnYXRpb24gTW9kZWxzICgnZHJhZnQtdGVtcGxpbi12Nm9wcy1wZGhvc3QnKSAtIGRy YWZ0IHVwZGF0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+TGUgMzEvMDUvMjAxOCDDoCAxNzowNCwgVGVtcGxpbiAoVVMp LCBGcmVkIEwgYSDDqWNyaXQmbmJzcDs6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFsZXgsPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGRvbuKAmXQgcXVpdGUgZm9s bG93IOKAkyBkbyB5b3Ugd2FudCB1cyB0byBkb2N1bWVudCB0aGUgY2FzZSB3aGVyZSB0aGU8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+cmVxdWVzdGluZyBub2RlIHJlY2VpdmVzIGEgZGVsZWdhdGVkIHByZWZp eCBhbmQgdGhlbiBkb2VzIG5vdGhpbmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+d2l0aCBpdCBhdCBhbGw/ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KTm8sIEkgZG8gbm90IHdhbnQgdG8gZXhwcmVzcyBzdWNoIGEgY2FzZS48YnI+DQo8 YnI+DQpJbiB0aGlzIHBhcnRpY3VsYXIgbGl0dGxlIGNhc2UgdGhlIG5vZGUgcmV2ZWl2ZXMgYSBk ZWxlZ2F0ZWQgcHJlZml4IF9hbmRfIGFkdmVydGlzZXMgaXQgaW4gUkEgZnVydGhlciBkb3duLiZu YnNwOyBZRXQgaXQgZG9lcyBub3QgdXNlIGl0IHRvIGZvcm0gYW55IGFkZHJlc3MgZm9yIGl0c2Vs Zi48YnI+DQpJbiBvcmRlciB0byBmb3JtIGFuIGFkZHJlc3MgZm9yIGl0c2VsZiB0aGUgbm9kZSB1 c2VzIHRoZSBwcmVmaXggcmVjZWl2ZWQgaW4gdGhlIFJBIGZyb20gdGhlIGNlbGx1bGFyIG5ldHdv cmsgKG5vdCBmcm9tIERIQ1AgUEQpLjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBub2RlIG5lZWRzIGF0IGxlYXN0IG9uZSBnbG9iYWxs eS11bmlxdWUgYWRkcmVzcyBhc3NpZ25lZCB0byBzb21lPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmludGVy ZmFjZSBzbyB0aGF0IGl0IGNhbiBzb3VyY2UgSUNNUCBtZXNzYWdlcyB0aGF0IG5lZWQgdG8gdHJh dmVsIG1vcmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dGhhbiBvbmUgaG9wLiBJdCBpcyB0cnVlIHRoYXQg dGhhdCBhZGRyZXNzIGNvdWxkIGNvbWUgZnJvbSBTTEFBQyB1c2luZzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5hbiBSQSBQSU8gaW5zdGVhZCBvZiBmcm9tIHRoZSBkZWxlZ2F0ZWQgcHJlZml4Lg0KPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy Pg0KSSBhZ3JlZS48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJ1dCBpcyB0aGUgY2Fz ZSBvZiBub3Q8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ZG9pbmcgYW55dGhpbmcgYXQgYWxsIHdpdGggdGhl IGRlbGVnYXRlZCBwcmVmaXggaW50ZXJlc3Rpbmc/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSXQgaXMgbm90ICZxdW90O25v dCBkb2luZyBhbnl0aGluZyBhdCBhbGwgd2l0aCB0aGUgZGVsZWdhdGVkIHByZWZpeCZxdW90Oy4m bmJzcDsgSXQgZG9lcyBzZXZlcmFsIHRoaW5ncyB3aXRoIHRoZSBkZWxlZ2F0ZWQgcHJlZml4Og0K PGJyPg0KLSBkZXJpdmVzIHN1Yi1wcmVmaXhlcyBvdXQgb2YgaXQsIG1ha2luZyBzZXZlYWwgLzY0 cyBvdXQgb2YgYSAvNTYuJm5ic3A7IFRoYXQgaXMgYWxyZWFkeSBhbiBvcGVyYXRpb24gdGhhdCBt dXN0IGJlIHNwZWNpZmllZC48YnI+DQotIGluc2VydHMgcm91dGVzIGluIGl0cyByb3V0aW5nIHRh YmxlIGZvciB0aGVzZSBwcmVmaXhlcy48YnI+DQotIGFkdmVydGlzZXMgdGhlc2UgcHJlZml4ZXMg aW4gUkEuPGJyPg0KLSB3aGVuIHRoZSBkZWxlZ2F0ZWQgcHJlZml4IGNoYW5nZXMgYWxsIHRoZSBh Ym92ZSBtdXN0IGJlIHVwZGF0ZWQuPGJyPg0KPGJyPg0KRnJvbSBhIHNvZnR3YXJlIHBvaW50IG9m IHZpZXcgdGhhdCBpcyBhIGxvZiBvZiBvcGVyYXRpb25zLjxicj4NCjxicj4NCkZyb20gYW4gaW50 ZXJvcGVyYWJpbGl0eSBzdGFuZHBvaW50OiBmb3JtaW5nIGEgLzY1IG91dCBvZiB0aGUgLzU2LCBh bmQgcHV0dGluZyBpbiBSQSwgY291bGQgYmUgcmVhc29uYWJsZSwgeWV0IG9ubHkgQlNEIGludGVy b3BlcmF0ZXMgKG5vdCBsaW51eCkuPGJyPg0KPGJyPg0KQWxleDxicj4NCjxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyAtIEZyZWQ8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4gQWxleGFuZHJlIFBldHJlc2N1 IFs8YSBocmVmPSJtYWlsdG86YWxleGFuZHJlLnBldHJlc2N1QGdtYWlsLmNvbSI+bWFpbHRvOmFs ZXhhbmRyZS5wZXRyZXNjdUBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJz ZGF5LCBNYXkgMzEsIDIwMTggMjozNCBBTTxicj4NCjxiPlRvOjwvYj4gVGVtcGxpbiAoVVMpLCBG cmVkIEwgPGEgaHJlZj0ibWFpbHRvOkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20iPiZsdDtGcmVk LkwuVGVtcGxpbkBib2VpbmcuY29tJmd0OzwvYT48YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1h aWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbdjZvcHNdIElQdjYgUHJlZml4IERlbGVnYXRpb24gTW9kZWxzICgnZHJhZnQtdGVt cGxpbi12Nm9wcy1wZGhvc3QnKSAtIGRyYWZ0IHVwZGF0ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3ICxzZXJpZiZxdW90OyxzZXJpZiI+SGkgRnJlZCw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyAsc2VyaWYmcXVvdDssc2VyaWYiPkJ1dCBGaWd1cmUgMSBoYXMgQWRkcmVzc2Vz IGFsbG9jYXRlZCBvbiB0aGUgZG93bnN0cmVhbSBpbnRlcmZhY2VzLCB3aGVyZWFzIEkgYW0gdGFs a2luZyBhYm91dCBub3QgcHV0IGFueSBBZGRyZXNzIG9uIHRoZW0gYmUgdGhleSB2aXJ0dWFsIG9y IHJlYWwuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcgLHNlcmlmJnF1b3Q7LHNlcmlmIj5B bGV4PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGUgMzAvMDUvMjAxOCDD oCAxNzo0MywgVGVtcGxpbiAoVVMpLCBGcmVkIEwgYSDDqWNyaXQmbmJzcDs6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkhpIEFsZXgsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5Hb29kIHBvaW50LCBidXQgSSB0aGluayB0aGUgbmV3IGZpZ3VyZSB5b3UgYXJlIHByb3Bv c2luZyBpcyBhbHJlYWR5IGNvdmVyZWQgdW5kZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ZmlndXJlIDEu IEZpZ3VyZSAxIGlzIGFuIElvVCByb3V0ZXIgdGhhdCBkb2VzIFJBIHRvIG90aGVyIG5vZGVzIGlu IHRoZSBuZXR3b3JrcyBpdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5jb250cm9scyDigJMgd2hldGhlciB0 aGUgbmV0d29ya3MgYXJlIGludGVybmFsIHZpcnR1YWwgbmV0d29ya3Mgb3IgZXh0ZXJuYWw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+cGh5c2ljYWwgbmV0d29ya3MuIFBlcmhhcHMgc29tZSBleHRyYSB0ZXh0 IHRvIGV4cGxhaW4gdGhlIElvVCBhbmQgZG93bnN0ZWFtPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPm5ldHdv cmsgUkEgdXNlIGNhc2UgaW4gY29uanVuY3Rpb24gd2l0aCBGaWd1cmUgMSB3b3VsZCBoZWxwPyBB bnkgc3VnZ2VzdGlvbnM/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5UaGFua3MgLSBGcmVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndp bmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4 dCI+IHY2b3BzIFs8YSBocmVmPSJtYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRv OnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BbGV4YW5k cmUgUGV0cmVzY3U8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBNYXkgMzAsIDIwMTggNjo0 MSBBTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9w c0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gSVB2NiBQcmVm aXggRGVsZWdhdGlvbiBNb2RlbHMgKCdkcmFmdC10ZW1wbGluLXY2b3BzLXBkaG9zdCcpIC0gZHJh ZnQgdXBkYXRlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcgLHNlcmlmJnF1b3Q7LHNlcmlmIj5JIHByb3Bvc2UgdGhpcyBmaWd1cmUgYXMgd2VsbCwgaW4g d2hpY2ggYW4gSW9UIHJvdXRlciAnUicgZG9lcyBub3QgZm9ybSBhbnkgYWRkcmVzcyBBIG9uIGFu eSBvZiBpdHMgaW50ZXJmYWNlcywgb3V0IG9mIHRoZSBkZWxlZ2F0ZWQgcHJlZml4IFAsPGJyPg0K ZXZlbiB0aG91Z2ggaXQgX2RvZXNfIHJlcXVlc3QgYW5kIG9idGFpbiBhIHByZWZpeCBQIGFuZCBk b2VzIFJBIGl0IHRvIG90aGVyIG5vZGVzIGluIHRoZSBuZXR3b3JrIGluIGNvbnRyb2xzLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHg8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1cHN0cmVhbSBsaW5rIHw8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0t LS0mIzQzOy0tLS0tLS0tLS0mIzQzOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8Jm5ic3A7IHVwc3RyZWFtIGludGVyZmFjZSB8PG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyYjNDM7LS0mIzQzOy0mIzQzOy0tJiM0 MzstJiM0MzstLSYjNDM7LS0tLS0mIzQzOy0tJiM0Mzs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgcmVxdWVzdGluZyBub2RlICdSJyB8PG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0t LS0tLS0tLS0tLSYjNDM7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Rm9yIGNvbXBhcmlz b24sIHRoZSBmaWd1cmVzIHByZXNlbnQgbm93IGluIC0yMCBhcmUgdGhlc2U6PG86cD48L286cD48 L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHg8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB1cHN0 cmVhbSBsaW5rIHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmIzQzOy0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0mIzQzOzxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8Jm5ic3A7IHVwc3RyZWFtIEludGVyZmFj ZSB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7 LS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgcmVxdWVzdGluZyBub2RlICdSJyB8PG86cD48L286cD48L3By ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmIzQzOy0tJiM0MzstJiM0MzstLSYj NDM7LSYjNDM7LS0mIzQzOy0tLS0tJiM0MzstLSYjNDM7PG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHxBMXwgfEEyfCB8QTN8IC4uLiB8QW58PG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0mIzQzOy0mIzQz Oy0tJiM0MzstJiM0MzstLSYjNDM7LS0tLS0mIzQzOy0tJiM0Mzs8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB2aXJ0dWFsIEludGVyZmFjZSZu YnNwOyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYj NDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJz cDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRmlndXJlIDI6IFdlYWsgRW5k IFN5c3RlbSBNb2RlbDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB4PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdXBzdHJl YW0gbGluayB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJiM0MzstLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyB1cHN0cmVhbSBpbnRlcmZhY2Ug fDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0t JiM0MzstJiM0MzstLSYjNDM7LSYjNDM7LS0mIzQzOy0tLS0tJiM0MzstLSYjNDM7PG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHxBMXwgfEEyfCB8QTN8IC4u LiB8QW58PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYj NDM7LS0mIzQzOy0mIzQzOy0tJiM0MzstJiM0MzstLSYjNDM7LS0tLS0mIzQzOy0tJiM0Mzs8bzpw PjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgcmVxdWVzdGlu ZyBub2RlICdSJyB8PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7PG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgdmlydHVhbCBpbnRlcmZh Y2UgfDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQz Oy0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IEZpZ3VyZSAzOiBTdHJvbmcgRW5kIFN5c3RlbSBNb2RlbDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9w cmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5MZSAzMC8wNS8yMDE4IMOgIDAzOjE0LCBGcmVkIEJha2VyIGEg w6ljcml0Jm5ic3A7OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+R2VuZXJhbCBxdWVz dGlvbiB0byB0aG9zZSB3aG8gY29tbWVudGVkIG9uIHRoZSBkcmFmdCB3aGVuIHdlIGRpc2N1c3Nl ZCBpdCBhIGZldyB3ZWVrcyBhZ286IGRvIHlvdSBhZ3JlZSB0aGF0IHRoaXMgdXBkYXRlIGFkZHJl c3NlcyB0aGUgaXNzdWVzIHlvdSByYWlzZWQ/IERvIHlvdSBoYXZlIGZ1cnRoZXIgY29tbWVudHMg b24gaXQ/PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxw cmU+T24gTWF5IDI5LCAyMDE4LCBhdCA5OjEzIFBNLCBUZW1wbGluIChVUyksIEZyZWQgTCA8YSBo cmVmPSJtYWlsdG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbSI+Jmx0O0ZyZWQuTC5UZW1wbGlu QGJvZWluZy5jb20mZ3Q7PC9hPiB3cm90ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPlRoZSBJ RVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0LyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtdGVtcGxpbi12Nm9wcy1wZGhvc3QvPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZl cnNpb25zIGF2YWlsYWJsZSBhdDo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGVtcGxpbi12Nm9wcy1wZGhvc3QtMjAiPmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10ZW1wbGluLXY2b3BzLXBkaG9zdC0yMDwv YT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9odG1sL2RyYWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0LTIwIj5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0LTIw PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9ZHJhZnQtdGVtcGxpbi12Nm9wcy1wZGhvc3QtMjAiPmh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC10ZW1wbGluLXY2b3BzLXBkaG9zdC0yMDwvYT48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHByZT4m bmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnY2b3BzIG1haWxpbmcg bGlzdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9y ZyI+djZvcHNAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m bmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_b8bfcf73fa404259a7284c846a07abc0XCH150608nwnosboeingcom_-- From nobody Thu May 31 14:29:15 2018 Return-Path: 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 CD6E4131F4A for ; Thu, 31 May 2018 14:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 U_5HaVqP6vZ1 for ; Thu, 31 May 2018 14:29:10 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (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 184F01326D5 for ; Thu, 31 May 2018 14:29:10 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id a14-v6so11409384pfi.1 for ; Thu, 31 May 2018 14:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=JTbOyll7FyxgJ4tuANfU9cWdDdLe6CicBvwyQ3wOuuE=; b=F+KdKy60bTPYdoAtigV/0bT4HEscZX05Vs6YJkHXBSnNMk4EgUmdilGgmpIvb+ItOm 2vQsSM0WEivPbZWHwNkcya8Qk1FjWWvQ+tWbCfHTSD0RKP49eoymi+k37SVdXgrk465U AJu75msTuutrPdRqz4R8bdScIq4mXexUFnrsvqzMYc3IHLZPbPJMhlD9Ne4IRbAKFKu6 ZqGX5tzRXWMTkeQMAWueO3NltuDCDmRcYPYCVFtNR85i12LDy6eIZKY+yUB9tq+kM8EK YUGhFA/fqNJbqEQYFrj2pHtypYOhqeUnsXhloFz9L7mI6Mntbz/YPEGhbnBQlvRGMCmD XGjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=JTbOyll7FyxgJ4tuANfU9cWdDdLe6CicBvwyQ3wOuuE=; b=r9g0gFHVeTKOG+mM4+tPjazpS37xX08EtvJsEtdUUtXhR4OEM7IJzvDmLqBksJlKNU n1zJN8jdTLq38PURZWWQeZW4vlNRTOYmhGeUFuLZR/ag5OSYVIO5Fdy01OLxfZy2Ea7c LXEOmtz1r/WmESymgcGjE914eIh1QYDrQaRvYcQCGj5g42ZfiKZpm+QIA/mCvVyB4aS7 nI6QtrK0ybP5spIYo6+mXJ+JyndhDpBGgh44kU2gcUF2l8pwP8v2hyNsKdEqVSzpCqbz eNBc2sxWTwaJMkzyMZhAQ7gKN9aRmmyPv/uHheY+R7u1olcM3rde69r2DwYc/9RVjonH Zh7g== X-Gm-Message-State: ALKqPwfFy7tEgBtVvtvYImviG+Vx/ASmDjzFQEYuQFwtWZSdcLrY7GfD v2opaF2Kkm7xKLRLNh2NC3wcMw== X-Google-Smtp-Source: ADUXVKKuLEUFPBSO1PhYiV0CoGQ1YHla4pYqsKWGCzLfoakADuPe2z1E4tg/rLA9l0Poyv/BZplVGA== X-Received: by 2002:a63:24c4:: with SMTP id k187-v6mr4040182pgk.434.1527802149409; Thu, 31 May 2018 14:29:09 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id z83-v6sm77383157pfd.103.2018.05.31.14.29.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 May 2018 14:29:08 -0700 (PDT) To: Erik Kline , jordi.palet=40consulintel.es@dmarc.ietf.org Cc: "v6ops@ietf.org WG" References: <59AC1E5C-31FF-4D74-B15F-76EBDD3D9362@consulintel.es> From: Brian E Carpenter Message-ID: <0eb8395f-ec1f-3592-b7f4-9634f47a942d@gmail.com> Date: Fri, 1 Jun 2018 09:29:12 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] =?utf-8?q?Internet_engineers_tear_into_United_Nations=27?= =?utf-8?q?_plan_to_move_us_all_to_IPv6_=E2=80=A2_The_Register?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 21:29:14 -0000 On 31/05/2018 20:16, Erik Kline wrote: > My reading of the doc was that's is mostly "if you have a > {/56,/48,...} here's how you might carve it up to provide sub-networks > of different service types". It wastes bits. That's the problem with almost any scheme that puts some kind of semantics on address bits or sub-fields. I agree that its global impact is much less within an ISP-assigned prefix than it would be if applied to bits that might end up in the BGP4 routing tables, but it's still a very naive and wasteful approach. Certainly some sites or types of application might end up doing this sort of thing. The Protocol Police won't stop them. But seeing it in an ITU document is very disturbing. Brian > I don't see any strong "requirements" language that leads me to think > this is anything other than one possible network layout. > On Thu, 31 May 2018 at 15:48, JORDI PALET MARTINEZ > wrote: >> >> Just realized, you have even the video of the presentation and what wa= s said after ... >> >> https://ripe76.ripe.net/programme/meeting-plan/ipv6-wg/ >> >> Also, the mail archive is here: >> >> https://www.ripe.net/ripe/mail/archives/ipv6-wg/ >> >> >> Saludos, >> Jordi >> >> >> >> =EF=BB=BF-----Mensaje original----- >> De: v6ops en nombre de JORDI PALET MARTINEZ <= jordi.palet=3D40consulintel.es@dmarc.ietf.org> >> Fecha: jueves, 31 de mayo de 2018, 8:42 >> Para: IPv6 Operations >> Asunto: Re: [v6ops] Internet engineers tear into United Nations' plan= to move us all to IPv6 =E2=80=A2 The Register >> >> It was presented two weeks ago in the IPv6 WG of the RIPE meeting = in Marseille, with a strong opposition. >> >> You can track also the comments in the mailing list archive. >> >> I explicitly suggested that this is topic of IETF, and they should= come to v6ops or 6man or one of the IoT WGs if they really believe this = is right. >> >> RIRs also have liaison and are working to tell them that this is r= eally broken. >> >> Regards, >> Jordi >> >> >> >> =EF=BB=BF-----Mensaje original----- >> De: v6ops en nombre de Brian E Carpenter = >> Organizaci=C3=B3n: University of Auckland >> Fecha: jueves, 31 de mayo de 2018, 5:52 >> Para: IPv6 Operations >> Asunto: [v6ops] Internet engineers tear into United Nations' plan = to move us all to IPv6 =E2=80=A2 The Register >> >> Ignoring the journalistic exaggerations in the article (2nd li= nk below), >> do we have a liaison comment going to the ITU about this draft= ? >> https://regmedia.co.uk/2018/05/30/itu-ipv6-may18.pdf >> It seems to be an excellent recipe for burning up address spac= e. >> The due date appears to be now. >> >> http://www.theregister.co.uk/2018/05/30/internet_engineers_uni= ted_nations_ipv6/ >> >> Regards >> Brian >> >> >> _______________________________________________ >> 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 privileg= ed or confidential. The information is intended to be for the exclusive u= se of the individual(s) named above and further non-explicilty authorized= disclosure, copying, distribution or use of the contents of this informa= tion, even if partially, including attached files, is strictly prohibited= and will be considered a criminal offense. If you are not the intended r= ecipient be aware that any disclosure, copying, distribution or use of th= e contents of this information, even if partially, including attached fil= es, 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 o= r confidential. The information is intended to be for the exclusive use o= f the individual(s) named above and further non-explicilty authorized dis= closure, 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 recip= ient be aware that any disclosure, copying, distribution or use of the co= ntents of this information, even if partially, including attached files, = is strictly prohibited, will be considered a criminal offense, so you mus= t reply to the original sender to inform about this communication and del= ete it. >> >> >> >> _______________________________________________ >> 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 From nobody Thu May 31 14:32:05 2018 Return-Path: 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 16029132D49 for ; Thu, 31 May 2018 14:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 AX5UQSaJhN0Y for ; Thu, 31 May 2018 14:32:01 -0700 (PDT) Received: from mail-pl0-x22b.google.com (mail-pl0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) (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 177F9132798 for ; Thu, 31 May 2018 14:32:01 -0700 (PDT) Received: by mail-pl0-x22b.google.com with SMTP id c41-v6so13971960plj.10 for ; Thu, 31 May 2018 14:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=oaYXuZjsrN+yHZWZcXTQkA9oIOuFuYrMnqep3djDp6k=; b=VIofpwlFMxd8hNtaaR5aAIfTa8Qgc5OmdPuQEyrUtqGNY4LsFawoyfNE+B80Y+1SEw p2fVdNwg67PDCv9ceyVgrvJlJjzXSAMyi5IATQQGqVj/ckbMGJuqxvBa3H5NEbKWWNPo i/R1Tj/7VZFkQg7caDpzV6ga4O+mzcQhRZ/C5JeEPY/f2l5rDtIlk0/7J5JEe9Z0Qkau NzcDmMqITx3dUNjNAum5ORQ7Fm5lZmkjS31iv7mrz07T6Dlytkm4haucO1QKmkt59ci3 TxVu7hp4MPoM3eKdx4UNE/SvMpCB8OT/wf5A6TNdseIOaL15xoc0IuwGW31O+BkAgsx/ Ne1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=oaYXuZjsrN+yHZWZcXTQkA9oIOuFuYrMnqep3djDp6k=; b=DW9NMIFeFij1dL+7GfOiazGz0In+d2W9jillogM4GXnSonxSQEPRKr+8PQ0pRGY3c3 WWbDeZSfhyTUrJxIOfphVeNpYWwVEeLgtCBg+6s8UREy+R8+QuhxUpWnI4HUmZVdGMrM 78R4tpIzZtRRCOmRWOEr3L5c+l/X8J3ieodojluQHb1i57J/QaVIFEnXeKzI6PUqkpzM QzvZx4UDu6nWmkGiMjL2i0Slm5fXlgjMskmF8fUe2AHidVwUVbhRTQion5GJZgnBOtE0 0EYydAU/SmHO5Go6D6MHDfcAWsU7MlNEE7QvTQuwIQEBQRuvYh3oYI1Vc52PimSDHhgF nP0Q== X-Gm-Message-State: ALKqPwfWXLB+c7R0r/7oH/ZC37rgZ+c5KwkO2+8DIuj3GS/YBjaCsN3k 3Wp/NtCaxFc6BG5VY3XfCc6hiA== X-Google-Smtp-Source: ADUXVKLhrdLya5f0BN7zMzcVQd2cMzV8khYyvuXPEUt3oe9EQ6TMPLHQHWGuHTiszubcE0Efy1dB6A== X-Received: by 2002:a17:902:2927:: with SMTP id g36-v6mr8375864plb.303.1527802320435; Thu, 31 May 2018 14:32:00 -0700 (PDT) Received: from [192.168.178.21] ([118.148.121.80]) by smtp.gmail.com with ESMTPSA id o84-v6sm88447368pfi.27.2018.05.31.14.31.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 May 2018 14:31:59 -0700 (PDT) To: Lee Howard , v6ops@ietf.org References: <17a0f0e1-c822-21e8-31e0-41c96ae1b2a5@gmail.com> <89a7eb01-e22f-f518-491a-822adae19003@asgard.org> From: Brian E Carpenter Message-ID: <73132fdc-13f0-4171-a7fa-275d63f778db@gmail.com> Date: Fri, 1 Jun 2018 09:32:04 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <89a7eb01-e22f-f518-491a-822adae19003@asgard.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] =?utf-8?q?Internet_engineers_tear_into_United_Nations=27?= =?utf-8?q?_plan_to_move_us_all_to_IPv6_=E2=80=A2_The_Register?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 21:32:03 -0000 On 01/06/2018 03:35, Lee Howard wrote: > I note that the IAB had a measured response: > > https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-04-04-iab-itu-t-sg-20-response-to-liaison-1546-attachment-1.pdf > > I support that statement. I'm a little puzzled why this list wasn't informed of this statement at the time. > Bearing in mind that I have no official position, and therefore any > opinions expressed below are mine only: > > The IETF, and any working group in it, has only one way to make a > statement: an RFC from the IETF stream. No other kind of document > requires IETF consensus, which is the only way to reflect an IETF > statement. I am skeptical that we can generate a timely consensus document. > > We don't need to say, "Stay out of our sandbox." Turf wars are stupid: > as engineers, we don't care who does the work, we care about the quality > of the work. Getting defensive is a sign that we care more about > protecting some interest than about making the Internet work better. > > Comments about the technical problems with the proposed model are > appropriate. I would include implementation considerations, such as the > potential for people to think the model is compulsory, or overrides > other local network considerations. However, I have no reason to believe > that comments on v6ops or other IETF mailing lists will be received by SG20. They can be, via our liaison channel. But it seems to be too late now (see above comment). Brian > > On those bases, RIPE may be a more effective place for discussion. > > Lee > > > On 05/30/2018 11:51 PM, Brian E Carpenter wrote: >> Ignoring the journalistic exaggerations in the article (2nd link below), >> do we have a liaison comment going to the ITU about this draft? >> https://regmedia.co.uk/2018/05/30/itu-ipv6-may18.pdf >> It seems to be an excellent recipe for burning up address space. >> The due date appears to be now. >> >> http://www.theregister.co.uk/2018/05/30/internet_engineers_united_nations_ipv6/ >> >> Regards >> Brian >> >> >> _______________________________________________ >> 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 > From nobody Thu May 31 16:39:38 2018 Return-Path: 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 F117F124234 for ; Thu, 31 May 2018 16:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 ZzT0hHcikup5 for ; Thu, 31 May 2018 16:39:35 -0700 (PDT) Received: from mail-pl0-x231.google.com (mail-pl0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) (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 2EDFD1201FA for ; Thu, 31 May 2018 16:39:35 -0700 (PDT) Received: by mail-pl0-x231.google.com with SMTP id 30-v6so14142629pld.13 for ; Thu, 31 May 2018 16:39:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=LE/6086YK5ueCQqkX0O5jQV0AH7r6Dbu0HgRVdQi+Ss=; b=eQipnjoAoQC8xZVOZSqL/+oslImJ6t5RytLx/fPwoGq7MHPS3DH3LhJcsSSX1BYOxh Bqm+yDItsFDoU6Yls9gsfVYELHvcEELpu0WwTutYfoXV8G4ZOI0vE2bd/RxS3y724pJq C5GdbMj1BL0S+7HvD6w7Ag4h5FfOrwLqiYV2VNkkpj/UAz3JciGkJRW6EOdoABOmuvW6 shLig0Unex896J41wXcyPaMsfZloep3LLVyNEVmR8bAgPJ9ptu2gOIuucnt8cBvCmjdm 545LoH0BPJ+RIuoJyN1Q29rTTDTEeQjeoL4rVBf1uei9wraQ0NeY1ix3PZAVa4aa/e9u RgOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=LE/6086YK5ueCQqkX0O5jQV0AH7r6Dbu0HgRVdQi+Ss=; b=hO3cRygLetWsp6TwEbAT90vlgnIECJP2ef9vBhptkCrbQBGX6SDtorgb5lSm0tDCFd qkG2y2WiJzDoJ95AVuDeR4Ga0pp169qYpB5sHwh2K9Lr5cSbu6CFlFksMpdyXvibcHiF 7zpJuNebeno3NlnUP1NrfpubpYTpNU6apJFqfsnlraBhZgzTiGjUF2vwILrM3lsEBCAZ 0/CBgC9+OtXw0oFgImYftY5YidhztwiS6toSuAL6wgZ5qXgxgJ8zF7nTNNmi6mbIvmpT Twufks9FkFGNKQNurTUCz2+9n807N6kL/FFZ29PfwcEwcBmHHwWCsArCzI5yinRnErgX +uGw== X-Gm-Message-State: ALKqPwejr63YNfQonwQ1n8Xi4jw2FwkARDu4CmJeyaqRHZDXZO7ESRJv X41RX69XLmSYduynXQi9FYerQl8n X-Google-Smtp-Source: ADUXVKIm+XbI2KAQvtqh98zuQQolSlr49HqF5U1bHs67+XBYB03iOAxA34guszL3dEUmVh0dv1IB2w== X-Received: by 2002:a17:902:b110:: with SMTP id q16-v6mr8739337plr.286.1527809974830; Thu, 31 May 2018 16:39:34 -0700 (PDT) Received: from [172.31.125.83] ([216.9.110.15]) by smtp.gmail.com with ESMTPSA id k84-v6sm38680754pfh.110.2018.05.31.16.39.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 May 2018 16:39:33 -0700 (PDT) From: Fred Baker Message-Id: <9F05FCE0-8D03-41D6-97C9-1C2C3DB15F79@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_3BE0DC3A-95C0-4A15-8A19-5E1D7B0074FD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Thu, 31 May 2018 16:40:58 -0700 In-Reply-To: <89a7eb01-e22f-f518-491a-822adae19003@asgard.org> Cc: v6ops@ietf.org To: Lee Howard References: <17a0f0e1-c822-21e8-31e0-41c96ae1b2a5@gmail.com> <89a7eb01-e22f-f518-491a-822adae19003@asgard.org> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [v6ops] =?utf-8?q?Internet_engineers_tear_into_United_Nations=27?= =?utf-8?q?_plan_to_move_us_all_to_IPv6_=E2=80=A2_The_Register?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2018 23:39:37 -0000 --Apple-Mail=_3BE0DC3A-95C0-4A15-8A19-5E1D7B0074FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The Register, as it often does, has an article on the topic. It's not = very supportive of SG20 :-) = https://www.theregister.co.uk/2018/05/30/internet_engineers_united_nations= _ipv6/ > On May 31, 2018, at 8:35 AM, Lee Howard wrote: >=20 > I note that the IAB had a measured response: >=20 > = https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-04-04-iab-itu-t= -sg-20-response-to-liaison-1546-attachment-1.pdf >=20 > I support that statement. >=20 > Bearing in mind that I have no official position, and therefore any = opinions expressed below are mine only: >=20 > The IETF, and any working group in it, has only one way to make a = statement: an RFC from the IETF stream. No other kind of document = requires IETF consensus, which is the only way to reflect an IETF = statement. I am skeptical that we can generate a timely consensus = document. >=20 > We don't need to say, "Stay out of our sandbox." Turf wars are stupid: = as engineers, we don't care who does the work, we care about the quality = of the work. Getting defensive is a sign that we care more about = protecting some interest than about making the Internet work better. >=20 > Comments about the technical problems with the proposed model are = appropriate. I would include implementation considerations, such as the = potential for people to think the model is compulsory, or overrides = other local network considerations. However, I have no reason to believe = that comments on v6ops or other IETF mailing lists will be received by = SG20. >=20 > On those bases, RIPE may be a more effective place for discussion. >=20 > Lee >=20 >=20 > On 05/30/2018 11:51 PM, Brian E Carpenter wrote: >> Ignoring the journalistic exaggerations in the article (2nd link = below), >> do we have a liaison comment going to the ITU about this draft? >> https://regmedia.co.uk/2018/05/30/itu-ipv6-may18.pdf >> It seems to be an excellent recipe for burning up address space. >> The due date appears to be now. >>=20 >> = http://www.theregister.co.uk/2018/05/30/internet_engineers_united_nations_= ipv6/ >>=20 >> Regards >> Brian >>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_3BE0DC3A-95C0-4A15-8A19-5E1D7B0074FD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEctjlJjQmVrp9uMq7EhdRnd2GP+AFAlsQiAoACgkQEhdRnd2G P+DpdhAAr5rdnUJjrKCG5yNoQlV7ENNyr3lmrNznWW8EyKwI26jxhaKX8W/6vCfL pvmOxh4QXDka+m7kR+irqAqN3+EEz3lrUDpvxFpEdcwPuivdUpEXFeA/4zhOSNBO uRLMKm373qS4jqaQQT72nK8VT5v+s2z9Oul7Qzecdmd3+BCsN559ehdMw4G1kw+5 HldTc41tHA1bCP/bVzrnxElZRXAS8yIGtNMzMNTeMHDMCzAxBdYXSZSZ8etb/le7 zstdSjOJZsGdKh4L6egq/XgsZX5nIq4fwISvOM4DWh0rzroRQAPaf/WHk9WIleEQ UpfoFE45+tbOGd0GyTJt6EkYNFNyMMklhd0AmxK3WpYIV6pCOJKwO3uT0XZiPYKd oNTU4fcSwEUnLwVG9ZuEfKZzJxTFUYugt/zjBgIYlqJCc/oVjMw+WgODiAGg1kin j3fXPR+NRl9nx2qNL1iUklzShk3CopgbYWreDxFsnwTCVRrDNrJiePeTfROGz+gR DvZWufC2n5H4TdI09v7sRENluFOFTVc8rV2FZDkMPuhIysGs5Zk3Fwd/yPRnu2if 8tiMkpIcLVlHpHhfpjqWOpZVhqtPOr6c7QMweIZq5ajpViTBLI78+qWiFwzi2KJj AgBfmMhvIJXwBA1pERhXkwHIdVEMHueDO34pCBQ2fAPUm6iiQlI= =tT4T -----END PGP SIGNATURE----- --Apple-Mail=_3BE0DC3A-95C0-4A15-8A19-5E1D7B0074FD--