From nobody Wed Aug 1 00:20:39 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 5E65E131041; Wed, 1 Aug 2018 00:20:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-v6ops-conditional-ras@ietf.org, Russ White , v6ops-chairs@ietf.org, russ@riw.us, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153310803137.22145.5132532082101433230.idtracker@ietfa.amsl.com> Date: Wed, 01 Aug 2018 00:20:31 -0700 Archived-At: Subject: [v6ops] Adam Roach's No Objection on draft-ietf-v6ops-conditional-ras-05: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 07:20:35 -0000 Adam Roach has entered the following ballot position for draft-ietf-v6ops-conditional-ras-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-conditional-ras/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to everyone who worked on this document. I have one substantive comment and a handful of editorial suggestions. --------------------------------------------------------------------------- §3.3.1: > It should be noted that in IPv4 multihoming with NAT, when the egress > interface is chosen without taking packet source address into account > (as internal hosts usually have addresses from [RFC1918] space), > sessions can not be preserved after an uplink recovery. This isn't necessarily true. For example, if the NAT is tracking which ISP-facing interface is associated with a given established session, the sessions will survive restoration of an uplink. I have exactly such an IPv4 multi-homing configuration working on my home network (with RFC 1918 addresses assigned to all local devices), and will happily share details of my configuration with interested parties. I propose striking this paragraph from the document. --------------------------------------------------------------------------- §1: > general multihoming scenario for enterprise networks and proposes > solution which relies heavily on the rule 5.5 of the default address Nit: "...proposes a solution..." --------------------------------------------------------------------------- §3.2.6: > (as there is no preferred addresses available) and the source address Nit: "...as there are no..." --------------------------------------------------------------------------- §3.3: > into account any other uplinks properties (such as latencyetc), so Nit: "...latency, etc.), so..." --------------------------------------------------------------------------- §3.3.1: > interrupted as there is no egress path for those packets and there is > not return path from the Internet to the correspodning prefix. In Nit: "...there is no return path..." Nit: "...corresponding..." --------------------------------------------------------------------------- From nobody Wed Aug 1 03:17: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 33EEE130DE9 for ; Wed, 1 Aug 2018 03:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=helix-net-nz.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 BSVoW_EEv-j7 for ; Wed, 1 Aug 2018 03:17:37 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 F38F5127333 for ; Wed, 1 Aug 2018 03:17:36 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id g191-v6so8890231ita.0 for ; Wed, 01 Aug 2018 03:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=EkjBGkEUg+5/EeH6bwiP8GCM+aG3wz5f0MDOkwKheXc=; b=x0tMzVn8xgYT6yDxBVssp1Msta1pw++NJri0yIwO6c/9UxV+x9I3nNPB3v96YT9yqz tXDFs3gCx/Du+9ob47K/++gQxYDrp0e9xi98aQGnITNS4c9Y5/wdWgGJx/+Y8NPZuTzE cUT9tsmqiCE2OZVVXTLsZm9jSg/4WVdvfqAtlPs+z6nkj5BhbUvLcda1sZzkwZgJQzy+ ZWAzBlnGVZcxTnn8P93oZyzwdd1NODYv4VGy6oXlrczeHpZg9H9TYRUypg1H1xD+qEf1 vWJpOONC25wX4NDE37iGpqa1yQq4BgY0MGMe//HLzW4SUVVp73M9nmCd5fcgD1R2J61Z 1Y3g== 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:content-transfer-encoding; bh=EkjBGkEUg+5/EeH6bwiP8GCM+aG3wz5f0MDOkwKheXc=; b=NpBAbH456uG+5SMw4TnHShmTKpxAxItWM95V3KRcNrE4C7yIchstStRu8tHA7joomo MKpcwjJIGHHQXCgN2SJtiQkS8W/I5VY6KvhcDKfsywLQHrGkynbhphgWJYoqfi132XJQ wZD/XoXY8LktB2GNShyExBw0zCbCh9evHh0C5meTCTMKrSLqtQE8IDB9g4Z5BhEVv5qy vixmH2trnwYmdecXxdavqM+tMlAWgzNSIdtCNasSSjCY79mzlRi0woUKt+fSJMhlYaDP Za13wPJhoezmXQjC0iBt52v5nkXqOjW9eE+Bh57W5kVjoP/oQtUwuUB37SFu7BfNZyS3 aWKA== X-Gm-Message-State: AOUpUlG7VAtOOXjnwrGNI6RXunNvCGl60WSaQTv+tWqFF/AvWqYxPP6S 0WVewKHy0vRjakLjHdKGOMuQ118LzK8= X-Google-Smtp-Source: AAOMgpetO8FPc3ajNm8mD3FjRmtcNhpU/92XvZ6SomjZa84IZZaLKRbbZZWNXr3AvLnza4Fr54fb8A== X-Received: by 2002:a24:f6cc:: with SMTP id u195-v6mr2804939ith.47.1533118655680; Wed, 01 Aug 2018 03:17:35 -0700 (PDT) Received: from mail-io0-f179.google.com (mail-io0-f179.google.com. [209.85.223.179]) by smtp.gmail.com with ESMTPSA id r126-v6sm3162894ita.26.2018.08.01.03.17.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Aug 2018 03:17:35 -0700 (PDT) Received: by mail-io0-f179.google.com with SMTP id q19-v6so15568093ioh.11; Wed, 01 Aug 2018 03:17:34 -0700 (PDT) X-Received: by 2002:a5e:9706:: with SMTP id w6-v6mr2630558ioj.257.1533118654807; Wed, 01 Aug 2018 03:17:34 -0700 (PDT) MIME-Version: 1.0 References: <2D09D61DDFA73D4C884805CC7865E6114DE61603@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DE61603@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Richard Patterson Date: Wed, 1 Aug 2018 11:17:23 +0100 X-Gmail-Original-Message-ID: Message-ID: To: bs7652@att.com, int-area@ietf.org, "v6ops@ietf.org list" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-patterson-intarea-ipoe-health-04 Post-IETF102 Discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 10:17:40 -0000 Hi Barbara, Thanks for the comments, my responses in-line, quoting snipped where appropriate: On Tue, 31 Jul 2018 at 19:50, STARK, BARBARA H wrote: > The consensus view here is that BFD Echo, when implemented as described i= n RFC 5881 and BBF specs, works. I don't have anyone asking for something m= ore complex than what has already been specified in BBF TR-146 (and TR-124 = for CPE, with management by TR-069 and the TR-181 data model parameters). T= here is no requirement here for manual configuration, DHCP configuration, o= r alternate DHCP mechanisms (Renew, Reconfigure, Rebind). I believe that this statement is a bit contradictory. TR-146 only specifies Renew as an action, and as you've mentioned below, this is often insufficient for an IPoE client to re-establish its session. Defining alternative actions is the primary motivation for this document. The configuration elements and the use of DHCP option for signalling of, were a tertiary consideration. > Getting vendors (CPE and BNG) to implement BFD Echo as currently specifie= d is painful. Defining something more complex (BFD Echo plus DHCP options p= lus other configuration parameters and various methods of configuring) is u= nlikely to be easier to get implemented. Defining something that doesn't wo= rk as well as BFD Echo is undesirable. > > It was the BNG vendors who said they preferred the current BFD Echo solut= ion. Getting CE router vendors to implement is indeed very difficult. Convi= ncing vendors to implement is definitely the most difficult aspect of BFD E= cho. This lack of full BFD support in the CE is the secondary motivation for creating this document. We considered it necessary to include ARP and ND as alternative methods that are hopefully already exposed to the application layer. (Although I'm not sure if this assumption is typically correct or not?). TR-146 briefly touches on the use of ARP Keep Alives, but only includes a requirement R-92 for it in the downstream direction. TR-146 also briefly touches on the use of Passive IPv6 NUD, and explains why this isn't a reliable detection method. We felt that expanding on the use of ARP Keep Alives to include upstream checking from the CPE, as well as the use of Active Neighbor Discovery probing instead of passive, was required. The idea is that these detection methods should be easily supportable by CEs, but with the trade off that their usage would put additional control-plane load on the BNG. If the consensus is that this additional health check mechanism is indeed superfluous, then focusing on a TR-146 -bis is probably the most appropriate next step. > A comment about CE routers: Although our CE routers do BFD Echo, we have = (in our labs) experimented with implementing a CE router on a Linux kernel = and discovered the kernel would not accept packets with a source address be= longing to itself. [The BFD echo is an IP packet with the destination and s= ource IPv4 addresses being identical and belonging to the CE router, becaus= e of BCP 38.] This is just a comment for anyone wanting to experiment. Our = CE routers do support BFD Echo. That's an interesting observation, thank you for raising it. If we progress further with the document, I'll be sure to include this as a consideration. > Here is a quote related to DHCP Renew and Reconfigure: "The Renew and Rec= onfigure approaches are useless as we found when we looked at that. It doe= sn't help with an unplanned migration where the subscriber access is moved = (e.g., card or node failure requiring rehoming a DSLAM to a BNG different p= ort or node). In those cases you can't send a Renew or Reconfigure since t= he IP context for the subscriber is lost." I agree. The current version of this document specifically rules out Reconfigure (and ForceRenew) as not being a viable alternative (Section 2). Likewise, this document also discusses the limitations of the Renew method (Section 5.1) and offers the alternative methods. It was left in there for backwards compatibility with TR-146, and because it may be useful in some networks. (and as Lorenzo noted, it will be further beneficial if BNG vendors can implement authentication based on the Renew messages alone) > To summarize: > I / we don't support Renew / Reconfigure or Rebind as options for what to= do when BFD Echo indicates failure of connectivity. No need for DHCP Optio= n to configure behavior for when BFD Echo fails. I / we do support BFD Echo= . I / we are neutral on the creation of DHCP options to configure BFD Echo = (TR-069/TR-181 configuration is ok for us). Defining alternative actions is the primary motivation for this draft, which is why a simple -bis style update to TR-146 might be sufficient, if no one sees benefit in the active ARP/ND methods, or the configuration parameters and DHCP option. As mentioned above, whilst Renew is the current default action specified, it's perceived to be the least effective of the methods and not preferred. I'd be happy with the removal of Renew and Rebind behaviours from this document, or as mentioned before, focusing on a single converged action that attempts a Renew before moving swiftly on to the more reliable approach of sending a Solicit/Discover. -Richard From nobody Wed Aug 1 04:19:06 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 1FCC0130E50; Wed, 1 Aug 2018 04:18:59 -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.83.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <153312233907.22029.11199804247296156561@ietfa.amsl.com> Date: Wed, 01 Aug 2018 04:18:59 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 11:18:59 -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-06.txt Pages : 20 Date : 2018-08-01 Abstract: This document discusses the most common scenarios of connecting an enterprise network to multiple ISPs using an address space assigned by an ISP and how the approach proposed in the "ietf-rtgwg- enterprise-pa-multihoming" draft could be applied in those scenarios. 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 adopts the approach proposed in the "ietf-rtgwg-enterprise-pa-multihoming" draft to provide a solution 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-06 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-conditional-ras-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-conditional-ras-06 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 Wed Aug 1 04:21:43 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 E48FC130E05; Wed, 1 Aug 2018 04:21:41 -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 v0T4-I0D4429; Wed, 1 Aug 2018 04:21:40 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::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 16B2C130E1A; Wed, 1 Aug 2018 04:21:40 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id f8-v6so16543516ljk.1; Wed, 01 Aug 2018 04:21:39 -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=EkjSF2UOIo+N/JFM0l3WGlcOQzkwpBs7cr8QL2sVtPk=; b=LBRbBRQSJv4MNHahY2QZqjv/DeFKpsGrJwGw9AVuwvIDzy6efFfn/1OdsugLQJoWRI VxBQQprq2SE7oofKoQM3GVjqQeh/PjLmkmLwHQHeeldJ2rAnJV5pRf3O8pfWMYYLZmVv dEKKXHOw8O//drNKpLTxH0dlHFR8RpEYT8FuatUeD6Z2LV+fmXYgwTSewg1zDiI8QLTu y/vq9N1j2gNUOgyYyOC2rBqBNbNFZ8hiP/ZeC61jBMO44OkhJOYMjk/Fz6fQLXwAzjpK 8p+BLurrHdvbnpmJdTATo4tZHdXN1WacmkY6WgP97Oigf3Fodm4L2UpNl2a0RlVpK2P8 1c8Q== 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=EkjSF2UOIo+N/JFM0l3WGlcOQzkwpBs7cr8QL2sVtPk=; b=i00mIgj58R/sk+gcx9nIlQxr0UYwtdmg60uMxzZyLUylkpbbTCgQvutkkqo+21YkF6 3jCjTOcE3isQO7PGsZCLWtRLmxHiereN0gk3jGfw7ltVp3S7iu1tALDfmZ29oYolUuze sCRv3/y5gJlgyW3LbVqwDsnPIRmbxHjW0RGaoIksCzXy0TdPTyDUUSGJApqJJKyW8A+1 GQiIvVOcNKieJFuCvS1Kt41m+ptK8+GPqkCYAWEZk0raBCOdCxa6w8Obh9ya63QmZKHT HcDwtFIKf/3rg21gSMGD9lEU8wwowOX5hpRfji5lXN20LS4ke/6o4pjkb5fNEBhSUtAT 7/Pw== X-Gm-Message-State: AOUpUlEG3bEMRi7HcS2iCuMJhtwqz3dhvvXBmYw8VJgGujYyMS0YjMnF n2Y30NaJZdeEvXxT9bUEVcDMXuqej3HDL29iwYAJ3LfO X-Google-Smtp-Source: AAOMgpdgLzcjcvVjQNmREvz4NILvdwt2QD6bvkRLctV2XRnulRzEB7NvMInbJXSB1aNBaTCj3ZmJQ6rH8ijzByBa2eU= X-Received: by 2002:a2e:8743:: with SMTP id q3-v6mr15977006ljj.139.1533122498197; Wed, 01 Aug 2018 04:21:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:1d82:0:0:0:0:0 with HTTP; Wed, 1 Aug 2018 04:21:17 -0700 (PDT) In-Reply-To: References: From: Jen Linkova Date: Wed, 1 Aug 2018 21:21:17 +1000 Message-ID: To: Yoshifumi Nishida Cc: tsv-art@ietf.org, draft-ietf-v6ops-conditional-ras@ietf.org, V6 Ops List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] TSV-ART telechat review of draft-ietf-v6ops-conditional-ras X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 11:21:42 -0000 Hi Yoshi, Thanks a lot for reviewing the draft and pointing out typos! The -06 version has been submitted (https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-06) and those issues fixed. On Wed, Jul 11, 2018 at 6:06 PM, Yoshifumi Nishida wrote: > Document: draft-ietf-v6ops-conditional-ras-05 > Reviewer: Yoshifumi Nishida > > I've reviewed this document as part of TSV-ART's ongoing effort to review > key IETF documents. These comments were written primarily for the transport > area directors, but are copied to the document's authors for their > information and to allow them to address any issues raised. Please always CC > tsv-art@ietf.org if you reply to or forward this review. > > Summary: This document is ready for publication. > > - Major Issues: None. > > - Minor Issues: > > Typos: > > Page 6: > (Stateless Address Autoconfiguration, [RFC4682] > -> > (Stateless Address Autoconfiguration, [RFC4682]) > > (by sending an RA with the preferred_lifetime set to 0 in the > corresponding PIO (Prefix Information option, [RFC4861]) > -> > (by sending an RA with the preferred_lifetime set to 0 in the > corresponding PIO (Prefix Information option, [RFC4861])) > > -- > Yoshi > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- SY, Jen Linkova aka Furry From nobody Wed Aug 1 04:31: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 964EA130E55; Wed, 1 Aug 2018 04:31:38 -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 knBcXYpiqBYd; Wed, 1 Aug 2018 04:31:37 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::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 C4717130E26; Wed, 1 Aug 2018 04:31:36 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id y17-v6so16540335ljy.8; Wed, 01 Aug 2018 04:31:36 -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=SofnNR1GcO07luTCdmJ13qdlj+fg5sc4CP/cXFMWCSo=; b=lnUCQQQrV0MCvgzW0AKVORwUIuEvLWry0ywAVdXp+V8013YtVBy7OhjnkID70SnN5E eU2sbRLdSkavoZi0sA0TJ6/dWWoyvR+1Ugx2OscapHLL1/PRLC3IDJuP3Q5CaCHqrfpe fwcM++Z+8YbVEEd/Jui3F81nMzTeZUnQVkjBxaDKsdARtuSvlMRuf0V1WbR0tXnGmfWh wYVGf38L++Uvdx/m6oFFTcAy2n80LGjA2tiI48U+Z/NzNBd4TkFRhGlIsoeYQ8248WXh UDoGrlJ6e2i+PgpVYFA94PcTA620QNTmpbf1HyUlSgKkV8Ejf0JMzri74tFv6fC2+/K7 ayeA== 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=SofnNR1GcO07luTCdmJ13qdlj+fg5sc4CP/cXFMWCSo=; b=tJlpIIl5BuC3FdWTr6j8DRgfPjtWBHQjeyAd/f/bj4o/nxtTKBRQm7912T32A/NDWE SahNewpyINDiwMDvSCwPbsU07Lj7eVrH0/n7757r/YlGtB5kS0PCN6w0+As16eeo0xiY Li+NccQ31MV0rUnNa4GawxqB5TG7PHMurKsZDZcsiqzoL9JvkqN3FMyaQGlTCRH3pmO8 +NDUnBAyqov6FxQ1N/6A0+aBLeLM6uiCtYbje7fLug9wBxZR93FoTYNKweEg1jHrdJiL pHmrS58iOcaN9n6mFEhwyUHVTiro1S/bzWA2fC/G0bn4dGhhFI6OiZAB+0fCGUuT5Tja 7XNg== X-Gm-Message-State: AOUpUlG6/1Zg8h9z176nT3WE2+PXx0yCTQCQZBJaceVxBtUwfvNkZHdU 15xKxfc6F/YpwN5dnBzMFx7C5RNfbx2e9XB38WjziP5/ X-Google-Smtp-Source: AAOMgpdJ3QiiStZ0dZ1/AL7KCOOBA4puUKr37MVjcF1QP7fsk6jQ85cDtGYYkBAiDh2MAVptMfbo6XfYn9osH2rvRbw= X-Received: by 2002:a2e:8743:: with SMTP id q3-v6mr16001836ljj.139.1533123094799; Wed, 01 Aug 2018 04:31:34 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:1d82:0:0:0:0:0 with HTTP; Wed, 1 Aug 2018 04:31:14 -0700 (PDT) In-Reply-To: <153257466404.7274.1932006527579909279.idtracker@ietfa.amsl.com> References: <153257466404.7274.1932006527579909279.idtracker@ietfa.amsl.com> From: Jen Linkova Date: Wed, 1 Aug 2018 21:31:14 +1000 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: The IESG , Russ White , v6ops-chairs@ietf.org, V6 Ops List , draft-ietf-v6ops-conditional-ras@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-v6ops-conditional-ras-05=3A_=28with_COMMENT=29?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 11:31:39 -0000 Hi Mirja, Thanks a lot for your feedback! -06 version has been submitted to address your comments: https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-06. Also please see my responses inline: > 1) The shepherd write-up says "The responsible Area Director is Ron Bonic= a." > and questions 7 and 8 say "TBD" I believe Warren has fixed those issues (thanks a lot, Warren!) >and the RFC8174 biolerplate is missing... Fixed. > 2) It seems that ietf-rtgwg-enterprise-pa-multihoming should maybe be a > normative reference (and that the abstract should be updated with the > respective RFC number as soon as ietf-rtgwg-enterprise-pa-multihoming is > published). Any even if it is not a normative reference, should those doc= s be > published together in order to refer to the RFC in the abstract (instead = of an > draft)? Ah, that's a tricky part...Initially I wanted ietf-rtgwg-enterprise-pa-multihoming to be a normative reference and those two documents published as a cluster. However the main reason for writing this draft was to document tactical solution available right here right now, while we are waiting for the proper one to come. So it would make sense to publish the conditional RAs draft reasonably quick. Unfortunately ietf-rtgwg-enterprise-pa-multihoming has been in 'Publication Requested ' state for the last 51 days and I'm afraid it might take a while before we can get it published. So it looks to me that this draft might be published independently (while ietf-rtgwg-enterprise-pa-multihoming contains all justifications/explanations on 'why SLAAC and not DHCPv6/ICMP error messages' it's still not really necessary to read the whole ietf-rtgwg-enterprise-pa-multihoming to understand the solution proposed in draft-ietf-v6ops-conditional-ras...Or am I biased here? > 3) Would it makes sense to also discuss what to do when one ISP is down b= ut > packets from that address space are received at the border router? Should= those > packet be forwarded to that ISP anyway or dropped? Or should they be forw= arded > to the other ISP with or without address translation? I've added Section 3.2.8: https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-06#page-15 Please let me know if it does not address your concern. > 4) It doesn=E2=80=99t seem right to me that the security consideration se= ction is empty. Updated it: https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-06#section-5 > 5) Lines are too long and therefore cropped in sec 3.2.1 and 3.2.2. Fixed. --=20 SY, Jen Linkova aka Furry From nobody Wed Aug 1 04:43:33 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 95B80130E26; Wed, 1 Aug 2018 04:43:32 -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 In5ys0ujCLZR; Wed, 1 Aug 2018 04:43:31 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::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 90CF9130E64; Wed, 1 Aug 2018 04:43:30 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id r13-v6so16589151ljg.10; Wed, 01 Aug 2018 04:43:30 -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=a3iNyeKlvSq9FA4Jqb/N1+1KCgx8vvmTJ3rpbSc1cGU=; b=nssU4P+/CB/K5Yi4a+INAH93sqwtNmUGqsA1TI/7aMQK6i877Q4P0qrNdNqLBpqRLI qigXwtfqoxnHvLNOj+r60vjF0VIH4Qst4pAAY8xLayWNsVB4ZRI4zCvOYcAAPd1qWnqK wwLYO5fhx/dLqF2LVP1ikEPC1fZlQidPdm0u5cf8YsgC4LoSeY9acOXdWX56iFjaIjLI Vq64/tIQqAHK9PfBjJ20NmPJV66ki5H+zXyZhUt8t8QN8425/v9qrSbqK6E7SWTgMs/r Pjr71gfe8LTQnLFIRxWDX7dLNyhBkQPd1dx3oHKeWa6ah11bgDmzHtKC0Y+1V+HdUpld VrtQ== 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=a3iNyeKlvSq9FA4Jqb/N1+1KCgx8vvmTJ3rpbSc1cGU=; b=oJ3xfl81kicG/rWkM3GgVF7qDjsaIDacZimgF8TN+5nF/HBfT79rMZ4bb7l7859SZm 1P33DW5QdAzqBl7VBEJ3STQcQEsc2oNqMYRDZ4vzucvA8o+QZboxuJf3Zv/6ClnBBaO/ jPHmpMyuYu/KzlBeo/a9WmrqRJOzJT9FDaQCGQQWDkfcOtaDsq/Sckmn1riA6CXC6Vyl E7LiMfDxBAl7RN0SRtCQ85yUzPyHxn6mkbZd0uweNa0eVZAhpV+sYZspvPJvcfo0+Q+c nGc2VwSdQ0+4kVrEx/ntAKGCWgo9EuZ9uz6vd/s+M67mbcckPZ/fMORJ4Hamw04rLXdM Sk3Q== X-Gm-Message-State: AOUpUlHfKvqH+gWwe7mlmJ4GTbqwcAEG4vvucDQLEv5K3SzHbpvMTRoo Jn9JmrcqXzo4AFm+NztWwd2uGllvHUThIYhVP1YZlPpS X-Google-Smtp-Source: AAOMgpeImKqJwYxAqiyyBMYv3rPIIs2LqAec6QWrurf8QVRRmSugHXTGl6vp+55WV//PWabIn7aLpcr5kIgavWr1y2c= X-Received: by 2002:a2e:4103:: with SMTP id o3-v6mr18618039lja.3.1533123808703; Wed, 01 Aug 2018 04:43:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:1d82:0:0:0:0:0 with HTTP; Wed, 1 Aug 2018 04:43:07 -0700 (PDT) In-Reply-To: <153292034480.7043.166309226503951804.idtracker@ietfa.amsl.com> References: <153292034480.7043.166309226503951804.idtracker@ietfa.amsl.com> From: Jen Linkova Date: Wed, 1 Aug 2018 21:43:07 +1000 Message-ID: To: Spencer Dawkins Cc: The IESG , Russ White , v6ops-chairs@ietf.org, V6 Ops List , draft-ietf-v6ops-conditional-ras@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Spencer Dawkins' Yes on draft-ietf-v6ops-conditional-ras-05: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 11:43:33 -0000 Hi Spencer, Thank you very much for your feedback! > I echo Mirja's thanks for a well-written document (and her curiosity about the > near-null Security Considerations - there's at least one recommendation in this > document, so it seems possible that some security consideration is worth > mentioning). The Section 5 updated: https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-06#section-5 > This text toward the bottom of the abstract > > this document > adopts the approach proposed in the "ietf-rtgwg-enterprise-pa- > multihoming" draft to provide a solution for a limited number of > common use cases. > > is pretty easy to miss. If the reader misses it, the first sentence is kind of > misleading - it just says > > This document discusses the most common scenarios of connecting an > enterprise network to multiple ISPs using an address space assigned > by an ISP. > > Perhaps it's worth pointing that out in the first sentence, rather than towards > the end of the abstract? I've updated the first sentence, it's now saying: "This document discusses the most common scenarios of connecting an enterprise network to multiple ISPs using an address space assigned by an ISP and how the approach proposed in the "ietf-rtgwg- enterprise-pa-multihoming" draft could be applied in those scenarios." (https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-06) Do you think it's more clear now? > I've been on the IESG far too long, but I have tried repeatedly to read > > While some work is being done in the Source Address Dependent Routing > (SADR) area (such as [I-D.ietf-rtgwg-dst-src-routing]), > > without thinking "but SADR isn't an (IETF) area?!?", and I can't do it. If > > While some work is being done on Source Address Dependent Routing > (SADR) (such as [I-D.ietf-rtgwg-dst-src-routing]), > > that would stop startling at least one reader ... Oops, sorry, did not think that the word 'area' is *so* overloaded..;) Fixed! > In 3.2.5. Topologies with Dedicated Border Routers > > For simplicity, all topologies above show the ISP uplinks 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 interface > status can not be used as a trigger for conditional RAs and route > presence as described above should be used instead. > > "as described above" might be easier to navigate if it was "as described above > in Section 3.1.2" - it's a six-page jump, if I'm tracking this cross reference > correctly, and if I'm not, an explicit section reference would be even more > appreciated. Fixed: https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-06#section-3.2.5 > I'm not sure that > > It should be noted that the proposed approach is not a silver bullet > for all possible multihoming scenarios. > > "silver bullet" is clear for readers from cultural contexts that don't include > werewolves or vampires ... but do the right thing, of course. Good point ;) I've added quotation marks around 'silver bullet' to indicate it's a the figure of speech. > > It's a nit, but "such as latencyetc". > > It's a nit, but "correspodning". Fixed. -- SY, Jen Linkova aka Furry From nobody Wed Aug 1 04:53:13 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 3D06E130E8B for ; Wed, 1 Aug 2018 04:53:10 -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, 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); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.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 RBdo_5nPZKO3 for ; Wed, 1 Aug 2018 04:53:08 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B80D130E77 for ; Wed, 1 Aug 2018 04:53:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=SN/NElCm+SbhSrIOoMjq4LQ+1PASCKZ6hhhwMHzJAC9UI2oKb+H4LbufGdQC2+GwVBITNvSH48patgCF0J+gEL65+5nLUDUT9L3tlZuWISN/8cF7QTPZq9G0tC43mAPGoOgB/VK49+OgwuY9dgw4XfJ4FtOp/TAJaehCeEYqb9g=; h=Received:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 1604 invoked from network); 1 Aug 2018 13:46:25 +0200 Received: from i577bce12.versanet.de (HELO ?192.168.178.24?) (87.123.206.18) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 1 Aug 2018 13:46:25 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: Date: Wed, 1 Aug 2018 13:46:24 +0200 Cc: The IESG , Russ White , v6ops-chairs@ietf.org, V6 Ops List , draft-ietf-v6ops-conditional-ras@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <153257466404.7274.1932006527579909279.idtracker@ietfa.amsl.com> To: Jen Linkova X-Mailer: Apple Mail (2.3445.9.1) X-PPP-Message-ID: <20180801114625.1595.28380@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [v6ops] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?= =?utf-8?q?-ietf-v6ops-conditional-ras-05=3A_=28with_COMMENT=29?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 11:53:10 -0000 Hi Jen, see below. > Am 01.08.2018 um 13:31 schrieb Jen Linkova : >=20 > Hi Mirja, >=20 > Thanks a lot for your feedback! > -06 version has been submitted to address your comments: > https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-06. >=20 > Also please see my responses inline: >=20 >> 1) The shepherd write-up says "The responsible Area Director is Ron = Bonica." >> and questions 7 and 8 say "TBD" >=20 > I believe Warren has fixed those issues (thanks a lot, Warren!) >=20 >> and the RFC8174 biolerplate is missing... >=20 > Fixed. >=20 >> 2) It seems that ietf-rtgwg-enterprise-pa-multihoming should maybe be = a >> normative reference (and that the abstract should be updated with the >> respective RFC number as soon as ietf-rtgwg-enterprise-pa-multihoming = is >> published). Any even if it is not a normative reference, should those = docs be >> published together in order to refer to the RFC in the abstract = (instead of an >> draft)? >=20 > Ah, that's a tricky part...Initially I wanted > ietf-rtgwg-enterprise-pa-multihoming > to be a normative reference and those two documents published as a = cluster. > However the main reason for writing this draft was to document > tactical solution available > right here right now, while we are waiting for the proper one to come. > So it would make sense to publish > the conditional RAs draft reasonably quick. Unfortunately > ietf-rtgwg-enterprise-pa-multihoming > has been in 'Publication Requested ' state for the last 51 days and > I'm afraid it might take a while > before we can get it published. So it looks to me that this draft > might be published independently (while > ietf-rtgwg-enterprise-pa-multihoming contains all > justifications/explanations on 'why SLAAC and not DHCPv6/ICMP error > messages' > it's still not really necessary to read the whole > ietf-rtgwg-enterprise-pa-multihoming to understand the solution > proposed > in draft-ietf-v6ops-conditional-ras...Or am I biased here? I unterstand this concern but actually a publication delay is not the = right basis to make a decision if this should be a normative reference = or not. If there is any part in ietf-rtgwg-enterprise-pa-multihoming = that the reader needs to consult to understand this document, it=E2=80=99s= a normative reference. However, actually I think form my read that it = is probably possible to understand this doc without having read = ietf-rtgwg-enterprise-pa-multihoming. It=E2=80=99s just that the way the = draft is referred in the text seems to require to read it. So I guess = you could change the wording used a bit and eventually add additional = explanation from ietf-rtgwg-enterprise-pa-multihoming where needed to = this doc to make sure they can be read independently, and then keep is = informative. However, having said that, given ietf-rtgwg-enterprise-pa-multihoming is = in =E2=80=9Epublication requested=E2=80=9C, I wouldn=E2=80=99t not be to = worried about the additional delay. Maybe just ping the responsible AD = of ietf-rtgwg-enterprise-pa-multihoming and make sure it will be moved = forward soon (given this dependency). >=20 >> 3) Would it makes sense to also discuss what to do when one ISP is = down but >> packets from that address space are received at the border router? = Should those >> packet be forwarded to that ISP anyway or dropped? Or should they be = forwarded >> to the other ISP with or without address translation? >=20 > I've added Section 3.2.8: > = https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-06#page-15 >=20 > Please let me know if it does not address your concern. Yes thanks!=20 >=20 >> 4) It doesn=E2=80=99t seem right to me that the security = consideration section is empty. >=20 > Updated it: > = https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-06#section-5 Thanks! Mirja >=20 >> 5) Lines are too long and therefore cropped in sec 3.2.1 and 3.2.2. >=20 > Fixed. >=20 > --=20 > SY, Jen Linkova aka Furry From nobody Wed Aug 1 04:55: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 92D2C130F62; Wed, 1 Aug 2018 04:55:44 -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 lb6IcB6lJEUv; Wed, 1 Aug 2018 04:55:43 -0700 (PDT) Received: from mail-lf1-x141.google.com (mail-lf1-x141.google.com [IPv6:2a00:1450:4864:20::141]) (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 972CB130E77; Wed, 1 Aug 2018 04:55:42 -0700 (PDT) Received: by mail-lf1-x141.google.com with SMTP id j8-v6so13109325lfb.4; Wed, 01 Aug 2018 04:55:42 -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=3fMSLixK8TgO1YiASs1hom26o5fHs34u/3x41ek9T7g=; b=j48bLEldAtaIc/wNOf74F/pGXHRzn5w3tenCGX48Il7W79Cpteg4cARuqAxT96GiLu 8uqKtEKG+v7pkbkCLzi0oi9FqeRoHJ0SkPD9RSmPWIm/sIH7oOd3c037gXwYcqqUN7nm cIeOdJCM/cnMl/+Y3H2IG/ImXtFiuht2kRv0GnqYrXWDU+70ZnPiL/JDFvlx21+eIUJ5 92u2+K6Lxnt6PR8T1ODOzZgdpXqly0m9AcmxdATzVf84t/9b4/AgAELAWVujl3gjzl1S H4rUvEr30bwHYY21CrR5iN7AKqBB6Db8vealRHvuzGtVk4KcX5lYEQfZCQ9Qga+Z0LDg UwNA== 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=3fMSLixK8TgO1YiASs1hom26o5fHs34u/3x41ek9T7g=; b=mss6A8Ini32Fueh6gTBLSmpToBC6vkDMTll7P5l5S9NedDlEgTHK/PRkqIRqOdp8CU E9xMim9eOPgBBxddPPM6SZZfY0hu1QrOkRHyyMq70jTBqQJ9tUmBLm/7l8mZm/+dpdQq Vlp4mFDy3bzJ7Px/kyHLckUIcS2y/qlQ34SdogjyghgDm9xhhFmx/Yz7ZNmphwAeYEt0 TfcU/hc+HrNVn1xtwEnHy5dMHzNVoXTM9cp4hBuhhLEjRhuCZVb9zm8w4jC2WksCxZQL dRekO9yybQwAfmuPGsyxw1UutXMD5W3kQ7jQnQNzVu9kJg4JEFoZzXMus93afOZOP01T wnfA== X-Gm-Message-State: AOUpUlHi0jy4BECh/dtAmfXPN1aVMRagfEYhEVd1IhqYp3mhWs73ekrS JSLAUWR14pAV2DjFi1bzOeq4oT7JgY0nyrFK2VgLeMw2 X-Google-Smtp-Source: AAOMgpeuv6VxDJqQTWnNTljoW4QF0Dggqm+PczXL4E2tdoe6JtFgeWIp6v3k7uFvA4l39QQE+mW9GtZe+I0qxj7uztw= X-Received: by 2002:a19:f104:: with SMTP id p4-v6mr13417381lfh.137.1533124540733; Wed, 01 Aug 2018 04:55:40 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:1d82:0:0:0:0:0 with HTTP; Wed, 1 Aug 2018 04:55:20 -0700 (PDT) In-Reply-To: <153310803137.22145.5132532082101433230.idtracker@ietfa.amsl.com> References: <153310803137.22145.5132532082101433230.idtracker@ietfa.amsl.com> From: Jen Linkova Date: Wed, 1 Aug 2018 21:55:20 +1000 Message-ID: To: Adam Roach Cc: The IESG , Russ White , v6ops-chairs@ietf.org, V6 Ops List , draft-ietf-v6ops-conditional-ras@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Adam Roach's No Objection on draft-ietf-v6ops-conditional-ras-05: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 11:55:49 -0000 Hi Adam, On Wed, Aug 1, 2018 at 5:20 PM, Adam Roach wrote: > =C2=A73.3.1: > >> It should be noted that in IPv4 multihoming with NAT, when the egress >> interface is chosen without taking packet source address into account >> (as internal hosts usually have addresses from [RFC1918] space), >> sessions can not be preserved after an uplink recovery. > > This isn't necessarily true. For example, if the NAT is tracking which > ISP-facing interface is associated with a given established session, the > sessions will survive restoration of an uplink. I have exactly such an I= Pv4 > multi-homing configuration working on my home network (with RFC 1918 addr= esses > assigned to all local devices), and will happily share details of my > configuration with interested parties. > > I propose striking this paragraph from the document. Good point. I've rephrased it to "It should be noted that in IPv4 multihoming with NAT, when the egress interface is chosen without taking packet source address into account (as internal hosts usually have addresses from [RFC1918] space), sessions might not be preserved after an uplink recovery unless packet forwarding is integrated with existing NAT sessions tracking." https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-06#section-3.3= .1 Would it address your concern? Thanks! (P.S. All nits fixed, thanks for pointing them out!) --=20 SY, Jen Linkova aka Furry From nobody Wed Aug 1 09:04:30 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 48A23130E6F; Wed, 1 Aug 2018 09:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 V9YwV7MkSPT3; Wed, 1 Aug 2018 09:04:14 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 80C21130E2E; Wed, 1 Aug 2018 09:04:14 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w71G47nD077941 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 1 Aug 2018 11:04:10 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Jen Linkova Cc: The IESG , Russ White , v6ops-chairs@ietf.org, V6 Ops List , draft-ietf-v6ops-conditional-ras@ietf.org References: <153310803137.22145.5132532082101433230.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: Date: Wed, 1 Aug 2018 11:04:06 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [v6ops] Adam Roach's No Objection on draft-ietf-v6ops-conditional-ras-05: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 16:04:20 -0000 On 8/1/18 6:55 AM, Jen Linkova wrote: > Hi Adam, > > On Wed, Aug 1, 2018 at 5:20 PM, Adam Roach wrote: >> §3.3.1: >> >>> It should be noted that in IPv4 multihoming with NAT, when the egress >>> interface is chosen without taking packet source address into account >>> (as internal hosts usually have addresses from [RFC1918] space), >>> sessions can not be preserved after an uplink recovery. >> This isn't necessarily true. For example, if the NAT is tracking which >> ISP-facing interface is associated with a given established session, the >> sessions will survive restoration of an uplink. I have exactly such an IPv4 >> multi-homing configuration working on my home network (with RFC 1918 addresses >> assigned to all local devices), and will happily share details of my >> configuration with interested parties. >> >> I propose striking this paragraph from the document. > Good point. I've rephrased it to > "It should be noted that in IPv4 multihoming with NAT, when the egress > interface is chosen without taking packet source address into account > (as internal hosts usually have addresses from [RFC1918] space), > sessions might not be preserved after an uplink recovery unless > packet forwarding is integrated with existing NAT sessions tracking." > > https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-06#section-3.3.1 > > Would it address your concern? It does. Thanks. /a From nobody Wed Aug 1 09:57:08 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 EBFF6130E58; Wed, 1 Aug 2018 09:56:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper To: "The IESG" Cc: draft-ietf-v6ops-conditional-ras@ietf.org, Russ White , v6ops-chairs@ietf.org, russ@riw.us, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153314261995.22116.11151750873382029406.idtracker@ietfa.amsl.com> Date: Wed, 01 Aug 2018 09:56:59 -0700 Archived-At: Subject: [v6ops] Alissa Cooper's No Objection on draft-ietf-v6ops-conditional-ras-06: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 16:57:00 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-v6ops-conditional-ras-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-conditional-ras/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I, too, was confused about the references to ietf-rtgwg-enterprise-pa-multihoming in the abstract, so would support the fixes previously suggested. Furthermore, the places where that document is named should be replaced with direct citations to it, which can then be updated to point to the corresponding RFC if it gets published in time or if it gets converted to a normative reference. Using 'the "ietf-rtgwg-enterprise-pa-multihoming" draft' is not going to age well since it won't always be a draft. In Section 5.1, I wonder if it's worth pointing out that by supporting enterprise multihoming the techniques described in this document can provide a privacy benefit to users, since remote peers view their traffic as having multiple source addresses? From nobody Wed Aug 1 13:33:26 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 0B44C130E2A; Wed, 1 Aug 2018 13:33:19 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 6JKXTcuQ3yQ7; Wed, 1 Aug 2018 13:33:16 -0700 (PDT) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (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 642AA130DC6; Wed, 1 Aug 2018 13:33:16 -0700 (PDT) Received: by mail-yb0-x22a.google.com with SMTP id h127-v6so8071659ybg.12; Wed, 01 Aug 2018 13:33:16 -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=wDTUc7VsFlbBJ1owWFZFEMh/GItfygg7a/c9OyFqOvo=; b=ePm9ZhpvMwo/OYw/IlWmed4ErfXHMfWGho3wobQsepa1XDHW0/vchfpASg6KO7XtIN utwAQRXzcJUU+RVBcC13mjhWbmBmLbx+seM4JDsTg7EeWDxGQgCSjMqxRQPsVtdGqiSt E+SGZpxeiwovzItZLXUk1SUbyKzkUxBfF6FYCVIwJwOaF78g3nYI4qezNYwQA/hpGwY4 5z/B2R31sakKjuYg7Vuc5Gm2MOkZYQQnxomR1VUPvPEvhxVbASUA0vKRrIbo38XF7TZ2 XUsvxrcKyfsP7DXE9e+/P9BEdLcP1LWZbedYNpw6DsfMFTXlto7YOT3CiEH+mvV4z/LX 0//g== 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=wDTUc7VsFlbBJ1owWFZFEMh/GItfygg7a/c9OyFqOvo=; b=SpT4ZXijMjDqG1ArLlSBiuq051EDbIQ8guu/A65Rz992s++O8w+WDCu2Gk6p692/Po UdYnwiv6eGmOUw569irDInys7EP/DP4CqdjiJYdCm8Xmwo9wqImlw7mC2E9MNDL2ztGh dvX7ElUUYO/DTQsJNfuUKzP0SE1IjcenftkPbKUCkXqMjJuEBozF5ojIPv89Le9Hq8PH v77APSaDg1yUYDwn+hGx9H1psoSLz+sDayicJIRGRKPvSpIzGKYiETTjLGa50OlKoHFn W4dcfP4nCb17pfGU37Mw0RXw/178e/xQFm7dgG6wKkvJ6novLARugmIt+AxGIo6DNH3V m6aQ== X-Gm-Message-State: AOUpUlHFPAP3+eMLecGfg9eUUu6ORghvV3MH6ZDiBaw8l66YN27hyf9e apcVlH5MLQ/4wVErdqW6FWPNhYriR4EXvFExrG0= X-Google-Smtp-Source: AAOMgpetH2ta7RjpijGXbtnCpQMJiTHu5xhVTlJZ5naqLolCTcjWf7JgPAYLuSTCg/N5l/JDp/fs0SzUJnxmYvIkKOE= X-Received: by 2002:a25:c581:: with SMTP id v123-v6mr2404290ybe.235.1533155595295; Wed, 01 Aug 2018 13:33:15 -0700 (PDT) MIME-Version: 1.0 References: <153292034480.7043.166309226503951804.idtracker@ietfa.amsl.com> In-Reply-To: From: Spencer Dawkins at IETF Date: Wed, 1 Aug 2018 15:33:03 -0500 Message-ID: To: Jen Linkova Cc: IESG , russ@riw.us, V6ops Chairs , v6ops list , draft-ietf-v6ops-conditional-ras@ietf.org Content-Type: multipart/alternative; boundary="000000000000a4a3540572659a20" Archived-At: Subject: Re: [v6ops] Spencer Dawkins' Yes on draft-ietf-v6ops-conditional-ras-05: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 20:33:19 -0000 --000000000000a4a3540572659a20 Content-Type: text/plain; charset="UTF-8" Hi, Jen, On Wed, Aug 1, 2018 at 6:43 AM Jen Linkova wrote: > Hi Spencer, > > Thank you very much for your feedback! > This all looks fine. Thank you for considering my comments. Spencer > > I echo Mirja's thanks for a well-written document (and her curiosity > about the > > near-null Security Considerations - there's at least one recommendation > in this > > document, so it seems possible that some security consideration is worth > > mentioning). > > The Section 5 updated: > https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-06#section-5 > > > This text toward the bottom of the abstract > > > > this document > > adopts the approach proposed in the "ietf-rtgwg-enterprise-pa- > > multihoming" draft to provide a solution for a limited number of > > common use cases. > > > > is pretty easy to miss. If the reader misses it, the first sentence is > kind of > > misleading - it just says > > > > This document discusses the most common scenarios of connecting an > > enterprise network to multiple ISPs using an address space assigned > > by an ISP. > > > > Perhaps it's worth pointing that out in the first sentence, rather than > towards > > the end of the abstract? > > I've updated the first sentence, it's now saying: > > "This document discusses the most common scenarios of connecting an > enterprise network to multiple ISPs using an address space assigned > by an ISP and how the approach proposed in the "ietf-rtgwg- > enterprise-pa-multihoming" draft could be applied in those scenarios." > > (https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-06) > > Do you think it's more clear now? > > > I've been on the IESG far too long, but I have tried repeatedly to read > > > > While some work is being done in the Source Address Dependent Routing > > (SADR) area (such as [I-D.ietf-rtgwg-dst-src-routing]), > > > > without thinking "but SADR isn't an (IETF) area?!?", and I can't do it. > If > > > > While some work is being done on Source Address Dependent Routing > > (SADR) (such as [I-D.ietf-rtgwg-dst-src-routing]), > > > > that would stop startling at least one reader ... > > Oops, sorry, did not think that the word 'area' is *so* overloaded..;) > Fixed! > > > In 3.2.5. Topologies with Dedicated Border Routers > > > > For simplicity, all topologies above show the ISP uplinks 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 interface > > status can not be used as a trigger for conditional RAs and route > > presence as described above should be used instead. > > > > "as described above" might be easier to navigate if it was "as described > above > > in Section 3.1.2" - it's a six-page jump, if I'm tracking this cross > reference > > correctly, and if I'm not, an explicit section reference would be even > more > > appreciated. > > Fixed: > > https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-06#section-3.2.5 > > > I'm not sure that > > > > It should be noted that the proposed approach is not a silver bullet > > for all possible multihoming scenarios. > > > > "silver bullet" is clear for readers from cultural contexts that don't > include > > werewolves or vampires ... but do the right thing, of course. > > Good point ;) I've added quotation marks around 'silver bullet' to > indicate it's a the figure of speech. > > > > > It's a nit, but "such as latencyetc". > > > > It's a nit, but "correspodning". > > Fixed. > > -- > SY, Jen Linkova aka Furry > --000000000000a4a3540572659a20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Jen,

On Wed, Aug 1, 2018 at 6:43 AM Jen Linkova <furry13@gmail.com> wrote:
Hi Spencer,

Thank you very much for your feedback!

= This all looks fine. Thank you for considering my comments.

<= /div>
Spencer
=C2=A0
>= I echo Mirja's thanks for a well-written document (and her curiosity a= bout the
> near-null Security Considerations - there's at least one recommend= ation in this
> document, so it seems possible that some security consideration is wor= th
> mentioning).

The Section 5 updated:
https://tools.ietf.org/html= /draft-ietf-v6ops-conditional-ras-06#section-5

> This text toward the bottom of the abstract
>
>=C2=A0 =C2=A0 this document
>=C2=A0 =C2=A0 adopts the approach proposed in the "ietf-rtgwg-ente= rprise-pa-
>=C2=A0 =C2=A0 multihoming" draft to provide a solution for a limit= ed number of
>=C2=A0 =C2=A0 common use cases.
>
> is pretty easy to miss. If the reader misses it, the first sentence is= kind of
> misleading - it just says
>
>=C2=A0 =C2=A0 This document discusses the most common scenarios of conn= ecting an
>=C2=A0 =C2=A0 enterprise network to multiple ISPs using an address spac= e assigned
>=C2=A0 =C2=A0 by an ISP.
>
> Perhaps it's worth pointing that out in the first sentence, rather= than towards
> the end of the abstract?

I've updated the first sentence, it's now saying:

"This document discusses the most common scenarios of connecting an =C2=A0 =C2=A0enterprise network to multiple ISPs using an address space ass= igned
=C2=A0 =C2=A0by an ISP and how the approach proposed in the "ietf-rtgw= g-
=C2=A0 =C2=A0enterprise-pa-multihoming" draft could be applied in thos= e scenarios."

(https://tools.ietf.org/html/draft-ie= tf-v6ops-conditional-ras-06)

Do you think it's more clear now?

> I've been on the IESG far too long, but I have tried repeatedly to= read
>
>=C2=A0 =C2=A0 While some work is being done in the Source Address Depen= dent Routing
>=C2=A0 =C2=A0 (SADR) area (such as [I-D.ietf-rtgwg-dst-src-routing]), >
> without thinking "but SADR isn't an (IETF) area?!?", and= I can't do it. If
>
>=C2=A0 =C2=A0 While some work is being done on Source Address Dependent= Routing
>=C2=A0 =C2=A0 (SADR) (such as [I-D.ietf-rtgwg-dst-src-routing]),
>
> that would stop startling at least one reader ...

Oops, sorry, did not think that the word 'area' is *so* overloaded.= .;) Fixed!

> In 3.2.5.=C2=A0 Topologies with Dedicated Border Routers
>
>=C2=A0 =C2=A0 For simplicity, all topologies above show the ISP uplinks= terminated
>=C2=A0 =C2=A0 on the first-hop routers.=C2=A0 Obviously, the proposed a= pproach can be
>=C2=A0 =C2=A0 used in more complex topologies when dedicated devices ar= e used for
>=C2=A0 =C2=A0 terminating ISP uplinks.=C2=A0 In that case VRRP mastersh= ip or interface
>=C2=A0 =C2=A0 status can not be used as a trigger for conditional RAs a= nd route
>=C2=A0 =C2=A0 presence as described above should be used instead.
>
> "as described above" might be easier to navigate if it was &= quot;as described above
> in Section 3.1.2" - it's a six-page jump, if I'm tracking= this cross reference
> correctly, and if I'm not, an explicit section reference would be = even more
> appreciated.

Fixed:
https://tools.ietf.org/= html/draft-ietf-v6ops-conditional-ras-06#section-3.2.5

> I'm not sure that
>
>=C2=A0 =C2=A0It should be noted that the proposed approach is not a sil= ver bullet
>=C2=A0 =C2=A0 for all possible multihoming scenarios.
>
> "silver bullet" is clear for readers from cultural contexts = that don't include
> werewolves or vampires ... but do the right thing, of course.

Good point ;) I've added quotation marks around 'silver bullet'= to
indicate it's a the figure of speech.

>
> It's a nit, but "such as latencyetc".
>
> It's a nit, but "correspodning".

Fixed.

--
SY, Jen Linkova aka Furry
--000000000000a4a3540572659a20-- From nobody Wed Aug 1 16:27:01 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 9C060130DC3; Wed, 1 Aug 2018 16:26:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-v6ops-conditional-ras@ietf.org, Russ White , v6ops-chairs@ietf.org, russ@riw.us, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153316601463.21847.9200082082622342279.idtracker@ietfa.amsl.com> Date: Wed, 01 Aug 2018 16:26:54 -0700 Archived-At: Subject: [v6ops] Ben Campbell's No Objection on draft-ietf-v6ops-conditional-ras-06: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2018 23:26:55 -0000 Ben Campbell has entered the following ballot position for draft-ietf-v6ops-conditional-ras-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-conditional-ras/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I share the confusion about the relationship to ietf-rtgwg-enterprise-pa-multihoming in the abstract. From nobody Wed Aug 1 19:27:04 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 CB377129C6A; Wed, 1 Aug 2018 19:26:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk To: "The IESG" Cc: draft-ietf-v6ops-conditional-ras@ietf.org, Russ White , v6ops-chairs@ietf.org, russ@riw.us, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153317681682.21918.12970450956130307676.idtracker@ietfa.amsl.com> Date: Wed, 01 Aug 2018 19:26:56 -0700 Archived-At: Subject: [v6ops] Benjamin Kaduk's No Objection on draft-ietf-v6ops-conditional-ras-06: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 02:26:57 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-v6ops-conditional-ras-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-conditional-ras/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'll echo Mirja and Spencer's question about the "empty" security considerations. (I actually don't much care for the "This memo introduces no new security considerations" formulation in general, unless it's literally the only content of the section -- it's either followed by new security considerations, in which it's just wrong, or followed by calling out specific portions of the referenced security considerations that are particularly relevant. In the latter case, it seems useful to provide more of a lead-in like "The general security considerations of [X] and[Y] apply, and in particular [...]".) Unfortunately, I don't seem to be in a good position to comment on actual additions to the security considerations section, since I don't have a clear picture of what the proposal in this document actually changes when compared to current/normal practices. This is presumably just a matter of my lacking the appropriate background knowledge for the routing bits, but in a scenario like Figure 3, with distinct edge and first-hop routers, what kind of RAs would the first-hop routers normally be sending? Would they be announcing the routes in question here just without the PIO markings, or not advertising anything at all, or something else? Other than that, thanks for the well-written document! From nobody Wed Aug 1 19:51:13 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 A5DBB130E5B; Wed, 1 Aug 2018 19:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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] 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 QvcGwZiSnjSz; Wed, 1 Aug 2018 19:51:09 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 ED0B6130E48; Wed, 1 Aug 2018 19:51:08 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id g6-v6so425909lfb.11; Wed, 01 Aug 2018 19:51:08 -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=XtdUdH2JbaD6pPVZiGbuIC+y2ipKbGYAARkqmU41Ys0=; b=X4bEKNrZjOGR6BNLsblE5e+NEGSnDbV+mfN7NlDLW45PH45krcYeEbjG8ohMMoAbt9 5UTeBM4BoNGdRkC1x623LmHjxA9epTuJIzoisVOfwXyz0+jYMgfoc6tz/phjDOhacvoF 9i2nIzuyed7yuvCCl6dhVoYtgwsgKj22waJLfFMSGrqGfiHdqU22XkjdLeDiOE3aMY0/ 7YZWf9oV35OdMe38HE25R4/Uvrd6znhCtjQhk8u5azLzwZbfKvO2CZkKKGvcEUoepxnL hG8081XfV1Gikwmy/nEb1ocBKjxHRaFZhtmoddHvhzGZ32PnGoFvkwgB8r/fod0sYuRJ QWIg== 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=XtdUdH2JbaD6pPVZiGbuIC+y2ipKbGYAARkqmU41Ys0=; b=ZWTQTTv52MLqaZqsK2IpIIe1Q+SAyFP72A0jUngeg/7WYoY5cCgN9X8CSULfJ4U+Co bKz8aoqDTs1r1XXafoUTxDL10ndTqYYKjhcGdxi5OBrri0VadUCUqrmYzv4D0InDIoch UwNemYb1zxhuQuOKOx8uTrGZRA1zzeHX3NWKW1MmSqzhZDzru75EiIGX4XZF+CB9Ep1B SwjkEzVJmAK4nN9pyO2XGQ6pjACpgM2PvxwxYyBrdoAuz+ksPsX9iIW0MFgvMTzjf+R7 9/rtRpupJWPH9OvinzbC2sM16NbrxH99PlNV52nJhQmfU1fd06SyofqPtPTM1qiQRSG9 eDYQ== X-Gm-Message-State: AOUpUlEIo+2fsZ3ZYO23vKvyr8cn5XKM4mC45Kf9GO8wZjdf3Uj7s3GE PmhDEmlCLh5Y5Hfeb5iNGsEN+HEHmNkO+lD8iv0= X-Google-Smtp-Source: AAOMgpe/8a814yUowoeoymw/26OuJucZRBsbtWhorQoDpZHoPGQUKPJD6oGJF/GDcXXFm0cdObkwj6hfn8eYCaI87x4= X-Received: by 2002:a19:f104:: with SMTP id p4-v6mr393827lfh.137.1533178267123; Wed, 01 Aug 2018 19:51:07 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:1d82:0:0:0:0:0 with HTTP; Wed, 1 Aug 2018 19:50:46 -0700 (PDT) In-Reply-To: <153317681682.21918.12970450956130307676.idtracker@ietfa.amsl.com> References: <153317681682.21918.12970450956130307676.idtracker@ietfa.amsl.com> From: Jen Linkova Date: Thu, 2 Aug 2018 12:50:46 +1000 Message-ID: To: Benjamin Kaduk Cc: The IESG , Russ White , v6ops-chairs@ietf.org, V6 Ops List , draft-ietf-v6ops-conditional-ras@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Benjamin Kaduk's No Objection on draft-ietf-v6ops-conditional-ras-06: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 02:51:11 -0000 Hi Benjamin, > I'll echo Mirja and Spencer's question about the "empty" security > considerations. (I actually don't much care for the "This memo introduces no > new security considerations" formulation in general, unless it's literally the > only content of the section -- it's either followed by new security > considerations, in which it's just wrong, or followed by calling out specific > portions of the referenced security considerations that are particularly > relevant. In the latter case, it seems useful to provide more of a lead-in > like "The general security considerations of [X] and[Y] apply, and in > particular [...]".) The most recent version (-06) submitted yesterday now has some text in the Security Considerations section: https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-06#section-5 I hope it addresses your question. > Unfortunately, I don't seem to be in a good position to comment on actual > additions to the security considerations section, since I don't have a clear > picture of what the proposal in this document actually changes when compared to > current/normal practices. This is presumably just a matter of my lacking the > appropriate background knowledge for the routing bits, but in a scenario like > Figure 3, with distinct edge and first-hop routers, what kind of RAs would the > first-hop routers normally be sending? Would they be announcing the routes in > question here just without the PIO markings, or not advertising anything at > all, or something else? Normally the first-hop routers are sending RAs which contain PIOs for the prefixes configured in the network. If the preferred-lifetime is not explicitly specified in the configuration by the administrator, those prefixes would have the default value of lifetime (7 days). Or any other value explicitly configured on the router (e.g. to deprecate a prefix for renumbering/if the wrong prefix has been configured, I have to edit routers configuration and set "prefix 2001:db8:1::/54 preferred-lifetime 0"). -- SY, Jen Linkova aka Furry From nobody Wed Aug 1 19:52:21 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 451E1130EA4; Wed, 1 Aug 2018 19:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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] 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 N5ltXiddmZNo; Wed, 1 Aug 2018 19:52:12 -0700 (PDT) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (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 9B738130E48; Wed, 1 Aug 2018 19:52:11 -0700 (PDT) Received: by mail-lf1-x12b.google.com with SMTP id g6-v6so427124lfb.11; Wed, 01 Aug 2018 19:52:11 -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=WK3kAlsiJhlcGN7f/3pKTL6xqrPZ8G7063kgnk8XRyk=; b=ktwQM5f5+3BWLcMNLgYe/1mrmn9OTIauQLKu8LGWdugkrrmfxjysawB5VpLOg6sdnU 10tleU7tQLs6xAHGnLySNUWVG8CLawyxc/LTHLvJ0MA0uQsargMTlCEITcCNDaNVUgXx BJ1cp7141VQlRkd12oq1aSbgAqXsazBlVO1Rh6sf0+3zeIUG7arcKt1rrkCjL2IvDil9 L+YoFNmh7H48bj+hmJmsS2NeUF1r9wqR7BeR1jLnZ7B+LGnMsRIvm+vekonjLchX8RiV P19oxaj60EGLOplv4SEBFecVaQpMC0AQDdJv3GI0AJaK7/ZtdIOkGiQWcaYNAnk8YC7l RdyQ== 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=WK3kAlsiJhlcGN7f/3pKTL6xqrPZ8G7063kgnk8XRyk=; b=dSrA32p94dFz0bOCQ/4/QyLAJ47i2IxS30mIKse+x20AsmWJVbX04r/tU5Sp1Qker5 3vfUF5j82LNKnLfZdxHCa40U8dtpDdizfTfUILHidhUxhuJXBRVePH8v0FOczXdO9AQt D1B3jt8g8NTUKbjCpfC1yn2R7wMhRq5829l9xpwL6YvFdtDzU48fR6iGIK+pgITmTnR9 bV+fhOuQGvHicRaPMP2kMZHYywODOrRq/UgJKWqwy+61ShnGVZi6r4hMLZU/ZUkfzo5k 7ScUACL8aVjL8TAcQq8I8S1dSzCzoRIaIjc5UZdv5r5bYe7jPhQWDC32kjlsvasaSrgS 0m+g== X-Gm-Message-State: AOUpUlGIh0b2xswo1FiECE/TpjQg2EOlNGzGvfB/KhmshCnKErCO636e tr2cdkZ1gbtzKehy3yhBfGNynJFhLf4TILy+zyHcoWFZ0JY= X-Google-Smtp-Source: AAOMgpcpyQEMeiPjTJZPB4ypE8069/rUrrL9Ishp4szojamS1ztKfHu83vMChZM5dS8vwOKhKPiQB1A95Y7f1v2HrlI= X-Received: by 2002:a19:c954:: with SMTP id z81-v6mr398265lff.107.1533178329892; Wed, 01 Aug 2018 19:52:09 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:1d82:0:0:0:0:0 with HTTP; Wed, 1 Aug 2018 19:51:49 -0700 (PDT) In-Reply-To: <153316601463.21847.9200082082622342279.idtracker@ietfa.amsl.com> References: <153316601463.21847.9200082082622342279.idtracker@ietfa.amsl.com> From: Jen Linkova Date: Thu, 2 Aug 2018 12:51:49 +1000 Message-ID: To: Ben Campbell Cc: The IESG , Russ White , v6ops-chairs@ietf.org, V6 Ops List , draft-ietf-v6ops-conditional-ras@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Ben Campbell's No Objection on draft-ietf-v6ops-conditional-ras-06: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 02:52:13 -0000 Hi Ben, > I share the confusion about the relationship to > ietf-rtgwg-enterprise-pa-multihoming in the abstract. Is the updated abstract (https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-06) still confusing? -- SY, Jen Linkova aka Furry From nobody Wed Aug 1 20:18: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 64AE6130EA8; Wed, 1 Aug 2018 20:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 TlH-seN9BS9U; Wed, 1 Aug 2018 20:18:17 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.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 92E59130DCA; Wed, 1 Aug 2018 20:18:16 -0700 (PDT) X-AuditID: 1209190d-50bff70000006081-f3-5b6277f69496 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id BC.25.24705.7F7726B5; Wed, 1 Aug 2018 23:18:15 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id w723IAji012109; Wed, 1 Aug 2018 23:18:11 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w723I5Io018630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Aug 2018 23:18:08 -0400 Date: Wed, 1 Aug 2018 22:18:06 -0500 From: Benjamin Kaduk To: Jen Linkova Cc: The IESG , Russ White , v6ops-chairs@ietf.org, V6 Ops List , draft-ietf-v6ops-conditional-ras@ietf.org Message-ID: <20180802031803.GA96369@kduck.kaduk.org> References: <153317681682.21918.12970450956130307676.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAKsWRmVeSWpSXmKPExsUixG6nrvu9PCnaYMd7OYsVC/qYLC7tbGOy mPFnIrPFw24Ti6mP3zNZnD62l9mBzWPnrLvsHkuW/GTyOP1wMnsAcxSXTUpqTmZZapG+XQJX xuwrXUwFEyUrnqy4wtrAuFOki5GTQ0LARGJ793yWLkYuDiGBxUwSL66uYoJwNjBK7O95BOVc YZJo+rKOFaSFRUBFovXmQmYQmw3Ibui+DGaLCChLLL93hRmkgVlgBaPE7wXnWUASwgLZEus7 3oHZvED7er5cBBskJDCVUeLBBXGIuKDEyZlPwGqYBbQkbvx7CbSZA8iWllj+jwMkzCkQKNG+ awUbiC0KtGtv3yH2CYwCs5B0z0LSPQuhewEj8ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdI73c zBK91JTSTYygwOaU5N3B+O+u1yFGAQ5GJR7eGwxJ0UKsiWXFlbmHGCU5mJREeV3SgUJ8Sfkp lRmJxRnxRaU5qcWHGCU4mJVEeJs9gHK8KYmVValF+TApaQ4WJXHeezXh0UIC6YklqdmpqQWp RTBZGQ4OJQleeWAECwkWpaanVqRl5pQgpJk4OEGG8wANDykDGV5ckJhbnJkOkT/FqMvx5/3U ScxCLHn5ealS4rw5IEUCIEUZpXlwc0AJSSJ7f80rRnGgt4R5+0GqeIDJDG7SK6AlTEBLsh0T QZaUJCKkpBoYn5XffGUQwVil2xwVGe4qxN24cdKyTStvnLkld/HXfhfvOW3vVPJantd0Gk6e sWnzSrsj/nOPyOk9kFvr+9rz9u3g08fkrZgjrc3KP9THF/9bn/Vg66Mr1lx7TiQf2uW9btes z+sqirpMb0xX1tszyWCzY8qmU62aredt/5nstFa4usv1fbhVvRJLcUaioRZzUXEiAJb7lJMj AwAA Archived-At: Subject: Re: [v6ops] Benjamin Kaduk's No Objection on draft-ietf-v6ops-conditional-ras-06: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 03:18:18 -0000 Thanks for the updates, Jen. [inline] On Thu, Aug 02, 2018 at 12:50:46PM +1000, Jen Linkova wrote: > Hi Benjamin, > > > I'll echo Mirja and Spencer's question about the "empty" security > > considerations. (I actually don't much care for the "This memo introduces no > > new security considerations" formulation in general, unless it's literally the > > only content of the section -- it's either followed by new security > > considerations, in which it's just wrong, or followed by calling out specific > > portions of the referenced security considerations that are particularly > > relevant. In the latter case, it seems useful to provide more of a lead-in > > like "The general security considerations of [X] and[Y] apply, and in > > particular [...]".) > > The most recent version (-06) submitted yesterday now has some text in > the Security Considerations section: > > https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-06#section-5 > > I hope it addresses your question. Oh! I was actually looking at the -06, but hadn't noticed how new it was (and thus that the previous comments referred to a much more empty security considerations section). I'd suggest dropping "This memo introduces no new security considerations." and starting off with something like "This memo describes a way to use existing Router Advertisements ([RFC4861]) and SLAAC ([RFC4862] mechansisms, and the security considerations for those technologies continue to apply. The types of message flows described in this memo could allow an attacker who is able to send a rogue RA to deprecate IPv6 addresses on hosts or [...]". > > Unfortunately, I don't seem to be in a good position to comment on actual > > additions to the security considerations section, since I don't have a clear > > picture of what the proposal in this document actually changes when compared to > > current/normal practices. This is presumably just a matter of my lacking the > > appropriate background knowledge for the routing bits, but in a scenario like > > Figure 3, with distinct edge and first-hop routers, what kind of RAs would the > > first-hop routers normally be sending? Would they be announcing the routes in > > question here just without the PIO markings, or not advertising anything at > > all, or something else? > > Normally the first-hop routers are sending RAs which contain PIOs for > the prefixes configured in the network. > If the preferred-lifetime is not explicitly specified in the > configuration by the administrator, those prefixes would have > the default value of lifetime (7 days). Or any other value explicitly > configured on the router (e.g. to deprecate a prefix for > renumbering/if the wrong > prefix has been configured, I have to edit routers configuration and > set "prefix 2001:db8:1::/54 preferred-lifetime 0"). Okay, so it sounds like the "new information" here is to conceptually tie the uplink status together with the RA preferred_lifetime fields, along with the policy implications on the routers themselves. The coverage added in the -06 seems to be enough, then. Thanks for the (quick) reply and clarifications! -Benjamin From nobody Thu Aug 2 06:51:45 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 18AD71277C8; Thu, 2 Aug 2018 06:51:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan To: "The IESG" Cc: draft-ietf-v6ops-conditional-ras@ietf.org, Russ White , v6ops-chairs@ietf.org, russ@riw.us, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153321790308.2265.731201835682425291.idtracker@ietfa.amsl.com> Date: Thu, 02 Aug 2018 06:51:43 -0700 Archived-At: Subject: [v6ops] Suresh Krishnan's Yes on draft-ietf-v6ops-conditional-ras-06: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 13:51:43 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-v6ops-conditional-ras-06: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-conditional-ras/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 3.1.1. I think a reference to RFC3704 (specifically written for describing ingress filtering for multihomed networks) might be a good addition here to RFC2827 * Sections 3.2.1., 3.2.2. etc. => I think it is important to specify (at least the bounds of) the valid lifetimes here as well. e.g. when the preferred lifetime is getting set to zero it is important to specify that the valid lifetime is set to a non zero value so that the host will form an address at all (even though it will not be used when there are preferred addresses). This is important to reduce the potential packet losses when the preferred uplink goes down. * Section 3.2.2. I think there is some text missing here about VRRP priorities here. There seems to be an assumption in the draft that the uplink A failure will lead to R1 becoming backup ("If ISP_A uplink is down, then R1 becomes a backup.") and this is not obvious at all. There needs to be a priority change with interface tracking if this has to happen and the backup has to take over as the master. From nobody Thu Aug 2 10:08: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 26394130E13 for ; Thu, 2 Aug 2018 10:08:55 -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 5hqMMQNr4Sng for ; Thu, 2 Aug 2018 10:08:53 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 88D80130DDF for ; Thu, 2 Aug 2018 10:08:52 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id s24-v6so1192775edr.8 for ; Thu, 02 Aug 2018 10:08:52 -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=HRJ1VVPjmqTDaymE0cWpVdFRhpLVCh9C0INJRYprXr0=; b=B3OFOmH7Wwu9nZtKkh4yfadezAuqYhwlFeja4j7pf0wEZCRZ2WKj0KA69ZxhO8+p0Y NNYhyuPt0h79UDViUWIONIV9yb0fQSCdykQQqmtQCflvnPpM2bl0tdkTenMwUngY8aIR seP8iUB3aUGlD6qINRu4SxA77fkcqYCXmHTk/x7morhfncYVK8L9mlsMH+oJZxukBzKP s+GE8bABK/LKAlYcf4et7lmR0rTyH5whyA7yo0YGz9uQv+MJtATCU03kN2kcFc5F8wPZ EvkDFnpsXRm1whp6Rv8CcYVdGnkR3U7IjBwyr9qVwIEmRm68sXS9wvV/mthVDPIV8YSr o7tg== 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=HRJ1VVPjmqTDaymE0cWpVdFRhpLVCh9C0INJRYprXr0=; b=TjQF3TkxlT6zzSRStmrzPwTEfnZYUpnyr1DOqnFpA3eWhPv4BxRZBFlJrtW7jxzLe/ elVmLSjSk8YDit7KVyrRdfZFCHz1Ir1AxUQHplTrOyELFIwRoRS6DTeo9eU1kgiOUqfa V8kkReBjO3y06c8BnvwqwvUUSVsQiEO1Ag+yrHvIYcloo9wbWYGLu5Zh9ZRqkk9zO4Pz 8ycRtgGL86J/ypP2ygf9Cr1XOVP3xpGn3OwNGfzPirHUYoaORhGkYonyHYgdA7t9IVYZ 7EYvUBuKMMOok9lCmvfvMWrck0o2QbfaUFjAMAVqnLtVCHRLCtkRKc13bP53gdnUPF9C wIqg== X-Gm-Message-State: AOUpUlFP1geVDkidc9ypIKCPu1Z+p/eKi6MVWH88Pvg3uaceGFGgUeHT vd3KrSeesTE+LvUxFeqP6vI= X-Google-Smtp-Source: AAOMgpfmLQBNriKTSPPipiKw5ijDu+ggDc2sefmGgyfwHLwWo3Dx5W4ohPtxInRumy4T/x5fka15/w== X-Received: by 2002:aa7:da16:: with SMTP id r22-v6mr4211127eds.54.1533229731103; Thu, 02 Aug 2018 10:08:51 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::102f? ([2600:8802:5600:1546::102f]) by smtp.gmail.com with ESMTPSA id f11-v6sm1777746ede.76.2018.08.02.10.08.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Aug 2018 10:08:50 -0700 (PDT) From: Fred Baker Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_262AD948-685B-4C45-B990-289753234F2C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 2 Aug 2018 10:08:45 -0700 In-Reply-To: <1839169394.23068455.1533070511328.JavaMail.zimbra@telecentro.net.ar> Cc: JORDI PALET MARTINEZ , "v6ops@ietf.org list" To: Alejandro D'Egidio References: <1839169394.23068455.1533070511328.JavaMail.zimbra@telecentro.net.ar> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 17:08:55 -0000 --Apple-Mail=_262AD948-685B-4C45-B990-289753234F2C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 No hats, just a dumb question. I think having the CPE put a separate subnet onto each customer LAN = makes sense. To begin with, it fits the architectural intent. But I'm a = little confused by the need to have a requirement regarding IPv4 = addressing, and very much confused by having a *different* requirement. = Why? If I were setting up my home router to be an all-facing thing, I would = perhaps put, for each segment or SSID enumerated as "N", = 2001:db8:m:N::/64 and 192.168.N.0/24. (Note that I don't; for reasons = related to the structure of my house, I have three APs scattered around, = and they all attach to the wired plant. Hence, they use the same address = space as the wired LAN. I have several SSIDs coming from the router = itself, which I don't use because they don't reach). But I would follow = the same rule for IPv4 as for IPv6; if I'm specifying a different = subnet per LAN/WLAN in IPv6, why would I not do so for IPv4? > On Jul 31, 2018, at 1:55 PM, Alejandro D'Egidio = wrote: >=20 > Hello Jordi, > My notes in lines. >=20 > Regards, > Alejandro >=20 > ----- Mensaje original ----- >> De: "JORDI PALET MARTINEZ" >> Para: "Alejandro Degidio" , "Ron Bonica" = >> CC: "v6ops@ietf.org list" >> Enviados: Lunes, 30 de Julio 2018 20:58:52 >> Asunto: Re: [v6ops] Weekly Review: = draft-ietf-v6ops-transition-ipv4aas >=20 >> Hi Alejandro, >>=20 >>=20 >>=20 >> Thanks for the input! >>=20 >>=20 >>=20 >> I think it is easy to understand: >>=20 >> "This document covers a set of IP transition techniques required when >>=20 >> ISPs have an IPv6-only access network." >>=20 >>=20 >>=20 >> even if the ISP already have an IPv6-only access network, or want to = have it. >>=20 >>=20 >>=20 >> But this may be something that a native English speaker could tell us = how better >> to say it. May be: >>=20 >> "This document covers a set of IP transition techniques required when >>=20 >> ISPs have or want to move to an IPv6-only access network." >>=20 >>=20 > Yes, it's great. >=20 >>=20 >> I'd some text in earlier versions about the reasons to have an = IPv6-only access >> network, but it was suggested to move it to the Annex A ... not sure = if you >> read them also. I'm happy to add some more text, if needed to the = annex A to >> describe several possible reasons. >>=20 >=20 > Yes, I've read all the document included the Annexes. >=20 >=20 >>=20 >>=20 >> The case for having multiple IPv4 subnets (one for each interface), = is feasible, >> as you say, by having multiple instances of the NAT46, which I think = is not a >> problem. >>=20 >>=20 >>=20 >> However, open question is valid also for any other IPv4aaS mechanism. >>=20 >>=20 >>=20 >> I'm not sure if we want to have that case considered as something = that MUST be >> supported as one more requirement, and if this is the case, it will = be a >> "general" transition requirement, and no need to go in the details = for each >> transition mechanism, or we really want to go to describe a specific = new >> requirement for this for each transition mechanism ... >>=20 >=20 > Just knowing that a CPE can have different LAN IPv4 prefixes I was = thinking that maybe it could be considered in General transition = requirements with something like: >=20 > "TRANS-6: The IPv6 Transition CE Router MAY have different IPv4 = prefixes on each Customer-Facing interfaces and the transition = mechanisms MUST have options to be compatible with it." >=20 >=20 >>=20 >>=20 >> What others think? >>=20 >>=20 >>=20 >> Regards, >>=20 >> Jordi >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> =EF=BB=BF-----Mensaje original----- >>=20 >> De: v6ops en nombre de Alejandro D'Egidio >> >>=20 >> Fecha: lunes, 30 de julio de 2018, 10:39 >>=20 >> Para: Ron Bonica >>=20 >> CC: "v6ops@ietf.org list" >>=20 >> Asunto: Re: [v6ops] Weekly Review: = draft-ietf-v6ops-transition-ipv4aas >>=20 >>=20 >>=20 >> Hello Ron, >>=20 >> I really like this draft! >>=20 >> Just a simple comment. >>=20 >> Where says: >>=20 >> This document covers a set of IP transition techniques required = when >>=20 >> ISPs have an IPv6-only access network. >>=20 >>=20 >>=20 >> Maybe could say: >>=20 >> This document covers a set of IP transition techniques required = when >>=20 >> ISPs wants to have an IPv6-only access network. >>=20 >>=20 >>=20 >> Maybe you can include some example of why ISPs wants to have an = IPv6 only access >> network. >>=20 >> For example, in my case, as we don't have more public IPv4 = addresses and we have >> IPv6 developed, why should I need to continue managing IPv4 = addresses? >>=20 >> Maybe some kind of this scenario could be included. >>=20 >>=20 >>=20 >> Regarding 3.2.1. 464XLAT: >>=20 >> Cablelabs defines that the CableModem must subnet the IPv6 Prefix = received from >> ISP to use different subnets on each LAN Interface. The size of = IPv6 "sub" >> prefix on each LAN depends on is ISP configured the CM to use = either favor >> depth or favor width. If ISP provides just a /64 IPv6 prefix (which = is not >> recommended) CM must share it with all LAN interfaces. >>=20 >>=20 >>=20 >> For IPv4, by the same private IPv4 prefix is shared between all LAN = interfaces >> (customer-facing interfaces). For this case I think it "3.2.1. = 464XLAT" is ok. >>=20 >> There are some cases where CM could have different private IPv4 = prefixes to each >> customer-facing interfaces. So I think, this is another scenario = that should be >> covered where CLAT will need to work with all the IPv4 LAN = prefixes. Maybe >> running multiple instances of its NAT46 (one for each LAN = interface) or one >> instance supporting multiple IPv4 addresses. >>=20 >>=20 >>=20 >> All this is in: >> = https://apps.cablelabs.com/specification/ipv4-and-ipv6-erouter-specificati= on/ >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Regards, >>=20 >> ALEJANDRO D'EGIDIO >>=20 >> Jefe de Ingenier=C3=ADa de Backbone | Direcci=C3=B3n de Ingenier=C3=AD= a >>=20 >> M: [ callto:+54 911 5794-1589 | +54 911 5794-1589 ] | F: [ = callto:+54 11 >> 3977-1025 | +54 11 3977-1025 ] | [ = mailto:adegidio@telecentro.net.ar | >> adegidio@telecentro.net.ar ] >>=20 >> Pje. Lavard=C3=A9n 157. Piso 3. CABA (C1437FBC) >>=20 >>=20 >>=20 >> ----- Mensaje original ----- >>=20 >> De: "Ron Bonica" >>=20 >> Para: "v6ops@ietf.org list" >>=20 >> Enviados: Lunes, 30 de Julio 2018 10:12:50 >>=20 >> Asunto: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas >>=20 >>=20 >>=20 >> Folks, >>=20 >>=20 >>=20 >> Each week between now and IETF 103, we will review and discuss one = draft with an >> eye towards progressing it. >>=20 >>=20 >>=20 >> This week, please review and comment on = draft-ietf-v6ops-transition-ipv4aas. >>=20 >>=20 >>=20 >> Fred and Ron >>=20 >>=20 >>=20 >> _______________________________________________ >>=20 >> v6ops mailing list >>=20 >> v6ops@ietf.org >>=20 >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >>=20 >> _______________________________________________ >>=20 >> v6ops mailing list >>=20 >> v6ops@ietf.org >>=20 >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >>=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 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. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = --------------------------------------------------------------------------= ------ The fact that there is a highway to hell and a stairway to heaven is an = interesting comment on projected traffic volume... --Apple-Mail=_262AD948-685B-4C45-B990-289753234F2C 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+AFAltjOp0ACgkQEhdRnd2G P+AbaA//WLLeZTzUKGpw3w8V8FAxLo6mSrYKo3TG8L0JOasWl/aJCBrA0TfACsp5 Ek/hM2RmvBWnqDpJPk+7/nvotpzZmrCFBXi4nar3zmncwnFM5+rYBVjOSbKp+6KR hya+RmRvY0hRgBbWunNxM1BB0EbYKExbszJlr8YFl9UWB5lFZ19mzx+czQRKdIql A2+gz6aqzi1uFdFR2K4aU/IrZlIDEhmEV/mLs8d0U+PFhUsHa6sgt0hN0PDaSCGi ge/qfncE8m7F/kVpmpye+QUGf3a1kkMIEtff8gEx4RCdrMrAW6lh7kBvr6vG1eB0 bPXmt72Abn1h0yPBCZhN9IQ8k5zuqF92LdeutKfU9Y9RpQtSh1+ci79E3J/mRWue LvX+p3iwuEM8oag9nNWMEFT9MLC2doyfsyY8B40qBCdbeAMC/rBes4xhky0BYYCE QLmw4bYOz0HXwMv4UP4wVWpEgIyLHWKfhtjV0QYkkmAQj+/JURqsDaAHJsRwxUDO NjXAKM5IaGwtpDVubnHam6VLYBjvyOooeye+KAMZzk4t06IuAY1gwihEyqECnmBR jMAmEeUX8/6WxVp8yQ+tBvJs6Fl9NxVjOlF2Rk6TqMkC4FSt0pFq4aA4q5EvVv+3 IS5FTM6mX9+Wde1ehftX+V+cqqGsTjSR8ETYArXVsuU0fX3wgyo= =AeXe -----END PGP SIGNATURE----- --Apple-Mail=_262AD948-685B-4C45-B990-289753234F2C-- From nobody Thu Aug 2 16:51:33 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 B9139130DBE for ; Thu, 2 Aug 2018 16:51:31 -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 0kykcCSR2VaG for ; Thu, 2 Aug 2018 16:51:28 -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 A2520126CC7 for ; Thu, 2 Aug 2018 16:51:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1533253885; x=1533858685; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=1PnoAw+yyUelHBWWsxltmF4AFQEDrELl7Qe3rO+5rxs=; b=p/ShfUND2GTaN obfRimrDBss8BkxrrRCI09Yz0Ia8o7SN/NLBGQG7rRGlYSNrE55JsI3JPJieWZkV W2TQufDE2nE06y2+cjmxMecJAQ/k3yDhPTKq4vIJbwugWPnsHkMyV5gCW1m1T/dm rhJlkpDxwFQhwp6akON6G8VlC5iUFg= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 03 Aug 2018 01:51:25 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 03 Aug 2018 01:51:24 +0200 Received: from [10.20.5.175] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005825182.msg for ; Fri, 03 Aug 2018 01:51:23 +0200 X-MDRemoteIP: 10.8.10.6 X-MDHelo: [10.20.5.175] X-MDArrival-Date: Fri, 03 Aug 2018 01:51:23 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1752e95d01=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.f.0.180709 Date: Thu, 02 Aug 2018 18:51:15 -0500 From: JORDI PALET MARTINEZ To: Fred Baker , Alejandro D'Egidio CC: "v6ops@ietf.org list" Message-ID: <92E96F99-8AF8-4265-ABEB-052AC037FE30@consulintel.es> Thread-Topic: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas References: <1839169394.23068455.1533070511328.JavaMail.zimbra@telecentro.net.ar> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 23:51:32 -0000 Actually, you do also in some cases for both, IPv4 and IPv6. If you want to have a specific subnet for a special "guest" SSID, you want = to separate that from the SSID of the home owners. You may want to have a separated segment also for a wired home office. You = don't want the kids being able to reach your work documents, etc. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: Fred Baker Fecha: jueves, 2 de agosto de 2018, 12:08 Para: Alejandro D'Egidio CC: JORDI PALET MARTINEZ , "v6ops@ietf.org list= " Asunto: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas No hats, just a dumb question. =20 I think having the CPE put a separate subnet onto each customer LAN mak= es sense. To begin with, it fits the architectural intent. But I'm a little= confused by the need to have a requirement regarding IPv4 addressing, and = very much confused by having a *different* requirement. Why? =20 If I were setting up my home router to be an all-facing thing, I would = perhaps put, for each segment or SSID enumerated as "N", 2001:db8:m:N::/64 = and 192.168.N.0/24. (Note that I don't; for reasons related to the structur= e of my house, I have three APs scattered around, and they all attach to th= e wired plant. Hence, they use the same address space as the wired LAN. I h= ave several SSIDs coming from the router itself, which I don't use because = they don't reach). But I would follow the same rule for IPv4 as for IPv6; i= f I'm specifying a different subnet per LAN/WLAN in IPv6, why would I not = do so for IPv4? =20 > On Jul 31, 2018, at 1:55 PM, Alejandro D'Egidio wrote: >=20 > Hello Jordi, > My notes in lines. >=20 > Regards, > Alejandro >=20 > ----- Mensaje original ----- >> De: "JORDI PALET MARTINEZ" >> Para: "Alejandro Degidio" , "Ron Bonica"= >> CC: "v6ops@ietf.org list" >> Enviados: Lunes, 30 de Julio 2018 20:58:52 >> Asunto: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4a= as >=20 >> Hi Alejandro, >>=20 >>=20 >>=20 >> Thanks for the input! >>=20 >>=20 >>=20 >> I think it is easy to understand: >>=20 >> "This document covers a set of IP transition techniques required whe= n >>=20 >> ISPs have an IPv6-only access network." >>=20 >>=20 >>=20 >> even if the ISP already have an IPv6-only access network, or want to= have it. >>=20 >>=20 >>=20 >> But this may be something that a native English speaker could tell u= s how better >> to say it. May be: >>=20 >> "This document covers a set of IP transition techniques required whe= n >>=20 >> ISPs have or want to move to an IPv6-only access network." >>=20 >>=20 > Yes, it's great. >=20 >>=20 >> I'd some text in earlier versions about the reasons to have an IPv6-= only access >> network, but it was suggested to move it to the Annex A ... not sure= if you >> read them also. I'm happy to add some more text, if needed to the an= nex A to >> describe several possible reasons. >>=20 >=20 > Yes, I've read all the document included the Annexes. >=20 >=20 >>=20 >>=20 >> The case for having multiple IPv4 subnets (one for each interface), = is feasible, >> as you say, by having multiple instances of the NAT46, which I think= is not a >> problem. >>=20 >>=20 >>=20 >> However, open question is valid also for any other IPv4aaS mechanism= . >>=20 >>=20 >>=20 >> I'm not sure if we want to have that case considered as something th= at MUST be >> supported as one more requirement, and if this is the case, it will = be a >> "general" transition requirement, and no need to go in the details f= or each >> transition mechanism, or we really want to go to describe a specific= new >> requirement for this for each transition mechanism ... >>=20 >=20 > Just knowing that a CPE can have different LAN IPv4 prefixes I was th= inking that maybe it could be considered in General transition requirements= with something like: >=20 > "TRANS-6: The IPv6 Transition CE Router MAY have different IPv4 prefi= xes on each Customer-Facing interfaces and the transition mechanisms MUST h= ave options to be compatible with it." >=20 >=20 >>=20 >>=20 >> What others think? >>=20 >>=20 >>=20 >> Regards, >>=20 >> Jordi >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> =EF=BB=BF-----Mensaje original----- >>=20 >> De: v6ops en nombre de Alejandro D'Egidio >> >>=20 >> Fecha: lunes, 30 de julio de 2018, 10:39 >>=20 >> Para: Ron Bonica >>=20 >> CC: "v6ops@ietf.org list" >>=20 >> Asunto: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4a= as >>=20 >>=20 >>=20 >> Hello Ron, >>=20 >> I really like this draft! >>=20 >> Just a simple comment. >>=20 >> Where says: >>=20 >> This document covers a set of IP transition techniques required wh= en >>=20 >> ISPs have an IPv6-only access network. >>=20 >>=20 >>=20 >> Maybe could say: >>=20 >> This document covers a set of IP transition techniques required wh= en >>=20 >> ISPs wants to have an IPv6-only access network. >>=20 >>=20 >>=20 >> Maybe you can include some example of why ISPs wants to have an IP= v6 only access >> network. >>=20 >> For example, in my case, as we don't have more public IPv4 address= es and we have >> IPv6 developed, why should I need to continue managing IPv4 addres= ses? >>=20 >> Maybe some kind of this scenario could be included. >>=20 >>=20 >>=20 >> Regarding 3.2.1. 464XLAT: >>=20 >> Cablelabs defines that the CableModem must subnet the IPv6 Prefix = received from >> ISP to use different subnets on each LAN Interface. The size of IP= v6 "sub" >> prefix on each LAN depends on is ISP configured the CM to use eith= er favor >> depth or favor width. If ISP provides just a /64 IPv6 prefix (whic= h is not >> recommended) CM must share it with all LAN interfaces. >>=20 >>=20 >>=20 >> For IPv4, by the same private IPv4 prefix is shared between all LA= N interfaces >> (customer-facing interfaces). For this case I think it "3.2.1. 46= 4XLAT" is ok. >>=20 >> There are some cases where CM could have different private IPv4 pr= efixes to each >> customer-facing interfaces. So I think, this is another scenario t= hat should be >> covered where CLAT will need to work with all the IPv4 LAN prefixe= s. Maybe >> running multiple instances of its NAT46 (one for each LAN interfac= e) or one >> instance supporting multiple IPv4 addresses. >>=20 >>=20 >>=20 >> All this is in: >> https://apps.cablelabs.com/specification/ipv4-and-ipv6-erouter-spe= cification/ >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Regards, >>=20 >> ALEJANDRO D'EGIDIO >>=20 >> Jefe de Ingenier=C3=ADa de Backbone | Direcci=C3=B3n de Ingenier= =C3=ADa >>=20 >> M: [ callto:+54 911 5794-1589 | +54 911 5794-1589 ] | F: [ callto:= +54 11 >> 3977-1025 | +54 11 3977-1025 ] | [ mailto:adegidio@telecentro.net.= ar | >> adegidio@telecentro.net.ar ] >>=20 >> Pje. Lavard=C3=A9n 157. Piso 3. CABA (C1437FBC) >>=20 >>=20 >>=20 >> ----- Mensaje original ----- >>=20 >> De: "Ron Bonica" >>=20 >> Para: "v6ops@ietf.org list" >>=20 >> Enviados: Lunes, 30 de Julio 2018 10:12:50 >>=20 >> Asunto: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas >>=20 >>=20 >>=20 >> Folks, >>=20 >>=20 >>=20 >> Each week between now and IETF 103, we will review and discuss one= draft with an >> eye towards progressing it. >>=20 >>=20 >>=20 >> This week, please review and comment on draft-ietf-v6ops-transitio= n-ipv4aas. >>=20 >>=20 >>=20 >> Fred and Ron >>=20 >>=20 >>=20 >> _______________________________________________ >>=20 >> v6ops mailing list >>=20 >> v6ops@ietf.org >>=20 >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >>=20 >> _______________________________________________ >>=20 >> v6ops mailing list >>=20 >> v6ops@ietf.org >>=20 >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >>=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 us= e of the >> individual(s) named above and further non-explicilty authorized disc= losure, >> copying, distribution or use of the contents of this information, ev= en 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 strictl= y >> prohibited, will be considered a criminal offense, so you must reply= to the >> original sender to inform about this communication and delete it. >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 -----------------------------------------------------------------------= --------- The fact that there is a highway to hell and a stairway to heaven is an= interesting comment on projected traffic volume... =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 Fri Aug 3 04:48: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 BEE85130FF9 for ; Fri, 3 Aug 2018 04:48:00 -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, 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=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 i7qUipdA-Mho for ; Fri, 3 Aug 2018 04:47:59 -0700 (PDT) Received: from mx0b-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 5CFB5130E2F for ; Fri, 3 Aug 2018 04:47:59 -0700 (PDT) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w73BiGBs024932 for ; Fri, 3 Aug 2018 04:47:59 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=eqCiViiJzG0/mzBGIYFhD5PFYuRGJbMMJwwvzHH4Ark=; b=Ju/aBvjlw3yPlClIEIG7OdSHJ6T803rYuxnLfev4sA5+QQ+NZRgVuT8FDK0+zuV/NKgH RT+M4ePbnpAi0pfadFCOfo+U63oI61YUhZTcx3vQpmgC0yxemw3zOVGe5TCFWbbwBo9E zoBpWLc61iPn5tb7z9dMmyqJpCOlmD6rQHCgMqUo3lqMvg8b4z1gRmNArCfvPw81GiyC yyRL2udd4o84hE6B94Yt2eYaYVKQn6Zvmf/nXNLvQ0U3G6x6cL6Zlo7Df25SJv1cI7bB H+0uCBwKUTO1tHW7UrEw+rAYT99y7iPvMJ6i4m1KQfgl0sWgeXeb7YxnPJGYRBpAoioy CQ== Received: from nam05-co1-obe.outbound.protection.outlook.com (mail-co1nam05lp0083.outbound.protection.outlook.com [216.32.181.83]) by mx0a-00273201.pphosted.com with ESMTP id 2kmk7qga7q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Fri, 03 Aug 2018 04:47:59 -0700 Received: from CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) by CO1PR05MB380.namprd05.prod.outlook.com (10.141.51.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.1017.12; Fri, 3 Aug 2018 11:47:57 +0000 Received: from CO1PR05MB443.namprd05.prod.outlook.com ([fe80::7de8:5a5d:b33e:cc4]) by CO1PR05MB443.namprd05.prod.outlook.com ([fe80::7de8:5a5d:b33e:cc4%13]) with mapi id 15.20.1017.010; Fri, 3 Aug 2018 11:47:57 +0000 From: Ron Bonica To: "v6ops@ietf.org" Thread-Topic: Weekly Review: draft-ietf-v6ops-transition-ipv4aas Thread-Index: AdQoBtUtXPFJi1UdSWq6rby/T4xfAgDGLCbg Date: Fri, 3 Aug 2018 11:47:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO1PR05MB380; 6:Ap4PQatjtGM7TsJJ8HFD2rSEktEqONNC4bH2ObcjelJBm2rqwLvoRSzRU/VfBJH1QOOeKcem90KsxbpNnD3jic/apaFLdsYNmi2TVLOAv0jrpHFp7asG+frB8Qi4ZqhsylrNAAcDjrhCvyw+TOBPv3aL0CIRMhR7TzlesiZqkPGm2lm7UUAzNH53tYxtOEM1ZfRjyQv9giHE1sWMj62onPsOKt7auKMaHHiOKxp3uqfICLcFZKcK5vG/JIpftovBH+I8AQoe4vEFcZ6HxoPWHuAwbahUULEr0JJjvgXTLBknhkP0i7MhMUqycIbtcE3oDh7KMKWVWIOCldGcj3H3EPJe21wfv5u98dc7RK1on4qGzvzF8WN5Mf/Bfjm4CUkGSdweAJ2byJYiRvoR02Vz88jlwZrAf3X8mJqH6Aw2zWtmJs+G9xCiP9QOYuH2JhyIfbqYfmUxaFxmrqqPOs6ftw==; 5:ParbyBZiRGXSZTh0l29uEsOqZGJpXKWqYyvGrCf8aaCb/1xxka5YaS2OxEFnaA961KDvx74/Hw0JfSFAUvQ/ba9L1221KD5qtEZsZW/zzJQsY1HM5gkgyrxH68SLlYbqwhhiyP+P54tacFhuKziPmhCoY/Ld00ClRjysBfdqtUs=; 7:y9MNf8j+6QLXllYIiVzVMXDtl9LH9c+3QIv4R9IwSTX3dF59lMVrz3lO6SOf/QEcVip4X2RVAJZi18c7C5nWfSbF/23rZJRa+ZFSHXaLZIJ7Pc1nTUoqwLiU1GRLIPoYdiKvyLIAgtKluJxD4DjOJcf1ZI26/gCF1gK14VpDeGjTZ/cV9sCs3bjVXC4BdHqxxMdDy0VAyXR9O6MXmn9aAa5ZXDuMAJA9Hbv/s+QRj8ATHxaOMKW1/tYB63L6TiGH x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 3124a5da-6ff9-43f5-aac6-08d5f936f4a5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600074)(711020)(4618075)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:CO1PR05MB380; x-ms-traffictypediagnostic: CO1PR05MB380: 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)(8121501046)(5005006)(3231311)(944501410)(52105095)(10201501046)(93006095)(93001095)(3002001)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:CO1PR05MB380; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB380; x-forefront-prvs: 0753EA505A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(136003)(366004)(39860400002)(376002)(346002)(9763003)(199004)(189003)(13464003)(102836004)(55016002)(105586002)(53546011)(9686003)(5640700003)(2900100001)(186003)(2351001)(2906002)(3846002)(66066001)(316002)(6506007)(26005)(106356001)(4743002)(14454004)(305945005)(478600001)(53936002)(6916009)(8676002)(5250100002)(229853002)(6436002)(476003)(81166006)(6246003)(97736004)(2501003)(5660300001)(99286004)(33656002)(25786009)(68736007)(7736002)(8936002)(7696005)(256004)(486006)(6116002)(86362001)(74316002)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB380; H:CO1PR05MB443.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: K40GnQtHRK7ij4vr1kGHL3vdjHnWYLecnTTvxhCh5GaJZojFhuaKIOdwqkRzeRj5GVKBGdjqaxTrO5RMX8jmiQwV9Wm67oRWooRXPCtNqdBcflffkPKyVMVYjXHPKQYJOZOqWm3BvEPMp+MswGVzhz98FFuAV+LsfswKw6P1KskG5lJCB3nQ/6HC5bvY5/PdujyuUET2btTYyT9S7aRhp8Js9k8a3RpHZx0rjl++qWIMnp0kSezv0fcBH1c0sRa9qNDWuHaLQH8Yrr5QAhgWQfVVb8GAUV3vZhT/7Bu7/X78E/7QyNUwJwsYCDeqTrN2p/P+9OhqFKqMDv7QJhZ/FVvKPjOWL2LHi2RhluQ0Z+A= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 3124a5da-6ff9-43f5-aac6-08d5f936f4a5 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2018 11:47:56.9903 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB380 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-03_04:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=854 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808030132 Archived-At: Subject: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 11:48:01 -0000 Folks, Thanks for many thought full comments on this draft. At this point I will ask Jordi to wait a few more days for the final commen= ts to trickle in, and then spin a new version of the draft. When a new vers= ion is available, we will initiate a WGLC. Fred and= Ron > -----Original Message----- > From: Ron Bonica > Sent: Monday, July 30, 2018 9:13 AM > To: 'v6ops@ietf.org' > Subject: Weekly Review: draft-ietf-v6ops-transition-ipv4aas >=20 > Folks, >=20 > Each week between now and IETF 103, we will review and discuss one draft > with an eye towards progressing it. >=20 > This week, please review and comment on draft-ietf-v6ops-transition- > ipv4aas. >=20 > Fred and Ron From nobody Fri Aug 3 04:55:21 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 34356130DE6 for ; Fri, 3 Aug 2018 04:55: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 4vn5gqu7PGJE for ; Fri, 3 Aug 2018 04:55: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 6A472130DDB for ; Fri, 3 Aug 2018 04:55:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1533297314; x=1533902114; 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=EYbLlNwPBo9D3ea6Thd57 Q0vmu/tDj3ZU1uqZw3boig=; b=A2VXIDvKxgdxN0Y5mpc904unCg7elUpt3VBgZ BD+OqzK+MEnD54rqx2nldGKio6umO1HEaJzIHJN+HCjOYm35SdQxd6EZWweyt9pI ANewDmOqvey+JFDM9U2woC+3E9tjbeTonrZIFMXTzS0426FYOM8j4G7JKBH7dd2J guT1Zw= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 03 Aug 2018 13:55:14 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 03 Aug 2018 13:55:14 +0200 Received: from [10.20.5.175] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005825612.msg for ; Fri, 03 Aug 2018 13:55:12 +0200 X-MDRemoteIP: 10.8.10.6 X-MDHelo: [10.20.5.175] X-MDArrival-Date: Fri, 03 Aug 2018 13:55:12 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=175342fce6=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.f.0.180709 Date: Fri, 03 Aug 2018 06:55:06 -0500 From: JORDI PALET MARTINEZ To: Ron Bonica , "v6ops@ietf.org" Message-ID: Thread-Topic: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 11:55:19 -0000 Thanks Ron. I think two people also volunteered in the meeting to review the doc. I was= waiting for inputs from them. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Ron Bonica Fecha: viernes, 3 de agosto de 2018, 6:48 Para: "v6ops@ietf.org" Asunto: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas Folks, =20 Thanks for many thought full comments on this draft. =20 At this point I will ask Jordi to wait a few more days for the final co= mments to trickle in, and then spin a new version of the draft. When a new = version is available, we will initiate a WGLC. =20 Fred= and Ron =20 > -----Original Message----- > From: Ron Bonica > Sent: Monday, July 30, 2018 9:13 AM > To: 'v6ops@ietf.org' > Subject: Weekly Review: draft-ietf-v6ops-transition-ipv4aas >=20 > Folks, >=20 > Each week between now and IETF 103, we will review and discuss one dr= aft > with an eye towards progressing it. >=20 > This week, please review and comment on draft-ietf-v6ops-transition- > ipv4aas. >=20 > Fred and Ron =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 Fri Aug 3 05:16: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 9BF8C128BAC for ; Fri, 3 Aug 2018 05:16:38 -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, 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=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 cwNoxllcNglV for ; Fri, 3 Aug 2018 05:16:35 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 66BB5127333 for ; Fri, 3 Aug 2018 05:16:35 -0700 (PDT) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w73CDo0G012969; Fri, 3 Aug 2018 05:16:30 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=CoXn6JQleaYTlSFEnBr4nTg/SVNhmTewVhGSfxCiuEM=; b=yHX3VpIAuN80mkWSlJ3yUFM9pdcpg5S06N0duEOGxxUjxHF9GcdVOEFCAoThhNvxvvYD q9+aDtCkQt5JwFN6ZzLnTtP60CrAC15WPrAKRDP53+9NVRU9Zv8W7QXmDX5u0YCQRKne m+0tr+0b83ccYkFbj8ftxdM3q75dodFO6UcE57sya/AZkYCKMqhxNx8rGwu0X1R22+wM fw1UIJiUDz3WL7CnbObrLQHQHv44JuXSC56R/ckLnI7pKGEmT1S6TGuIF3KdjLdfQq78 t/dSvPLcZQZNSwDwja9K14+CysbsvlFL0EVQSQWVN/b9h7KlLo5FXTDGnm0MW8LJDwf6 pg== Received: from nam04-sn1-obe.outbound.protection.outlook.com (mail-sn1nam04lp0085.outbound.protection.outlook.com [216.32.180.85]) by mx0b-00273201.pphosted.com with ESMTP id 2kmnu103wk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 03 Aug 2018 05:16:30 -0700 Received: from CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) by CO1PR05MB265.namprd05.prod.outlook.com (10.141.71.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1017.13; Fri, 3 Aug 2018 12:16:28 +0000 Received: from CO1PR05MB443.namprd05.prod.outlook.com ([fe80::7de8:5a5d:b33e:cc4]) by CO1PR05MB443.namprd05.prod.outlook.com ([fe80::7de8:5a5d:b33e:cc4%13]) with mapi id 15.20.1017.010; Fri, 3 Aug 2018 12:16:28 +0000 From: Ron Bonica To: JORDI PALET MARTINEZ , "v6ops@ietf.org" Thread-Topic: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas Thread-Index: AQHUKyDcrbXeRHUWrUWYf8OnzY9VVKSt8RMw Date: Fri, 3 Aug 2018 12:16:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO1PR05MB265; 6:s2IiSOYtgXugihlqkh8VbMLPJza42yiXE7XqLnGLyKuca5MwHTG1YsXrQwf6gmf47ZIXnOZ54heOLO3IoN8R+7UH7+MiRpTCDLoA8KCwjHVU/J+tDROh/wErJI5yKcsuqgCvi/9bhGrleVAbRO9rtK407tiXZEV1CQ1bPEBPDpIw0CtsLnQ6FDsubS1ko2gkQrsrZCSMYsbxXHBSV8Zl0Mv4uEqo5IZvtUamgoNW2v6gLAShoc8aLG6McCF0z35s/1oCffWVhageaVCsXhLgXbMwKm9+nEeOSk60R+wSCR3/jbrQjtTmUUoKIF0s/Wf9AA1Va6Iu6qekQDN34BOlNg03s8uEBvo23zhAbMKDj53cq/04LxvafvgdTUIwX7LEeNTpeEdI9wqHjkqm5c4YoeSk2Apm9fIhboQYfZmF3CRkUruABCRaQPBojOeKNQg82rlFc21d7KZVqu08Safr8A==; 5:tO/qA5BORQi2CN7+bHgcnf+VqOnmZ9fvq8HnVm5T2KkSxD5Pm8CqHivuKl1itnHnkFXZIcdqmq928qngTTpW33OMBRNd6BUEscey5IJkbqab6Ijopv2uM+EL3ROJp0/W8hssSHGuwb/PoYCdGOnhekY8DCA4RNVIxAphY50Qgv0=; 7:DX21JgWQ/7i7jqesagZI1TZv0pj6YOLgvAwOnPE7OttjiivGfGEzC6IPKiUeY/++IwOlG5rhu64Fw5jUtdeogWAkHkJmUGxKq/sowrDeII4u9f3k11uapALNgDh3/3mlBPKzrMQf/LU8duMb6sUlGG0WFwXNCOXsQkjRDtExAZfWZ9KBO4FfC8+C9+kenf97sd6EIunsMR6JF+CfjdV3fLiL5xhImJk7rscQISS4TdBg6yCvSuSg9uRQydAL//4i x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 5258548e-502a-4a46-1545-08d5f93af0b7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:CO1PR05MB265; x-ms-traffictypediagnostic: CO1PR05MB265: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(138986009662008)(223705240517415); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231311)(944501410)(52105095)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:CO1PR05MB265; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB265; x-forefront-prvs: 0753EA505A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(136003)(346002)(376002)(366004)(396003)(9763003)(13464003)(199004)(189003)(59124004)(9686003)(2501003)(5250100002)(74316002)(966005)(76176011)(2900100001)(5024004)(106356001)(105586002)(478600001)(14444005)(575784001)(476003)(102836004)(486006)(86362001)(26005)(305945005)(256004)(99286004)(7736002)(316002)(7696005)(6506007)(53936002)(186003)(6306002)(110136005)(53546011)(11346002)(6246003)(68736007)(97736004)(446003)(6116002)(5660300001)(81166006)(14454004)(2906002)(19627235002)(55016002)(66066001)(6436002)(8676002)(229853002)(8936002)(33656002)(3846002)(81156014)(25786009)(45954006); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB265; H:CO1PR05MB443.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: z7B9MGAwPda62AEEbZxiMg1pPNVYeUXp7quzuGybNvyv7pq5KOzuSN5Fd9NMGDGm/L8BZT41zYcmlDBGDMtNsWqo8w5KCsUqHrBgHwjnHeMu8yXQD6IJ7cIrgJDpDeYq8foDUEGy5ZybS2+IiRCYF4ORklIIfCbM5twGyGpA3mFz1DOENxXivib8OhZ4mQ5Uo1/LKWEJyDstM/8I7VyUf/gCsXMeRUjxhSnbtG8bl784pW22YVyHWuEbJwUxR9IvYvvV6no6jPQSnjoKUAHPDuXyRvHc1FxniJJvKLX7DJo1G894nWh0F9bYsQqRmQIQCpDXHqVk9EC47kw1CNOGkZ0G2Lc2DCDRTJHiN9/JFgE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 5258548e-502a-4a46-1545-08d5f93af0b7 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2018 12:16:28.3805 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB265 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-03_04:, , 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-1807170000 definitions=main-1808030136 Archived-At: Subject: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 12:16:38 -0000 Sm9yZGksDQoNClRoZSBtaW51dGVzIGRvbid0IHJlZmxlY3Qgd2hvIHRob3NlIHBlb3BsZSB3ZXJl LiBCdXQgSSBiZWxpZXZlIHRoYXQgd2UgaGFkIG1vcmUgdGhhbiB0d28gcmV2aWV3cyBsYXN0IHdl ZWssIHNvIHdlIGNhbiBwcm9iYWJseSBnbyBhaGVhZCB3aXRoIG5ldyByZXZpc2lvbiBhbmQgV0dM Qy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uDQoNCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKT1JESSBQQUxFVCBNQVJUSU5F WiA8am9yZGkucGFsZXRAY29uc3VsaW50ZWwuZXM+DQo+IFNlbnQ6IEZyaWRheSwgQXVndXN0IDMs IDIwMTggNzo1NSBBTQ0KPiBUbzogUm9uIEJvbmljYSA8cmJvbmljYUBqdW5pcGVyLm5ldD47IHY2 b3BzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIFdlZWtseSBSZXZpZXc6IGRyYWZ0 LWlldGYtdjZvcHMtdHJhbnNpdGlvbi1pcHY0YWFzDQo+IA0KPiBUaGFua3MgUm9uLg0KPiANCj4g DQo+IA0KPiBJIHRoaW5rIHR3byBwZW9wbGUgYWxzbyB2b2x1bnRlZXJlZCBpbiB0aGUgbWVldGlu ZyB0byByZXZpZXcgdGhlIGRvYy4gSSB3YXMNCj4gd2FpdGluZyBmb3IgaW5wdXRzIGZyb20gdGhl bS4NCj4gDQo+IA0KPiANCj4gUmVnYXJkcywNCj4gDQo+IEpvcmRpDQo+IA0KPiANCj4gDQo+IA0K PiANCj4gDQo+IA0KPiDvu78tLS0tLU1lbnNhamUgb3JpZ2luYWwtLS0tLQ0KPiANCj4gRGU6IHY2 b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnPiBlbiBub21icmUgZGUgUm9uIEJvbmljYQ0KPiA8 cmJvbmljYUBqdW5pcGVyLm5ldD4NCj4gDQo+IEZlY2hhOiB2aWVybmVzLCAzIGRlIGFnb3N0byBk ZSAyMDE4LCA2OjQ4DQo+IA0KPiBQYXJhOiAidjZvcHNAaWV0Zi5vcmciIDx2Nm9wc0BpZXRmLm9y Zz4NCj4gDQo+IEFzdW50bzogUmU6IFt2Nm9wc10gV2Vla2x5IFJldmlldzogZHJhZnQtaWV0Zi12 Nm9wcy10cmFuc2l0aW9uLWlwdjRhYXMNCj4gDQo+IA0KPiANCj4gICAgIEZvbGtzLA0KPiANCj4g DQo+IA0KPiAgICAgVGhhbmtzIGZvciBtYW55IHRob3VnaHQgZnVsbCBjb21tZW50cyBvbiB0aGlz IGRyYWZ0Lg0KPiANCj4gDQo+IA0KPiAgICAgQXQgdGhpcyBwb2ludCBJIHdpbGwgYXNrIEpvcmRp IHRvIHdhaXQgYSBmZXcgbW9yZSBkYXlzIGZvciB0aGUgZmluYWwgY29tbWVudHMNCj4gdG8gdHJp Y2tsZSBpbiwgYW5kIHRoZW4gc3BpbiBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4gV2hlbiBh IG5ldyB2ZXJzaW9uIGlzDQo+IGF2YWlsYWJsZSwgd2Ugd2lsbCBpbml0aWF0ZSBhIFdHTEMuDQo+ IA0KPiANCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgRnJlZCBhbmQgUm9uDQo+IA0KPiANCj4gDQo+ICAg ICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IA0KPiAgICAgPiBGcm9tOiBSb24gQm9u aWNhDQo+IA0KPiAgICAgPiBTZW50OiBNb25kYXksIEp1bHkgMzAsIDIwMTggOToxMyBBTQ0KPiAN Cj4gICAgID4gVG86ICd2Nm9wc0BpZXRmLm9yZycgPHY2b3BzQGlldGYub3JnPg0KPiANCj4gICAg ID4gU3ViamVjdDogV2Vla2x5IFJldmlldzogZHJhZnQtaWV0Zi12Nm9wcy10cmFuc2l0aW9uLWlw djRhYXMNCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiBGb2xrcywNCj4gDQo+ICAgICA+DQo+IA0K PiAgICAgPiBFYWNoIHdlZWsgYmV0d2VlbiBub3cgYW5kIElFVEYgMTAzLCB3ZSB3aWxsIHJldmll dyBhbmQgZGlzY3VzcyBvbmUNCj4gZHJhZnQNCj4gDQo+ICAgICA+IHdpdGggYW4gZXllIHRvd2Fy ZHMgcHJvZ3Jlc3NpbmcgaXQuDQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gVGhpcyB3ZWVrLCBw bGVhc2UgcmV2aWV3IGFuZCBjb21tZW50IG9uIGRyYWZ0LWlldGYtdjZvcHMtdHJhbnNpdGlvbi0N Cj4gDQo+ICAgICA+IGlwdjRhYXMuDQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRnJlZCBhbmQgUm9uDQo+IA0K PiANCj4gDQo+ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiANCj4gICAgIHY2b3BzIG1haWxpbmcgbGlzdA0KPiANCj4gICAgIHY2b3BzQGlldGYu b3JnDQo+IA0KPiAgICAgaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHBzLQ0KPiAzQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fdjZvcHMmZD1Ed0lG YVEmYz1IQWtZdWg2M3JzdWhyNg0KPiBTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPUZj aDlGUTgyc2lyLUJvTHg4NGhLdUt3bC0NCj4gQVdGMkVmcEhjQXdyRFRoS1A4Jm09amtkU05FTTdL Q295WXFud0VTRHJoM2ZPUGFpeTlaTUVOY1FOWEYNCj4gZ0ZwNncmcz03aVhxRWJBU1N4SFFOdU5Z eERlT1A5ODljcWY5TFZPQ2pqNnJMd0lCVFNBJmU9DQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+ ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4gSVB2NCBp cyBvdmVyDQo+IEFyZSB5b3UgcmVhZHkgZm9yIHRoZSBuZXcgSW50ZXJuZXQgPw0KPiBodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0NCj4gM0FfX3d3dy5jb25z dWxpbnRlbC5lcyZkPUR3SUZhUSZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy0NCj4gbmRi M3ZvRFRYY1d6b0NJJnI9RmNoOUZRODJzaXItQm9MeDg0aEt1S3dsLQ0KPiBBV0YyRWZwSGNBd3JE VGhLUDgmbT1qa2RTTkVNN0tDb3lZcW53RVNEcmgzZk9QYWl5OVpNRU5jUU5YRg0KPiBnRnA2dyZz PWJhUnVRcGdTTW95QTlvQWJucTc1eHNNTkE5UWYyS2JoeFZmUzdxV1gyZUEmZT0NCj4gVGhlIElQ djYgQ29tcGFueQ0KPiANCj4gVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2UgY29udGFpbnMgaW5mb3Jt YXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3INCj4gY29uZmlkZW50aWFsLiBUaGUgaW5m b3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZQ0K PiBpbmRpdmlkdWFsKHMpIG5hbWVkIGFib3ZlIGFuZCBmdXJ0aGVyIG5vbi1leHBsaWNpbHR5IGF1 dGhvcml6ZWQgZGlzY2xvc3VyZSwNCj4gY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0 aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgZXZlbiBpZg0KPiBwYXJ0aWFsbHksIGlu Y2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgd2lsbCBi ZSBjb25zaWRlcmVkIGENCj4gY3JpbWluYWwgb2ZmZW5zZS4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCBiZSBhd2FyZSB0aGF0IGFueQ0KPiBkaXNjbG9zdXJlLCBjb3B5aW5n LCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9u LA0KPiBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJp Y3RseSBwcm9oaWJpdGVkLCB3aWxsIGJlDQo+IGNvbnNpZGVyZWQgYSBjcmltaW5hbCBvZmZlbnNl LCBzbyB5b3UgbXVzdCByZXBseSB0byB0aGUgb3JpZ2luYWwgc2VuZGVyIHRvDQo+IGluZm9ybSBh Ym91dCB0aGlzIGNvbW11bmljYXRpb24gYW5kIGRlbGV0ZSBpdC4NCj4gDQo+IA0KDQo= From nobody Fri Aug 3 14:24: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 9AC691310E7; Fri, 3 Aug 2018 14:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=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 EsqBZOG3PTzF; Fri, 3 Aug 2018 14:24:20 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 EC120130DFE; Fri, 3 Aug 2018 14:24:19 -0700 (PDT) Received: from [10.0.1.95] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w73LOGAQ009042 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 3 Aug 2018 16:24:17 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.95] From: Ben Campbell Message-Id: <2ED81238-C631-46CA-BD73-F48C1A267F10@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_92E84B37-7F84-4D73-BDF4-92BC051F1B25"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 3 Aug 2018 16:24:12 -0500 In-Reply-To: Cc: Russ White , draft-ietf-v6ops-conditional-ras@ietf.org, V6 Ops List , v6ops-chairs@ietf.org, The IESG To: Jen Linkova References: <153316601463.21847.9200082082622342279.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] Ben Campbell's No Objection on draft-ietf-v6ops-conditional-ras-06: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2018 21:24:22 -0000 --Apple-Mail=_92E84B37-7F84-4D73-BDF4-92BC051F1B25 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii That is easier to understand, thanks! Ben. > On Aug 1, 2018, at 9:51 PM, Jen Linkova wrote: > > Hi Ben, > >> I share the confusion about the relationship to >> ietf-rtgwg-enterprise-pa-multihoming in the abstract. > > Is the updated abstract > (https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-06) > still confusing? > > -- > SY, Jen Linkova aka Furry > --Apple-Mail=_92E84B37-7F84-4D73-BDF4-92BC051F1B25 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----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAltkx/wACgkQgFZKbJXz 1A0ZQw/7Bx04xyjnKvpk48nPGELh1ByLpiGJy5DXWkkWB0c468YeazmOUsRdJZsf pjrbYnK/0ninFnd2CaoStmrQwvana4NEcUOPl0Ns0IAkCatDz53G3YKKwXO/cvLF 99mf4naPX8oyWJGdjNYdZcNHaOBQhcfK3D5JdnJoKn7YfBQHZI9kNQ4Rqt9icekx /5PuW8HwPiI7/7xDGbj6Dzav4Xfas8+NwCt0tWZBVgfIR8nJO6rAMKQRxILQBeCo LABRe976ODxHb01pt+fjvCetBEACVvKKLSxNRFgVDR45pEhfdQ1QNLXLgGB7/Lmg zqzET18Pli21zqjnBO98DAf9L1kscPf3fovIXLCVtmBU0kXd3T3+hkFXaq7KVp7T sQ+x5VlsiE98XGgjp5U4vkXg9AmkysWy9Nq0nCtEFKOfVfepjT5e29tLGKeCYnku t3MKkNbdlpPp9jCHpj55K4xZb9MfekvatijPKdUFYMdeqP05Xhu7r4DHRBXM0tkD Y+J/whhCWSTDJAsWlQPRoH89Pl4MJEHpEK871znbS54L/fIi5bL1bDn94eXMC86Z cIDdX7FT5VoGyuK1iWlETF/ejUeFVGgd0PDVT1NEJ81tDvygfs5K7dht6MyUpBVH 0nriJWeYUMHxwRQqcO/cxa+lOBGRVOrjM02dd4pKg5J04Z6xStI= =4CiV -----END PGP SIGNATURE----- --Apple-Mail=_92E84B37-7F84-4D73-BDF4-92BC051F1B25-- From nobody Mon Aug 6 06:20: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 4CD1A130E1E for ; Mon, 6 Aug 2018 06:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] 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 qa993hXsJTep for ; Mon, 6 Aug 2018 06:19:58 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 E8BDA130DFD for ; Mon, 6 Aug 2018 06:19:57 -0700 (PDT) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w76DJvaU016916 for ; Mon, 6 Aug 2018 06:19:57 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=lLQkAOOki0JF++MfrDzkE+Y+TcGFYbu0HUnSGSpvizQ=; b=Qxu38XU7BRwLPty+J/Hfz3dsbE7bUJlnVcuWEzXLp497fLeeB1NpWM39vcooghuw3SYG 7o23pkjoA5vqXz0SpUZtLWt4vUQctXiPQIKTWuLJtXscc4DOYCIm8bt5KTnxl9AaGlgO eBvk8IY2ogzwTqcHrp6ziAnbId2so8GfetLL1jDaZ8RK+v2DndqUUPcaU0okVUyMxSxt fhWAe9NduKa2OiQO597OT4QTgc7KDaGomAtpPgcKgWraNSmeo/MtP4MTbilxefToayi6 /Q2mkYCW2GzKmu+3nEGrsLls0eB+N7jp27rrmMnBTmBy9nMulAUfiqqKMkZsIEu80GwA Lw== Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0019.outbound.protection.outlook.com [216.32.180.19]) by mx0b-00273201.pphosted.com with ESMTP id 2kphbs0ka5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 06 Aug 2018 06:19:57 -0700 Received: from CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) by CO1PR05MB361.namprd05.prod.outlook.com (10.141.51.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.1038.17; Mon, 6 Aug 2018 13:19:55 +0000 Received: from CO1PR05MB443.namprd05.prod.outlook.com ([fe80::7de8:5a5d:b33e:cc4]) by CO1PR05MB443.namprd05.prod.outlook.com ([fe80::7de8:5a5d:b33e:cc4%13]) with mapi id 15.20.1038.013; Mon, 6 Aug 2018 13:19:55 +0000 From: Ron Bonica To: "v6ops@ietf.org" Thread-Topic: Weekly Review: draft-ietf-v6ops-nat64-deployment Thread-Index: AdQtiB/qSgqC9SmOR+25UTxbKfEDTw== Date: Mon, 6 Aug 2018 13:19:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO1PR05MB361; 6:gYa/TGE0lZ1JjoKQpAgRmL3PFtz5S7sCCEWp36kfSSlE7WOnRBNosta8jBm1zMXVmStnvaFL4fM/Q29FGUqjeCgitKm7fmVC34k4ntQ8F2nKHDqB+HmZEqWB85lzAAymvcc5qHLwDTxP16G3hCfs3wwHAZ47FMZISXNPZRW5GVlCDJ/C7OmQM1JT4fy0B7hDX9KbvqSHs+gvwkjx0WtI/OHjRjMVlOTj7fxNqV9G34OoyAdmhyKcVvLO+nSp6bQLOovbnNCbKCBhZbwcSTSrbmo5l3AU4JBWaNzP9JEs/92abmdsGTGhO3j8u+29IauYLy7GD6bPwd/9ih/8LmmOAsp8iVRu0PshQJ+/Inh2U+yNyoICTtQoWnCEZiq+nHyKVrhtI6JSlAEXSOuoC9L+PO6afEyu/UW472L8tAN/jK/r2ouzNizfIxK5O2UAQvenkpnNeKSFu8xPburzBU6Npw==; 5:6xpKqYh7y3AieOwEAvFOM5Vsp7tBha4RioOQ1zIGZxFvKTN4vVVX7ztdG0gvl05akwyp8FlwarzI4j6S8JNz3zwTUOjpln6MCxsYhJhG30MuC1Nfng490umtLa13c35pW4/i/Qywx7CGJYavUncPnm8k9aFb51iaauSCukpKU1w=; 7:4RsWMv14gE30lKgCL0Zx4cGuoR2lLJq47FYXWxYendTa2IiXaTakX1h22KXN5RAXPqeTIU5jvxWwXw7plGT60zb23sL5oAdXLjiS/U6ZAlyW2/ES8mmcnWwvzs0snFwaKBlmegmu8slpyIZlUMzMK+bKtaCghtSjBrlok/G3hmNdBGsjwoFB9ErG2X+fxTtaX3x+GIFxshLWEQA2EJgDBMmbP33AFXuE/wcbs7TFenHjHAe/g5D5Jasv/jc5ra6M x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: c16a3e8b-bbd5-424e-a3de-08d5fb9f4ce3 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:CO1PR05MB361; x-ms-traffictypediagnostic: CO1PR05MB361: 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)(93006095)(93001095)(3002001)(10201501046)(3231311)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:CO1PR05MB361; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB361; x-forefront-prvs: 07562C22DA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39860400002)(366004)(136003)(396003)(9763003)(199004)(189003)(4743002)(186003)(81156014)(81166006)(66066001)(6116002)(3846002)(74316002)(558084003)(97736004)(8676002)(2501003)(5250100002)(2351001)(55016002)(256004)(6506007)(14454004)(26005)(8936002)(316002)(99286004)(7696005)(33656002)(68736007)(6916009)(7736002)(53936002)(476003)(102836004)(2900100001)(9686003)(305945005)(486006)(86362001)(5640700003)(25786009)(106356001)(2906002)(6436002)(5660300001)(105586002)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB361; H:CO1PR05MB443.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: bHASVdYWjAvcHCkDRUYk+QauqWwp6zFJpraBRlq+kJq9jjOEbTN8fXtmnsjGFDrNUJqndtxFnOBTQSlrh7Zf5JE8PIbIEL+h8BM3lfOkpRfeDHF1a8Ao07W003Ly8hp/frfEw7T5ESumq8bSyLutkZI9uz76c9J3C1S8tRnNaPTwTTi/B5t9NHimiAMgUt0GyO8qNQq3PMbwVCGoH81cWn2+1hX9yXenuQqhfNRrAYoXZDewdyWWlEkmO6VPlBRx2lzZZkpOg1qt3YXY+8ij1X/ua0BoVR7RTMDuAjSokNNSrMVPGkDCiS2paRnehj7Z2swYkZ7xpUTXJ8LDB4z8waBGf4FA6VCpAAJgrNo126M= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: c16a3e8b-bbd5-424e-a3de-08d5fb9f4ce3 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2018 13:19:54.9745 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB361 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-06_07:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=602 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808060142 Archived-At: Subject: [v6ops] Weekly Review: draft-ietf-v6ops-nat64-deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 13:20:00 -0000 Folks, Each week between now and IETF 103, we will review and discuss one draft wi= th an eye towards progressing it. This week, please review and comment on draft-ietf-v6ops-nat64-deployment. Fred and Ron From nobody Mon Aug 6 13:06:48 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 53CE9129AB8 for ; Mon, 6 Aug 2018 13:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tSRuDYZUWMiM for ; Mon, 6 Aug 2018 13:06:45 -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 9A28812426A for ; Mon, 6 Aug 2018 13:06:44 -0700 (PDT) Received: from [192.168.1.134] (host-79-121-42-161.kabelnet.hu [79.121.42.161]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id w76K6XSr004085 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 6 Aug 2018 22:06:40 +0200 (CEST) (envelope-from lencse@hit.bme.hu) X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-42-161.kabelnet.hu [79.121.42.161] claimed to be [192.168.1.134] To: v6ops@ietf.org References: From: =?UTF-8?Q?Lencse_G=c3=a1bor?= Message-ID: Date: Mon, 6 Aug 2018 22:06:28 +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: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.100.1 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.161; helo=[192.168.1.134]; 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] Weekly Review: draft-ietf-v6ops-nat64-deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 20:06:47 -0000 Dear Jordi, I have read draft-ietf-v6ops-nat64-deployment and found a few nits, usually typos. I recommend the following corrections (in the manner: "old text" --> "new text"): 1. a. "how as been configured" --> perhaps: "how it has been configured" ? 3.1.1 (below Fig. 3) "This is an scenario" --> "This is a scenario" 3.1.2 "Furthermore, as indicated in [RFC6877] (464XLAT), can be used in" --> "Furthermore, as indicated in [RFC6877], 464XLAT can be used in" 3.3. "In some cases, a "bad" idem is not necessarily" --> "In some cases, a "bad" item is not necessarily" 4.1. "they don't perform validation themselves an instead, rely" --> "they don't perform validation themselves and instead, rely" 5. "considered de simpler" --> "considered the simpler" 13.2. [DNS64-Benchm] G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theory and Practice", September 2018. --> [DNS64-Benchm] G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theory and Practice", Computer Communications, vol. 127, no. 1, pp. 61-74, September 1, 2018, DOI: 10.1016/j.comcom.2018.05.005 [Threat-DNS64] 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", September 2018. --> [Threat-DNS64] 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, August 1, 2018, DOI: 10.1016/j.cose.2018.04.012 (Now our papers are fully citable, please include the complete bibliographic data.) Best regards, Gbor P.S.: I hope to be able to contribute with NAT64 benchmarking results in about a half year. One of my PhD students has implemented an RFC 8219 compliant NAT64 tester. Now it is in a very alpha state, but I hope that we will be able to use it for comparing the performances of several NAT64 implementations during the fall semester. 8/6/2018 3:19 PM keltezssel, Ron Bonica rta: > Folks, > > Each week between now and IETF 103, we will review and discuss one draft with an eye towards progressing it. > > This week, please review and comment on draft-ietf-v6ops-nat64-deployment. > > Fred and Ron > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Aug 6 14:17: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 5CD6D130E58 for ; Mon, 6 Aug 2018 14:17:07 -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 jQKSDNhVX31q for ; Mon, 6 Aug 2018 14:17:06 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 17BA1130DDC for ; Mon, 6 Aug 2018 14:17:06 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id j205-v6so24797506oib.4 for ; Mon, 06 Aug 2018 14:17:06 -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=2P6XdBAoYchwW03Sx3/ahqbPB9ITtTuxDAM7V7XVriQ=; b=NQ9AYgbNuItz15S+T2SD4LrPz7ZbIT3YKxOFMFfY/AR25ZZXzO3EsUyUtdybAgOJ3D zAb5h3/+YZTWaFCaAnZK4cwtNTvHMoHk+J33AbiVc0y76eCnmdmM+GFtvhpM/mOlkbzb jBSpqyfCbCwl5xX3VztRmu7B4dpmK7i0Y52XFBAo9H1ZX5QaU+rUqfzlMLKtpNIPC8QL 9oHpppNo6eK4x1YBwiwPSIx/p1fLGKnG0u6GQVKSidOUUPWnG7cPotSGOP+/LRhR3jIO OWC3lb/WYZka1br/sz7S6wglYGROmpFPYm5m5Ko0VxH71yZbXtJDN1s2rbxRURqIvZ+K V5eg== 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=2P6XdBAoYchwW03Sx3/ahqbPB9ITtTuxDAM7V7XVriQ=; b=TarF3yXhI0oXzjcdezmCuyO5aMjj7e2QakUPMNNhu2KQuvAUGasx6N+zkFRrE+fHkt /xMs1fEt2k9hsPoKzJ2j8UuGSqOR9AyZ9VTmf+JJdbHOn454T7KWNQdIp7EHmUE5LHQJ bXxAvX5HZYWt8XhuLXENMHG48O+wEj+33c+pyqFlxBPndhzN3FE8m6crUXJxEd4ehesd Y5BSRsxKi9IJ6mQ4U8p6ICDkaf2+vARjLecHQJdPz+aYHRZnCk8MFs5SGIML8u7EnjVD H3lJzuSpPGbqWn6+IzXMR5hGEu/G2gFGJvlR0vzFKucFUPrUCThIYpIjNWeD5iRjHucw XaSw== X-Gm-Message-State: AOUpUlG7377I6wv7qkgNWR4CKBEQqcENSmJlKUdfRpXMdZfRx0FOhjSW sZU0bnud2PnF4IOo0R1iK2Y= X-Google-Smtp-Source: AAOMgpf+aseBlFt+PU/YVygaikdv9Q2zlcgnYiZ66HNMDVe9/gtajMvKaX1kI4wp1pvXmVaQIvsTXQ== X-Received: by 2002:aca:d7c2:: with SMTP id o185-v6mr17320187oig.55.1533590225419; Mon, 06 Aug 2018 14:17:05 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::1034? ([2600:8802:5600:1546::1034]) by smtp.gmail.com with ESMTPSA id t131-v6sm12812352oie.34.2018.08.06.14.17.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Aug 2018 14:17:04 -0700 (PDT) From: Fred Baker Message-Id: <8D16231E-46DC-439C-9E3B-27D8169769B2@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_27A3E153-F0A3-4BD6-B673-D3BCBA40F4C0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 6 Aug 2018 14:17:02 -0700 In-Reply-To: Cc: v6ops@ietf.org To: =?utf-8?Q?Lencse_G=C3=A1bor?= References: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] Weekly Review: draft-ietf-v6ops-nat64-deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2018 21:17:07 -0000 --Apple-Mail=_27A3E153-F0A3-4BD6-B673-D3BCBA40F4C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 6, 2018, at 1:06 PM, Lencse G=C3=A1bor = wrote: >=20 > P.S.: I hope to be able to contribute with NAT64 benchmarking results = in about a half year. One of my PhD students has implemented an RFC 8219 = compliant NAT64 tester. Now it is in a very alpha state, but I hope that = we will be able to use it for comparing the performances of several = NAT64 implementations during the fall semester. We'll be interested in its results whenever they come. First choice = would be "before IETF 103", and the next would be "before IETF 104". = --------------------------------------------------------------------------= ------ The fact that there is a highway to hell and a stairway to heaven is an = interesting comment on projected traffic volume... --Apple-Mail=_27A3E153-F0A3-4BD6-B673-D3BCBA40F4C0 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+AFAltous4ACgkQEhdRnd2G P+BYExAAkvEYrLqwKxGhsOhtw9T+ZFjbBtcbEf/0vzM063ErA7NdASj/sXEhkZvC L14LSHSoO+qaHULH0b2Cgnd/AGoOY0NTs+pyHnaYytSRZP6jJfGH5ixC3jM8j4A4 cwQaZ1Gq1cOBGODtbPlDfkz4jwOP2WYOhNAt/D/DAQl8wqhbehotOsJ8rWs4IaHJ uO41KR2ddhJ9AbUi4YU/bwap2795lSAq0OLACyrdClz/WvTBWUK/Fmo4GmKysfqo 03nywwletJf3fnywPSraF4h4OPY7cqO06IqcnLE4PJYhu4H56FeKxaXbZUC70bnm Jbt3OBhFY+SVy+bmnXdCeJ+AS6PZ9JTgWkuNj4LgBbg1nKj5Ck9xyRgeleJTmFnR qsy97+wMkWoZsY58DnJSuoKbyXuXurOG3mMWxe4b8vGxQJjIOmHbmZgF8fiobA3n 8Kz3R/qHrPLcCDQNJBuahRPw2z0Nxummwj2FPVfWQddnGrML/Q8IrXgVwfBgxL2H iTe8g4vZGr1jdYSj4lFF+IlbqgpOYB7UNeClsgJvdH2VV5YDXYwdkHsyv8D+si88 KHvtHYny9zgSgiG1uUQLoVU9OYQYjF2EQDFeioinz4FM5NNHEYpn1lnsdqBtEgRG vsUOdFJjUPbRcFInPn5Kb0A3DYKBQBjXSqORmVHCTud2Iy+nmFE= =liGt -----END PGP SIGNATURE----- --Apple-Mail=_27A3E153-F0A3-4BD6-B673-D3BCBA40F4C0-- From nobody Thu Aug 9 08:03:35 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 A0909130DE0 for ; Thu, 9 Aug 2018 08:03:32 -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 yo-zitPfYzjk for ; Thu, 9 Aug 2018 08:03:30 -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 6D925130DD5 for ; Thu, 9 Aug 2018 08:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1533827007; x=1534431807; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=qaVmMbA7stJeW42+OkEIvHGIagmUWoH3Bd4tqo/uiTk=; b=jHc3M0cuPmyDs M0Cq46QhhdnBeVeoFPwCHQlfJXeayH4+PhE6gFS7SYpFqlLrR8Di8i7hwm0qqtrl aZwRCo+rMO++K8nOtpR1D9pP/1bIleYxubTMJIv3xalc3iI0FsDQx8GwVccIRX6S nj9txyH/6krem8yZPqV30U2gJmFwuA= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 09 Aug 2018 17:03:27 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 09 Aug 2018 17:03:26 +0200 Received: from [10.20.5.175] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005834694.msg for ; Thu, 09 Aug 2018 17:03:25 +0200 X-MDRemoteIP: 10.8.10.6 X-MDHelo: [10.20.5.175] X-MDArrival-Date: Thu, 09 Aug 2018 17:03:25 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17593b5162=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.f.0.180709 Date: Thu, 09 Aug 2018 10:03:16 -0500 From: JORDI PALET MARTINEZ To: Richard Patterson , CC: "v6ops@ietf.org list" Message-ID: <19402025-57D9-4F6A-99FE-8563CAD41CE9@consulintel.es> Thread-Topic: [v6ops] Review of draft-ietf-v6ops-transition-ipv4aas-05 References: <787AE7BB302AE849A7480A190F8B93302DF66859@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DF66983@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2D09D61DDFA73D4C884805CC7865E6114DE43A3D@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DE4D923@GAALPA1MSGUSRBF.ITServices.sbc.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] Review of draft-ietf-v6ops-transition-ipv4aas-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 15:03:33 -0000 Hi Richard, Barbara, Thanks and sorry, I'm late reacting to this, working in a new version durin= g the weekend, following Ron advise, in order to go for a last-call. Let me try to summarize what you are saying with a proposed text (basic ide= a, remove superfluous text and only state what may be not obvious for an im= plementor, that already must know about UPnP and has read the rest of the d= ocument ...). Let me know if I missed anything: Actual text: 5. UPnP Support UPnP SHOULD be disabled by DEFAULT on the IPv6 Transition CE Router when using an IPv4aaS transition mechanism. UPnP MAY be enabled when an IPv6 Transition CE Router is configured to use a stateless mechanism that allows unsolicited inbound packets through to the CE, such as MAP or lw4o6, or when configured with a port set containing all 65535 ports, e.g., with an IPv4 address sharing ratio of 1. If UPnP is enabled on an IPv6 Transition CE Router, the UPnP agent MUST reject any port mapping requests for port numbers outside of the port set allocated to the IPv6 Transition CE Router. UPnP SHOULD also be enabled on an IPv6 Transition CE Router configured for IPv4aaS mechanisms that support PCP [RFC6887], if implemented in conjunction with a method to control the external port mapping, such as IGD-PCP IWF [RFC6970]. An IPv6 Transition CE Router that implements a UPnP agent, SHOULD support the Open Connectivity Foundation's IGD:2 specification, including the AddAnyPortMapping() function. New text: 5. UPnP Support If the [UPnP WANIPConnection:2] service is enabled on a CE router,=20 but cannot be associated with an IPv4 interface established by an=20 IPv4aas mechanism or cannot interwork with PCP or a configured=20 port set, an AddPortMapping() or AddAnyPortMapping() action=20 MUST be rejected with error code 729 "ConflictWithOtherMechanisms".=20 Note that IGD:1 and its WANIPConnection:1 service have been=20 deprecated by OCF. Then, new informative reference for [UPnP WANIPConnection:2] http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v= 2-Service.pdf Is that right? Regads, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Richard Patterson Fecha: martes, 24 de julio de 2018, 5:08 Para: CC: "v6ops@ietf.org list" Asunto: Re: [v6ops] Review of draft-ietf-v6ops-transition-ipv4aas-05 Hi Barbara, =20 On Mon, 23 Jul 2018 at 18:09, STARK, BARBARA H wrote: > > I think the proposed text is confusing and self-contradictory, needs = to be more precise in language used around UPnP capabilities, and isn't the= correct recommendation. Inline indication of where I see these problems, a= nd proposed text at the bottom. =20 Fair enough, I won't then try to justify any of my proposed text, but rather focus on your recommended text instead. I will say that the conflict/confusion was probably because it was intended to be read linearly as: "By default reject, unless......." =20 =20 > Here is what I would recommend: > > If the [UPnP WANIPConnection:2] service is enabled on a CE router, bu= t cannot be associated with an IPv4 interface established by an IPv4aas mec= hanism or cannot interwork with PCP or a configured port set, an AddPortMap= ping() or AddAnyPortMapping() action MUST be rejected with error code 729 "= ConflictWithOtherMechanisms". Note that IGD:1 and its WANIPConnection:1 ser= vice have been deprecated by OCF. > > I think that's all that needs to be said. Any properly interworked WA= NIPConnection:2 service can be expected to behave properly according to UPn= P specs. > Then add informative reference to [UPnP WANIPConnection:2] that point= s to http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf. =20 =20 "interwork with [...] a configured port set" is too vague for my liking. It's not clear that this means it should reject AddPortMapping() requests for a port outside of the port set, or provide an alternative port when requested with AddAnyPortMapping(). I'd like to see this elaborated a bit more on. =20 Whilst IGD:1 is deprecated, it is what's out there so we need to make sure to capture the AddPortMapping() behaviour correctly. Even when newer CPEs start supporting IGD:2 (most are still dragging their heals IME), it requires applications to also alter their behaviour to make use of the new AddAnyPortMapping() function. =20 I do agree that the more concise wording is better, and that sections of the previously suggested wording were superfluous when read in context with the rest of the document. Apologies for that. =20 -Richard =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 Aug 9 08:39:35 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 CE5E1130E3F for ; Thu, 9 Aug 2018 08:39:32 -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 0VkjNmOFWwji for ; Thu, 9 Aug 2018 08:39:28 -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 4B879130E6A for ; Thu, 9 Aug 2018 08:39:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1533829166; x=1534433966; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:Mime-version: Content-type:Content-transfer-encoding; bh=fNtWUct1s0dYKEG9HX9Om y0iShYJ+KhGup7QrA6ilx0=; b=pHL00RcgpikEtyzpqIrsVj1s2TO/sMpM1YvHE e/hqxrPXGFiL4iMg2BrU2zhKGEszd2MHX2xz3Q5FC1JrU+z80LWf23O1frcY/oRN x7D6g1CpIYtxz3I1LoTELpIZDOnsfG5Cz9DVpPHvGBJXhHNWDGI1TaSx/cK3yPwo mgSPfQ= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 09 Aug 2018 17:39:26 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 09 Aug 2018 17:39:26 +0200 Received: from [10.20.5.175] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005834711.msg for ; Thu, 09 Aug 2018 17:39:25 +0200 X-MDRemoteIP: 10.8.10.6 X-MDHelo: [10.20.5.175] X-MDArrival-Date: Thu, 09 Aug 2018 17:39:25 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17593b5162=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.f.0.180709 Date: Thu, 09 Aug 2018 10:39:13 -0500 From: JORDI PALET MARTINEZ To: Alejandro D'Egidio CC: Ron Bonica , "v6ops@ietf.org list" Message-ID: Thread-Topic: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 15:39:34 -0000 Hi Alejandro, I think this may sort out your requirement: TRANS-6: The IPv6 Transition CE Router MAY have multiple IPv4 prefixes to be used in different customer-facing interfaces, and the IPv6 Transition CE Router MUST support multiple instances of the relevant transition mechanism code, to allow configuring them. Do you agree? Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: Alejandro D'Egidio Fecha: martes, 31 de julio de 2018, 15:55 Para: JORDI PALET MARTINEZ CC: Ron Bonica , "v6ops@ietf.org list" Asunto: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas Hello Jordi, My notes in lines. =20 Regards, Alejandro =20 ----- Mensaje original ----- > De: "JORDI PALET MARTINEZ" > Para: "Alejandro Degidio" , "Ron Bonica" = > CC: "v6ops@ietf.org list" > Enviados: Lunes, 30 de Julio 2018 20:58:52 > Asunto: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aa= s =20 > Hi Alejandro, >=20 >=20 >=20 > Thanks for the input! >=20 >=20 >=20 > I think it is easy to understand: >=20 > "This document covers a set of IP transition techniques required when >=20 > ISPs have an IPv6-only access network." >=20 >=20 >=20 > even if the ISP already have an IPv6-only access network, or want to = have it. >=20 >=20 >=20 > But this may be something that a native English speaker could tell us= how better > to say it. May be: >=20 > "This document covers a set of IP transition techniques required when >=20 > ISPs have or want to move to an IPv6-only access network." >=20 >=20 Yes, it's great. =20 >=20 > I'd some text in earlier versions about the reasons to have an IPv6-o= nly access > network, but it was suggested to move it to the Annex A ... not sure = if you > read them also. I'm happy to add some more text, if needed to the ann= ex A to > describe several possible reasons. >=20 =20 Yes, I've read all the document included the Annexes. =20 =20 >=20 >=20 > The case for having multiple IPv4 subnets (one for each interface), i= s feasible, > as you say, by having multiple instances of the NAT46, which I think = is not a > problem. >=20 >=20 >=20 > However, open question is valid also for any other IPv4aaS mechanism. >=20 >=20 >=20 > I'm not sure if we want to have that case considered as something tha= t MUST be > supported as one more requirement, and if this is the case, it will b= e a > "general" transition requirement, and no need to go in the details fo= r each > transition mechanism, or we really want to go to describe a specific = new > requirement for this for each transition mechanism ... >=20 =20 Just knowing that a CPE can have different LAN IPv4 prefixes I was thin= king that maybe it could be considered in General transition requirements w= ith something like: =20 "TRANS-6: The IPv6 Transition CE Router MAY have different IPv4 prefixe= s on each Customer-Facing interfaces and the transition mechanisms MUST hav= e options to be compatible with it." =20 =20 >=20 >=20 > What others think? >=20 >=20 >=20 > Regards, >=20 > Jordi >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=EF=BB=BF-----Mensaje original----- >=20 > De: v6ops en nombre de Alejandro D'Egidio > >=20 > Fecha: lunes, 30 de julio de 2018, 10:39 >=20 > Para: Ron Bonica >=20 > CC: "v6ops@ietf.org list" >=20 > Asunto: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aa= s >=20 >=20 >=20 > Hello Ron, >=20 > I really like this draft! >=20 > Just a simple comment. >=20 > Where says: >=20 > This document covers a set of IP transition techniques required wh= en >=20 > ISPs have an IPv6-only access network. >=20 > =20 >=20 > Maybe could say: >=20 > This document covers a set of IP transition techniques required wh= en >=20 > ISPs wants to have an IPv6-only access network. >=20 > =20 >=20 > Maybe you can include some example of why ISPs wants to have an IP= v6 only access > network. >=20 > For example, in my case, as we don't have more public IPv4 address= es and we have > IPv6 developed, why should I need to continue managing IPv4 addres= ses? >=20 > Maybe some kind of this scenario could be included. >=20 > =20 >=20 > Regarding 3.2.1. 464XLAT: >=20 > Cablelabs defines that the CableModem must subnet the IPv6 Prefix = received from > ISP to use different subnets on each LAN Interface. The size of IP= v6 "sub" > prefix on each LAN depends on is ISP configured the CM to use eith= er favor > depth or favor width. If ISP provides just a /64 IPv6 prefix (whic= h is not > recommended) CM must share it with all LAN interfaces. >=20 > =20 >=20 > For IPv4, by the same private IPv4 prefix is shared between all LA= N interfaces > (customer-facing interfaces). For this case I think it "3.2.1. 46= 4XLAT" is ok. >=20 > There are some cases where CM could have different private IPv4 pr= efixes to each > customer-facing interfaces. So I think, this is another scenario t= hat should be > covered where CLAT will need to work with all the IPv4 LAN prefixe= s. Maybe > running multiple instances of its NAT46 (one for each LAN interfac= e) or one > instance supporting multiple IPv4 addresses. >=20 > =20 >=20 > All this is in: > https://apps.cablelabs.com/specification/ipv4-and-ipv6-erouter-spe= cification/ >=20 > =20 >=20 > =20 >=20 > =20 >=20 > Regards, >=20 > ALEJANDRO D'EGIDIO >=20 > Jefe de Ingenier=C3=ADa de Backbone | Direcci=C3=B3n de Ingenier= =C3=ADa >=20 > M: [ callto:+54 911 5794-1589 | +54 911 5794-1589 ] | F: [ callto:= +54 11 > 3977-1025 | +54 11 3977-1025 ] | [ mailto:adegidio@telecentro.net.= ar | > adegidio@telecentro.net.ar ] >=20 > Pje. Lavard=C3=A9n 157. Piso 3. CABA (C1437FBC) >=20 > =20 >=20 > ----- Mensaje original ----- >=20 > De: "Ron Bonica" >=20 > Para: "v6ops@ietf.org list" >=20 > Enviados: Lunes, 30 de Julio 2018 10:12:50 >=20 > Asunto: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas >=20 > =20 >=20 > Folks, >=20 > =20 >=20 > Each week between now and IETF 103, we will review and discuss one= draft with an > eye towards progressing it. >=20 > =20 >=20 > This week, please review and comment on draft-ietf-v6ops-transitio= n-ipv4aas. >=20 > =20 >=20 > Fred and Ron >=20 > =20 >=20 > _______________________________________________ >=20 > v6ops mailing list >=20 > v6ops@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/v6ops >=20 > =20 >=20 > _______________________________________________ >=20 > v6ops mailing list >=20 > v6ops@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/v6ops >=20 > =20 >=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 the > individual(s) named above and further non-explicilty authorized discl= osure, > copying, distribution or use of the contents of this information, eve= n 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. =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 Aug 9 11: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 E862E130E95 for ; Thu, 9 Aug 2018 11:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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=telecentro.net.ar 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 wUWZjAdTalGN for ; Thu, 9 Aug 2018 11:07:18 -0700 (PDT) Received: from mail.telecentro.net.ar (mail.telecentro.net.ar [190.55.63.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D6CE130E8E for ; Thu, 9 Aug 2018 11:07:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 16100320209F; Thu, 9 Aug 2018 15:07:16 -0300 (-03) Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id d2Q1CGh8HjIf; Thu, 9 Aug 2018 15:07:15 -0300 (-03) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 27693320209A; Thu, 9 Aug 2018 15:07:15 -0300 (-03) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.telecentro.net.ar 27693320209A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecentro.net.ar; s=25118654-7AE4-11E8-AD98-8D0B0E6845CD; t=1533838035; bh=76vmhBV3AwiTTvzDTDSqgGShhtBjhY2QcVHMjcC47wA=; h=Date:From:To:Message-ID:MIME-Version; b=dsjQEgmNow7kXKxfLWIsDLncFnHzwNBedniF4+oDbX+SiuUhQUyK1amrX5GDjklIc XoNnqhRAS7MaIoQX6Fw3P3qF0NgxtGRdN7IlOxuFbpnVCDaPU5nYrAu49ELKjzSNOP yVLB5EWbbfSlYaB5g/wPJIVL85ksV/ECQXxxfzjAgkUnJdjoffczaAvMWhlNDSaqJX MRCBehZcCA7uHaok9mnMQjaHYBbQKsmnpKOE2z4/RSY2P8+K1/0ikiG21gJG47aKtx e86hUZabbuS6YmZ2gJoMhjM5aSYlhfA40KfU45tUxzUCtTmQNFROeML0CeBLGLIsDv fJawjeS40uYAQ== X-Virus-Scanned: amavisd-new at tclmail6.telecentro.local Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id EF2RwZTgiL7U; Thu, 9 Aug 2018 15:07:15 -0300 (-03) Received: from tclmail6.telecentro.local (tclmail6.telecentro.local [10.210.50.96]) by mail.telecentro.net.ar (Postfix) with ESMTP id 0A09A3202094; Thu, 9 Aug 2018 15:07:15 -0300 (-03) Date: Thu, 9 Aug 2018 15:07:14 -0300 (ART) From: Alejandro D'Egidio To: JORDI PALET MARTINEZ Cc: Ron Bonica , "v6ops@ietf.org list" Message-ID: <228072760.12181019.1533838034939.JavaMail.zimbra@telecentro.net.ar> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.210.50.96] X-Mailer: Zimbra 8.8.8_GA_3008 (ZimbraWebClient - GC68 (Win)/8.8.8_GA_1703) Thread-Topic: Weekly Review: draft-ietf-v6ops-transition-ipv4aas Thread-Index: if+Qw0qDGLHcr0WGCXoz7Spj5wGUjg== Archived-At: Subject: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 18:07:22 -0000 Hello Jordi, Yes, I agree. Thanks for considering that. Regards, Alejandro ----- Mensaje original ----- De: "JORDI PALET MARTINEZ" Para: "Alejandro Degidio" CC: "Ron Bonica" , "v6ops@ietf.org list" Enviados: Jueves, 9 de Agosto 2018 12:39:13 Asunto: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas Hi Alejandro, I think this may sort out your requirement: TRANS-6: The IPv6 Transition CE Router MAY have multiple IPv4 prefixes to be used in different customer-facing interfaces, and the IPv6 Transition CE Router MUST support multiple instances of the relevant transition mechanism code, to allow configuring them. Do you agree? Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: Alejandro D'Egidio Fecha: martes, 31 de julio de 2018, 15:55 Para: JORDI PALET MARTINEZ CC: Ron Bonica , "v6ops@ietf.org list" Asunto: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas Hello Jordi, My notes in lines. =20 Regards, Alejandro =20 ----- Mensaje original ----- > De: "JORDI PALET MARTINEZ" > Para: "Alejandro Degidio" , "Ron Bonica" = > CC: "v6ops@ietf.org list" > Enviados: Lunes, 30 de Julio 2018 20:58:52 > Asunto: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aa= s =20 > Hi Alejandro, >=20 >=20 >=20 > Thanks for the input! >=20 >=20 >=20 > I think it is easy to understand: >=20 > "This document covers a set of IP transition techniques required when >=20 > ISPs have an IPv6-only access network." >=20 >=20 >=20 > even if the ISP already have an IPv6-only access network, or want to = have it. >=20 >=20 >=20 > But this may be something that a native English speaker could tell us= how better > to say it. May be: >=20 > "This document covers a set of IP transition techniques required when >=20 > ISPs have or want to move to an IPv6-only access network." >=20 >=20 Yes, it's great. =20 >=20 > I'd some text in earlier versions about the reasons to have an IPv6-o= nly access > network, but it was suggested to move it to the Annex A ... not sure = if you > read them also. I'm happy to add some more text, if needed to the ann= ex A to > describe several possible reasons. >=20 =20 Yes, I've read all the document included the Annexes. =20 =20 >=20 >=20 > The case for having multiple IPv4 subnets (one for each interface), i= s feasible, > as you say, by having multiple instances of the NAT46, which I think = is not a > problem. >=20 >=20 >=20 > However, open question is valid also for any other IPv4aaS mechanism. >=20 >=20 >=20 > I'm not sure if we want to have that case considered as something tha= t MUST be > supported as one more requirement, and if this is the case, it will b= e a > "general" transition requirement, and no need to go in the details fo= r each > transition mechanism, or we really want to go to describe a specific = new > requirement for this for each transition mechanism ... >=20 =20 Just knowing that a CPE can have different LAN IPv4 prefixes I was thin= king that maybe it could be considered in General transition requirements w= ith something like: =20 "TRANS-6: The IPv6 Transition CE Router MAY have different IPv4 prefixe= s on each Customer-Facing interfaces and the transition mechanisms MUST hav= e options to be compatible with it." =20 =20 >=20 >=20 > What others think? >=20 >=20 >=20 > Regards, >=20 > Jordi >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=EF=BB=BF-----Mensaje original----- >=20 > De: v6ops en nombre de Alejandro D'Egidio > >=20 > Fecha: lunes, 30 de julio de 2018, 10:39 >=20 > Para: Ron Bonica >=20 > CC: "v6ops@ietf.org list" >=20 > Asunto: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aa= s >=20 >=20 >=20 > Hello Ron, >=20 > I really like this draft! >=20 > Just a simple comment. >=20 > Where says: >=20 > This document covers a set of IP transition techniques required wh= en >=20 > ISPs have an IPv6-only access network. >=20 > =20 >=20 > Maybe could say: >=20 > This document covers a set of IP transition techniques required wh= en >=20 > ISPs wants to have an IPv6-only access network. >=20 > =20 >=20 > Maybe you can include some example of why ISPs wants to have an IP= v6 only access > network. >=20 > For example, in my case, as we don't have more public IPv4 address= es and we have > IPv6 developed, why should I need to continue managing IPv4 addres= ses? >=20 > Maybe some kind of this scenario could be included. >=20 > =20 >=20 > Regarding 3.2.1. 464XLAT: >=20 > Cablelabs defines that the CableModem must subnet the IPv6 Prefix = received from > ISP to use different subnets on each LAN Interface. The size of IP= v6 "sub" > prefix on each LAN depends on is ISP configured the CM to use eith= er favor > depth or favor width. If ISP provides just a /64 IPv6 prefix (whic= h is not > recommended) CM must share it with all LAN interfaces. >=20 > =20 >=20 > For IPv4, by the same private IPv4 prefix is shared between all LA= N interfaces > (customer-facing interfaces). For this case I think it "3.2.1. 46= 4XLAT" is ok. >=20 > There are some cases where CM could have different private IPv4 pr= efixes to each > customer-facing interfaces. So I think, this is another scenario t= hat should be > covered where CLAT will need to work with all the IPv4 LAN prefixe= s. Maybe > running multiple instances of its NAT46 (one for each LAN interfac= e) or one > instance supporting multiple IPv4 addresses. >=20 > =20 >=20 > All this is in: > https://apps.cablelabs.com/specification/ipv4-and-ipv6-erouter-spe= cification/ >=20 > =20 >=20 > =20 >=20 > =20 >=20 > Regards, >=20 > ALEJANDRO D'EGIDIO >=20 > Jefe de Ingenier=C3=ADa de Backbone | Direcci=C3=B3n de Ingenier= =C3=ADa >=20 > M: [ callto:+54 911 5794-1589 | +54 911 5794-1589 ] | F: [ callto:= +54 11 > 3977-1025 | +54 11 3977-1025 ] | [ mailto:adegidio@telecentro.net.= ar | > adegidio@telecentro.net.ar ] >=20 > Pje. Lavard=C3=A9n 157. Piso 3. CABA (C1437FBC) >=20 > =20 >=20 > ----- Mensaje original ----- >=20 > De: "Ron Bonica" >=20 > Para: "v6ops@ietf.org list" >=20 > Enviados: Lunes, 30 de Julio 2018 10:12:50 >=20 > Asunto: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas >=20 > =20 >=20 > Folks, >=20 > =20 >=20 > Each week between now and IETF 103, we will review and discuss one= draft with an > eye towards progressing it. >=20 > =20 >=20 > This week, please review and comment on draft-ietf-v6ops-transitio= n-ipv4aas. >=20 > =20 >=20 > Fred and Ron >=20 > =20 >=20 > _______________________________________________ >=20 > v6ops mailing list >=20 > v6ops@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/v6ops >=20 > =20 >=20 > _______________________________________________ >=20 > v6ops mailing list >=20 > v6ops@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/v6ops >=20 > =20 >=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 the > individual(s) named above and further non-explicilty authorized discl= osure, > copying, distribution or use of the contents of this information, eve= n 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. =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 Aug 9 12:31: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 A9B0B130EC7 for ; Thu, 9 Aug 2018 12:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 g_i-v4Wi1egB for ; Thu, 9 Aug 2018 12:31:01 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 E59C0130EB9 for ; Thu, 9 Aug 2018 12:31:00 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w79JPBlp029650; Thu, 9 Aug 2018 15:29:59 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049462.ppops.net-00191d01. with ESMTP id 2krtjhjk65-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Aug 2018 15:29:59 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w79JTxZE026161; Thu, 9 Aug 2018 15:29:59 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [135.47.91.177]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w79JTrGL026035; Thu, 9 Aug 2018 15:29:53 -0400 Received: from zlp30486.vci.att.com (zlp30486.vci.att.com [127.0.0.1]) by zlp30486.vci.att.com (Service) with ESMTP id 2C5B94048B5A; Thu, 9 Aug 2018 19:29:53 +0000 (GMT) Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (unknown [130.8.218.156]) by zlp30486.vci.att.com (Service) with ESMTPS id 183214048B52; Thu, 9 Aug 2018 19:29:53 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0408.000; Thu, 9 Aug 2018 15:29:52 -0400 From: "STARK, BARBARA H" To: "'JORDI PALET MARTINEZ'" , "Alejandro D'Egidio" CC: "v6ops@ietf.org list" Thread-Topic: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas Thread-Index: AQHUL/dDGlgPknfZwUKlfoyXzIkUtaS3m+1g Date: Thu, 9 Aug 2018 19:29:52 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DE68EAA@GAALPA1MSGUSRBF.ITServices.sbc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.248.179] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-09_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy 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-1807170000 definitions=main-1808090194 Archived-At: Subject: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 19:31:03 -0000 PiAgICBUUkFOUy02OiAgVGhlIElQdjYgVHJhbnNpdGlvbiBDRSBSb3V0ZXIgTUFZIGhhdmUgbXVs dGlwbGUgSVB2NA0KPiAgICAgICAgICAgICAgcHJlZml4ZXMgdG8gYmUgdXNlZCBpbiBkaWZmZXJl bnQgY3VzdG9tZXItZmFjaW5nDQo+ICAgICAgICAgICAgICBpbnRlcmZhY2VzLCBhbmQgdGhlIElQ djYgVHJhbnNpdGlvbiBDRSBSb3V0ZXIgTVVTVCBzdXBwb3J0DQo+ICAgICAgICAgICAgICBtdWx0 aXBsZSBpbnN0YW5jZXMgb2YgdGhlIHJlbGV2YW50IHRyYW5zaXRpb24gbWVjaGFuaXNtDQo+ICAg ICAgICAgICAgICBjb2RlLCB0byBhbGxvdyBjb25maWd1cmluZyB0aGVtLg0KDQpUaGlzIHByb3Bv c2VkIHNlbnRlbmNlIHN0cnVjdHVyZSBsb2dpY2FsbHkgcmVzb2x2ZXMgdG8gKmFsd2F5cyogcmVx dWlyaW5nIHN1cHBvcnQgZm9yIG11bHRpcGxlIGluc3RhbmNlcy4gSSBkb24ndCB0aGluayB0aGlz IGlzIGFwcHJvcHJpYXRlIChlLmcuLCBmb3IgYSBzaW1wbGUgcm91dGVyIHRoYXQgb25seSBzdXBw b3J0cyBhIHNpbmdsZSBMQU4gSVB2NCBpbnRlcmZhY2UgYW5kIHNpbmdsZSBXQU4gSVB2NCBpbnRl cmZhY2UpLCBhbmQgcGVyaGFwcyBpdCdzIG5vdCB3aGF0J3MgaW50ZW5kZWQuIFRoZSBzZW50ZW5j ZSBpcyBhbHNvIHZlcnkgZGlmZmljdWx0IHRvIHBhcnNlIGFuZCBJJ20gbm90IGF0IGFsbCBzdXJl IEkgdW5kZXJzdGFuZCB3aGF0IGl0J3MgdHJ5aW5nIHRvIHNheS4NCg0KSXMgdGhpcyBzYXlpbmcg dGhhdCBpZiB0aGUgQ0Ugcm91dGVyIGhhcywgZm9yIGV4YW1wbGUsIGEgR3Vlc3QgV2ktRmkgSVB2 NCBzdWJuZXQgYW5kIGEgImhvbWUiIFdpLUZpIElQdjQgc3VibmV0IChib3RoIHRvIHRoZSBMQU4p LCB0aGF0IGl0IG11c3QgaW5zdGFudGlhdGUgMiBpbnN0YW5jZXMgb2YgKGZvciBleGFtcGxlKSBE Uy1MaXRlPyBXaGF0IGlmIHRoZSBJU1AgZG9lc24ndCBhbGxvdyBtb3JlIHRoYW4gb25lIGluc3Rh bmNlPyBIb3cgaXMgdGhlIElTUCBzdXBwb3NlZCB0byBzaWduYWwgd2hldGhlciBtb3JlIHRoYW4g b25lIGlzIGFsbG93ZWQ/IFdoeSB3b3VsZCAyIGluc3RhbmNlcyBiZSByZXF1aXJlZD8gDQpXb3Vs ZCB0aGlzIGFwcGx5IHRvIHRoZSBjYXNlIHdoZXJlIHRoZSByb3V0ZXIgc2ltcGx5IHN1cHBvcnRz IDIgTEFOIHNlZ21lbnRzIGFzIGRpZmZlcmVudCBzdWJuZXRzPyANCkknbSBzb3JyeSwgYnV0IEkn bSByZWFsbHkgbm90IHVuZGVyc3RhbmRpbmcgd2hhdCBjb25kaXRpb24gaXMgYmVpbmcgZGVzY3Jp YmVkLg0KDQpBcyBmb3IgcmVzb2x2aW5nIHRoZSBsb2dpY2FsIHNlbnRlbmNlIHN0cnVjdHVyZSwg SSB3b3VsZCBzdWdnZXN0IHdvcmRpbmcgdGhlIHJlcXVpcmVtZW50IGFzICJJZiA8Y29uZGl0aW9u IHJlbGF0ZWQgdG8gbXVsdGlwbGUgSVB2NCBMQU4gcHJlZml4ZXM+LCB0aGVuIHRoZSBJUHY2IFRy YW5zaXRpb24gQ0UgUm91dGVyIE1VU1QgPHdoYXRldmVyIG11c3QgYmUgZG9uZT4uIiBJZiB5b3Ug d2FudCB0byBleHBsYWluIHdoeSB0aGlzIHJlcXVpcmVtZW50IGV4aXN0cywgbWFrZSB0aGF0IGEg c2VwYXJhdGUgc2VudGVuY2UsIHN1Y2ggYXMgIlRoaXMgd2lsbCBhbGxvdyBzZXBhcmF0ZSBjb25m aWd1cmF0aW9uIG9mIHRoZSB0cmFuc2l0aW9uIG1lY2hhbmlzbSBpbnN0YW5jZXMuIg0KQmFyYmFy YQ0KDQo+IO+7vy0tLS0tTWVuc2FqZSBvcmlnaW5hbC0tLS0tDQo+IA0KPiBEZTogQWxlamFuZHJv IEQnRWdpZGlvIDxhZGVnaWRpb0B0ZWxlY2VudHJvLm5ldC5hcj4NCi4uLi4gc25pcHBpbmcgcmVs ZXZhbnQgdGV4dC4uLi4uDQo+ICAgICA+IFRoZSBjYXNlIGZvciBoYXZpbmcgbXVsdGlwbGUgSVB2 NCBzdWJuZXRzIChvbmUgZm9yIGVhY2ggaW50ZXJmYWNlKSwgaXMNCj4gZmVhc2libGUsDQo+ICAg ICA+IGFzIHlvdSBzYXksIGJ5IGhhdmluZyBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgdGhlIE5BVDQ2 LCB3aGljaCBJIHRoaW5rIGlzIG5vdA0KPiBhIHByb2JsZW0uDQo+ICAgICA+IEhvd2V2ZXIsIG9w ZW4gcXVlc3Rpb24gaXMgdmFsaWQgYWxzbyBmb3IgYW55IG90aGVyIElQdjRhYVMgbWVjaGFuaXNt LiANCj4gICAgID4gSSdtIG5vdCBzdXJlIGlmIHdlIHdhbnQgdG8gaGF2ZSB0aGF0IGNhc2UgY29u c2lkZXJlZCBhcyBzb21ldGhpbmcgdGhhdA0KPiBNVVNUIGJlIHN1cHBvcnRlZCBhcyBvbmUgbW9y ZSByZXF1aXJlbWVudCwgYW5kIGlmIHRoaXMgaXMgdGhlIGNhc2UsIGl0IHdpbGwgYmUgYQ0KPiAg ICAgPiAiZ2VuZXJhbCIgdHJhbnNpdGlvbiByZXF1aXJlbWVudCwgYW5kIG5vIG5lZWQgdG8gZ28g aW4gdGhlIGRldGFpbHMgZm9yDQo+IGVhY2ggdHJhbnNpdGlvbiBtZWNoYW5pc20sIG9yIHdlIHJl YWxseSB3YW50IHRvIGdvIHRvIGRlc2NyaWJlIGEgc3BlY2lmaWMgbmV3DQo+ICAgICA+IHJlcXVp cmVtZW50IGZvciB0aGlzIGZvciBlYWNoIHRyYW5zaXRpb24gbWVjaGFuaXNtIC4uLg0KPiANCj4g ICAgIEp1c3Qga25vd2luZyB0aGF0IGEgQ1BFIGNhbiBoYXZlIGRpZmZlcmVudCBMQU4gSVB2NCBw cmVmaXhlcyBJIHdhcyB0aGlua2luZw0KPiB0aGF0IG1heWJlIGl0IGNvdWxkIGJlIGNvbnNpZGVy ZWQgaW4gR2VuZXJhbCB0cmFuc2l0aW9uIHJlcXVpcmVtZW50cyB3aXRoDQo+IHNvbWV0aGluZyBs aWtlOiANCj4gDQo+ICAgICAiVFJBTlMtNjogVGhlIElQdjYgVHJhbnNpdGlvbiBDRSBSb3V0ZXIg TUFZIGhhdmUgZGlmZmVyZW50IElQdjQgcHJlZml4ZXMNCj4gb24gZWFjaCBDdXN0b21lci1GYWNp bmcgaW50ZXJmYWNlcyBhbmQgdGhlIHRyYW5zaXRpb24gbWVjaGFuaXNtcyBNVVNUDQo+IGhhdmUg b3B0aW9ucyB0byBiZSBjb21wYXRpYmxlIHdpdGggaXQuIg0KDQo= From nobody Thu Aug 9 12:44: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 8762E130ECE for ; Thu, 9 Aug 2018 12:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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=telecentro.net.ar 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 Y5wvpKPy2RXf for ; Thu, 9 Aug 2018 12:44:46 -0700 (PDT) Received: from mail.telecentro.net.ar (mail.telecentro.net.ar [190.55.63.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 888CE130ECB for ; Thu, 9 Aug 2018 12:44:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 320853202FC9; Thu, 9 Aug 2018 16:44:44 -0300 (-03) Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Ar4B30igzv01; Thu, 9 Aug 2018 16:44:43 -0300 (-03) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 76A6C3202FB9; Thu, 9 Aug 2018 16:44:43 -0300 (-03) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.telecentro.net.ar 76A6C3202FB9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecentro.net.ar; s=25118654-7AE4-11E8-AD98-8D0B0E6845CD; t=1533843883; bh=NIenK+UHDg4kiZaP7G9jTUZ94vSKZwxiUhY4WTZYCPs=; h=Date:From:To:Message-ID:MIME-Version; b=LwHAtEFz4yi1aqM5peFkMor2t5UvwJABveN1u5Cu53zkAI7qDkqPOKfLbrp0EVOSk sHH0Xr8Mf8oZpLU0vkEC8jbjqomBlz6IElUeo46X3QZ/oZvNwipXl/4VMIRY1fBwwD SMGoC4/lD1Bmd5jhUTe9WhZw2p28XTMeftY/zNk8evj/4qxqaE/UoA6lU7ic3YwQZE CDWJm8sMXYdtB5o51Buzgu7Ktz4CbIIlqHxS4v5XG/9yMK0/2hy4Ob2wsutRIcDWHV 6us5EgxXX2qNwTi7VIe7BVscdzsTO+hYL8yaaN2gDdJ+aDIaLbOEtN26SRiLcC2pUF 1HYXsxCDbUJDg== X-Virus-Scanned: amavisd-new at tclmail6.telecentro.local Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id uqMCKoeyHZPZ; Thu, 9 Aug 2018 16:44:43 -0300 (-03) Received: from tclmail6.telecentro.local (tclmail6.telecentro.local [10.210.50.96]) by mail.telecentro.net.ar (Postfix) with ESMTP id 636573202F9C; Thu, 9 Aug 2018 16:44:43 -0300 (-03) Date: Thu, 9 Aug 2018 16:44:43 -0300 (ART) From: Alejandro D'Egidio To: "STARK, BARBARA H" Cc: JORDI PALET MARTINEZ , "v6ops@ietf.org list" Message-ID: <690943494.12649475.1533843883346.JavaMail.zimbra@telecentro.net.ar> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DE68EAA@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DE68EAA@GAALPA1MSGUSRBF.ITServices.sbc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.210.50.96] X-Mailer: Zimbra 8.8.8_GA_3008 (ZimbraWebClient - GC68 (Win)/8.8.8_GA_1703) Thread-Topic: Weekly Review: draft-ietf-v6ops-transition-ipv4aas Thread-Index: AQHUL/dDGlgPknfZwUKlfoyXzIkUtaS3m+1gvT1bDCI= Archived-At: Subject: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 19:44:50 -0000 Hi Barbara, Maybe the text could say "and the IPv6 Transition CE Router MUST support it= to allow configuring them." The truth is that CPE, at least Cablemodems, could have different subnets o= n each customer-facing interface. The idea is that Transition Mechanism sup= ports that (many IPv4 addresses of differents LAN interfaces). Regards, Alejandro ----- Mensaje original ----- > De: "STARK, BARBARA H" > Para: "JORDI PALET MARTINEZ" , "Alejandro Degidio" > > CC: "v6ops@ietf.org list" > Enviados: Jueves, 9 de Agosto 2018 16:29:52 > Asunto: RE: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas >> TRANS-6: The IPv6 Transition CE Router MAY have multiple IPv4 >> prefixes to be used in different customer-facing >> interfaces, and the IPv6 Transition CE Router MUST support >> multiple instances of the relevant transition mechanism >> code, to allow configuring them. >=20 > This proposed sentence structure logically resolves to *always* requiring > support for multiple instances. I don't think this is appropriate (e.g., = for a > simple router that only supports a single LAN IPv4 interface and single W= AN > IPv4 interface), and perhaps it's not what's intended. The sentence is al= so > very difficult to parse and I'm not at all sure I understand what it's tr= ying > to say. >=20 > Is this saying that if the CE router has, for example, a Guest Wi-Fi IPv4= subnet > and a "home" Wi-Fi IPv4 subnet (both to the LAN), that it must instantiat= e 2 > instances of (for example) DS-Lite? What if the ISP doesn't allow more th= an one > instance? How is the ISP supposed to signal whether more than one is allo= wed? > Why would 2 instances be required? > Would this apply to the case where the router simply supports 2 LAN segme= nts as > different subnets? > I'm sorry, but I'm really not understanding what condition is being descr= ibed. >=20 > As for resolving the logical sentence structure, I would suggest wording = the > requirement as "If , the= n the > IPv6 Transition CE Router MUST ." If you want to e= xplain > why this requirement exists, make that a separate sentence, such as "This= will > allow separate configuration of the transition mechanism instances." > Barbara >=20 >> =EF=BB=BF-----Mensaje original----- >>=20 >> De: Alejandro D'Egidio > .... snipping relevant text..... >> > The case for having multiple IPv4 subnets (one for each interface)= , is >> feasible, >> > as you say, by having multiple instances of the NAT46, which I thi= nk is not >> a problem. >> > However, open question is valid also for any other IPv4aaS mechani= sm. >> > I'm not sure if we want to have that case considered as something = that >> MUST be supported as one more requirement, and if this is the case, it w= ill be a >> > "general" transition requirement, and no need to go in the details= for >> each transition mechanism, or we really want to go to describe a specifi= c new >> > requirement for this for each transition mechanism ... >>=20 >> Just knowing that a CPE can have different LAN IPv4 prefixes I was t= hinking >> that maybe it could be considered in General transition requirements wit= h >> something like: >>=20 >> "TRANS-6: The IPv6 Transition CE Router MAY have different IPv4 pref= ixes >> on each Customer-Facing interfaces and the transition mechanisms MUST >> have options to be compatible with it." From nobody Thu Aug 9 12:59: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 40DF5130ED2 for ; Thu, 9 Aug 2018 12:59: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 fpTRzZsnKsOY for ; Thu, 9 Aug 2018 12:59:42 -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 AEAC9130ED1 for ; Thu, 9 Aug 2018 12:59:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1533844780; x=1534449580; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=1q0HdtughbqCOCHU1HzTOh+pbAc16jmi71BHwfYrzrU=; b=Zo0LoCKd3NqBZ 22+kJTl/KNaQIy10i5pzNEXY1wP0lZfks9vsCtuyVQMeoYK5225yxBW5JCGIYwbJ R4gdBgxCnuMg47RnS2buiDarXmebJG3zq6Uuk6TneAFl1PO0YcdVAH/vj8sKXXXj bqkefWZ3JH3XsHnnhCdLlKIIvA7okM= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 09 Aug 2018 21:59:40 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 09 Aug 2018 21:59:37 +0200 Received: from [10.20.5.175] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005834842.msg for ; Thu, 09 Aug 2018 21:59:36 +0200 X-MDRemoteIP: 10.8.10.6 X-MDHelo: [10.20.5.175] X-MDArrival-Date: Thu, 09 Aug 2018 21:59:36 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17593b5162=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.f.0.180709 Date: Thu, 09 Aug 2018 14:59:24 -0500 From: JORDI PALET MARTINEZ To: "STARK, BARBARA H" , Alejandro D'Egidio CC: "v6ops@ietf.org list" Message-ID: <92B9B648-FD18-464D-9B0F-C038A0184E93@consulintel.es> Thread-Topic: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas References: <2D09D61DDFA73D4C884805CC7865E6114DE68EAA@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DE68EAA@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 19:59:46 -0000 Hi Barbara, Your SSID example is the perfect one about the need for this and I don't th= ink anything is needed in the ISP side. Fred suggested a small change, and I'm trying to figure out how to combine = that with your comment as well. I think this can make it: The IPv6 Transition CE Router MAY support multiple IPv4 prefixes=20 on its various customer-facing interfaces. In that case, it MUST=20 support configuration of multiple instances of the relevant code=20 of the transition mechanism and/or appropriate subnetting=20 on each such interface. For example, if the ISP provides a 192.168.0.0/16 to the CE (section 4.2 of= DS-Lite, RFC6333), each interface will get different subnet mask, as the u= ser don't need 16 bits for each interface ... In the case of lw4o6, the CE it is running its own NAT, so no issues. In the case of 464XLAT, you just need multiple instances of the NAT46 (so i= s equivalent to the case of the lw4o6). Etc. So, basically it is either a different instance and/or subnet mask configur= ation. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de "STARK, BARBARA H" Fecha: jueves, 9 de agosto de 2018, 14:31 Para: 'JORDI PALET MARTINEZ' , Alejandro D'Egidio CC: "v6ops@ietf.org list" Asunto: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas > TRANS-6: The IPv6 Transition CE Router MAY have multiple IPv4 > prefixes to be used in different customer-facing > interfaces, and the IPv6 Transition CE Router MUST suppo= rt > multiple instances of the relevant transition mechanism > code, to allow configuring them. =20 This proposed sentence structure logically resolves to *always* requiri= ng support for multiple instances. I don't think this is appropriate (e.g.,= for a simple router that only supports a single LAN IPv4 interface and sin= gle WAN IPv4 interface), and perhaps it's not what's intended. The sentence= is also very difficult to parse and I'm not at all sure I understand what = it's trying to say. =20 Is this saying that if the CE router has, for example, a Guest Wi-Fi IP= v4 subnet and a "home" Wi-Fi IPv4 subnet (both to the LAN), that it must in= stantiate 2 instances of (for example) DS-Lite? What if the ISP doesn't all= ow more than one instance? How is the ISP supposed to signal whether more t= han one is allowed? Why would 2 instances be required?=20 Would this apply to the case where the router simply supports 2 LAN seg= ments as different subnets?=20 I'm sorry, but I'm really not understanding what condition is being des= cribed. =20 As for resolving the logical sentence structure, I would suggest wordin= g the requirement as "If ,= then the IPv6 Transition CE Router MUST ." If you w= ant to explain why this requirement exists, make that a separate sentence, = such as "This will allow separate configuration of the transition mechanism= instances." Barbara =20 > =EF=BB=BF-----Mensaje original----- >=20 > De: Alejandro D'Egidio .... snipping relevant text..... > > The case for having multiple IPv4 subnets (one for each interfa= ce), is > feasible, > > as you say, by having multiple instances of the NAT46, which I = think is not > a problem. > > However, open question is valid also for any other IPv4aaS mech= anism.=20 > > I'm not sure if we want to have that case considered as somethi= ng that > MUST be supported as one more requirement, and if this is the case, i= t will be a > > "general" transition requirement, and no need to go in the deta= ils for > each transition mechanism, or we really want to go to describe a spec= ific new > > requirement for this for each transition mechanism ... >=20 > Just knowing that a CPE can have different LAN IPv4 prefixes I wa= s thinking > that maybe it could be considered in General transition requirements = with > something like:=20 >=20 > "TRANS-6: The IPv6 Transition CE Router MAY have different IPv4 p= refixes > on each Customer-Facing interfaces and the transition mechanisms MUST > have options to be compatible with it." =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 Aug 9 13:07:21 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 5046C130E8A for ; Thu, 9 Aug 2018 13:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 cf6J_GQQuWDl for ; Thu, 9 Aug 2018 13:07:17 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 9144C130ED1 for ; Thu, 9 Aug 2018 13:07:17 -0700 (PDT) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w79K6NP1040081; Thu, 9 Aug 2018 16:07:11 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049459.ppops.net-00191d01. with ESMTP id 2kruexhpqa-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Aug 2018 16:07:11 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w79K7B9P008698; Thu, 9 Aug 2018 16:07:11 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [135.47.91.179]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w79K7540008416; Thu, 9 Aug 2018 16:07:05 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id 13C00400036F; Thu, 9 Aug 2018 20:07:05 +0000 (GMT) Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (unknown [130.8.218.150]) by zlp30484.vci.att.com (Service) with ESMTPS id 00CD54000364; Thu, 9 Aug 2018 20:07:05 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0408.000; Thu, 9 Aug 2018 16:07:04 -0400 From: "STARK, BARBARA H" To: "'JORDI PALET MARTINEZ'" , Richard Patterson CC: "v6ops@ietf.org list" Thread-Topic: [v6ops] Review of draft-ietf-v6ops-transition-ipv4aas-05 Thread-Index: AdQgS3QgQiNxrFhHTyqVBUzs4Ev5DQAKEf+AAAFoKQAAAuaD4AA2avYAAEx/aQAAMcH0gAMu/ikAAAEMToA= Date: Thu, 9 Aug 2018 20:07:04 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DE6901D@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <787AE7BB302AE849A7480A190F8B93302DF66859@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DF66983@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2D09D61DDFA73D4C884805CC7865E6114DE43A3D@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DE4D923@GAALPA1MSGUSRBF.ITServices.sbc.com> <19402025-57D9-4F6A-99FE-8563CAD41CE9@consulintel.es> In-Reply-To: <19402025-57D9-4F6A-99FE-8563CAD41CE9@consulintel.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.248.179] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-09_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808090200 Archived-At: Subject: Re: [v6ops] Review of draft-ietf-v6ops-transition-ipv4aas-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 20:07:20 -0000 DQoNCj4gSGkgUmljaGFyZCwgQmFyYmFyYSwNCj4gDQo+IFRoYW5rcyBhbmQgc29ycnksIEknbSBs YXRlIHJlYWN0aW5nIHRvIHRoaXMsIHdvcmtpbmcgaW4gYSBuZXcgdmVyc2lvbiBkdXJpbmcNCj4g dGhlIHdlZWtlbmQsIGZvbGxvd2luZyBSb24gYWR2aXNlLCBpbiBvcmRlciB0byBnbyBmb3IgYSBs YXN0LWNhbGwuDQo+IA0KPiBMZXQgbWUgdHJ5IHRvIHN1bW1hcml6ZSB3aGF0IHlvdSBhcmUgc2F5 aW5nIHdpdGggYSBwcm9wb3NlZCB0ZXh0IChiYXNpYw0KPiBpZGVhLCByZW1vdmUgc3VwZXJmbHVv dXMgdGV4dCBhbmQgb25seSBzdGF0ZSB3aGF0IG1heSBiZSBub3Qgb2J2aW91cyBmb3IgYW4NCj4g aW1wbGVtZW50b3IsIHRoYXQgYWxyZWFkeSBtdXN0IGtub3cgYWJvdXQgVVBuUCBhbmQgaGFzIHJl YWQgdGhlIHJlc3Qgb2YNCj4gdGhlIGRvY3VtZW50IC4uLikuIExldCBtZSBrbm93IGlmIEkgbWlz c2VkIGFueXRoaW5nOg0KLS0tLS0tLS0tLSBzbmlwIC0tLS0tLS0tLQ0KPiBOZXcgdGV4dDoNCj4g NS4gIFVQblAgU3VwcG9ydA0KPiANCj4gSWYgdGhlIFtVUG5QIFdBTklQQ29ubmVjdGlvbjoyXSBz ZXJ2aWNlIGlzIGVuYWJsZWQgb24gYSBDRSByb3V0ZXIsDQo+IGJ1dCBjYW5ub3QgYmUgYXNzb2Np YXRlZCB3aXRoIGFuIElQdjQgaW50ZXJmYWNlIGVzdGFibGlzaGVkIGJ5IGFuDQo+IElQdjRhYXMg bWVjaGFuaXNtIG9yIGNhbm5vdCBpbnRlcndvcmsgd2l0aCBQQ1Agb3IgYSBjb25maWd1cmVkDQo+ IHBvcnQgc2V0LCBhbiBBZGRQb3J0TWFwcGluZygpIG9yIEFkZEFueVBvcnRNYXBwaW5nKCkgYWN0 aW9uDQo+IE1VU1QgYmUgcmVqZWN0ZWQgd2l0aCBlcnJvciBjb2RlIDcyOSAiQ29uZmxpY3RXaXRo T3RoZXJNZWNoYW5pc21zIi4NCj4gTm90ZSB0aGF0IElHRDoxIGFuZCBpdHMgV0FOSVBDb25uZWN0 aW9uOjEgc2VydmljZSBoYXZlIGJlZW4NCj4gZGVwcmVjYXRlZCBieSBPQ0YuDQoNCkkgdGhpbmsg UmljaGFyZCBoYWQgc29tZSBjb25jZXJucyB3aXRoIHRoaXMgbGFuZ3VhZ2UgKHdoaWNoIGlzIHRo ZSBsYW5ndWFnZSBJIHByb3Bvc2VkKS4gSSB3ZW50IGFuZCBmb3VuZCB3aGF0IFJpY2hhcmQgc2Fp ZDoNCg0KPFJQPiAiaW50ZXJ3b3JrIHdpdGggWy4uLl0gIGEgY29uZmlndXJlZCBwb3J0IHNldCIg aXMgdG9vIHZhZ3VlIGZvciBteSBsaWtpbmcuICBJdCdzIG5vdCBjbGVhciB0aGF0IHRoaXMgbWVh bnMgaXQgc2hvdWxkIHJlamVjdA0KQWRkUG9ydE1hcHBpbmcoKSByZXF1ZXN0cyBmb3IgYSBwb3J0 IG91dHNpZGUgb2YgdGhlIHBvcnQgc2V0LCBvciBwcm92aWRlIGFuIGFsdGVybmF0aXZlIHBvcnQg d2hlbiByZXF1ZXN0ZWQgd2l0aCBBZGRBbnlQb3J0TWFwcGluZygpLg0KSSdkIGxpa2UgdG8gc2Vl IHRoaXMgZWxhYm9yYXRlZCBhIGJpdCBtb3JlIG9uLg0KV2hpbHN0IElHRDoxIGlzIGRlcHJlY2F0 ZWQsIGl0IGlzIHdoYXQncyBvdXQgdGhlcmUgc28gd2UgbmVlZCB0byBtYWtlIHN1cmUgdG8gY2Fw dHVyZSB0aGUgQWRkUG9ydE1hcHBpbmcoKSBiZWhhdmlvdXIgY29ycmVjdGx5LiAgRXZlbiB3aGVu IG5ld2VyIENQRXMgc3RhcnQgc3VwcG9ydGluZyBJR0Q6MiAobW9zdCBhcmUgc3RpbGwgZHJhZ2dp bmcgdGhlaXIgaGVhbHMgSU1FKSwgaXQgcmVxdWlyZXMgYXBwbGljYXRpb25zIHRvIGFsc28gYWx0 ZXIgdGhlaXIgYmVoYXZpb3VyIHRvIG1ha2UgdXNlIG9mIHRoZSBuZXcgQWRkQW55UG9ydE1hcHBp bmcoKSBmdW5jdGlvbi48L1JQPg0KDQpUbyBhZGRyZXNzIFJpY2hhcmQncyBmaXJzdCBjb25jZXJu LCBwZXJoYXBzIHJlcGxhY2UgIm9yIGNhbm5vdCBpbnRlcndvcmsgd2l0aCBQQ1Agb3IgYSBjb25m aWd1cmVkIHBvcnQgc2V0IiB3aXRoICJvciBjYW5ub3QgZGV0ZXJtaW5lIHdoaWNoIHBvcnRzIGFy ZSBhdmFpbGFibGUgKHRocm91Z2ggUENQIG9yIGFjY2VzcyB0byBhIGNvbmZpZ3VyZWQgcG9ydCBz ZXQsIGlmIHRoZSBJUHZhYXMgbWVjaGFuaXNtIGxpbWl0cyB0aGUgYXZhaWxhYmxlIHBvcnRzKSIu DQoNClRvIGFkZHJlc3MgQWRkUG9ydE1hcHBpbmcoKSBmYWlsdXJlcywgSSBzdWdnZXN0IGFkZGlu ZyBhIHNlbnRlbmNlIChiZWZvcmUgdGhlIGxhc3Qgc2VudGVuY2UpIHRoYXQgc2F5cyAiQW4gQWRk UG9ydE1hcHBpbmcoKSByZXF1ZXN0IGZvciBhIHBvcnQgdGhhdCBpcyBub3QgYXZhaWxhYmxlIE1V U1QgcmVzdWx0IGluICJDb25mbGljdEluTWFwcGluZ0VudHJ5LiINCg0KQmFyYmFyYQ0KDQo= From nobody Thu Aug 9 13:23: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 AEA86130E0F for ; Thu, 9 Aug 2018 13:23: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 3fUMLHQyivMY for ; Thu, 9 Aug 2018 13:23:26 -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 02139130E5E for ; Thu, 9 Aug 2018 13:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1533846204; x=1534451004; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=0RzMiaiT9cpzMWaHvtPeLhg0JiAP2RFGRpoihlNn014=; b=tr9EzN2ONAA9r tH4DVMw8THV7uAhaa5xA4Vbl2VP5n/OaofHAU1wwu06YMHpcXdLeUqzeQaOhhsm6 f7FPbmT/dJcdhJEQmBIBpzc91+PctjRvSzW/TMAISL1RaH5/BhjdxEpD/4gSzbLD iwMtJBnDYhptZKh7ZwT08HpH//mXlc= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 09 Aug 2018 22:23:24 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 09 Aug 2018 22:23:24 +0200 Received: from [10.20.5.175] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005834860.msg for ; Thu, 09 Aug 2018 22:23:23 +0200 X-MDRemoteIP: 10.8.10.6 X-MDHelo: [10.20.5.175] X-MDArrival-Date: Thu, 09 Aug 2018 22:23:23 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17593b5162=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.f.0.180709 Date: Thu, 09 Aug 2018 15:23:13 -0500 From: JORDI PALET MARTINEZ To: "STARK, BARBARA H" , Richard Patterson CC: "v6ops@ietf.org list" Message-ID: Thread-Topic: [v6ops] Review of draft-ietf-v6ops-transition-ipv4aas-05 References: <787AE7BB302AE849A7480A190F8B93302DF66859@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DF66983@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2D09D61DDFA73D4C884805CC7865E6114DE43A3D@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DE4D923@GAALPA1MSGUSRBF.ITServices.sbc.com> <19402025-57D9-4F6A-99FE-8563CAD41CE9@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DE6901D@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DE6901D@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Review of draft-ietf-v6ops-transition-ipv4aas-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 20:23:29 -0000 Let's see if I got it right: 5. UPnP Support If the UPnP WANIPConnection:2 service [UPnP-WANIPC] is enabled on a CE router, but cannot be associated with an IPv4 interface established by an IPv4aaS mechanism or cannot determine which ports are available (through PCP or access to a configured port set, if the IPv4aaS mechanism limits the available ports), an AddPortMapping() or AddAnyPortMapping() action MUST be rejected with error code 729 "ConflictWithOtherMechanisms". An AddPortMapping() request for a port that is not available MUST result in "ConflictInMappingEntry". Note that IGD:1 and its WANIPConnection:1 service have been deprecated by OCF. [UPnP-WANIPC] UPnP Forum, "WANIPConnection:2 Service", December 2010, . Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: "STARK, BARBARA H" Fecha: jueves, 9 de agosto de 2018, 15:07 Para: 'JORDI PALET MARTINEZ' , Richard Patterso= n CC: "v6ops@ietf.org list" Asunto: RE: [v6ops] Review of draft-ietf-v6ops-transition-ipv4aas-05 =20 =20 > Hi Richard, Barbara, >=20 > Thanks and sorry, I'm late reacting to this, working in a new version= during > the weekend, following Ron advise, in order to go for a last-call. >=20 > Let me try to summarize what you are saying with a proposed text (bas= ic > idea, remove superfluous text and only state what may be not obvious = for an > implementor, that already must know about UPnP and has read the rest = of > the document ...). Let me know if I missed anything: ---------- snip --------- > New text: > 5. UPnP Support >=20 > If the [UPnP WANIPConnection:2] service is enabled on a CE router, > but cannot be associated with an IPv4 interface established by an > IPv4aas mechanism or cannot interwork with PCP or a configured > port set, an AddPortMapping() or AddAnyPortMapping() action > MUST be rejected with error code 729 "ConflictWithOtherMechanisms". > Note that IGD:1 and its WANIPConnection:1 service have been > deprecated by OCF. =20 I think Richard had some concerns with this language (which is the lang= uage I proposed). I went and found what Richard said: =20 "interwork with [...] a configured port set" is too vague for my = liking. It's not clear that this means it should reject AddPortMapping() requests for a port outside of the port set, or provid= e an alternative port when requested with AddAnyPortMapping(). I'd like to see this elaborated a bit more on. Whilst IGD:1 is deprecated, it is what's out there so we need to make s= ure to capture the AddPortMapping() behaviour correctly. Even when newer C= PEs start supporting IGD:2 (most are still dragging their heals IME), it re= quires applications to also alter their behaviour to make use of the new Ad= dAnyPortMapping() function. =20 To address Richard's first concern, perhaps replace "or cannot interwor= k with PCP or a configured port set" with "or cannot determine which ports = are available (through PCP or access to a configured port set, if the IPvaa= s mechanism limits the available ports)". =20 To address AddPortMapping() failures, I suggest adding a sentence (befo= re the last sentence) that says "An AddPortMapping() request for a port tha= t is not available MUST result in "ConflictInMappingEntry." =20 Barbara =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 Thu Aug 9 13:23: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 E234D130F9D for ; Thu, 9 Aug 2018 13:23: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, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=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 goLqA2NIEWmR for ; Thu, 9 Aug 2018 13:23:44 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 C7AB6130FED for ; Thu, 9 Aug 2018 13:23:43 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id s198-v6so12041977oih.11 for ; Thu, 09 Aug 2018 13:23:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=+c3bSNfISA7oWxKrK9SKK3qwY7wIMLXeQs84bFTeJ0w=; b=WBC8JzanRV1Bmbza3fyjSL2vKovGfamQZme7j3ubD+xeT9vrji8tf6RuliIPFbCeFe +BtlaZP0fxd0XsZknahJchpxToD8+Tbyi8Norl+EEFFqnjQ7pc40pqIfskm3W/qRfnI8 p5WqWVtmRE1TaUnh2adfvO7NaB8S3D92zTedqzAwh5qpfqi7a8bd1VKAbETnwT2081g0 lo9wd29EoVjyFkf9KABz3MnEvrcFE/XuURwcYcYJ2pqCv88ZwNIICUAJ4G7rQCkjCjZP 9X7tr3RwSprlbxfyciFHehDiAR4PL+yffa6ufwT6c6BD8sm4uE6Cvc7MDc5itxAbHKJG vUCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=+c3bSNfISA7oWxKrK9SKK3qwY7wIMLXeQs84bFTeJ0w=; b=STxFa+zWpLJuAcBWc8fbuEZYUuMkPk79Zvfw8oc5Dl2tFFUFKw5e2C7ywrXSqjabjY jiI5FnyT0BOw39V5KAB94ePXreUp6womvhnBy0io56l4Cj5KtBItF0BJg0eyAAuGxVv6 jHuxoG4ZPSHDwQp/WdcSdjCrkSXSDdIJRrvHpWX/PcHLr1rSAGpP9yV0icfzp7GKm4VM VUwnA2o1KDplhvjIdgdpZXtPevDiCQ5kvIO8DDP2gzoRFjcLvFBmwjGgxMysBNl5rtnU uJf2MgE/S/aZmFzlfJNA/pD33UNt/vqCmi3Pt7Uoyn3KQfTwN3T7mMRs0JzbhP9E33T7 JByg== X-Gm-Message-State: AOUpUlE8vDaxwMeLhb5iyaGu/fNTD5ZOkKhlrQgUdU5zAJUoxRmoxLpz 2ecwB3YeyC+tPD+rOf/M1sA= X-Google-Smtp-Source: AA+uWPxdxMmrm98kv3Z3/79okOtPPy5jNbIQCb3l4BEq/lh6qaidoZGRH62HX/n5sAPbjIpLPJtAoQ== X-Received: by 2002:aca:acb:: with SMTP id k72-v6mr3868477oiy.78.1533846222954; Thu, 09 Aug 2018 13:23:42 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::101f? ([2600:8802:5600:1546::101f]) by smtp.gmail.com with ESMTPSA id r187-v6sm5503491oie.43.2018.08.09.13.23.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Aug 2018 13:23:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Fred Baker X-Mailer: Apple Mail (2.3445.9.1) In-Reply-To: Date: Thu, 9 Aug 2018 13:23:40 -0700 Content-Transfer-Encoding: quoted-printable Received: from ?IPv6:2600:8802:5600:1546::1039? ([2600:8802:5600:1546::1039]) by smtp.gmail.com with ESMTPSA id m11-v6sm5860047oif.27.2018.08.09.10.44.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Aug 2018 10:44:43 -0700 (PDT) Message-Id: <788A2825-037A-4D84-9379-C0EB6F587FB9@gmail.com> References: To: bs7652@att.com, v6ops@ietf.org Archived-At: Subject: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 20:23:57 -0000 I sent this to Jordi privately. Would you agree with my construction? =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94/ English is your second language, and you do very well in it. However, as a n= ative speaker, may I offer a friendly amendment? TRANS-6: The IPv6 Transitional Router MAY be configured with multiple IPv4 prefixes o= n its various customer-facing interfaces. When so configured, it MUST support configuration of different transition me= chanisms on each such interface. > On Aug 9, 2018, at 8:39 AM, JORDI PALET MARTINEZ wrote: >=20 > Hi Alejandro, >=20 >=20 >=20 > I think this may sort out your requirement: >=20 >=20 >=20 > TRANS-6: The IPv6 Transition CE Router MAY have multiple IPv4 >=20 > prefixes to be used in different customer-facing >=20 > interfaces, and the IPv6 Transition CE Router MUST support >=20 > multiple instances of the relevant transition mechanism >=20 > code, to allow configuring them. >=20 >=20 >=20 > Do you agree? >=20 >=20 >=20 > Regards, >=20 > Jordi >=20 >=20 >=20 >=20 >=20 >=20 >=20 > =EF=BB=BF-----Mensaje original----- >=20 > De: Alejandro D'Egidio >=20 > Fecha: martes, 31 de julio de 2018, 15:55 >=20 > Para: JORDI PALET MARTINEZ >=20 > CC: Ron Bonica , "v6ops@ietf.org list" >=20 > Asunto: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas >=20 >=20 >=20 > Hello Jordi, >=20 > My notes in lines. >=20 >=20 >=20 > Regards, >=20 > Alejandro >=20 >=20 >=20 > ----- Mensaje original ----- >=20 >> De: "JORDI PALET MARTINEZ" >=20 >> Para: "Alejandro Degidio" , "Ron Bonica" >=20 >> CC: "v6ops@ietf.org list" >=20 >> Enviados: Lunes, 30 de Julio 2018 20:58:52 >=20 >> Asunto: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas >=20 >=20 >=20 >> Hi Alejandro, >=20 >=20 >=20 >=20 >> Thanks for the input! >=20 >=20 >=20 >=20 >> I think it is easy to understand: >=20 >=20 >> "This document covers a set of IP transition techniques required when >=20 >=20 >> ISPs have an IPv6-only access network." >=20 >=20 >=20 >=20 >> even if the ISP already have an IPv6-only access network, or want to have= it. >=20 >=20 >=20 >=20 >> But this may be something that a native English speaker could tell us how= better >=20 >> to say it. May be: >=20 >=20 >> "This document covers a set of IP transition techniques required when >=20 >=20 >> ISPs have or want to move to an IPv6-only access network." >=20 >=20 >=20 > Yes, it's great. >=20 >=20 >=20 >=20 >> I'd some text in earlier versions about the reasons to have an IPv6-only a= ccess >=20 >> network, but it was suggested to move it to the Annex A ... not sure if y= ou >=20 >> read them also. I'm happy to add some more text, if needed to the annex A= to >=20 >> describe several possible reasons. >=20 >=20 >=20 >=20 > Yes, I've read all the document included the Annexes. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> The case for having multiple IPv4 subnets (one for each interface), is fe= asible, >=20 >> as you say, by having multiple instances of the NAT46, which I think is n= ot a >=20 >> problem. >=20 >=20 >=20 >=20 >> However, open question is valid also for any other IPv4aaS mechanism. >=20 >=20 >=20 >=20 >> I'm not sure if we want to have that case considered as something that MU= ST be >=20 >> supported as one more requirement, and if this is the case, it will be a >=20 >> "general" transition requirement, and no need to go in the details for ea= ch >=20 >> transition mechanism, or we really want to go to describe a specific new >=20 >> requirement for this for each transition mechanism ... >=20 >=20 >=20 >=20 > Just knowing that a CPE can have different LAN IPv4 prefixes I was think= ing that maybe it could be considered in General transition requirements wit= h something like: >=20 >=20 >=20 > "TRANS-6: The IPv6 Transition CE Router MAY have different IPv4 prefixes= on each Customer-Facing interfaces and the transition mechanisms MUST have o= ptions to be compatible with it." >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> What others think? >=20 >=20 >=20 >=20 >> Regards, >=20 >=20 >> Jordi >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> =EF=BB=BF-----Mensaje original----- >=20 >=20 >> De: v6ops en nombre de Alejandro D'Egidio >=20 >> >=20 >=20 >> Fecha: lunes, 30 de julio de 2018, 10:39 >=20 >=20 >> Para: Ron Bonica >=20 >=20 >> CC: "v6ops@ietf.org list" >=20 >=20 >> Asunto: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas >=20 >=20 >=20 >=20 >> Hello Ron, >=20 >=20 >> I really like this draft! >=20 >=20 >> Just a simple comment. >=20 >=20 >> Where says: >=20 >=20 >> This document covers a set of IP transition techniques required when >=20 >=20 >> ISPs have an IPv6-only access network. >=20 >=20 >=20 >=20 >> Maybe could say: >=20 >=20 >> This document covers a set of IP transition techniques required when >=20 >=20 >> ISPs wants to have an IPv6-only access network. >=20 >=20 >=20 >=20 >> Maybe you can include some example of why ISPs wants to have an IPv6 onl= y access >=20 >> network. >=20 >=20 >> For example, in my case, as we don't have more public IPv4 addresses and= we have >=20 >> IPv6 developed, why should I need to continue managing IPv4 addresses? >=20 >=20 >> Maybe some kind of this scenario could be included. >=20 >=20 >=20 >=20 >> Regarding 3.2.1. 464XLAT: >=20 >=20 >> Cablelabs defines that the CableModem must subnet the IPv6 Prefix receiv= ed from >=20 >> ISP to use different subnets on each LAN Interface. The size of IPv6 "su= b" >=20 >> prefix on each LAN depends on is ISP configured the CM to use either fav= or >=20 >> depth or favor width. If ISP provides just a /64 IPv6 prefix (which is n= ot >=20 >> recommended) CM must share it with all LAN interfaces. >=20 >=20 >=20 >=20 >> For IPv4, by the same private IPv4 prefix is shared between all LAN inte= rfaces >=20 >> (customer-facing interfaces). For this case I think it "3.2.1. 464XLAT"= is ok. >=20 >=20 >> There are some cases where CM could have different private IPv4 prefixes= to each >=20 >> customer-facing interfaces. So I think, this is another scenario that sh= ould be >=20 >> covered where CLAT will need to work with all the IPv4 LAN prefixes. May= be >=20 >> running multiple instances of its NAT46 (one for each LAN interface) or o= ne >=20 >> instance supporting multiple IPv4 addresses. >=20 >=20 >=20 >=20 >> All this is in: >=20 >> https://apps.cablelabs.com/specification/ipv4-and-ipv6-erouter-specifica= tion/ >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> Regards, >=20 >=20 >> ALEJANDRO D'EGIDIO >=20 >=20 >> Jefe de Ingenier=C3=ADa de Backbone | Direcci=C3=B3n de Ingenier=C3=ADa >=20 >=20 >> M: [ callto:+54 911 5794-1589 | +54 911 5794-1589 ] | F: [ callto:+54 11= >=20 >> 3977-1025 | +54 11 3977-1025 ] | [ mailto:adegidio@telecentro.net.ar | >=20 >> adegidio@telecentro.net.ar ] >=20 >=20 >> Pje. Lavard=C3=A9n 157. Piso 3. CABA (C1437FBC) >=20 >=20 >=20 >=20 >> ----- Mensaje original ----- >=20 >=20 >> De: "Ron Bonica" >=20 >=20 >> Para: "v6ops@ietf.org list" >=20 >=20 >> Enviados: Lunes, 30 de Julio 2018 10:12:50 >=20 >=20 >> Asunto: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas >=20 >=20 >=20 >=20 >> Folks, >=20 >=20 >=20 >=20 >> Each week between now and IETF 103, we will review and discuss one draft= with an >=20 >> eye towards progressing it. >=20 >=20 >=20 >=20 >> This week, please review and comment on draft-ietf-v6ops-transition-ipv4= aas. >=20 >=20 >=20 >=20 >> Fred and Ron >=20 >=20 >=20 >=20 >> _______________________________________________ >=20 >=20 >> v6ops mailing list >=20 >=20 >> v6ops@ietf.org >=20 >=20 >> https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 >> _______________________________________________ >=20 >=20 >> v6ops mailing list >=20 >=20 >> v6ops@ietf.org >=20 >=20 >> https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> ********************************************** >=20 >> IPv4 is over >=20 >> Are you ready for the new Internet ? >=20 >> http://www.consulintel.es >=20 >> The IPv6 Company >=20 >=20 >> This electronic message contains information which may be privileged or >=20 >> confidential. The information is intended to be for the exclusive use of t= he >=20 >> individual(s) named above and further non-explicilty authorized disclosur= e, >=20 >> copying, distribution or use of the contents of this information, even if= >=20 >> partially, including attached files, is strictly prohibited and will be >=20 >> considered a criminal offense. If you are not the intended recipient be a= ware >=20 >> that any disclosure, copying, distribution or use of the contents of this= >=20 >> information, even if partially, including attached files, is strictly >=20 >> prohibited, will be considered a criminal offense, so you must reply to t= he >=20 >> original sender to inform about this communication and delete it. >=20 >=20 >=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 co= nfidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, c= opying, distribution or use of the contents of this information, even if par= tially, including attached files, is strictly prohibited and will be conside= red a criminal offense. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this informat= ion, even if partially, including attached files, is strictly prohibited, wi= ll be considered a criminal offense, so you must reply to the original sende= r to inform about this communication and delete it. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops ----------------------------------------------------------------------------= ---- The fact that there is a highway to hell and a stairway to heaven is an inte= resting comment on projected traffic volume... From nobody Thu Aug 9 13:32:57 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 06111130E70 for ; Thu, 9 Aug 2018 13:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 EDplqXQQCMQg for ; Thu, 9 Aug 2018 13:32:53 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 2F314130E77 for ; Thu, 9 Aug 2018 13:32:53 -0700 (PDT) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w79KPJQO015175; Thu, 9 Aug 2018 16:32:52 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 2krv3f17f9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Aug 2018 16:32:52 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w79KWpPb031162; Thu, 9 Aug 2018 16:32:51 -0400 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [135.47.91.178]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w79KWmId031086; Thu, 9 Aug 2018 16:32:49 -0400 Received: from zlp30485.vci.att.com (zlp30485.vci.att.com [127.0.0.1]) by zlp30485.vci.att.com (Service) with ESMTP id 7110B4048C36; Thu, 9 Aug 2018 20:32:48 +0000 (GMT) Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (unknown [130.8.218.157]) by zlp30485.vci.att.com (Service) with ESMTPS id 5A9144048C34; Thu, 9 Aug 2018 20:32:48 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0408.000; Thu, 9 Aug 2018 16:32:47 -0400 From: "STARK, BARBARA H" To: "'Alejandro D'Egidio'" CC: JORDI PALET MARTINEZ , "v6ops@ietf.org list" Thread-Topic: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas Thread-Index: AQHUL/dDGlgPknfZwUKlfoyXzIkUtaS3m+1gvT1bDCLCwuKY4A== Date: Thu, 9 Aug 2018 20:32:47 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DE690F1@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DE68EAA@GAALPA1MSGUSRBF.ITServices.sbc.com> <690943494.12649475.1533843883346.JavaMail.zimbra@telecentro.net.ar> In-Reply-To: <690943494.12649475.1533843883346.JavaMail.zimbra@telecentro.net.ar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.248.179] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-09_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808090203 Archived-At: Subject: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 20:32:55 -0000 PiBIaSBCYXJiYXJhLA0KPiANCj4gTWF5YmUgdGhlIHRleHQgY291bGQgc2F5ICJhbmQgdGhlIElQ djYgVHJhbnNpdGlvbiBDRSBSb3V0ZXIgTVVTVCBzdXBwb3J0IGl0DQo+IHRvIGFsbG93IGNvbmZp Z3VyaW5nIHRoZW0uIg0KPiANCj4gVGhlIHRydXRoIGlzIHRoYXQgQ1BFLCBhdCBsZWFzdCBDYWJs ZW1vZGVtcywgY291bGQgaGF2ZSBkaWZmZXJlbnQgc3VibmV0cyBvbg0KPiBlYWNoIGN1c3RvbWVy LWZhY2luZyBpbnRlcmZhY2UuIFRoZSBpZGVhIGlzIHRoYXQgVHJhbnNpdGlvbiBNZWNoYW5pc20N Cj4gc3VwcG9ydHMgdGhhdCAobWFueSBJUHY0IGFkZHJlc3NlcyBvZiBkaWZmZXJlbnRzIExBTiBp bnRlcmZhY2VzKS4gDQoNCkhpIEFsZWphbmRybywNClllcywgdGhlcmUgYXJlIG1hbnkgc2ltcGxl IENFIHJvdXRlcnMgdGhhdCBzdXBwb3J0IG11bHRpcGxlIExBTiBzdWJuZXRzLCB0b2RheS4gVGhl IG11bHRpcGxlIExBTiBJUHY0IGludGVyZmFjZXMgdG9kYXkgbWF5IGJlIHN1cHBvcnRlZCBieSBh IHNpbmdsZSAibmF0aXZlIiBXQU4gSVB2NCBpbnRlcmZhY2UsIG9yIHBvdGVudGlhbGx5IHRoZXkg Y291bGQgZWFjaCBoYXZlIHRoZWlyIG93biAibmF0aXZlIiBXQU4gSVB2NCBpbnRlcmZhY2UgKGUu Zy4sIGJ5IHVzaW5nIHNlcGFyYXRlIFZMQU5zKS4gTm90ZSB0aGF0IHRoaXMgc2Vjb25kIGNhc2Ug dGVuZHMgdG8gb2NjdXIgbWFpbmx5IHdoZW4gdGhlICBJU1AgaXMgc3VwcGx5aW5nIGEgc3BlY2lh bGl6ZWQgQ0Ugcm91dGVyIGZvciB1c2Ugd2l0aCB0aGVpciBzZXJ2aWNlLiBJdCBpcyB1bmNvbW1v biBpbiAiZ2VuZXJpYyIgQ0Ugcm91dGVycy4gV2hlcmUgbXVsdGlwbGUgTEFOIHNlZ21lbnRzIGFs bCBzaGFyZSB0aGUgc2FtZSAibmF0aXZlIiBXQU4gSVB2NCBjb25uZWN0aW9uIHRvZGF5LCBJIHdv dWxkIGV4cGVjdCB0aGVtIHRvIGNvbnRpbnVlIHRvIGRvIHNvIHdoZW4gdGhlIElQdjQgY29ubmVj dGlvbiBpcyB0dW5uZWxlZC4gVGhpcyBzaG91bGQgbm90IGJlIHByb2hpYml0ZWQuIFdlIHNob3Vs ZCBub3QgYmUgcmVxdWlyaW5nIGFsbCByb3V0ZXJzIHRoYXQgc3VwcG9ydCBtb3JlIHRoYW4gb25l IHN1Ym5ldCB0byBzdXBwb3J0IG11bHRpcGxlIFdBTiBJUHY0IGludGVyZmFjZXMuIElmIGEgQ2Fi bGVtb2RlbSBkb2VzLCB0aGF0J3MgZmluZS4gSWYgYSByZXRhaWwgTGlua3N5cyByb3V0ZXIgc3Vw cG9ydHMgbXVsdGlwbGUgTEFOIHN1Ym5ldHMgYnV0IGp1c3QgYSBzaW5nbGUgV0FOIElQdjQgaW50 ZXJmYWNlLCB0aGF0IHNob3VsZCBiZSBmaW5lLCB0b28uIA0KDQpUaGUgcHJvcG9zZWQgcmVxdWly ZW1lbnQgc2VlbXMgdG8gYmUgc2F5aW5nIHRoZSBDRSByb3V0ZXIgTVVTVCBtYWludGFpbiBhIHNl cGFyYXRlIFdBTiBJUHY0IHR1bm5lbGVkIGludGVyZmFjZSBmb3IgZWFjaCBkaXN0aW5jdCBMQU4g c3VibmV0LiBJZiB0aGF0IGlzIHdoYXQgaXQgaXMgc2F5aW5nLCB0aGVuIEkgZGlzYWdyZWUgdGhp cyBpcyBhIHJlcXVpcmVtZW50IGZvciBhbGwgcm91dGVycy4gSWYgdGhhdCBpcyBub3Qgd2hhdCBp dCBpcyBzYXlpbmcsIHRoZW4gdGhlIHdvcmRzIG5lZWQgdG8gYmUgY2hhbmdlZC4NCkJhcmJhcmEN CiANCj4gUmVnYXJkcywNCj4gQWxlamFuZHJvDQo+IA0KPiAtLS0tLSBNZW5zYWplIG9yaWdpbmFs IC0tLS0tDQo+ID4gRGU6ICJTVEFSSywgQkFSQkFSQSBIIiA8YnM3NjUyQGF0dC5jb20+DQo+ID4g UGFyYTogIkpPUkRJIFBBTEVUIE1BUlRJTkVaIg0KPiA8am9yZGkucGFsZXQ9NDBjb25zdWxpbnRl bC5lc0BkbWFyYy5pZXRmLm9yZz4sICJBbGVqYW5kcm8gRGVnaWRpbyINCj4gPiA8YWRlZ2lkaW9A dGVsZWNlbnRyby5uZXQuYXI+DQo+ID4gQ0M6ICJ2Nm9wc0BpZXRmLm9yZyBsaXN0IiA8djZvcHNA aWV0Zi5vcmc+DQo+ID4gRW52aWFkb3M6IEp1ZXZlcywgOSBkZSBBZ29zdG8gMjAxOCAxNjoyOTo1 Mg0KPiA+IEFzdW50bzogUkU6IFt2Nm9wc10gV2Vla2x5IFJldmlldzogZHJhZnQtaWV0Zi12Nm9w cy10cmFuc2l0aW9uLWlwdjRhYXMNCj4gDQo+ID4+ICAgIFRSQU5TLTY6ICBUaGUgSVB2NiBUcmFu c2l0aW9uIENFIFJvdXRlciBNQVkgaGF2ZSBtdWx0aXBsZSBJUHY0DQo+ID4+ICAgICAgICAgICAg ICBwcmVmaXhlcyB0byBiZSB1c2VkIGluIGRpZmZlcmVudCBjdXN0b21lci1mYWNpbmcNCj4gPj4g ICAgICAgICAgICAgIGludGVyZmFjZXMsIGFuZCB0aGUgSVB2NiBUcmFuc2l0aW9uIENFIFJvdXRl ciBNVVNUIHN1cHBvcnQNCj4gPj4gICAgICAgICAgICAgIG11bHRpcGxlIGluc3RhbmNlcyBvZiB0 aGUgcmVsZXZhbnQgdHJhbnNpdGlvbiBtZWNoYW5pc20NCj4gPj4gICAgICAgICAgICAgIGNvZGUs IHRvIGFsbG93IGNvbmZpZ3VyaW5nIHRoZW0uDQo+ID4NCj4gPiBUaGlzIHByb3Bvc2VkIHNlbnRl bmNlIHN0cnVjdHVyZSBsb2dpY2FsbHkgcmVzb2x2ZXMgdG8gKmFsd2F5cyoNCj4gPiByZXF1aXJp bmcgc3VwcG9ydCBmb3IgbXVsdGlwbGUgaW5zdGFuY2VzLiBJIGRvbid0IHRoaW5rIHRoaXMgaXMN Cj4gPiBhcHByb3ByaWF0ZSAoZS5nLiwgZm9yIGEgc2ltcGxlIHJvdXRlciB0aGF0IG9ubHkgc3Vw cG9ydHMgYSBzaW5nbGUgTEFODQo+ID4gSVB2NCBpbnRlcmZhY2UgYW5kIHNpbmdsZSBXQU4NCj4g PiBJUHY0IGludGVyZmFjZSksIGFuZCBwZXJoYXBzIGl0J3Mgbm90IHdoYXQncyBpbnRlbmRlZC4g VGhlIHNlbnRlbmNlIGlzDQo+ID4gYWxzbyB2ZXJ5IGRpZmZpY3VsdCB0byBwYXJzZSBhbmQgSSdt IG5vdCBhdCBhbGwgc3VyZSBJIHVuZGVyc3RhbmQgd2hhdA0KPiA+IGl0J3MgdHJ5aW5nIHRvIHNh eS4NCj4gPg0KPiA+IElzIHRoaXMgc2F5aW5nIHRoYXQgaWYgdGhlIENFIHJvdXRlciBoYXMsIGZv ciBleGFtcGxlLCBhIEd1ZXN0IFdpLUZpDQo+ID4gSVB2NCBzdWJuZXQgYW5kIGEgImhvbWUiIFdp LUZpIElQdjQgc3VibmV0IChib3RoIHRvIHRoZSBMQU4pLCB0aGF0IGl0DQo+ID4gbXVzdCBpbnN0 YW50aWF0ZSAyIGluc3RhbmNlcyBvZiAoZm9yIGV4YW1wbGUpIERTLUxpdGU/IFdoYXQgaWYgdGhl IElTUA0KPiA+IGRvZXNuJ3QgYWxsb3cgbW9yZSB0aGFuIG9uZSBpbnN0YW5jZT8gSG93IGlzIHRo ZSBJU1Agc3VwcG9zZWQgdG8gc2lnbmFsDQo+IHdoZXRoZXIgbW9yZSB0aGFuIG9uZSBpcyBhbGxv d2VkPw0KPiA+IFdoeSB3b3VsZCAyIGluc3RhbmNlcyBiZSByZXF1aXJlZD8NCj4gPiBXb3VsZCB0 aGlzIGFwcGx5IHRvIHRoZSBjYXNlIHdoZXJlIHRoZSByb3V0ZXIgc2ltcGx5IHN1cHBvcnRzIDIg TEFODQo+ID4gc2VnbWVudHMgYXMgZGlmZmVyZW50IHN1Ym5ldHM/DQo+ID4gSSdtIHNvcnJ5LCBi dXQgSSdtIHJlYWxseSBub3QgdW5kZXJzdGFuZGluZyB3aGF0IGNvbmRpdGlvbiBpcyBiZWluZw0K PiBkZXNjcmliZWQuDQo+ID4NCj4gPiBBcyBmb3IgcmVzb2x2aW5nIHRoZSBsb2dpY2FsIHNlbnRl bmNlIHN0cnVjdHVyZSwgSSB3b3VsZCBzdWdnZXN0DQo+ID4gd29yZGluZyB0aGUgcmVxdWlyZW1l bnQgYXMgIklmIDxjb25kaXRpb24gcmVsYXRlZCB0byBtdWx0aXBsZSBJUHY0IExBTg0KPiA+IHBy ZWZpeGVzPiwgdGhlbiB0aGUNCj4gPiBJUHY2IFRyYW5zaXRpb24gQ0UgUm91dGVyIE1VU1QgPHdo YXRldmVyIG11c3QgYmUgZG9uZT4uIiBJZiB5b3Ugd2FudA0KPiA+IHRvIGV4cGxhaW4gd2h5IHRo aXMgcmVxdWlyZW1lbnQgZXhpc3RzLCBtYWtlIHRoYXQgYSBzZXBhcmF0ZSBzZW50ZW5jZSwNCj4g PiBzdWNoIGFzICJUaGlzIHdpbGwgYWxsb3cgc2VwYXJhdGUgY29uZmlndXJhdGlvbiBvZiB0aGUg dHJhbnNpdGlvbiBtZWNoYW5pc20NCj4gaW5zdGFuY2VzLiINCj4gPiBCYXJiYXJhDQo+ID4NCj4g Pj4g77u/LS0tLS1NZW5zYWplIG9yaWdpbmFsLS0tLS0NCj4gPj4NCj4gPj4gRGU6IEFsZWphbmRy byBEJ0VnaWRpbyA8YWRlZ2lkaW9AdGVsZWNlbnRyby5uZXQuYXI+DQo+ID4gLi4uLiBzbmlwcGlu ZyByZWxldmFudCB0ZXh0Li4uLi4NCj4gPj4gICAgID4gVGhlIGNhc2UgZm9yIGhhdmluZyBtdWx0 aXBsZSBJUHY0IHN1Ym5ldHMgKG9uZSBmb3IgZWFjaA0KPiA+PiBpbnRlcmZhY2UpLCBpcyBmZWFz aWJsZSwNCj4gPj4gICAgID4gYXMgeW91IHNheSwgYnkgaGF2aW5nIG11bHRpcGxlIGluc3RhbmNl cyBvZiB0aGUgTkFUNDYsIHdoaWNoIEkNCj4gPj4gdGhpbmsgaXMgbm90IGEgcHJvYmxlbS4NCj4g Pj4gICAgID4gSG93ZXZlciwgb3BlbiBxdWVzdGlvbiBpcyB2YWxpZCBhbHNvIGZvciBhbnkgb3Ro ZXIgSVB2NGFhUw0KPiBtZWNoYW5pc20uDQo+ID4+ICAgICA+IEknbSBub3Qgc3VyZSBpZiB3ZSB3 YW50IHRvIGhhdmUgdGhhdCBjYXNlIGNvbnNpZGVyZWQgYXMNCj4gPj4gc29tZXRoaW5nIHRoYXQg TVVTVCBiZSBzdXBwb3J0ZWQgYXMgb25lIG1vcmUgcmVxdWlyZW1lbnQsIGFuZCBpZiB0aGlzDQo+ IGlzIHRoZSBjYXNlLCBpdCB3aWxsIGJlIGENCj4gPj4gICAgID4gImdlbmVyYWwiIHRyYW5zaXRp b24gcmVxdWlyZW1lbnQsIGFuZCBubyBuZWVkIHRvIGdvIGluIHRoZQ0KPiA+PiBkZXRhaWxzIGZv ciBlYWNoIHRyYW5zaXRpb24gbWVjaGFuaXNtLCBvciB3ZSByZWFsbHkgd2FudCB0byBnbyB0byBk ZXNjcmliZQ0KPiBhIHNwZWNpZmljIG5ldw0KPiA+PiAgICAgPiByZXF1aXJlbWVudCBmb3IgdGhp cyBmb3IgZWFjaCB0cmFuc2l0aW9uIG1lY2hhbmlzbSAuLi4NCj4gPj4NCj4gPj4gICAgIEp1c3Qg a25vd2luZyB0aGF0IGEgQ1BFIGNhbiBoYXZlIGRpZmZlcmVudCBMQU4gSVB2NCBwcmVmaXhlcyBJ DQo+ID4+IHdhcyB0aGlua2luZyB0aGF0IG1heWJlIGl0IGNvdWxkIGJlIGNvbnNpZGVyZWQgaW4g R2VuZXJhbCB0cmFuc2l0aW9uDQo+ID4+IHJlcXVpcmVtZW50cyB3aXRoIHNvbWV0aGluZyBsaWtl Og0KPiA+Pg0KPiA+PiAgICAgIlRSQU5TLTY6IFRoZSBJUHY2IFRyYW5zaXRpb24gQ0UgUm91dGVy IE1BWSBoYXZlIGRpZmZlcmVudCBJUHY0DQo+ID4+IHByZWZpeGVzIG9uIGVhY2ggQ3VzdG9tZXIt RmFjaW5nIGludGVyZmFjZXMgYW5kIHRoZSB0cmFuc2l0aW9uDQo+ID4+IG1lY2hhbmlzbXMgTVVT VCBoYXZlIG9wdGlvbnMgdG8gYmUgY29tcGF0aWJsZSB3aXRoIGl0LiINCg== From nobody Thu Aug 9 13:33: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 54336131002 for ; Thu, 9 Aug 2018 13:33:35 -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 6NPQwINGBl1B for ; Thu, 9 Aug 2018 13:33:32 -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 A1139130FF8 for ; Thu, 9 Aug 2018 13:33:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1533846809; x=1534451609; 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=uBhm60CL agRHAT1/d5AT09Iv5LprrfECDLx9ClZWHdA=; b=SyYh+Zx0Fhol508g+xmNeC56 Ygn7871l3TKdpZA+0Qsl6uvy88m42GUXvg8jBqLCbfDIokZ/OWPwCy7MpudsO202 y9rVCiOR0/t6uDNWreC6hmEnIeP81lBGvFpt2NRSZQHNYI+l01zZf0uWMCGju9Ay Ll/mBMMaFH0hWEoIEe0= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 09 Aug 2018 22:33:29 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 09 Aug 2018 22:33:29 +0200 Received: from [10.20.5.175] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005834868.msg for ; Thu, 09 Aug 2018 22:33:28 +0200 X-MDRemoteIP: 10.8.10.6 X-MDHelo: [10.20.5.175] X-MDArrival-Date: Thu, 09 Aug 2018 22:33:28 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17593b5162=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.f.0.180709 Date: Thu, 09 Aug 2018 15:33:17 -0500 From: JORDI PALET MARTINEZ To: Fred Baker , , Message-ID: <16E6B022-D471-4F9C-B534-F891E6D2CBB1@consulintel.es> Thread-Topic: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas References: <788A2825-037A-4D84-9379-C0EB6F587FB9@gmail.com> In-Reply-To: <788A2825-037A-4D84-9379-C0EB6F587FB9@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 20:33:43 -0000 Hi Fred, After responding to you and reading Barbara comment I realized, that your 2= nd part doesn't work ... It is not about "multiple" transition mechanisms, it is about, it is about = multiple IPv4 ranges, so subnetting (and may be several NAT or NAT46 instan= ces). We explicitly decided not to consider that a single CE will simultaneously = run several transition mechanisms, because that may create a number of conf= licts, that doesn't make sense to take into consideration. (section 3.2) This document takes no position on simultaneous operation of one or several transition mechanisms and/or native IPv4. An ISP may want to have different customers in different "transition stages= " (from dual stack to IPv4aaS, or from one IPv4aaS to another), but simulta= neously the same CE ? So that's why I proposed this: The IPv6 Transition CE Router MAY support multiple IPv4 prefixes on its various customer-facing interfaces. In that case, it MUST support configuration of multiple instances of the relevant code of the transition mechanism and/or appropriate subnetting on each such interface. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Fred Baker Fecha: jueves, 9 de agosto de 2018, 15:24 Para: , Asunto: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas I sent this to Jordi privately. Would you agree with my construction? =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= / =20 English is your second language, and you do very well in it. However, a= s a native speaker, may I offer a friendly amendment? =20 TRANS-6: The IPv6 Transitional Router MAY be configured with multiple IPv4 prefi= xes on its various customer-facing interfaces. When so configured, it MUST support configuration of different transiti= on mechanisms on each such interface. =20 > On Aug 9, 2018, at 8:39 AM, JORDI PALET MARTINEZ wrote: >=20 > Hi Alejandro, >=20 >=20 >=20 > I think this may sort out your requirement: >=20 >=20 >=20 > TRANS-6: The IPv6 Transition CE Router MAY have multiple IPv4 >=20 > prefixes to be used in different customer-facing >=20 > interfaces, and the IPv6 Transition CE Router MUST support >=20 > multiple instances of the relevant transition mechanism >=20 > code, to allow configuring them. >=20 >=20 >=20 > Do you agree? >=20 >=20 >=20 > Regards, >=20 > Jordi >=20 >=20 >=20 >=20 >=20 >=20 >=20 > =EF=BB=BF-----Mensaje original----- >=20 > De: Alejandro D'Egidio >=20 > Fecha: martes, 31 de julio de 2018, 15:55 >=20 > Para: JORDI PALET MARTINEZ >=20 > CC: Ron Bonica , "v6ops@ietf.org list" >=20 > Asunto: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aa= s >=20 >=20 >=20 > Hello Jordi, >=20 > My notes in lines. >=20 >=20 >=20 > Regards, >=20 > Alejandro >=20 >=20 >=20 > ----- Mensaje original ----- >=20 >> De: "JORDI PALET MARTINEZ" >=20 >> Para: "Alejandro Degidio" , "Ron Bonica"= >=20 >> CC: "v6ops@ietf.org list" >=20 >> Enviados: Lunes, 30 de Julio 2018 20:58:52 >=20 >> Asunto: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4a= as >=20 >=20 >=20 >> Hi Alejandro, >=20 >=20 >=20 >=20 >> Thanks for the input! >=20 >=20 >=20 >=20 >> I think it is easy to understand: >=20 >=20 >> "This document covers a set of IP transition techniques required whe= n >=20 >=20 >> ISPs have an IPv6-only access network." >=20 >=20 >=20 >=20 >> even if the ISP already have an IPv6-only access network, or want to= have it. >=20 >=20 >=20 >=20 >> But this may be something that a native English speaker could tell u= s how better >=20 >> to say it. May be: >=20 >=20 >> "This document covers a set of IP transition techniques required whe= n >=20 >=20 >> ISPs have or want to move to an IPv6-only access network." >=20 >=20 >=20 > Yes, it's great. >=20 >=20 >=20 >=20 >> I'd some text in earlier versions about the reasons to have an IPv6-= only access >=20 >> network, but it was suggested to move it to the Annex A ... not sure= if you >=20 >> read them also. I'm happy to add some more text, if needed to the an= nex A to >=20 >> describe several possible reasons. >=20 >=20 >=20 >=20 > Yes, I've read all the document included the Annexes. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> The case for having multiple IPv4 subnets (one for each interface), = is feasible, >=20 >> as you say, by having multiple instances of the NAT46, which I think= is not a >=20 >> problem. >=20 >=20 >=20 >=20 >> However, open question is valid also for any other IPv4aaS mechanism= . >=20 >=20 >=20 >=20 >> I'm not sure if we want to have that case considered as something th= at MUST be >=20 >> supported as one more requirement, and if this is the case, it will = be a >=20 >> "general" transition requirement, and no need to go in the details f= or each >=20 >> transition mechanism, or we really want to go to describe a specific= new >=20 >> requirement for this for each transition mechanism ... >=20 >=20 >=20 >=20 > Just knowing that a CPE can have different LAN IPv4 prefixes I was = thinking that maybe it could be considered in General transition requiremen= ts with something like: >=20 >=20 >=20 > "TRANS-6: The IPv6 Transition CE Router MAY have different IPv4 pre= fixes on each Customer-Facing interfaces and the transition mechanisms MUST= have options to be compatible with it." >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> What others think? >=20 >=20 >=20 >=20 >> Regards, >=20 >=20 >> Jordi >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> =EF=BB=BF-----Mensaje original----- >=20 >=20 >> De: v6ops en nombre de Alejandro D'Egidio >=20 >> >=20 >=20 >> Fecha: lunes, 30 de julio de 2018, 10:39 >=20 >=20 >> Para: Ron Bonica >=20 >=20 >> CC: "v6ops@ietf.org list" >=20 >=20 >> Asunto: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4a= as >=20 >=20 >=20 >=20 >> Hello Ron, >=20 >=20 >> I really like this draft! >=20 >=20 >> Just a simple comment. >=20 >=20 >> Where says: >=20 >=20 >> This document covers a set of IP transition techniques required whe= n >=20 >=20 >> ISPs have an IPv6-only access network. >=20 >=20 >=20 >=20 >> Maybe could say: >=20 >=20 >> This document covers a set of IP transition techniques required whe= n >=20 >=20 >> ISPs wants to have an IPv6-only access network. >=20 >=20 >=20 >=20 >> Maybe you can include some example of why ISPs wants to have an IPv= 6 only access >=20 >> network. >=20 >=20 >> For example, in my case, as we don't have more public IPv4 addresse= s and we have >=20 >> IPv6 developed, why should I need to continue managing IPv4 address= es? >=20 >=20 >> Maybe some kind of this scenario could be included. >=20 >=20 >=20 >=20 >> Regarding 3.2.1. 464XLAT: >=20 >=20 >> Cablelabs defines that the CableModem must subnet the IPv6 Prefix r= eceived from >=20 >> ISP to use different subnets on each LAN Interface. The size of IPv= 6 "sub" >=20 >> prefix on each LAN depends on is ISP configured the CM to use eithe= r favor >=20 >> depth or favor width. If ISP provides just a /64 IPv6 prefix (which= is not >=20 >> recommended) CM must share it with all LAN interfaces. >=20 >=20 >=20 >=20 >> For IPv4, by the same private IPv4 prefix is shared between all LAN= interfaces >=20 >> (customer-facing interfaces). For this case I think it "3.2.1. 464= XLAT" is ok. >=20 >=20 >> There are some cases where CM could have different private IPv4 pre= fixes to each >=20 >> customer-facing interfaces. So I think, this is another scenario th= at should be >=20 >> covered where CLAT will need to work with all the IPv4 LAN prefixes= . Maybe >=20 >> running multiple instances of its NAT46 (one for each LAN interface= ) or one >=20 >> instance supporting multiple IPv4 addresses. >=20 >=20 >=20 >=20 >> All this is in: >=20 >> https://apps.cablelabs.com/specification/ipv4-and-ipv6-erouter-spec= ification/ >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> Regards, >=20 >=20 >> ALEJANDRO D'EGIDIO >=20 >=20 >> Jefe de Ingenier=C3=ADa de Backbone | Direcci=C3=B3n de Ingenier=C3= =ADa >=20 >=20 >> M: [ callto:+54 911 5794-1589 | +54 911 5794-1589 ] | F: [ callto:+= 54 11 >=20 >> 3977-1025 | +54 11 3977-1025 ] | [ mailto:adegidio@telecentro.net.a= r | >=20 >> adegidio@telecentro.net.ar ] >=20 >=20 >> Pje. Lavard=C3=A9n 157. Piso 3. CABA (C1437FBC) >=20 >=20 >=20 >=20 >> ----- Mensaje original ----- >=20 >=20 >> De: "Ron Bonica" >=20 >=20 >> Para: "v6ops@ietf.org list" >=20 >=20 >> Enviados: Lunes, 30 de Julio 2018 10:12:50 >=20 >=20 >> Asunto: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas >=20 >=20 >=20 >=20 >> Folks, >=20 >=20 >=20 >=20 >> Each week between now and IETF 103, we will review and discuss one = draft with an >=20 >> eye towards progressing it. >=20 >=20 >=20 >=20 >> This week, please review and comment on draft-ietf-v6ops-transition= -ipv4aas. >=20 >=20 >=20 >=20 >> Fred and Ron >=20 >=20 >=20 >=20 >> _______________________________________________ >=20 >=20 >> v6ops mailing list >=20 >=20 >> v6ops@ietf.org >=20 >=20 >> https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 >> _______________________________________________ >=20 >=20 >> v6ops mailing list >=20 >=20 >> v6ops@ietf.org >=20 >=20 >> https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> ********************************************** >=20 >> IPv4 is over >=20 >> Are you ready for the new Internet ? >=20 >> http://www.consulintel.es >=20 >> The IPv6 Company >=20 >=20 >> This electronic message contains information which may be privileged= or >=20 >> confidential. The information is intended to be for the exclusive us= e of the >=20 >> individual(s) named above and further non-explicilty authorized disc= losure, >=20 >> copying, distribution or use of the contents of this information, ev= en if >=20 >> partially, including attached files, is strictly prohibited and will= be >=20 >> considered a criminal offense. If you are not the intended recipient= be aware >=20 >> that any disclosure, copying, distribution or use of the contents of= this >=20 >> information, even if partially, including attached files, is strictl= y >=20 >> prohibited, will be considered a criminal offense, so you must reply= to the >=20 >> original sender to inform about this communication and delete it. >=20 >=20 >=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= 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. >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops =20 -----------------------------------------------------------------------= --------- The fact that there is a highway to hell and a stairway to heaven is an= interesting comment on projected traffic volume... =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 Aug 9 13:37: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 48A02130EBE for ; Thu, 9 Aug 2018 13:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 1PNpnk9nFenz for ; Thu, 9 Aug 2018 13:37:12 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 A343D130E77 for ; Thu, 9 Aug 2018 13:37:12 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w79KZ5R5016217; Thu, 9 Aug 2018 16:37:07 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 2krvkhga5y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Aug 2018 16:37:06 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w79Kb6M8004943; Thu, 9 Aug 2018 16:37:06 -0400 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [135.47.91.189]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w79Kb3jY004922; Thu, 9 Aug 2018 16:37:04 -0400 Received: from zlp30483.vci.att.com (zlp30483.vci.att.com [127.0.0.1]) by zlp30483.vci.att.com (Service) with ESMTP id EFCFE4014668; Thu, 9 Aug 2018 20:37:03 +0000 (GMT) Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (unknown [130.8.218.156]) by zlp30483.vci.att.com (Service) with ESMTPS id D8A4F4014665; Thu, 9 Aug 2018 20:37:03 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0408.000; Thu, 9 Aug 2018 16:37:03 -0400 From: "STARK, BARBARA H" To: "'JORDI PALET MARTINEZ'" , Richard Patterson CC: "v6ops@ietf.org list" Thread-Topic: [v6ops] Review of draft-ietf-v6ops-transition-ipv4aas-05 Thread-Index: AdQgS3QgQiNxrFhHTyqVBUzs4Ev5DQAKEf+AAAFoKQAAAuaD4AA2avYAAEx/aQAAMcH0gAMu/ikAAAEMToAACiBGgAAH6exA Date: Thu, 9 Aug 2018 20:37:03 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DE69153@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <787AE7BB302AE849A7480A190F8B93302DF66859@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302DF66983@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2D09D61DDFA73D4C884805CC7865E6114DE43A3D@GAALPA1MSGUSRBF.ITServices.sbc.com> <2D09D61DDFA73D4C884805CC7865E6114DE4D923@GAALPA1MSGUSRBF.ITServices.sbc.com> <19402025-57D9-4F6A-99FE-8563CAD41CE9@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DE6901D@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.248.179] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-09_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808090205 Archived-At: Subject: Re: [v6ops] Review of draft-ietf-v6ops-transition-ipv4aas-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 20:37:16 -0000 WWVzLCB0aGF0J3Mgd2hhdCBJIHByb3Bvc2UuIEkgdGhpbmsgUmljaGFyZCBuZWVkcyB0byBzYXkg d2hldGhlciBpdCdzIG9rIGZvciBoaW0uDQpCYXJiYXJhDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogSk9SREkgUEFMRVQgTUFSVElORVogPGpvcmRpLnBhbGV0QGNvbnN1 bGludGVsLmVzPg0KPiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDA5LCAyMDE4IDQ6MjMgUE0NCj4g VG86IFNUQVJLLCBCQVJCQVJBIEggPGJzNzY1MkBhdHQuY29tPjsgUmljaGFyZCBQYXR0ZXJzb24N Cj4gPHJpY2hhcmRAaGVsaXgubmV0Lm56Pg0KPiBDYzogdjZvcHNAaWV0Zi5vcmcgbGlzdCA8djZv cHNAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIFJldmlldyBvZiBkcmFmdC1pZXRm LXY2b3BzLXRyYW5zaXRpb24taXB2NGFhcy0wNQ0KPiANCj4gTGV0J3Mgc2VlIGlmIEkgZ290IGl0 IHJpZ2h0Og0KPiANCj4gDQo+IA0KPiA1LiAgVVBuUCBTdXBwb3J0DQo+IA0KPiANCj4gDQo+ICAg IElmIHRoZSBVUG5QIFdBTklQQ29ubmVjdGlvbjoyIHNlcnZpY2UgW1VQblAtV0FOSVBDXSBpcyBl bmFibGVkIG9uIGENCj4gDQo+ICAgIENFIHJvdXRlciwgYnV0IGNhbm5vdCBiZSBhc3NvY2lhdGVk IHdpdGggYW4gSVB2NCBpbnRlcmZhY2UNCj4gDQo+ICAgIGVzdGFibGlzaGVkIGJ5IGFuIElQdjRh YVMgbWVjaGFuaXNtIG9yIGNhbm5vdCBkZXRlcm1pbmUgd2hpY2ggcG9ydHMNCj4gDQo+ICAgIGFy ZSBhdmFpbGFibGUgKHRocm91Z2ggUENQIG9yIGFjY2VzcyB0byBhIGNvbmZpZ3VyZWQgcG9ydCBz ZXQsIGlmIHRoZQ0KPiANCj4gICAgSVB2NGFhUyBtZWNoYW5pc20gbGltaXRzIHRoZSBhdmFpbGFi bGUgcG9ydHMpLCBhbiBBZGRQb3J0TWFwcGluZygpIG9yDQo+IA0KPiAgICBBZGRBbnlQb3J0TWFw cGluZygpIGFjdGlvbiBNVVNUIGJlIHJlamVjdGVkIHdpdGggZXJyb3IgY29kZSA3MjkNCj4gDQo+ ICAgICJDb25mbGljdFdpdGhPdGhlck1lY2hhbmlzbXMiLg0KPiANCj4gDQo+IA0KPiAgICBBbiBB ZGRQb3J0TWFwcGluZygpIHJlcXVlc3QgZm9yIGEgcG9ydCB0aGF0IGlzIG5vdCBhdmFpbGFibGUg TVVTVA0KPiANCj4gICAgcmVzdWx0IGluICJDb25mbGljdEluTWFwcGluZ0VudHJ5Ii4NCj4gDQo+ IA0KPiANCj4gICAgTm90ZSB0aGF0IElHRDoxIGFuZCBpdHMgV0FOSVBDb25uZWN0aW9uOjEgc2Vy dmljZSBoYXZlIGJlZW4NCj4gDQo+ICAgIGRlcHJlY2F0ZWQgYnkgT0NGLg0KPiANCj4gDQo+IA0K PiAgIFtVUG5QLVdBTklQQ10NCj4gDQo+ICAgICAgICAgICAgICAgVVBuUCBGb3J1bSwgIldBTklQ Q29ubmVjdGlvbjoyIFNlcnZpY2UiLCBEZWNlbWJlciAyMDEwLA0KPiANCj4gICAgICAgICAgICAg ICA8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtDQo+IDNB X191cG5wLm9yZ19zcGVjc19nd18mZD1Ed0lGYVEmYz1MRllaLQ0KPiBvOV9IVU1lTVRTUWljdmpJ ZyZyPUxvR3poQy0NCj4gOHNjOFNZOFRxNHZyZm9nJm09Q216bXVZMlEwcDZEOVhfWU5DUkhwaV92 T0lmVUtUMi0NCj4gTk9RT3BQaWlHa0Emcz1yZlVjd1lwdzdnN3ZDVHdWWncyQy0tUmRfa3BOYkct YkMzUzdRSVBYVFNBJmU9DQo+IA0KPiAgICAgICAgICAgICAgIFVQblAtZ3ctV0FOSVBDb25uZWN0 aW9uLXYyLVNlcnZpY2UucGRmPi4NCj4gDQo+IA0KPiANCj4gUmVnYXJkcywNCj4gDQo+IEpvcmRp DQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiDvu78tLS0tLU1lbnNhamUgb3JpZ2luYWwt LS0tLQ0KPiANCj4gRGU6ICJTVEFSSywgQkFSQkFSQSBIIiA8YnM3NjUyQGF0dC5jb20+DQo+IA0K PiBGZWNoYToganVldmVzLCA5IGRlIGFnb3N0byBkZSAyMDE4LCAxNTowNw0KPiANCj4gUGFyYTog J0pPUkRJIFBBTEVUIE1BUlRJTkVaJyA8am9yZGkucGFsZXRAY29uc3VsaW50ZWwuZXM+LCBSaWNo YXJkDQo+IFBhdHRlcnNvbiA8cmljaGFyZEBoZWxpeC5uZXQubno+DQo+IA0KPiBDQzogInY2b3Bz QGlldGYub3JnIGxpc3QiIDx2Nm9wc0BpZXRmLm9yZz4NCj4gDQo+IEFzdW50bzogUkU6IFt2Nm9w c10gUmV2aWV3IG9mIGRyYWZ0LWlldGYtdjZvcHMtdHJhbnNpdGlvbi1pcHY0YWFzLTA1DQo+IA0K PiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAgICAgPiBIaSBSaWNoYXJkLCBCYXJiYXJhLA0KPiAN Cj4gICAgID4NCj4gDQo+ICAgICA+IFRoYW5rcyBhbmQgc29ycnksIEknbSBsYXRlIHJlYWN0aW5n IHRvIHRoaXMsIHdvcmtpbmcgaW4gYSBuZXcgdmVyc2lvbg0KPiBkdXJpbmcNCj4gDQo+ICAgICA+ IHRoZSB3ZWVrZW5kLCBmb2xsb3dpbmcgUm9uIGFkdmlzZSwgaW4gb3JkZXIgdG8gZ28gZm9yIGEg bGFzdC1jYWxsLg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+IExldCBtZSB0cnkgdG8gc3VtbWFy aXplIHdoYXQgeW91IGFyZSBzYXlpbmcgd2l0aCBhIHByb3Bvc2VkIHRleHQgKGJhc2ljDQo+IA0K PiAgICAgPiBpZGVhLCByZW1vdmUgc3VwZXJmbHVvdXMgdGV4dCBhbmQgb25seSBzdGF0ZSB3aGF0 IG1heSBiZSBub3Qgb2J2aW91cw0KPiBmb3IgYW4NCj4gDQo+ICAgICA+IGltcGxlbWVudG9yLCB0 aGF0IGFscmVhZHkgbXVzdCBrbm93IGFib3V0IFVQblAgYW5kIGhhcyByZWFkIHRoZSByZXN0DQo+ IG9mDQo+IA0KPiAgICAgPiB0aGUgZG9jdW1lbnQgLi4uKS4gTGV0IG1lIGtub3cgaWYgSSBtaXNz ZWQgYW55dGhpbmc6DQo+IA0KPiAgICAgLS0tLS0tLS0tLSBzbmlwIC0tLS0tLS0tLQ0KPiANCj4g ICAgID4gTmV3IHRleHQ6DQo+IA0KPiAgICAgPiA1LiAgVVBuUCBTdXBwb3J0DQo+IA0KPiAgICAg Pg0KPiANCj4gICAgID4gSWYgdGhlIFtVUG5QIFdBTklQQ29ubmVjdGlvbjoyXSBzZXJ2aWNlIGlz IGVuYWJsZWQgb24gYSBDRSByb3V0ZXIsDQo+IA0KPiAgICAgPiBidXQgY2Fubm90IGJlIGFzc29j aWF0ZWQgd2l0aCBhbiBJUHY0IGludGVyZmFjZSBlc3RhYmxpc2hlZCBieSBhbg0KPiANCj4gICAg ID4gSVB2NGFhcyBtZWNoYW5pc20gb3IgY2Fubm90IGludGVyd29yayB3aXRoIFBDUCBvciBhIGNv bmZpZ3VyZWQNCj4gDQo+ICAgICA+IHBvcnQgc2V0LCBhbiBBZGRQb3J0TWFwcGluZygpIG9yIEFk ZEFueVBvcnRNYXBwaW5nKCkgYWN0aW9uDQo+IA0KPiAgICAgPiBNVVNUIGJlIHJlamVjdGVkIHdp dGggZXJyb3IgY29kZSA3MjkgIkNvbmZsaWN0V2l0aE90aGVyTWVjaGFuaXNtcyIuDQo+IA0KPiAg ICAgPiBOb3RlIHRoYXQgSUdEOjEgYW5kIGl0cyBXQU5JUENvbm5lY3Rpb246MSBzZXJ2aWNlIGhh dmUgYmVlbg0KPiANCj4gICAgID4gZGVwcmVjYXRlZCBieSBPQ0YuDQo+IA0KPiANCj4gDQo+ICAg ICBJIHRoaW5rIFJpY2hhcmQgaGFkIHNvbWUgY29uY2VybnMgd2l0aCB0aGlzIGxhbmd1YWdlICh3 aGljaCBpcyB0aGUgbGFuZ3VhZ2UNCj4gSSBwcm9wb3NlZCkuIEkgd2VudCBhbmQgZm91bmQgd2hh dCBSaWNoYXJkIHNhaWQ6DQo+IA0KPiANCj4gDQo+ICAgICA8UlA+ICJpbnRlcndvcmsgd2l0aCBb Li4uXSAgYSBjb25maWd1cmVkIHBvcnQgc2V0IiBpcyB0b28gdmFndWUgZm9yIG15IGxpa2luZy4N Cj4gSXQncyBub3QgY2xlYXIgdGhhdCB0aGlzIG1lYW5zIGl0IHNob3VsZCByZWplY3QNCj4gDQo+ ICAgICBBZGRQb3J0TWFwcGluZygpIHJlcXVlc3RzIGZvciBhIHBvcnQgb3V0c2lkZSBvZiB0aGUg cG9ydCBzZXQsIG9yIHByb3ZpZGUNCj4gYW4gYWx0ZXJuYXRpdmUgcG9ydCB3aGVuIHJlcXVlc3Rl ZCB3aXRoIEFkZEFueVBvcnRNYXBwaW5nKCkuDQo+IA0KPiAgICAgSSdkIGxpa2UgdG8gc2VlIHRo aXMgZWxhYm9yYXRlZCBhIGJpdCBtb3JlIG9uLg0KPiANCj4gICAgIFdoaWxzdCBJR0Q6MSBpcyBk ZXByZWNhdGVkLCBpdCBpcyB3aGF0J3Mgb3V0IHRoZXJlIHNvIHdlIG5lZWQgdG8gbWFrZSBzdXJl DQo+IHRvIGNhcHR1cmUgdGhlIEFkZFBvcnRNYXBwaW5nKCkgYmVoYXZpb3VyIGNvcnJlY3RseS4g IEV2ZW4gd2hlbiBuZXdlcg0KPiBDUEVzIHN0YXJ0IHN1cHBvcnRpbmcgSUdEOjIgKG1vc3QgYXJl IHN0aWxsIGRyYWdnaW5nIHRoZWlyIGhlYWxzIElNRSksIGl0DQo+IHJlcXVpcmVzIGFwcGxpY2F0 aW9ucyB0byBhbHNvIGFsdGVyIHRoZWlyIGJlaGF2aW91ciB0byBtYWtlIHVzZSBvZiB0aGUgbmV3 DQo+IEFkZEFueVBvcnRNYXBwaW5nKCkgZnVuY3Rpb24uPC9SUD4NCj4gDQo+IA0KPiANCj4gICAg IFRvIGFkZHJlc3MgUmljaGFyZCdzIGZpcnN0IGNvbmNlcm4sIHBlcmhhcHMgcmVwbGFjZSAib3Ig Y2Fubm90IGludGVyd29yaw0KPiB3aXRoIFBDUCBvciBhIGNvbmZpZ3VyZWQgcG9ydCBzZXQiIHdp dGggIm9yIGNhbm5vdCBkZXRlcm1pbmUgd2hpY2ggcG9ydHMgYXJlDQo+IGF2YWlsYWJsZSAodGhy b3VnaCBQQ1Agb3IgYWNjZXNzIHRvIGEgY29uZmlndXJlZCBwb3J0IHNldCwgaWYgdGhlIElQdmFh cw0KPiBtZWNoYW5pc20gbGltaXRzIHRoZSBhdmFpbGFibGUgcG9ydHMpIi4NCj4gDQo+IA0KPiAN Cj4gICAgIFRvIGFkZHJlc3MgQWRkUG9ydE1hcHBpbmcoKSBmYWlsdXJlcywgSSBzdWdnZXN0IGFk ZGluZyBhIHNlbnRlbmNlIChiZWZvcmUNCj4gdGhlIGxhc3Qgc2VudGVuY2UpIHRoYXQgc2F5cyAi QW4gQWRkUG9ydE1hcHBpbmcoKSByZXF1ZXN0IGZvciBhIHBvcnQgdGhhdCBpcw0KPiBub3QgYXZh aWxhYmxlIE1VU1QgcmVzdWx0IGluICJDb25mbGljdEluTWFwcGluZ0VudHJ5LiINCj4gDQo+IA0K PiANCj4gICAgIEJhcmJhcmENCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+IElQdjQgaXMgb3Zl cg0KPiBBcmUgeW91IHJlYWR5IGZvciB0aGUgbmV3IEludGVybmV0ID8NCj4gaHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtDQo+IDNBX193d3cuY29uc3VsaW50 ZWwuZXMmZD1Ed0lGYVEmYz1MRllaLQ0KPiBvOV9IVU1lTVRTUWljdmpJZyZyPUxvR3poQy0NCj4g OHNjOFNZOFRxNHZyZm9nJm09Q216bXVZMlEwcDZEOVhfWU5DUkhwaV92T0lmVUtUMi0NCj4gTk9R T3BQaWlHa0Emcz1JREpoUG9EcmhYNHZIU3k2WnBKaWhqb210eFg5VlI4QUhpcEt0ejdzSk13JmU9 DQo+IFRoZSBJUHY2IENvbXBhbnkNCj4gDQo+IFRoaXMgZWxlY3Ryb25pYyBtZXNzYWdlIGNvbnRh aW5zIGluZm9ybWF0aW9uIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yDQo+IGNvbmZpZGVudGlh bC4gVGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVkIHRvIGJlIGZvciB0aGUgZXhjbHVzaXZlIHVz ZSBvZiB0aGUNCj4gaW5kaXZpZHVhbChzKSBuYW1lZCBhYm92ZSBhbmQgZnVydGhlciBub24tZXhw bGljaWx0eSBhdXRob3JpemVkIGRpc2Nsb3N1cmUsDQo+IGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBv ciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24sIGV2ZW4gaWYNCj4gcGFy dGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQg YW5kIHdpbGwgYmUgY29uc2lkZXJlZCBhDQo+IGNyaW1pbmFsIG9mZmVuc2UuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgYmUgYXdhcmUgdGhhdCBhbnkNCj4gZGlzY2xvc3Vy ZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBp bmZvcm1hdGlvbiwNCj4gZXZlbiBpZiBwYXJ0aWFsbHksIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxl cywgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCwgd2lsbCBiZQ0KPiBjb25zaWRlcmVkIGEgY3JpbWlu YWwgb2ZmZW5zZSwgc28geW91IG11c3QgcmVwbHkgdG8gdGhlIG9yaWdpbmFsIHNlbmRlciB0bw0K PiBpbmZvcm0gYWJvdXQgdGhpcyBjb21tdW5pY2F0aW9uIGFuZCBkZWxldGUgaXQuDQo+IA0KPiAN Cg0K From nobody Thu Aug 9 13:39: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 1CAC4130EBE for ; Thu, 9 Aug 2018 13:39:07 -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 XVbBNcSvFlTH for ; Thu, 9 Aug 2018 13:39:04 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::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 BFFBB130E8A for ; Thu, 9 Aug 2018 13:39:03 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id k12-v6so12143022oiw.8 for ; Thu, 09 Aug 2018 13:39:03 -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=1PkRXjB+h3dZXqkSZa8sRaUotCJ8NGXIMQuPyhAFhMo=; b=o17JG2wvug1DLK5nnL9jTSxiRdloNmXec8LopAtJC/p25RlRIjIb5cGVChpc6Qktmb N1ZPSZpqg4DswjfO1jK2cwqWc2wPfpCtv93Ie1zjAjlX6eCjG/aNorRNqVI/UGI3sfnT RgTeZ6JdhWS7qGtuT/iau2OWQ69/OxG/NJDco7pNJYWDjDuxU4isI+DLgaNKwn+w40BW pfdj5tEOeskqeLkaadfcYvq6AU1eNBCEr5/P9xdJJuYI4dZb1fF3qsd8gjJttkTfIrje DZK0YgRbhQvGpSotWrYiBpuDZsq46DICeW8mLqc3XNU1Ldar2mz/x9WfK2sxXk6o+49m HyQA== 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=1PkRXjB+h3dZXqkSZa8sRaUotCJ8NGXIMQuPyhAFhMo=; b=DgKCztYE8gDywu1EIxrHvXX/LsLq28Ezu74uMlr7sNcTMQv/6xp3ecWT4zaVReD/6L SqIB/487Bo502HpQNc3QfthnZCAhx/aZgfKNyZ7AYwFRBJfoBjGz6cM2GytXzKeBfM70 YwdHYGIfmrtUyndYb6hXAOrgnIxANPdDawZv0jUlPP/Fvg694JdvZiBqtltZOzgGmeRm ZBkG5N9yC5RPDmQe630u4iHYUeQZMkFKNTPQWMvJ+g3eFGVdKSUiEUz2ndthjW90pxyL TEahxlKLcF7qkCPVVDJOUfxDHlesFKKOv4qNdX9ydCOd4PzIleZhRNw3rhZTw1opmOhb 3nAQ== X-Gm-Message-State: AOUpUlEAxR8Sp7pmlPL416UyIK9x6rar7GSWMmjOO3ekuwlGdDnioszd Cm709q+b9952ACaPanyTmRAL86z/ X-Google-Smtp-Source: AA+uWPyJbTr2eL526Mdz4UXfCioEuG/BAT+uLCNO43J6J3kyDAAhC236DjlAsW20D5mRbduZTg6FCw== X-Received: by 2002:aca:c5d8:: with SMTP id v207-v6mr3862653oif.264.1533847142789; Thu, 09 Aug 2018 13:39:02 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::101f? ([2600:8802:5600:1546::101f]) by smtp.gmail.com with ESMTPSA id f144-v6sm11876721oib.39.2018.08.09.13.39.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Aug 2018 13:39:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Fred Baker X-Mailer: iPhone Mail (16A5339e) In-Reply-To: <16E6B022-D471-4F9C-B534-F891E6D2CBB1@consulintel.es> Date: Thu, 9 Aug 2018 13:39:00 -0700 Cc: bs7652@att.com, v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1BF25695-2CE8-411F-B508-E3F23C2DD5CB@gmail.com> References: <788A2825-037A-4D84-9379-C0EB6F587FB9@gmail.com> <16E6B022-D471-4F9C-B534-F891E6D2CBB1@consulintel.es> To: JORDI PALET MARTINEZ Archived-At: Subject: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 20:39:08 -0000 No problem. Massage it appropriately. That goes to the clarity of the langua= ge I was trying to restate ;-) Sent using a machine that autocorrects in interesting ways... > On Aug 9, 2018, at 1:33 PM, JORDI PALET MARTINEZ wrote: >=20 > Hi Fred, >=20 >=20 >=20 > After responding to you and reading Barbara comment I realized, that your 2= nd part doesn't work ... >=20 >=20 >=20 > It is not about "multiple" transition mechanisms, it is about, it is about= multiple IPv4 ranges, so subnetting (and may be several NAT or NAT46 instan= ces). >=20 >=20 >=20 > We explicitly decided not to consider that a single CE will simultaneously= run several transition mechanisms, because that may create a number of conf= licts, that doesn't make sense to take into consideration. >=20 > (section 3.2) >=20 > This document takes no position on simultaneous operation of one or >=20 > several transition mechanisms and/or native IPv4. >=20 >=20 >=20 > An ISP may want to have different customers in different "transition stage= s" (from dual stack to IPv4aaS, or from one IPv4aaS to another), but simulta= neously the same CE ? >=20 >=20 >=20 > So that's why I proposed this: >=20 >=20 >=20 > The IPv6 Transition CE Router MAY support multiple IPv4 prefixes >=20 > on its various customer-facing interfaces. In that case, it MUST >=20 > support configuration of multiple instances of the relevant code >=20 > of the transition mechanism and/or appropriate subnetting >=20 > on each such interface. >=20 >=20 >=20 > Regards, >=20 > Jordi >=20 >=20 >=20 >=20 >=20 >=20 >=20 > =EF=BB=BF-----Mensaje original----- >=20 > De: v6ops en nombre de Fred Baker >=20 > Fecha: jueves, 9 de agosto de 2018, 15:24 >=20 > Para: , >=20 > Asunto: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas >=20 >=20 >=20 > I sent this to Jordi privately. Would you agree with my construction? >=20 > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94/ >=20 >=20 >=20 > English is your second language, and you do very well in it. However, a= s a native speaker, may I offer a friendly amendment? >=20 >=20 >=20 > TRANS-6: >=20 > The IPv6 Transitional Router MAY be configured with multiple IPv4 prefi= xes on its various customer-facing interfaces. >=20 > When so configured, it MUST support configuration of different transiti= on mechanisms on each such interface. >=20 >=20 >=20 >>> On Aug 9, 2018, at 8:39 AM, JORDI PALET MARTINEZ wrote: >>=20 >>=20 >=20 >> Hi Alejandro, >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >> I think this may sort out your requirement: >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >> TRANS-6: The IPv6 Transition CE Router MAY have multiple IPv4 >=20 >>=20 >=20 >> prefixes to be used in different customer-facing >=20 >>=20 >=20 >> interfaces, and the IPv6 Transition CE Router MUST support >=20 >>=20 >=20 >> multiple instances of the relevant transition mechanism >=20 >>=20 >=20 >> code, to allow configuring them. >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >> Do you agree? >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >> Regards, >=20 >>=20 >=20 >> Jordi >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >> =EF=BB=BF-----Mensaje original----- >=20 >>=20 >=20 >> De: Alejandro D'Egidio >=20 >>=20 >=20 >> Fecha: martes, 31 de julio de 2018, 15:55 >=20 >>=20 >=20 >> Para: JORDI PALET MARTINEZ >=20 >>=20 >=20 >> CC: Ron Bonica , "v6ops@ietf.org list" >=20 >>=20 >=20 >> Asunto: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >> Hello Jordi, >=20 >>=20 >=20 >> My notes in lines. >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >> Regards, >=20 >>=20 >=20 >> Alejandro >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >> ----- Mensaje original ----- >=20 >>=20 >=20 >>> De: "JORDI PALET MARTINEZ" >=20 >>=20 >=20 >>> Para: "Alejandro Degidio" , "Ron Bonica" >=20 >>=20 >=20 >>> CC: "v6ops@ietf.org list" >=20 >>=20 >=20 >>> Enviados: Lunes, 30 de Julio 2018 20:58:52 >=20 >>=20 >=20 >>> Asunto: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>> Hi Alejandro, >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>> Thanks for the input! >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>> I think it is easy to understand: >=20 >>=20 >=20 >>=20 >=20 >>> "This document covers a set of IP transition techniques required when >=20 >>=20 >=20 >>=20 >=20 >>> ISPs have an IPv6-only access network." >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>> even if the ISP already have an IPv6-only access network, or want to hav= e it. >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>> But this may be something that a native English speaker could tell us ho= w better >=20 >>=20 >=20 >>> to say it. May be: >=20 >>=20 >=20 >>=20 >=20 >>> "This document covers a set of IP transition techniques required when >=20 >>=20 >=20 >>=20 >=20 >>> ISPs have or want to move to an IPv6-only access network." >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >> Yes, it's great. >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>> I'd some text in earlier versions about the reasons to have an IPv6-only= access >=20 >>=20 >=20 >>> network, but it was suggested to move it to the Annex A ... not sure if y= ou >=20 >>=20 >=20 >>> read them also. I'm happy to add some more text, if needed to the annex A= to >=20 >>=20 >=20 >>> describe several possible reasons. >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >> Yes, I've read all the document included the Annexes. >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>> The case for having multiple IPv4 subnets (one for each interface), is f= easible, >=20 >>=20 >=20 >>> as you say, by having multiple instances of the NAT46, which I think is n= ot a >=20 >>=20 >=20 >>> problem. >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>> However, open question is valid also for any other IPv4aaS mechanism. >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>> I'm not sure if we want to have that case considered as something that M= UST be >=20 >>=20 >=20 >>> supported as one more requirement, and if this is the case, it will be a= >=20 >>=20 >=20 >>> "general" transition requirement, and no need to go in the details for e= ach >=20 >>=20 >=20 >>> transition mechanism, or we really want to go to describe a specific new= >=20 >>=20 >=20 >>> requirement for this for each transition mechanism ... >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >> Just knowing that a CPE can have different LAN IPv4 prefixes I was think= ing that maybe it could be considered in General transition requirements wit= h something like: >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >> "TRANS-6: The IPv6 Transition CE Router MAY have different IPv4 prefixes= on each Customer-Facing interfaces and the transition mechanisms MUST have o= ptions to be compatible with it." >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>> What others think? >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>> Regards, >=20 >>=20 >=20 >>=20 >=20 >>> Jordi >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>> =EF=BB=BF-----Mensaje original----- >=20 >>=20 >=20 >>=20 >=20 >>> De: v6ops en nombre de Alejandro D'Egidio >=20 >>=20 >=20 >>> >=20 >>=20 >=20 >>=20 >=20 >>> Fecha: lunes, 30 de julio de 2018, 10:39 >=20 >>=20 >=20 >>=20 >=20 >>> Para: Ron Bonica >=20 >>=20 >=20 >>=20 >=20 >>> CC: "v6ops@ietf.org list" >=20 >>=20 >=20 >>=20 >=20 >>> Asunto: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>> Hello Ron, >=20 >>=20 >=20 >>=20 >=20 >>> I really like this draft! >=20 >>=20 >=20 >>=20 >=20 >>> Just a simple comment. >=20 >>=20 >=20 >>=20 >=20 >>> Where says: >=20 >>=20 >=20 >>=20 >=20 >>> This document covers a set of IP transition techniques required when >=20 >>=20 >=20 >>=20 >=20 >>> ISPs have an IPv6-only access network. >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>> Maybe could say: >=20 >>=20 >=20 >>=20 >=20 >>> This document covers a set of IP transition techniques required when >=20 >>=20 >=20 >>=20 >=20 >>> ISPs wants to have an IPv6-only access network. >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>> Maybe you can include some example of why ISPs wants to have an IPv6 onl= y access >=20 >>=20 >=20 >>> network. >=20 >>=20 >=20 >>=20 >=20 >>> For example, in my case, as we don't have more public IPv4 addresses and= we have >=20 >>=20 >=20 >>> IPv6 developed, why should I need to continue managing IPv4 addresses? >=20 >>=20 >=20 >>=20 >=20 >>> Maybe some kind of this scenario could be included. >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>> Regarding 3.2.1. 464XLAT: >=20 >>=20 >=20 >>=20 >=20 >>> Cablelabs defines that the CableModem must subnet the IPv6 Prefix receiv= ed from >=20 >>=20 >=20 >>> ISP to use different subnets on each LAN Interface. The size of IPv6 "su= b" >=20 >>=20 >=20 >>> prefix on each LAN depends on is ISP configured the CM to use either fav= or >=20 >>=20 >=20 >>> depth or favor width. If ISP provides just a /64 IPv6 prefix (which is n= ot >=20 >>=20 >=20 >>> recommended) CM must share it with all LAN interfaces. >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>> For IPv4, by the same private IPv4 prefix is shared between all LAN inte= rfaces >=20 >>=20 >=20 >>> (customer-facing interfaces). For this case I think it "3.2.1. 464XLAT"= is ok. >=20 >>=20 >=20 >>=20 >=20 >>> There are some cases where CM could have different private IPv4 prefixes= to each >=20 >>=20 >=20 >>> customer-facing interfaces. So I think, this is another scenario that sh= ould be >=20 >>=20 >=20 >>> covered where CLAT will need to work with all the IPv4 LAN prefixes. May= be >=20 >>=20 >=20 >>> running multiple instances of its NAT46 (one for each LAN interface) or o= ne >=20 >>=20 >=20 >>> instance supporting multiple IPv4 addresses. >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>> All this is in: >=20 >>=20 >=20 >>> https://apps.cablelabs.com/specification/ipv4-and-ipv6-erouter-specifica= tion/ >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>> Regards, >=20 >>=20 >=20 >>=20 >=20 >>> ALEJANDRO D'EGIDIO >=20 >>=20 >=20 >>=20 >=20 >>> Jefe de Ingenier=C3=ADa de Backbone | Direcci=C3=B3n de Ingenier=C3=ADa >=20 >>=20 >=20 >>=20 >=20 >>> M: [ callto:+54 911 5794-1589 | +54 911 5794-1589 ] | F: [ callto:+54 11= >=20 >>=20 >=20 >>> 3977-1025 | +54 11 3977-1025 ] | [ mailto:adegidio@telecentro.net.ar | >=20 >>=20 >=20 >>> adegidio@telecentro.net.ar ] >=20 >>=20 >=20 >>=20 >=20 >>> Pje. Lavard=C3=A9n 157. Piso 3. CABA (C1437FBC) >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>> ----- Mensaje original ----- >=20 >>=20 >=20 >>=20 >=20 >>> De: "Ron Bonica" >=20 >>=20 >=20 >>=20 >=20 >>> Para: "v6ops@ietf.org list" >=20 >>=20 >=20 >>=20 >=20 >>> Enviados: Lunes, 30 de Julio 2018 10:12:50 >=20 >>=20 >=20 >>=20 >=20 >>> Asunto: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>> Folks, >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>> Each week between now and IETF 103, we will review and discuss one draft= with an >=20 >>=20 >=20 >>> eye towards progressing it. >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>> This week, please review and comment on draft-ietf-v6ops-transition-ipv4= aas. >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>> Fred and Ron >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>> _______________________________________________ >=20 >>=20 >=20 >>=20 >=20 >>> v6ops mailing list >=20 >>=20 >=20 >>=20 >=20 >>> v6ops@ietf.org >=20 >>=20 >=20 >>=20 >=20 >>> https://www.ietf.org/mailman/listinfo/v6ops >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>> _______________________________________________ >=20 >>=20 >=20 >>=20 >=20 >>> v6ops mailing list >=20 >>=20 >=20 >>=20 >=20 >>> v6ops@ietf.org >=20 >>=20 >=20 >>=20 >=20 >>> https://www.ietf.org/mailman/listinfo/v6ops >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>> ********************************************** >=20 >>=20 >=20 >>> IPv4 is over >=20 >>=20 >=20 >>> Are you ready for the new Internet ? >=20 >>=20 >=20 >>> http://www.consulintel.es >=20 >>=20 >=20 >>> The IPv6 Company >=20 >>=20 >=20 >>=20 >=20 >>> This electronic message contains information which may be privileged or >=20 >>=20 >=20 >>> confidential. The information is intended to be for the exclusive use of= the >=20 >>=20 >=20 >>> individual(s) named above and further non-explicilty authorized disclosu= re, >=20 >>=20 >=20 >>> copying, distribution or use of the contents of this information, even i= f >=20 >>=20 >=20 >>> partially, including attached files, is strictly prohibited and will be >=20 >>=20 >=20 >>> considered a criminal offense. If you are not the intended recipient be a= ware >=20 >>=20 >=20 >>> that any disclosure, copying, distribution or use of the contents of thi= s >=20 >>=20 >=20 >>> information, even if partially, including attached files, is strictly >=20 >>=20 >=20 >>> prohibited, will be considered a criminal offense, so you must reply to t= he >=20 >>=20 >=20 >>> original sender to inform about this communication and delete it. >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >> ********************************************** >=20 >> IPv4 is over >=20 >> Are you ready for the new Internet ? >=20 >> http://www.consulintel.es >=20 >> The IPv6 Company >=20 >>=20 >=20 >> This electronic message contains information which may be privileged or c= onfidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, c= opying, distribution or use of the contents of this information, even if par= tially, including attached files, is strictly prohibited and will be conside= red a criminal offense. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this informat= ion, even if partially, including attached files, is strictly prohibited, wi= ll be considered a criminal offense, so you must reply to the original sende= r to inform about this communication and delete it. >=20 >>=20 >=20 >>=20 >=20 >>=20 >=20 >> _______________________________________________ >=20 >> v6ops mailing list >=20 >> v6ops@ietf.org >=20 >> https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=20 > -----------------------------------------------------------------------= --------- >=20 > The fact that there is a highway to hell and a stairway to heaven is an= interesting comment on projected traffic volume... >=20 >=20 >=20 > _______________________________________________ >=20 > v6ops mailing list >=20 > v6ops@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=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 co= nfidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, c= opying, distribution or use of the contents of this information, even if par= tially, including attached files, is strictly prohibited and will be conside= red a criminal offense. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this informat= ion, even if partially, including attached files, is strictly prohibited, wi= ll be considered a criminal offense, so you must reply to the original sende= r to inform about this communication and delete it. >=20 >=20 >=20 From nobody Thu Aug 9 13:50:10 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 D9851130E0E for ; Thu, 9 Aug 2018 13:50:07 -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, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=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 y8nodRYOK-3u for ; Thu, 9 Aug 2018 13:50:04 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 30C7112426A for ; Thu, 9 Aug 2018 13:50:04 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id 13-v6so12246684ois.1 for ; Thu, 09 Aug 2018 13:50:04 -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=AsqKjreMScmBPnHZXskQyDR0OqYGz5SnwZFbcwytZkA=; b=TfsLdVkiqnE7P9BuPi9IquSLJYX8Cxa92QDDKUsEwovHQA+xFBYA8I1T3UNDWN89B3 BvbPGvDRYH3sdReTPfu3RPUhjK4ok2fzj1NHP7zS0JqaT6tHytIihwYU72zZVdPKZkbv ZgcWiDuqQiMW5EyLdYtOPxPV332DqXad4zKnE9G5B/Wq6rgMva/2zJwR3Vs51bs9cpbK YzE46bna7FZxL8Fxkgp8T5FuhhgC9B6KfWXRJsTkRs/EbOmH+FsBfVM3JNPusifisK9j Qr53tbLF70SneW3WXCL3osoHJCIkcQZBoaYFLxFbb3Bpuv0RUwIONAuCceJLot/l5UXd nBRg== 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=AsqKjreMScmBPnHZXskQyDR0OqYGz5SnwZFbcwytZkA=; b=d8rBYkvdqIDvqNWq9lLspZZaZ9gmw9ZOZGxx6xbV9sh/1K98outjVngdSSMJdBql60 /DvhVT+7CnwuLoCLjuIZDo/cvPMxqP8srcEcfe2ua2hud4RHjfwkGKyk5ink9xLre8Rz 8adolN1wHdEANB+Duj6fk3I5/8Mc2/Ci7mfcX+ps2bYHxpiN/9QWKsu8CBsd3DwpfjQN 7fj4eC2BzyqHDTfDCNBbzn9VYIB9j8TkrLdvTPrxouBbbqRu+WiPmAZPfOat71hfPZBg iZ0G6527vZ+b7kQFCX2JuS2FdX16e+mb6nY57B2EWbIeVgTFprbGIZf1K5AfH2Azu9RH O7Fg== X-Gm-Message-State: AOUpUlGXy/XQFErKVV+gG1knygYJ9eopMYbbDkszboEwa123+5PEyTG7 4Ah7kIESS19BMV++jjpxzSveSJe9 X-Google-Smtp-Source: AA+uWPwSfBe+BME7LqdK2fsdNX/QjlzWdV9l6RvcKN6Pn5OIfDwZPZDLlhVvWw+qLOSj6flMZX0mug== X-Received: by 2002:aca:2b14:: with SMTP id i20-v6mr4016932oik.335.1533847803217; Thu, 09 Aug 2018 13:50:03 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::101f? ([2600:8802:5600:1546::101f]) by smtp.gmail.com with ESMTPSA id m7-v6sm8292269oia.32.2018.08.09.13.50.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Aug 2018 13:50:02 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Fred Baker X-Mailer: iPhone Mail (16A5339e) In-Reply-To: <1BF25695-2CE8-411F-B508-E3F23C2DD5CB@gmail.com> Date: Thu, 9 Aug 2018 13:50:01 -0700 Cc: bs7652@att.com, v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <788A2825-037A-4D84-9379-C0EB6F587FB9@gmail.com> <16E6B022-D471-4F9C-B534-F891E6D2CBB1@consulintel.es> <1BF25695-2CE8-411F-B508-E3F23C2DD5CB@gmail.com> To: JORDI PALET MARTINEZ Archived-At: Subject: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 20:50:09 -0000 I tend to think a lot of this resolved to =E2=80=9Cwhat is the configured at= tribute an attribute of?=E2=80=9D. If you=E2=80=99re doing Nat44, I would ex= pect that is almost always an attribute of the upstream interface - it trans= lates from an =E2=80=9Cinside=E2=80=9D address to an =E2=80=9Coutside=E2=80=9D= address, which is an address the upstream network can route to. In a CLAT, I= would think the CLAT is functionally upstream, as it translates to the IPv6= network, which is from that perspective upstream. So potentially many IPv4 s= ubnets feed into the translator, which results in messages within a single I= Pv6 prefix that is routed upstream.=20 What makes me crazy is making it an attribute of the router. I could imagine= a scenario in which the router serves multiple upstreams, and therefore tra= nslates to multiple upstream prefixes. And yes, configuring it on the downstream interface would be cumbersome. Sent using a machine that autocorrects in interesting ways... > On Aug 9, 2018, at 1:39 PM, Fred Baker wrote: >=20 > No problem. Massage it appropriately. That goes to the clarity of the lang= uage I was trying to restate ;-) >=20 > Sent using a machine that autocorrects in interesting ways... >=20 >> On Aug 9, 2018, at 1:33 PM, JORDI PALET MARTINEZ wrote: >>=20 >> Hi Fred, >>=20 >>=20 >>=20 >> After responding to you and reading Barbara comment I realized, that your= 2nd part doesn't work ... >>=20 >>=20 >>=20 >> It is not about "multiple" transition mechanisms, it is about, it is abou= t multiple IPv4 ranges, so subnetting (and may be several NAT or NAT46 insta= nces). >>=20 >>=20 >>=20 >> We explicitly decided not to consider that a single CE will simultaneousl= y run several transition mechanisms, because that may create a number of con= flicts, that doesn't make sense to take into consideration. >>=20 >> (section 3.2) >>=20 >> This document takes no position on simultaneous operation of one or >>=20 >> several transition mechanisms and/or native IPv4. >>=20 >>=20 >>=20 >> An ISP may want to have different customers in different "transition stag= es" (from dual stack to IPv4aaS, or from one IPv4aaS to another), but simult= aneously the same CE ? >>=20 >>=20 >>=20 >> So that's why I proposed this: >>=20 >>=20 >>=20 >> The IPv6 Transition CE Router MAY support multiple IPv4 prefixes >>=20 >> on its various customer-facing interfaces. In that case, it MUST >>=20 >> support configuration of multiple instances of the relevant code >>=20 >> of the transition mechanism and/or appropriate subnetting >>=20 >> on each such interface. >>=20 >>=20 >>=20 >> Regards, >>=20 >> Jordi >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> =EF=BB=BF-----Mensaje original----- >>=20 >> De: v6ops en nombre de Fred Baker >>=20 >> Fecha: jueves, 9 de agosto de 2018, 15:24 >>=20 >> Para: , >>=20 >> Asunto: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas >>=20 >>=20 >>=20 >> I sent this to Jordi privately. Would you agree with my construction? >>=20 >> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94/ >>=20 >>=20 >>=20 >> English is your second language, and you do very well in it. However, a= s a native speaker, may I offer a friendly amendment? >>=20 >>=20 >>=20 >> TRANS-6: >>=20 >> The IPv6 Transitional Router MAY be configured with multiple IPv4 prefi= xes on its various customer-facing interfaces. >>=20 >> When so configured, it MUST support configuration of different transiti= on mechanisms on each such interface. >>=20 >>=20 >>=20 >>>> On Aug 9, 2018, at 8:39 AM, JORDI PALET MARTINEZ wrote: >>>=20 >>>=20 >>=20 >>> Hi Alejandro, >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>> I think this may sort out your requirement: >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>> TRANS-6: The IPv6 Transition CE Router MAY have multiple IPv4 >>=20 >>>=20 >>=20 >>> prefixes to be used in different customer-facing >>=20 >>>=20 >>=20 >>> interfaces, and the IPv6 Transition CE Router MUST support >>=20 >>>=20 >>=20 >>> multiple instances of the relevant transition mechanism >>=20 >>>=20 >>=20 >>> code, to allow configuring them. >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>> Do you agree? >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>> Regards, >>=20 >>>=20 >>=20 >>> Jordi >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>> =EF=BB=BF-----Mensaje original----- >>=20 >>>=20 >>=20 >>> De: Alejandro D'Egidio >>=20 >>>=20 >>=20 >>> Fecha: martes, 31 de julio de 2018, 15:55 >>=20 >>>=20 >>=20 >>> Para: JORDI PALET MARTINEZ >>=20 >>>=20 >>=20 >>> CC: Ron Bonica , "v6ops@ietf.org list" >>=20 >>>=20 >>=20 >>> Asunto: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>> Hello Jordi, >>=20 >>>=20 >>=20 >>> My notes in lines. >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>> Regards, >>=20 >>>=20 >>=20 >>> Alejandro >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>> ----- Mensaje original ----- >>=20 >>>=20 >>=20 >>>> De: "JORDI PALET MARTINEZ" >>=20 >>>=20 >>=20 >>>> Para: "Alejandro Degidio" , "Ron Bonica" >>=20 >>>=20 >>=20 >>>> CC: "v6ops@ietf.org list" >>=20 >>>=20 >>=20 >>>> Enviados: Lunes, 30 de Julio 2018 20:58:52 >>=20 >>>=20 >>=20 >>>> Asunto: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> Hi Alejandro, >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> Thanks for the input! >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> I think it is easy to understand: >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> "This document covers a set of IP transition techniques required when >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> ISPs have an IPv6-only access network." >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> even if the ISP already have an IPv6-only access network, or want to ha= ve it. >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> But this may be something that a native English speaker could tell us h= ow better >>=20 >>>=20 >>=20 >>>> to say it. May be: >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> "This document covers a set of IP transition techniques required when >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> ISPs have or want to move to an IPv6-only access network." >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>> Yes, it's great. >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> I'd some text in earlier versions about the reasons to have an IPv6-onl= y access >>=20 >>>=20 >>=20 >>>> network, but it was suggested to move it to the Annex A ... not sure if= you >>=20 >>>=20 >>=20 >>>> read them also. I'm happy to add some more text, if needed to the annex= A to >>=20 >>>=20 >>=20 >>>> describe several possible reasons. >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>> Yes, I've read all the document included the Annexes. >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> The case for having multiple IPv4 subnets (one for each interface), is f= easible, >>=20 >>>=20 >>=20 >>>> as you say, by having multiple instances of the NAT46, which I think is= not a >>=20 >>>=20 >>=20 >>>> problem. >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> However, open question is valid also for any other IPv4aaS mechanism. >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> I'm not sure if we want to have that case considered as something that M= UST be >>=20 >>>=20 >>=20 >>>> supported as one more requirement, and if this is the case, it will be a= >>=20 >>>=20 >>=20 >>>> "general" transition requirement, and no need to go in the details for e= ach >>=20 >>>=20 >>=20 >>>> transition mechanism, or we really want to go to describe a specific ne= w >>=20 >>>=20 >>=20 >>>> requirement for this for each transition mechanism ... >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>> Just knowing that a CPE can have different LAN IPv4 prefixes I was think= ing that maybe it could be considered in General transition requirements wit= h something like: >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>> "TRANS-6: The IPv6 Transition CE Router MAY have different IPv4 prefixes= on each Customer-Facing interfaces and the transition mechanisms MUST have o= ptions to be compatible with it." >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> What others think? >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> Regards, >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> Jordi >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> =EF=BB=BF-----Mensaje original----- >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> De: v6ops en nombre de Alejandro D'Egidio >>=20 >>>=20 >>=20 >>>> >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> Fecha: lunes, 30 de julio de 2018, 10:39 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> Para: Ron Bonica >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> CC: "v6ops@ietf.org list" >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> Asunto: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> Hello Ron, >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> I really like this draft! >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> Just a simple comment. >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> Where says: >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> This document covers a set of IP transition techniques required when >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> ISPs have an IPv6-only access network. >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> Maybe could say: >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> This document covers a set of IP transition techniques required when >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> ISPs wants to have an IPv6-only access network. >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> Maybe you can include some example of why ISPs wants to have an IPv6 on= ly access >>=20 >>>=20 >>=20 >>>> network. >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> For example, in my case, as we don't have more public IPv4 addresses an= d we have >>=20 >>>=20 >>=20 >>>> IPv6 developed, why should I need to continue managing IPv4 addresses? >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> Maybe some kind of this scenario could be included. >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> Regarding 3.2.1. 464XLAT: >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> Cablelabs defines that the CableModem must subnet the IPv6 Prefix recei= ved from >>=20 >>>=20 >>=20 >>>> ISP to use different subnets on each LAN Interface. The size of IPv6 "s= ub" >>=20 >>>=20 >>=20 >>>> prefix on each LAN depends on is ISP configured the CM to use either fa= vor >>=20 >>>=20 >>=20 >>>> depth or favor width. If ISP provides just a /64 IPv6 prefix (which is n= ot >>=20 >>>=20 >>=20 >>>> recommended) CM must share it with all LAN interfaces. >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> For IPv4, by the same private IPv4 prefix is shared between all LAN int= erfaces >>=20 >>>=20 >>=20 >>>> (customer-facing interfaces). For this case I think it "3.2.1. 464XLAT= " is ok. >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> There are some cases where CM could have different private IPv4 prefixe= s to each >>=20 >>>=20 >>=20 >>>> customer-facing interfaces. So I think, this is another scenario that s= hould be >>=20 >>>=20 >>=20 >>>> covered where CLAT will need to work with all the IPv4 LAN prefixes. Ma= ybe >>=20 >>>=20 >>=20 >>>> running multiple instances of its NAT46 (one for each LAN interface) or= one >>=20 >>>=20 >>=20 >>>> instance supporting multiple IPv4 addresses. >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> All this is in: >>=20 >>>=20 >>=20 >>>> https://apps.cablelabs.com/specification/ipv4-and-ipv6-erouter-specific= ation/ >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> Regards, >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> ALEJANDRO D'EGIDIO >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> Jefe de Ingenier=C3=ADa de Backbone | Direcci=C3=B3n de Ingenier=C3=ADa= >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> M: [ callto:+54 911 5794-1589 | +54 911 5794-1589 ] | F: [ callto:+54 1= 1 >>=20 >>>=20 >>=20 >>>> 3977-1025 | +54 11 3977-1025 ] | [ mailto:adegidio@telecentro.net.ar | >>=20 >>>=20 >>=20 >>>> adegidio@telecentro.net.ar ] >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> Pje. Lavard=C3=A9n 157. Piso 3. CABA (C1437FBC) >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> ----- Mensaje original ----- >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> De: "Ron Bonica" >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> Para: "v6ops@ietf.org list" >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> Enviados: Lunes, 30 de Julio 2018 10:12:50 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> Asunto: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> Folks, >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> Each week between now and IETF 103, we will review and discuss one draf= t with an >>=20 >>>=20 >>=20 >>>> eye towards progressing it. >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> This week, please review and comment on draft-ietf-v6ops-transition-ipv= 4aas. >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> Fred and Ron >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> _______________________________________________ >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> v6ops mailing list >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> v6ops@ietf.org >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> _______________________________________________ >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> v6ops mailing list >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> v6ops@ietf.org >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> ********************************************** >>=20 >>>=20 >>=20 >>>> IPv4 is over >>=20 >>>=20 >>=20 >>>> Are you ready for the new Internet ? >>=20 >>>=20 >>=20 >>>> http://www.consulintel.es >>=20 >>>=20 >>=20 >>>> The IPv6 Company >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>> This electronic message contains information which may be privileged or= >>=20 >>>=20 >>=20 >>>> confidential. The information is intended to be for the exclusive use o= f the >>=20 >>>=20 >>=20 >>>> individual(s) named above and further non-explicilty authorized disclos= ure, >>=20 >>>=20 >>=20 >>>> copying, distribution or use of the contents of this information, even i= f >>=20 >>>=20 >>=20 >>>> partially, including attached files, is strictly prohibited and will be= >>=20 >>>=20 >>=20 >>>> considered a criminal offense. If you are not the intended recipient be= aware >>=20 >>>=20 >>=20 >>>> that any disclosure, copying, distribution or use of the contents of th= is >>=20 >>>=20 >>=20 >>>> information, even if partially, including attached files, is strictly >>=20 >>>=20 >>=20 >>>> prohibited, will be considered a criminal offense, so you must reply to= the >>=20 >>>=20 >>=20 >>>> original sender to inform about this communication and delete it. >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>> ********************************************** >>=20 >>> IPv4 is over >>=20 >>> Are you ready for the new Internet ? >>=20 >>> http://www.consulintel.es >>=20 >>> The IPv6 Company >>=20 >>>=20 >>=20 >>> This electronic message contains information which may be privileged or c= onfidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, c= opying, distribution or use of the contents of this information, even if par= tially, including attached files, is strictly prohibited and will be conside= red a criminal offense. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this informat= ion, even if partially, including attached files, is strictly prohibited, wi= ll be considered a criminal offense, so you must reply to the original sende= r to inform about this communication and delete it. >>=20 >>>=20 >>=20 >>>=20 >>=20 >>>=20 >>=20 >>> _______________________________________________ >>=20 >>> v6ops mailing list >>=20 >>> v6ops@ietf.org >>=20 >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >>=20 >> -----------------------------------------------------------------------= --------- >>=20 >> The fact that there is a highway to hell and a stairway to heaven is an= interesting comment on projected traffic volume... >>=20 >>=20 >>=20 >> _______________________________________________ >>=20 >> v6ops mailing list >>=20 >> v6ops@ietf.org >>=20 >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >>=20 >>=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 c= onfidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, c= opying, distribution or use of the contents of this information, even if par= tially, including attached files, is strictly prohibited and will be conside= red a criminal offense. If you are not the intended recipient be aware that a= ny disclosure, copying, distribution or use of the contents of this informat= ion, even if partially, including attached files, is strictly prohibited, wi= ll be considered a criminal offense, so you must reply to the original sende= r to inform about this communication and delete it. >>=20 >>=20 >>=20 From nobody Thu Aug 9 13:59: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 DED81130EBB for ; Thu, 9 Aug 2018 13:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 YUjVb2JmdCUk for ; Thu, 9 Aug 2018 13:59:11 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 45FE612426A for ; Thu, 9 Aug 2018 13:59:11 -0700 (PDT) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w79Ktcx5020000; Thu, 9 Aug 2018 16:59:04 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049295.ppops.net-00191d01. with ESMTP id 2krv3f1see-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 09 Aug 2018 16:59:04 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w79Kx2da005746; Thu, 9 Aug 2018 16:59:03 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w79Kx1PH005740; Thu, 9 Aug 2018 16:59:01 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id 6BB1F4014048; Thu, 9 Aug 2018 20:59:01 +0000 (GMT) Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (unknown [130.8.218.157]) by zlp30487.vci.att.com (Service) with ESMTPS id 59AD94014045; Thu, 9 Aug 2018 20:59:01 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0408.000; Thu, 9 Aug 2018 16:59:00 -0400 From: "STARK, BARBARA H" To: "'JORDI PALET MARTINEZ'" , Fred Baker , "v6ops@ietf.org" Thread-Topic: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas Thread-Index: AQHUL/dDGlgPknfZwUKlfoyXzIkUtaS4INcAgAACsID//75nQA== Date: Thu, 9 Aug 2018 20:59:00 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DE69247@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <788A2825-037A-4D84-9379-C0EB6F587FB9@gmail.com> <16E6B022-D471-4F9C-B534-F891E6D2CBB1@consulintel.es> In-Reply-To: <16E6B022-D471-4F9C-B534-F891E6D2CBB1@consulintel.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.248.179] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-09_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=664 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808090208 Archived-At: Subject: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 20:59:14 -0000 PiBIaSBGcmVkLA0KPiANCj4gQWZ0ZXIgcmVzcG9uZGluZyB0byB5b3UgYW5kIHJlYWRpbmcgQmFy YmFyYSBjb21tZW50IEkgcmVhbGl6ZWQsIHRoYXQgeW91cg0KPiAybmQgcGFydCBkb2Vzbid0IHdv cmsgLi4uDQo+IA0KPiBJdCBpcyBub3QgYWJvdXQgIm11bHRpcGxlIiB0cmFuc2l0aW9uIG1lY2hh bmlzbXMsIGl0IGlzIGFib3V0LCBpdCBpcyBhYm91dA0KPiBtdWx0aXBsZSBJUHY0IHJhbmdlcywg c28gc3VibmV0dGluZyAoYW5kIG1heSBiZSBzZXZlcmFsIE5BVCBvciBOQVQ0Ng0KPiBpbnN0YW5j ZXMpLg0KPiANCj4gV2UgZXhwbGljaXRseSBkZWNpZGVkIG5vdCB0byBjb25zaWRlciB0aGF0IGEg c2luZ2xlIENFIHdpbGwgc2ltdWx0YW5lb3VzbHkgcnVuDQo+IHNldmVyYWwgdHJhbnNpdGlvbiBt ZWNoYW5pc21zLCBiZWNhdXNlIHRoYXQgbWF5IGNyZWF0ZSBhIG51bWJlciBvZg0KPiBjb25mbGlj dHMsIHRoYXQgZG9lc24ndCBtYWtlIHNlbnNlIHRvIHRha2UgaW50byBjb25zaWRlcmF0aW9uLg0K PiANCj4gKHNlY3Rpb24gMy4yKQ0KPiANCj4gICBUaGlzIGRvY3VtZW50IHRha2VzIG5vIHBvc2l0 aW9uIG9uIHNpbXVsdGFuZW91cyBvcGVyYXRpb24gb2Ygb25lIG9yDQo+ICAgIHNldmVyYWwgdHJh bnNpdGlvbiBtZWNoYW5pc21zIGFuZC9vciBuYXRpdmUgSVB2NC4NCj4gDQo+IEFuIElTUCBtYXkg d2FudCB0byBoYXZlIGRpZmZlcmVudCBjdXN0b21lcnMgaW4gZGlmZmVyZW50ICJ0cmFuc2l0aW9u IHN0YWdlcyINCj4gKGZyb20gZHVhbCBzdGFjayB0byBJUHY0YWFTLCBvciBmcm9tIG9uZSBJUHY0 YWFTIHRvIGFub3RoZXIpLCBidXQNCj4gc2ltdWx0YW5lb3VzbHkgdGhlIHNhbWUgQ0UgPw0KPiAN Cj4gU28gdGhhdCdzIHdoeSBJIHByb3Bvc2VkIHRoaXM6DQo+IA0KPiBUaGUgSVB2NiBUcmFuc2l0 aW9uIENFIFJvdXRlciBNQVkgc3VwcG9ydCBtdWx0aXBsZSBJUHY0IHByZWZpeGVzDQo+IG9uIGl0 cyB2YXJpb3VzIGN1c3RvbWVyLWZhY2luZyBpbnRlcmZhY2VzLiBJbiB0aGF0IGNhc2UsIGl0IE1V U1QNCj4gc3VwcG9ydCBjb25maWd1cmF0aW9uIG9mIG11bHRpcGxlIGluc3RhbmNlcyBvZiB0aGUg cmVsZXZhbnQgY29kZQ0KPiBvZiB0aGUgdHJhbnNpdGlvbiBtZWNoYW5pc20gYW5kL29yIGFwcHJv cHJpYXRlIHN1Ym5ldHRpbmcNCj4gb24gZWFjaCBzdWNoIGludGVyZmFjZS4NCg0KT2gsIEkgdGhp bmsgbWF5YmUgSSB1bmRlcnN0YW5kIHdoZXJlIHlvdSdyZSB0cnlpbmcgdG8gZ28gd2l0aCB0aGlz LiBMZXQgbWUgc2VlIGlmIEkgY2FuIHBhcmFwaHJhc2U6DQoNCklmIGFuIElQdjYgVHJhbnNpdGlv biBDRSBSb3V0ZXIgc3VwcG9ydHMgbW9yZSB0aGFuIG9uZSBMQU4gc3VibmV0LCBhbmQgdGhlIElQ djRhYXMgbWVjaGFuaXNtIGRvZXMgbm90IHJlcXVpcmUgTkFQVCwgdGhlIElQdjYgVHJhbnNpdGlv biBDRSBSb3V0ZXIgTVVTVCBlaXRoZXIgYXBwcm9wcmlhdGVseSBzdWJuZXQgdGhlIGFzc2lnbmVk IGFkZHJlc3Mgc3BhY2Ugb3IgZGlzYWJsZSBzdXBwb3J0IGZvciBtdWx0aXBsZSBzdWJuZXRzLiBJ ZiBzdWJuZXR0aW5nIG9mIHRoZSBhc3NpZ25lZCBhZGRyZXNzIHNwYWNlIGlzIHN1cHBvcnRlZCwg aXQgU0hPVUxEIGFsbG93IGNvbmZpZ3VyYXRpb24gb2YgdGhlIGFkZHJlc3Mgc3BhY2UgYXNzaWdu ZWQgdG8gZWFjaCBzdWJuZXQuDQpJZiBhbiBJUHY2IFRyYW5zaXRpb24gQ0UgUm91dGVyIHN1cHBv cnRzIG1vcmUgdGhhbiBvbmUgTEFOIHN1Ym5ldCwgYW5kIHRoZSBJUHY0YWFzIG1lY2hhbmlzbSBy ZXF1aXJlcyBOQVBULCB0aGUgSVB2NiBUcmFuc2l0aW9uIENFIFJvdXRlciBNVVNUIHN1cHBvcnQg dGhlIElQdjRhYXMgTkFQVCB0byBlYWNoIHN1Ym5ldC4NCg0KRGlkIEkgZ2V0IHRoYXQgcmlnaHQ/ DQoNCkJhcmJhcmENCg== From nobody Thu Aug 9 14:44:28 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 B244B130EF7 for ; Thu, 9 Aug 2018 14:44:26 -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 M3fGuDtex0Dt for ; Thu, 9 Aug 2018 14:44:24 -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 22E4C130EF3 for ; Thu, 9 Aug 2018 14:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1533851062; x=1534455862; 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=v48M7+Uh BP0rrwK3OHtKWoQWh34RblUFlNR40LUKJqQ=; b=je66Ovy69o9qCstuMAsTKvZ6 5eitnXDftUfe5Nh/+EJDKJpSVoD+INAwbKL1A73uLoA8ZKO9A+FlkCEmPWeVzNGn yf/lISikh7DylqzahasDbQTjlMHh9kx/Dcxdr58SK4vQnGuIifSpqHg6RCk6FyTm p4YEiOtoH7hbP/rzLV4= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 09 Aug 2018 23:44:22 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 09 Aug 2018 23:44:22 +0200 Received: from [10.20.5.175] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005834936.msg for ; Thu, 09 Aug 2018 23:44:20 +0200 X-MDRemoteIP: 10.8.10.6 X-MDHelo: [10.20.5.175] X-MDArrival-Date: Thu, 09 Aug 2018 23:44:20 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17593b5162=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.f.0.180709 Date: Thu, 09 Aug 2018 16:44:09 -0500 From: JORDI PALET MARTINEZ To: "STARK, BARBARA H" , Fred Baker , "v6ops@ietf.org" Message-ID: <570D4A4D-F355-48F4-AAB3-0D17A0C55227@consulintel.es> Thread-Topic: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas References: <788A2825-037A-4D84-9379-C0EB6F587FB9@gmail.com> <16E6B022-D471-4F9C-B534-F891E6D2CBB1@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DE69247@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DE69247@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 21:44:28 -0000 In fact, I just realized that is simpler than that, because, you don't even= need multiple instances and there are several possible ways to actually im= plement that (maybe single instance, but multiple tables, or even a single = table with a field to correlate each entry to a specific interface, etc.), = even for the same transition mechanism, so starting from Barbara text, I th= ink we are almost there: "If an IPv6 Transition CE Router supports more than one LAN subnet, the IPv= 6 Transition CE Router MUST allow appropriately subnetting and configuring = the address space (which may depend on each transition mechanism) among the= several interfaces. In some transition mechanisms, this MAY require differ= entiating mappings/translations per interfaces." If we just say "the address space" I think it is quite obvious that it depe= nds on what is the transition mechanism, so may be the () is not needed. If we allow this part "or disable support for multiple subnets", then we ar= en't fulfilling the requirement as per Alejandro request. It is not NAPT (because it may be NAT46). Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: "STARK, BARBARA H" Fecha: jueves, 9 de agosto de 2018, 15:59 Para: 'JORDI PALET MARTINEZ' , Fred Baker , "v6ops@ietf.org" Asunto: RE: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas > Hi Fred, >=20 > After responding to you and reading Barbara comment I realized, that = your > 2nd part doesn't work ... >=20 > It is not about "multiple" transition mechanisms, it is about, it is = about > multiple IPv4 ranges, so subnetting (and may be several NAT or NAT46 > instances). >=20 > We explicitly decided not to consider that a single CE will simultane= ously run > several transition mechanisms, because that may create a number of > conflicts, that doesn't make sense to take into consideration. >=20 > (section 3.2) >=20 > This document takes no position on simultaneous operation of one or > several transition mechanisms and/or native IPv4. >=20 > An ISP may want to have different customers in different "transition = stages" > (from dual stack to IPv4aaS, or from one IPv4aaS to another), but > simultaneously the same CE ? >=20 > So that's why I proposed this: >=20 > The IPv6 Transition CE Router MAY support multiple IPv4 prefixes > on its various customer-facing interfaces. In that case, it MUST > support configuration of multiple instances of the relevant code > of the transition mechanism and/or appropriate subnetting > on each such interface. =20 Oh, I think maybe I understand where you're trying to go with this. Let= me see if I can paraphrase: =20 If an IPv6 Transition CE Router supports more than one LAN subnet, and = the IPv4aas mechanism does not require NAPT, the IPv6 Transition CE Router = MUST either appropriately subnet the assigned address space or disable supp= ort for multiple subnets. If subnetting of the assigned address space is su= pported, it SHOULD allow configuration of the address space assigned to eac= h subnet. If an IPv6 Transition CE Router supports more than one LAN subnet, and = the IPv4aas mechanism requires NAPT, the IPv6 Transition CE Router MUST sup= port the IPv4aas NAPT to each subnet. =20 Did I get that right? =20 Barbara =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 Fri Aug 10 05:18:18 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 E184D130DE9; Fri, 10 Aug 2018 05:18:16 -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.83.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <153390349689.1552.10600803899190290794@ietfa.amsl.com> Date: Fri, 10 Aug 2018 05:18:16 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 12:18:17 -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-07.txt Pages : 21 Date : 2018-08-10 Abstract: This document discusses the most common scenarios of connecting an enterprise network to multiple ISPs using an address space assigned by an ISP and how the approach proposed in the "ietf-rtgwg- enterprise-pa-multihoming" draft could be applied in those scenarios. 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 adopts the approach proposed in the "ietf-rtgwg-enterprise-pa-multihoming" draft to provide a solution 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-07 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-conditional-ras-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-conditional-ras-07 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 Aug 10 05:26: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 2D6621286E3; Fri, 10 Aug 2018 05:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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] 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 ZrOvtksC_ZcK; Fri, 10 Aug 2018 05:26:13 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 538E0126CB6; Fri, 10 Aug 2018 05:26:13 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id a134-v6so6458158lfe.6; Fri, 10 Aug 2018 05:26:13 -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=DVC0ZTcURdbYk28a9hD8zndOrRiMGvrGYTunNRnPjmk=; b=uQ2IPiyuFbhNOi/2uTGj58rW+qg9Z/N0dC1sR0veqCATCit+bAGuf0eNWCkvt5DsxN Hc3bahxMcTn/YBRxZF19MJFvCo01H6/fn/ZSz0P5hZDw0ymO5Ll0B0Kgh4dvoyQFxKyj IZbYtJYLVQUHcPtS/mdMwOQGVHnKIEupK/sTw4yRfMQAIiGS3pk+vKo7GI7tVlLte/gv XQHRXZHGTvB9ATwH9mrtWCMQmMj/TlmlcfYN9HiKJ94ueQwpYl+Rlw1H+lzFUTArJZgT gI/bqtk/So6uAxbwTky+bZR6S9GbjQTAY1xmTdXpyvPP0dNlveVarqDuqZhIkqxW2Pcg pJTw== 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=DVC0ZTcURdbYk28a9hD8zndOrRiMGvrGYTunNRnPjmk=; b=ao/w8VBJ2ke4cFKRwrs/ZD9a0ny2CpaluzGTPo9ZiaErpqgb4a9OKZo7KxCDmhh8PN eYg7nWMMOHA4ELRqCPhl23ety6gD5CmBbNK3k7xgBOXCdgMF+kl7FOjO6FR/aRHibCtL 9fhGusi94vLXdf+7XL2z7v9jHEYf7JuQgc3HNkDPbREx9KwFYVs1QzxCumLk/2n/hio3 laQpm5L7A5rydir3K6oNRfRcwhpm0o9K9ZjNdCUvqu+h6gSPHGClybClPmv5tV8ymD0j k9zNCgDllKy67wskTAtgZiFELEuVkLrjToTl3W/vq5r7xb9sPNTTDBYTah3dWqQiNVBw JQOA== X-Gm-Message-State: AOUpUlFolpuyp2AThy20/Jf+dw0bGZIB7spzDmk6b5RiXQpfW+DYjxQ/ VPQK2CAZEML0Xlwvf3o3St/3/bVLsYlDU8eIacoNNWCC X-Google-Smtp-Source: AA+uWPyj/RRwGiXRQNRzcN6ygwf05kXsRVUJg8gcnno/tB/lf0dROz3BlmBAhhJ9lcpIIKKcFUGclyiHbfnm6OrrLWs= X-Received: by 2002:a19:ca09:: with SMTP id a9-v6mr4242405lfg.142.1533903971482; Fri, 10 Aug 2018 05:26:11 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:1d82:0:0:0:0:0 with HTTP; Fri, 10 Aug 2018 05:25:50 -0700 (PDT) In-Reply-To: <153321790308.2265.731201835682425291.idtracker@ietfa.amsl.com> References: <153321790308.2265.731201835682425291.idtracker@ietfa.amsl.com> From: Jen Linkova Date: Fri, 10 Aug 2018 22:25:50 +1000 Message-ID: To: Suresh Krishnan Cc: The IESG , Russ White , v6ops-chairs@ietf.org, V6 Ops List , draft-ietf-v6ops-conditional-ras@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Yes on draft-ietf-v6ops-conditional-ras-06: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 12:26:15 -0000 Hi Suresh, On Thu, Aug 2, 2018 at 11:51 PM, Suresh Krishnan wrote: > * Section 3.1.1. > > I think a reference to RFC3704 (specifically written for describing ingress > filtering for multihomed networks) might be a good addition here to RFC2827 Done! > * Sections 3.2.1., 3.2.2. etc. > > => I think it is important to specify (at least the bounds of) the valid > lifetimes here as well. e.g. when the preferred lifetime is getting set to zero > it is important to specify that the valid lifetime is set to a non zero value > so that the host will form an address at all (even though it will not be used > when there are preferred addresses). This is important to reduce the potential > packet losses when the preferred uplink goes down. I've added a paragraph clarifying that we only modify preferred lifetime and that RFC4862 does not allow an RA with both preferred and valid lifetime for the prefix set to 0 to invalidate the address completely: https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-07 > * Section 3.2.2. > > I think there is some text missing here about VRRP priorities here. There seems > to be an assumption in the draft that the uplink A failure will lead to R1 > becoming backup ("If ISP_A uplink is down, then R1 becomes a backup.") and this > is not obvious at all. There needs to be a priority change with interface > tracking if this has to happen and the backup has to take over as the master. I've rephrased it to: "R1 is the VRRP master by default (when ISP_A uplink is up). If ISP_A uplink is down, then R1 becomes a backup (the VRRP interface status tracking is expected to be used to automatically modify the VRRP priorities and trigger the mastership switchover). " Please let me know if the new version does not address your comments! Thanks! -- SY, Jen Linkova aka Furry From nobody Fri Aug 10 05:30: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 507911286E3 for ; Fri, 10 Aug 2018 05:30:49 -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_RED=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 Kbt0O5MS61-4 for ; Fri, 10 Aug 2018 05:30: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 34FD4126CB6 for ; Fri, 10 Aug 2018 05:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1533904243; x=1534509043; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=bHDPPkDXyW/SMWV4Lg0SVZ6FsLCXQFoJuXn07WQpPig=; b=qwll0n/D9GasD uVxMBOb9DYTnVrFW7H2UruwYxqRknI1TIsBFtaM6DkKB3hjO/V3oFZmb7NTamHBZ c4bRhLwHpbp9Xx0VoyAQIEDGvdiXM7ZvjPAVXNs3U5+5Wkok594TG5nFJGIFzgVY edrzi9uQgIyXasYz081X12rUCcWwrk= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 10 Aug 2018 14:30:43 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 10 Aug 2018 14:30:43 +0200 Received: from [10.20.5.175] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005835357.msg for ; Fri, 10 Aug 2018 14:30:42 +0200 X-MDRemoteIP: 10.8.10.6 X-MDHelo: [10.20.5.175] X-MDArrival-Date: Fri, 10 Aug 2018 14:30:42 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1760d610f2=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.f.0.180709 Date: Fri, 10 Aug 2018 07:30:34 -0500 From: JORDI PALET MARTINEZ To: "STARK, BARBARA H" CC: "v6ops@ietf.org list" Message-ID: <09ECA1D3-4B83-4828-9BA9-DE2EDA314F74@consulintel.es> Thread-Topic: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas References: <2D09D61DDFA73D4C884805CC7865E6114DE68EAA@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DE68EAA@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 12:30:49 -0000 Hi Barbara, See my last proposal on this, I think already follows the IF ... THEN ... (= I don't think a "then" is needed before the ", the", but it may be an Engli= sh grammar issue): "If an IPv6 Transition CE Router supports more than one LAN subnet, the IPv= 6 Transition CE Router MUST allow appropriately subnetting and configuring = the address space (which may depend on each transition mechanism) among the= several interfaces. In some transition mechanisms, this MAY require differ= entiating mappings/translations per interfaces." I'm convinced that this is irrelevant to "what" the ISP is providing, so no= need for any signaling. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: "STARK, BARBARA H" Fecha: viernes, 10 de agosto de 2018, 0:59 Para: 'JORDI PALET MARTINEZ' CC: "v6ops@ietf.org list" Asunto: RE: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas > TRANS-6: The IPv6 Transition CE Router MAY have multiple IPv4 > prefixes to be used in different customer-facing > interfaces, and the IPv6 Transition CE Router MUST suppo= rt > multiple instances of the relevant transition mechanism > code, to allow configuring them. =20 This proposed sentence structure logically resolves to *always* requiri= ng support for multiple instances. I don't think this is appropriate (e.g.,= for a simple router that only supports a single LAN IPv4 interface and sin= gle WAN IPv4 interface), and perhaps it's not what's intended. The sentence= is also very difficult to parse and I'm not at all sure I understand what = it's trying to say. =20 Is this saying that if the CE router has, for example, a Guest Wi-Fi IP= v4 subnet and a "home" Wi-Fi IPv4 subnet (both to the LAN), that it must in= stantiate 2 instances of (for example) DS-Lite? What if the ISP doesn't all= ow more than one instance? How is the ISP supposed to signal whether more t= han one is allowed? Why would 2 instances be required?=20 Would this apply to the case where the router simply supports 2 LAN seg= ments as different subnets?=20 I'm sorry, but I'm really not understanding what condition is being des= cribed. =20 As for resolving the logical sentence structure, I would suggest wordin= g the requirement as "If ,= then the IPv6 Transition CE Router MUST ." If you w= ant to explain why this requirement exists, make that a separate sentence, = such as "This will allow separate configuration of the transition mechanism= instances." Barbara =20 > =EF=BB=BF-----Mensaje original----- >=20 > De: Alejandro D'Egidio .... snipping relevant text..... > > The case for having multiple IPv4 subnets (one for each interfa= ce), is > feasible, > > as you say, by having multiple instances of the NAT46, which I = think is not > a problem. > > However, open question is valid also for any other IPv4aaS mech= anism.=20 > > I'm not sure if we want to have that case considered as somethi= ng that > MUST be supported as one more requirement, and if this is the case, i= t will be a > > "general" transition requirement, and no need to go in the deta= ils for > each transition mechanism, or we really want to go to describe a spec= ific new > > requirement for this for each transition mechanism ... >=20 > Just knowing that a CPE can have different LAN IPv4 prefixes I wa= s thinking > that maybe it could be considered in General transition requirements = with > something like:=20 >=20 > "TRANS-6: The IPv6 Transition CE Router MAY have different IPv4 p= refixes > on each Customer-Facing interfaces and the transition mechanisms MUST > have options to be compatible with it." =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 Fri Aug 10 05:58:37 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 84681130DD5 for ; Fri, 10 Aug 2018 05:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 DXLUufFv3qiM for ; Fri, 10 Aug 2018 05:58:34 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 0ECA712F18C for ; Fri, 10 Aug 2018 05:58:33 -0700 (PDT) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w7ACuCHa032477; Fri, 10 Aug 2018 08:58:29 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049459.ppops.net-00191d01. with ESMTP id 2ks9unhpy1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 10 Aug 2018 08:58:29 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w7ACwSLs010115; Fri, 10 Aug 2018 08:58:28 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [135.47.91.179]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w7ACwONQ010012; Fri, 10 Aug 2018 08:58:25 -0400 Received: from zlp30484.vci.att.com (zlp30484.vci.att.com [127.0.0.1]) by zlp30484.vci.att.com (Service) with ESMTP id 8A92E4000361; Fri, 10 Aug 2018 12:58:24 +0000 (GMT) Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (unknown [130.8.218.150]) by zlp30484.vci.att.com (Service) with ESMTPS id 79DF54000359; Fri, 10 Aug 2018 12:58:24 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0408.000; Fri, 10 Aug 2018 08:58:24 -0400 From: "STARK, BARBARA H" To: "'JORDI PALET MARTINEZ'" CC: "v6ops@ietf.org list" Thread-Topic: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas Thread-Index: AQHUL/dDGlgPknfZwUKlfoyXzIkUtaS3m+1ggAGTEAD//8Kf0A== Date: Fri, 10 Aug 2018 12:58:23 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DE69DC6@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <2D09D61DDFA73D4C884805CC7865E6114DE68EAA@GAALPA1MSGUSRBF.ITServices.sbc.com> <09ECA1D3-4B83-4828-9BA9-DE2EDA314F74@consulintel.es> In-Reply-To: <09ECA1D3-4B83-4828-9BA9-DE2EDA314F74@consulintel.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.242.173] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-10_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=854 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808100142 Archived-At: Subject: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 12:58:36 -0000 PiAiSWYgYW4gSVB2NiBUcmFuc2l0aW9uIENFIFJvdXRlciBzdXBwb3J0cyBtb3JlIHRoYW4gb25l IExBTiBzdWJuZXQsIHRoZSBJUHY2DQo+IFRyYW5zaXRpb24gQ0UgUm91dGVyIE1VU1QgYWxsb3cg YXBwcm9wcmlhdGVseSBzdWJuZXR0aW5nIGFuZCBjb25maWd1cmluZw0KPiB0aGUgYWRkcmVzcyBz cGFjZSAod2hpY2ggbWF5IGRlcGVuZCBvbiBlYWNoIHRyYW5zaXRpb24gbWVjaGFuaXNtKSBhbW9u Zw0KPiB0aGUgc2V2ZXJhbCBpbnRlcmZhY2VzLiBJbiBzb21lIHRyYW5zaXRpb24gbWVjaGFuaXNt cywgdGhpcyBNQVkgcmVxdWlyZQ0KPiBkaWZmZXJlbnRpYXRpbmcgbWFwcGluZ3MvdHJhbnNsYXRp b25zIHBlciBpbnRlcmZhY2VzLiINCg0KSSB3b3VsZCBzdWdnZXN0IGNoYW5naW5nICJNQVkiIHRv ICJtYXkiICh0aGUgbGFzdCBzZW50ZW5jZSByZWFkcyBtb3JlIHRvIG1lIGFzIHNvbWV0aGluZyB0 aGF0IHNpbXBseSBjb3VsZCBiZSB0cnVlLCByYXRoZXIgdGhhbiBzb21ldGhpbmcgdGhpcyBkb2N1 bWVudCBpcyBleHBsaWNpdGx5IHBlcm1pdHRpbmcpLg0KQXMgYSBuaXQ6IEkgd291bGQgc3VnZ2Vz dCBjaGFuZ2luZyAiYXBwcm9wcmlhdGVseSIgdG8gImFwcHJvcHJpYXRlIi4NCkkgY2FuIGxpdmUg d2l0aCB0aGlzLiBUaHguDQpCYXJiYXJhDQo= From nobody Fri Aug 10 06:24:00 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 70F9C130E04 for ; Fri, 10 Aug 2018 06:23:58 -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 lIDvH_4Q9q3v for ; Fri, 10 Aug 2018 06:23:56 -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 3C4C812F18C for ; Fri, 10 Aug 2018 06:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1533907434; x=1534512234; i=jordi.palet@consulintel.es; q=dns/txt; h=User-Agent:Date: Subject:From:To:CC:Message-ID:Thread-Topic:References: In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; bh=lnxhWaHxu+q3velup45JyQTRCa+escxdGUrBJNigOGg=; b=F+SAQ4W5l1LxK 4kRHqprITL7Hx0pR3wNB4Q8AwYcg0VJNSA0A9TSpZCVbqiITp7s8tOitJ9DNE+SC qD70LZ4x7GRWdNn28ExZC3vIaeWJykEwSM8LUl2u3Z0BWnhOYkgUxhElvdiz2aNf 6DUgg1tM1JZv5e3svXrEbr1cfFP+0k= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 10 Aug 2018 15:23:54 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 10 Aug 2018 15:23:54 +0200 Received: from [10.20.5.175] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005835394.msg for ; Fri, 10 Aug 2018 15:23:52 +0200 X-MDRemoteIP: 10.8.10.6 X-MDHelo: [10.20.5.175] X-MDArrival-Date: Fri, 10 Aug 2018 15:23:52 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1760d610f2=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.f.0.180709 Date: Fri, 10 Aug 2018 08:23:39 -0500 From: JORDI PALET MARTINEZ To: "STARK, BARBARA H" CC: "v6ops@ietf.org list" Message-ID: <46CFAD61-D69B-4E7F-8A52-A0A512AF26C6@consulintel.es> Thread-Topic: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas References: <2D09D61DDFA73D4C884805CC7865E6114DE68EAA@GAALPA1MSGUSRBF.ITServices.sbc.com> <09ECA1D3-4B83-4828-9BA9-DE2EDA314F74@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DE69DC6@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DE69DC6@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 13:23:58 -0000 Thanks and agree with your points. Not sure if you say this in English "sold out" :-) Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: "STARK, BARBARA H" Fecha: viernes, 10 de agosto de 2018, 7:58 Para: 'JORDI PALET MARTINEZ' CC: "v6ops@ietf.org list" Asunto: RE: [v6ops] Weekly Review: draft-ietf-v6ops-transition-ipv4aas > "If an IPv6 Transition CE Router supports more than one LAN subnet, t= he IPv6 > Transition CE Router MUST allow appropriately subnetting and configur= ing > the address space (which may depend on each transition mechanism) amo= ng > the several interfaces. In some transition mechanisms, this MAY requi= re > differentiating mappings/translations per interfaces." =20 I would suggest changing "MAY" to "may" (the last sentence reads more t= o me as something that simply could be true, rather than something this doc= ument is explicitly permitting). As a nit: I would suggest changing "appropriately" to "appropriate". I can live with this. Thx. Barbara =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 Fri Aug 10 06:36:44 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 95003130E4C; Fri, 10 Aug 2018 06:36:26 -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.83.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <153390818654.25640.4000190988737382245@ietfa.amsl.com> Date: Fri, 10 Aug 2018 06:36:26 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 13:36:33 -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-06.txt Pages : 21 Date : 2018-08-10 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-06 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-ipv4aas-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-transition-ipv4aas-06 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 Aug 10 06:42: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 DBDB4130DCC for ; Fri, 10 Aug 2018 06:42:32 -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 pQZb0N9sNIkI for ; Fri, 10 Aug 2018 06:42:30 -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 7029F130DD5 for ; Fri, 10 Aug 2018 06:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1533908548; x=1534513348; 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=GAgzWWs+ A5hSBFJ8V8TFr7U5eknnR29IGF60t5xbWQA=; b=s5dEb9W4rr7MYjDSJqQi3m8q gyhlOzbM/p5KPUUvr4i9G3O4V3ZEd3K1IszPyJGxuToTi9L9WVreEWhGV3pHXIoF JJhImITx2RQaOK7rBSONXqvTdx+yCnXoiK9c63ATdzEe7idP2NhRSuMAb0K8Ivvc +o1nnfkLsvT2MXgw2pM= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 10 Aug 2018 15:42:28 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 10 Aug 2018 15:42:28 +0200 Received: from [10.20.5.175] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005835405.msg for ; Fri, 10 Aug 2018 15:42:27 +0200 X-MDRemoteIP: 10.8.10.6 X-MDHelo: [10.20.5.175] X-MDArrival-Date: Fri, 10 Aug 2018 15:42:27 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1760d610f2=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.f.0.180709 Date: Fri, 10 Aug 2018 08:42:15 -0500 From: JORDI PALET MARTINEZ To: , Ron Bonica Message-ID: <7582FCA0-D81F-4AD1-9C4C-5D86C7A8088B@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-06.txt References: <153390818654.25640.4000190988737382245@ietfa.amsl.com> In-Reply-To: <153390818654.25640.4000190988737382245@ietfa.amsl.com> 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-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 13:42:33 -0000 Hi all, Ron, I just posted the new version, which I think resolves all the issues: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/?inclu= de_text=3D1 We didn't get confirmation from Richard, who has provided text for the UPnP= section, but I think should be fine (he may be in vacations), in case you = want to start already the last call. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Responder a: Fecha: viernes, 10 de agosto de 2018, 8:38 Para: CC: Asunto: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-06.txt =20 A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the IPv6 Operations WG of the IETF. =20 Title : Requirements for IPv6 Customer Edge Routers t= o Support IPv4 Connectivity as-a-Service Authors : Jordi Palet Martinez Hans M.-H. Liu Masanobu Kawashima Filename : draft-ietf-v6ops-transition-ipv4aas-06.txt Pages : 21 Date : 2018-08-10 =20 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. =20 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. =20 =20 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ =20 There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-transition-ipv4aas-06 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-ipv4a= as-06 =20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-transition-ipv4aas= -06 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =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 Fri Aug 10 06:48: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 7D823130DD5 for ; Fri, 10 Aug 2018 06:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkCYCp14pQUo for ; Fri, 10 Aug 2018 06:48:36 -0700 (PDT) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F345128B14 for ; Fri, 10 Aug 2018 06:48:36 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 41n60M030hz10l9; Fri, 10 Aug 2018 15:48:35 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.21]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 41n60L66YDzDq7W; Fri, 10 Aug 2018 15:48:34 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM6C.corporate.adroot.infra.ftgroup ([fe80::d9f5:9741:7525:a199%18]) with mapi id 14.03.0408.000; Fri, 10 Aug 2018 15:48:34 +0200 From: To: JORDI PALET MARTINEZ , "v6ops@ietf.org" , Ron Bonica Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-06.txt Thread-Index: AQHUMLAODpozxzJOOk+53v5icxRBX6S5ACDg Date: Fri, 10 Aug 2018 13:48:33 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DFA8C64@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <153390818654.25640.4000190988737382245@ietfa.amsl.com> <7582FCA0-D81F-4AD1-9C4C-5D86C7A8088B@consulintel.es> In-Reply-To: <7582FCA0-D81F-4AD1-9C4C-5D86C7A8088B@consulintel.es> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 13:48:39 -0000 SGkgSm9yZGksIA0KDQpJJ20gYWZyYWlkIHRoaXMgdmVyc2lvbiBkb2VzIG5vdCBhZGRyZXNzIHRo ZSBjb21tZW50cyBJIHNoYXJlZCBvbiAtMDUuIA0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1l c3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2Vz QGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEpPUkRJIFBBTEVUIE1BUlRJTkVaDQo+IEVudm95w6nC oDogdmVuZHJlZGkgMTAgYW/Du3QgMjAxOCAxNTo0Mg0KPiDDgMKgOiB2Nm9wc0BpZXRmLm9yZzsg Um9uIEJvbmljYQ0KPiBPYmpldMKgOiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRm LXY2b3BzLXRyYW5zaXRpb24taXB2NGFhcy0wNi50eHQNCj4gDQo+IEhpIGFsbCwgUm9uLA0KPiAN Cj4gDQo+IA0KPiBJIGp1c3QgcG9zdGVkIHRoZSBuZXcgdmVyc2lvbiwgd2hpY2ggSSB0aGluayBy ZXNvbHZlcyBhbGwgdGhlIGlzc3VlczoNCj4gDQo+IA0KPiANCj4gaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy10cmFuc2l0aW9uLQ0KPiBpcHY0YWFzLz9p bmNsdWRlX3RleHQ9MQ0KPiANCj4gDQo+IA0KPiBXZSBkaWRuJ3QgZ2V0IGNvbmZpcm1hdGlvbiBm cm9tIFJpY2hhcmQsIHdobyBoYXMgcHJvdmlkZWQgdGV4dCBmb3IgdGhlIFVQblANCj4gc2VjdGlv biwgYnV0IEkgdGhpbmsgc2hvdWxkIGJlIGZpbmUgKGhlIG1heSBiZSBpbiB2YWNhdGlvbnMpLCBp biBjYXNlIHlvdQ0KPiB3YW50IHRvIHN0YXJ0IGFscmVhZHkgdGhlIGxhc3QgY2FsbC4NCj4gDQo+ IA0KPiANCj4gUmVnYXJkcywNCj4gDQo+IEpvcmRpDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+ IA0KPiDvu78tLS0tLU1lbnNhamUgb3JpZ2luYWwtLS0tLQ0KPiANCj4gRGU6IHY2b3BzIDx2Nm9w cy1ib3VuY2VzQGlldGYub3JnPiBlbiBub21icmUgZGUgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9y Zz4NCj4gDQo+IFJlc3BvbmRlciBhOiA8djZvcHNAaWV0Zi5vcmc+DQo+IA0KPiBGZWNoYTogdmll cm5lcywgMTAgZGUgYWdvc3RvIGRlIDIwMTgsIDg6MzgNCj4gDQo+IFBhcmE6IDxpLWQtYW5ub3Vu Y2VAaWV0Zi5vcmc+DQo+IA0KPiBDQzogPHY2b3BzQGlldGYub3JnPg0KPiANCj4gQXN1bnRvOiBb djZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMtdHJhbnNpdGlvbi1pcHY0YWFzLTA2 LnR4dA0KPiANCj4gDQo+IA0KPiANCj4gDQo+ICAgICBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBh dmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4gZGlyZWN0b3JpZXMu DQo+IA0KPiAgICAgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSVB2NiBPcGVyYXRp b25zIFdHIG9mIHRoZSBJRVRGLg0KPiANCj4gDQo+IA0KPiAgICAgICAgICAgICBUaXRsZSAgICAg ICAgICAgOiBSZXF1aXJlbWVudHMgZm9yIElQdjYgQ3VzdG9tZXIgRWRnZSBSb3V0ZXJzIHRvDQo+ IFN1cHBvcnQgSVB2NCBDb25uZWN0aXZpdHkgYXMtYS1TZXJ2aWNlDQo+IA0KPiAgICAgICAgICAg ICBBdXRob3JzICAgICAgICAgOiBKb3JkaSBQYWxldCBNYXJ0aW5leg0KPiANCj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgSGFucyBNLi1ILiBMaXUNCj4gDQo+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIE1hc2Fub2J1IEthd2FzaGltYQ0KPiANCj4gICAgIAlGaWxlbmFtZSAg ICAgICAgOiBkcmFmdC1pZXRmLXY2b3BzLXRyYW5zaXRpb24taXB2NGFhcy0wNi50eHQNCj4gDQo+ ICAgICAJUGFnZXMgICAgICAgICAgIDogMjENCj4gDQo+ICAgICAJRGF0ZSAgICAgICAgICAgIDog MjAxOC0wOC0xMA0KPiANCj4gDQo+IA0KPiAgICAgQWJzdHJhY3Q6DQo+IA0KPiAgICAgICAgVGhp cyBkb2N1bWVudCBzcGVjaWZpZXMgdGhlIElQdjQgc2VydmljZSBjb250aW51aXR5IHJlcXVpcmVt ZW50cyBmb3INCj4gDQo+ICAgICAgICBhbiBJUHY2IEN1c3RvbWVyIEVkZ2UgKENFKSByb3V0ZXIs IGVpdGhlciBwcm92aWRlZCBieSB0aGUgc2VydmljZQ0KPiANCj4gICAgICAgIHByb3ZpZGVyIG9y IHRocnUgdGhlIHJldGFpbCBtYXJrZXQuDQo+IA0KPiANCj4gDQo+ICAgICAgICBTcGVjaWZpY2Fs bHksIHRoaXMgZG9jdW1lbnQgZXh0ZW5kcyB0aGUgIkJhc2ljIFJlcXVpcmVtZW50cyBmb3IgSVB2 Ng0KPiANCj4gICAgICAgIEN1c3RvbWVyIEVkZ2UgUm91dGVycyIgaW4gb3JkZXIgdG8gYWxsb3cg dGhlIHByb3Zpc2lvbmluZyBvZiBJUHY2DQo+IA0KPiAgICAgICAgdHJhbnNpdGlvbiBzZXJ2aWNl cyBmb3IgdGhlIHN1cHBvcnQgb2YgIklQdjQgYXMtYS1TZXJ2aWNlIiAoSVB2NGFhUykNCj4gDQo+ ICAgICAgICBieSBtZWFucyBvZiBuZXcgdHJhbnNpdGlvbiBtZWNoYW5pc21zLiAgVGhlIGRvY3Vt ZW50IG9ubHkgY292ZXJzDQo+IA0KPiAgICAgICAgdHJhbnNpdGlvbiB0ZWNobm9sb2dpZXMgZm9y IGRlbGl2ZXJpbmcgSVB2NCBpbiBJUHY2LW9ubHkgYWNjZXNzDQo+IA0KPiAgICAgICAgbmV0d29y a3MsIGNvbW1vbmx5IGNhbGxlZCAiSVB2NCBhcy1hLVNlcnZpY2UiIChJUHY0YWFTKSwgYXMgcmVx dWlyZWQNCj4gDQo+ICAgICAgICBpbiBhIHdvcmxkIHdoZXJlIElQdjQgYWRkcmVzc2VzIGFyZSBu byBsb25nZXIgYXZhaWxhYmxlLCBzbyBob3N0cyBpbg0KPiANCj4gICAgICAgIHRoZSBjdXN0b21l ciBMQU5zIHdpdGggSVB2NC1vbmx5IG9yIElQdjYtb25seSBhcHBsaWNhdGlvbnMgb3INCj4gDQo+ ICAgICAgICBkZXZpY2VzLCByZXF1aXJpbmcgdG8gY29tbXVuaWNhdGUgd2l0aCBJUHY0LW9ubHkg c2VydmljZXMgYXQgdGhlDQo+IA0KPiAgICAgICAgSW50ZXJuZXQsIGFyZSBzdGlsbCBhYmxlIHRv IGRvIHNvLg0KPiANCj4gDQo+IA0KPiANCj4gDQo+ICAgICBUaGUgSUVURiBkYXRhdHJhY2tlciBz dGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gDQo+ICAgICBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLXRyYW5zaXRpb24taXB2NGFhcy8NCj4g DQo+IA0KPiANCj4gICAgIFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJs ZSBhdDoNCj4gDQo+ICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi12 Nm9wcy10cmFuc2l0aW9uLWlwdjRhYXMtMDYNCj4gDQo+ICAgICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtdHJhbnNpdGlvbi0NCj4gaXB2NGFh cy0wNg0KPiANCj4gDQo+IA0KPiAgICAgQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24g aXMgYXZhaWxhYmxlIGF0Og0KPiANCj4gICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1pZXRmLXY2b3BzLXRyYW5zaXRpb24taXB2NGFhcy0wNg0KPiANCj4gDQo+IA0K PiANCj4gDQo+ICAgICBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiBzdWJtaXNzaW9uDQo+IA0KPiAgICAgdW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9y Zy4NCj4gDQo+IA0KPiANCj4gICAgIEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUg YnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gDQo+ICAgICBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzLw0KPiANCj4gDQo+IA0KPiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gDQo+ICAgICB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gDQo+ ICAgICB2Nm9wc0BpZXRmLm9yZw0KPiANCj4gICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdjZvcHMNCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KPiBJUHY0IGlzIG92ZXINCj4gQXJl IHlvdSByZWFkeSBmb3IgdGhlIG5ldyBJbnRlcm5ldCA/DQo+IGh0dHA6Ly93d3cuY29uc3VsaW50 ZWwuZXMNCj4gVGhlIElQdjYgQ29tcGFueQ0KPiANCj4gVGhpcyBlbGVjdHJvbmljIG1lc3NhZ2Ug Y29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3INCj4gY29uZmlk ZW50aWFsLiBUaGUgaW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSBleGNsdXNp dmUgdXNlIG9mIHRoZQ0KPiBpbmRpdmlkdWFsKHMpIG5hbWVkIGFib3ZlIGFuZCBmdXJ0aGVyIG5v bi1leHBsaWNpbHR5IGF1dGhvcml6ZWQgZGlzY2xvc3VyZSwNCj4gY29weWluZywgZGlzdHJpYnV0 aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgZXZlbiBpZg0K PiBwYXJ0aWFsbHksIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgc3RyaWN0bHkgcHJvaGli aXRlZCBhbmQgd2lsbCBiZQ0KPiBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2ZmZW5zZS4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2FyZQ0KPiB0aGF0IGFueSBkaXNj bG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0 aGlzDQo+IGluZm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVk IGZpbGVzLCBpcyBzdHJpY3RseQ0KPiBwcm9oaWJpdGVkLCB3aWxsIGJlIGNvbnNpZGVyZWQgYSBj cmltaW5hbCBvZmZlbnNlLCBzbyB5b3UgbXVzdCByZXBseSB0byB0aGUNCj4gb3JpZ2luYWwgc2Vu ZGVyIHRvIGluZm9ybSBhYm91dCB0aGlzIGNvbW11bmljYXRpb24gYW5kIGRlbGV0ZSBpdC4NCj4g DQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== From nobody Fri Aug 10 06:54: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 268CB130DD5 for ; Fri, 10 Aug 2018 06:54:14 -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 uG6mtmaCqaFI for ; Fri, 10 Aug 2018 06:54:11 -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 70B47130DCC for ; Fri, 10 Aug 2018 06:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1533909249; x=1534514049; 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=mZIsg7D9 NDp88+eVR98Qh5Y3RMqu6hpxavgYoK8YwKw=; b=pNYPZuzuxJg6XZZUNuA2K90G yc9KGo4NgwFeRr6HkxaM0mGdGLIF9Zqo9p75whOpRSa3BUMx7FoGP/Vys+wFmudZ zjWeZCIgRq0CqarGNuwAXYqi38PmnICvwwFXRZwpAvc6EKEUwIX+1sdfcLt86GyA OvL+5wqXk2Y/IvHhMGw= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Fri, 10 Aug 2018 15:54:09 +0200 X-Spam-Processed: mail.consulintel.es, Fri, 10 Aug 2018 15:54:09 +0200 Received: from [10.20.5.175] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005835413.msg for ; Fri, 10 Aug 2018 15:54:07 +0200 X-MDRemoteIP: 10.8.10.6 X-MDHelo: [10.20.5.175] X-MDArrival-Date: Fri, 10 Aug 2018 15:54:07 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1760d610f2=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.f.0.180709 Date: Fri, 10 Aug 2018 08:53:58 -0500 From: JORDI PALET MARTINEZ To: "v6ops@ietf.org list" Message-ID: <86A86DDC-77AE-4A72-AC87-ADBDBAED3840@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-06.txt References: <153390818654.25640.4000190988737382245@ietfa.amsl.com> <7582FCA0-D81F-4AD1-9C4C-5D86C7A8088B@consulintel.es> <787AE7BB302AE849A7480A190F8B93302DFA8C64@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DFA8C64@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 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-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 13:54:14 -0000 Hi Med, I guess you're referring basically regarding [I-D.pref64folks-6man-ra-pref6= 4]. We know it, and we are waiting for a decision on this from 6man. I'm happy to remove that if we don't hear anything on that, and also up to = the indications from Ron and Fred. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Fecha: viernes, 10 de agosto de 2018, 8:49 Para: JORDI PALET MARTINEZ ,= "v6ops@ietf.org" , Ron Bonica Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-06.txt Hi Jordi,=20 =20 I'm afraid this version does not address the comments I shared on -05.= =20 =20 Cheers, Med =20 > -----Message d'origine----- > De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de JORDI PALET = MARTINEZ > Envoy=C3=A9 : vendredi 10 ao=C3=BBt 2018 15:42 > =C3=80 : v6ops@ietf.org; Ron Bonica > Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-0= 6.txt >=20 > Hi all, Ron, >=20 >=20 >=20 > I just posted the new version, which I think resolves all the issues: >=20 >=20 >=20 > https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition- > ipv4aas/?include_text=3D1 >=20 >=20 >=20 > We didn't get confirmation from Richard, who has provided text for th= e UPnP > section, but I think should be fine (he may be in vacations), in case= you > want to start already the last call. >=20 >=20 >=20 > Regards, >=20 > Jordi >=20 >=20 >=20 >=20 >=20 >=20 >=20 > =EF=BB=BF-----Mensaje original----- >=20 > De: v6ops en nombre de >=20 > Responder a: >=20 > Fecha: viernes, 10 de agosto de 2018, 8:38 >=20 > Para: >=20 > CC: >=20 > Asunto: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-06.tx= t >=20 >=20 >=20 >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Draft= s > directories. >=20 > This draft is a work item of the IPv6 Operations WG of the IETF. >=20 >=20 >=20 > Title : Requirements for IPv6 Customer Edge Rou= ters to > Support IPv4 Connectivity as-a-Service >=20 > Authors : Jordi Palet Martinez >=20 > Hans M.-H. Liu >=20 > Masanobu Kawashima >=20 > Filename : draft-ietf-v6ops-transition-ipv4aas-06.txt >=20 > Pages : 21 >=20 > Date : 2018-08-10 >=20 >=20 >=20 > Abstract: >=20 > This document specifies the IPv4 service continuity requiremen= ts for >=20 > an IPv6 Customer Edge (CE) router, either provided by the serv= ice >=20 > provider or thru the retail market. >=20 >=20 >=20 > Specifically, this document extends the "Basic Requirements fo= r IPv6 >=20 > Customer Edge Routers" in order to allow the provisioning of I= Pv6 >=20 > transition services for the support of "IPv4 as-a-Service" (IP= v4aaS) >=20 > by means of new transition mechanisms. The document only cove= rs >=20 > transition technologies for delivering IPv4 in IPv6-only acces= s >=20 > networks, commonly called "IPv4 as-a-Service" (IPv4aaS), as re= quired >=20 > in a world where IPv4 addresses are no longer available, so ho= sts in >=20 > the customer LANs with IPv4-only or IPv6-only applications or >=20 > devices, requiring to communicate with IPv4-only services at t= he >=20 > Internet, are still able to do so. >=20 >=20 >=20 >=20 >=20 > The IETF datatracker status page for this draft is: >=20 > https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4= aas/ >=20 >=20 >=20 > There are also htmlized versions available at: >=20 > https://tools.ietf.org/html/draft-ietf-v6ops-transition-ipv4aas-0= 6 >=20 > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition= - > ipv4aas-06 >=20 >=20 >=20 > A diff from the previous version is available at: >=20 > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-transition-i= pv4aas-06 >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission >=20 > until the htmlized version and diff are available at tools.ietf.o= rg. >=20 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: >=20 > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 >=20 > _______________________________________________ >=20 > v6ops mailing list >=20 > v6ops@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=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 the > individual(s) named above and further non-explicilty authorized discl= osure, > copying, distribution or use of the contents of this information, eve= n 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. >=20 >=20 >=20 > _______________________________________________ > 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 =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 Fri Aug 10 07:01: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 42FF5130DD5 for ; Fri, 10 Aug 2018 07:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgXdUFk03W01 for ; Fri, 10 Aug 2018 07:00:58 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9506A129C6A for ; Fri, 10 Aug 2018 07:00:58 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 41n6Gd1TsnzBtPn; Fri, 10 Aug 2018 16:00:57 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 41n6Gd0bRGz2xCW; Fri, 10 Aug 2018 16:00:57 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0408.000; Fri, 10 Aug 2018 16:00:56 +0200 From: To: JORDI PALET MARTINEZ , "v6ops@ietf.org list" Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-06.txt Thread-Index: AQHUMLGv8I71ORo5ZEG2gpN/KEbkg6S5AxUA Date: Fri, 10 Aug 2018 14:00:55 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DFA8C96@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <153390818654.25640.4000190988737382245@ietfa.amsl.com> <7582FCA0-D81F-4AD1-9C4C-5D86C7A8088B@consulintel.es> <787AE7BB302AE849A7480A190F8B93302DFA8C64@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <86A86DDC-77AE-4A72-AC87-ADBDBAED3840@consulintel.es> In-Reply-To: <86A86DDC-77AE-4A72-AC87-ADBDBAED3840@consulintel.es> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 14:01:01 -0000 UmUtLA0KDQpZZXMsIHRoYXQgaXMgYSBtYWpvciBvbmUuLi5idXQgdGhlcmUgYXJlIGFsc28gbWFu eSBvdGhlciBtaW5vciBvbmVzIHRoYXQgSSB3b3VsZCBsaWtlIHRvIHNlZSBmaXhlZC4gDQoNClRo ZSBvbmx5IG9uZXMgd2hpY2ggYXJlIGZpeGVkIGluIC0wNiBhcmUgdGhlIG9uZXMgYWJvdXQgVVBu UC4gVGhhbmtzLiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0t LS0tDQo+IERlwqA6IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEg cGFydCBkZSBKT1JESSBQQUxFVCBNQVJUSU5FWg0KPiBFbnZvecOpwqA6IHZlbmRyZWRpIDEwIGFv w7t0IDIwMTggMTU6NTQNCj4gw4DCoDogdjZvcHNAaWV0Zi5vcmcgbGlzdA0KPiBPYmpldMKgOiBS ZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLXRyYW5zaXRpb24taXB2NGFh cy0wNi50eHQNCj4gDQo+IEhpIE1lZCwNCj4gDQo+IA0KPiANCj4gSSBndWVzcyB5b3UncmUgcmVm ZXJyaW5nIGJhc2ljYWxseSByZWdhcmRpbmcgW0ktRC5wcmVmNjRmb2xrcy02bWFuLXJhLQ0KPiBw cmVmNjRdLg0KPiANCj4gDQo+IA0KPiBXZSBrbm93IGl0LCBhbmQgd2UgYXJlIHdhaXRpbmcgZm9y IGEgZGVjaXNpb24gb24gdGhpcyBmcm9tIDZtYW4uDQo+IA0KPiANCj4gDQo+IEknbSBoYXBweSB0 byByZW1vdmUgdGhhdCBpZiB3ZSBkb24ndCBoZWFyIGFueXRoaW5nIG9uIHRoYXQsIGFuZCBhbHNv IHVwIHRvDQo+IHRoZSBpbmRpY2F0aW9ucyBmcm9tIFJvbiBhbmQgRnJlZC4NCj4gDQo+IA0KPiAN Cj4gUmVnYXJkcywNCj4gDQo+IEpvcmRpDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiDv u78tLS0tLU1lbnNhamUgb3JpZ2luYWwtLS0tLQ0KPiANCj4gRGU6IHY2b3BzIDx2Nm9wcy1ib3Vu Y2VzQGlldGYub3JnPiBlbiBub21icmUgZGUNCj4gPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j b20+DQo+IA0KPiBGZWNoYTogdmllcm5lcywgMTAgZGUgYWdvc3RvIGRlIDIwMTgsIDg6NDkNCj4g DQo+IFBhcmE6IEpPUkRJIFBBTEVUIE1BUlRJTkVaIDxqb3JkaS5wYWxldD00MGNvbnN1bGludGVs LmVzQGRtYXJjLmlldGYub3JnPiwNCj4gInY2b3BzQGlldGYub3JnIiA8djZvcHNAaWV0Zi5vcmc+ LCBSb24gQm9uaWNhIDxyYm9uaWNhQGp1bmlwZXIubmV0Pg0KPiANCj4gQXN1bnRvOiBSZTogW3Y2 b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXY2b3BzLXRyYW5zaXRpb24taXB2NGFhcy0wNi50 eHQNCj4gDQo+IA0KPiANCj4gICAgIEhpIEpvcmRpLA0KPiANCj4gDQo+IA0KPiAgICAgSSdtIGFm cmFpZCB0aGlzIHZlcnNpb24gZG9lcyBub3QgYWRkcmVzcyB0aGUgY29tbWVudHMgSSBzaGFyZWQg b24gLTA1Lg0KPiANCj4gDQo+IA0KPiAgICAgQ2hlZXJzLA0KPiANCj4gICAgIE1lZA0KPiANCj4g DQo+IA0KPiAgICAgPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gDQo+ICAgICA+IERl IDogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEpP UkRJIFBBTEVUDQo+IE1BUlRJTkVaDQo+IA0KPiAgICAgPiBFbnZvecOpIDogdmVuZHJlZGkgMTAg YW/Du3QgMjAxOCAxNTo0Mg0KPiANCj4gICAgID4gw4AgOiB2Nm9wc0BpZXRmLm9yZzsgUm9uIEJv bmljYQ0KPiANCj4gICAgID4gT2JqZXQgOiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1p ZXRmLXY2b3BzLXRyYW5zaXRpb24taXB2NGFhcy0NCj4gMDYudHh0DQo+IA0KPiAgICAgPg0KPiAN Cj4gICAgID4gSGkgYWxsLCBSb24sDQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAg ICA+DQo+IA0KPiAgICAgPiBJIGp1c3QgcG9zdGVkIHRoZSBuZXcgdmVyc2lvbiwgd2hpY2ggSSB0 aGluayByZXNvbHZlcyBhbGwgdGhlIGlzc3VlczoNCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0K PiANCj4gICAgID4NCj4gDQo+ICAgICA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtdjZvcHMtdHJhbnNpdGlvbi0NCj4gDQo+ICAgICA+IGlwdjRhYXMvP2luY2x1 ZGVfdGV4dD0xDQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAg ICAgPiBXZSBkaWRuJ3QgZ2V0IGNvbmZpcm1hdGlvbiBmcm9tIFJpY2hhcmQsIHdobyBoYXMgcHJv dmlkZWQgdGV4dCBmb3IgdGhlDQo+IFVQblANCj4gDQo+ICAgICA+IHNlY3Rpb24sIGJ1dCBJIHRo aW5rIHNob3VsZCBiZSBmaW5lIChoZSBtYXkgYmUgaW4gdmFjYXRpb25zKSwgaW4gY2FzZQ0KPiB5 b3UNCj4gDQo+ICAgICA+IHdhbnQgdG8gc3RhcnQgYWxyZWFkeSB0aGUgbGFzdCBjYWxsLg0KPiAN Cj4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gUmVnYXJkcywN Cj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiBKb3JkaQ0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0KPiAN Cj4gICAgID4NCj4gDQo+ICAgICA+IO+7vy0tLS0tTWVuc2FqZSBvcmlnaW5hbC0tLS0tDQo+IA0K PiAgICAgPg0KPiANCj4gICAgID4gRGU6IHY2b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnPiBl biBub21icmUgZGUgPGludGVybmV0LQ0KPiBkcmFmdHNAaWV0Zi5vcmc+DQo+IA0KPiAgICAgPg0K PiANCj4gICAgID4gUmVzcG9uZGVyIGE6IDx2Nm9wc0BpZXRmLm9yZz4NCj4gDQo+ICAgICA+DQo+ IA0KPiAgICAgPiBGZWNoYTogdmllcm5lcywgMTAgZGUgYWdvc3RvIGRlIDIwMTgsIDg6MzgNCj4g DQo+ICAgICA+DQo+IA0KPiAgICAgPiBQYXJhOiA8aS1kLWFubm91bmNlQGlldGYub3JnPg0KPiAN Cj4gICAgID4NCj4gDQo+ICAgICA+IENDOiA8djZvcHNAaWV0Zi5vcmc+DQo+IA0KPiAgICAgPg0K PiANCj4gICAgID4gQXN1bnRvOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdjZvcHMt dHJhbnNpdGlvbi1pcHY0YWFzLTA2LnR4dA0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0K PiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgQSBOZXcg SW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJh ZnRzDQo+IA0KPiAgICAgPiBkaXJlY3Rvcmllcy4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAg ICAgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSVB2NiBPcGVyYXRpb25zIFdHIG9m IHRoZSBJRVRGLg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4g ICAgID4gICAgICAgICAgICAgVGl0bGUgICAgICAgICAgIDogUmVxdWlyZW1lbnRzIGZvciBJUHY2 IEN1c3RvbWVyIEVkZ2UNCj4gUm91dGVycyB0bw0KPiANCj4gICAgID4gU3VwcG9ydCBJUHY0IENv bm5lY3Rpdml0eSBhcy1hLVNlcnZpY2UNCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgICAg ICAgICBBdXRob3JzICAgICAgICAgOiBKb3JkaSBQYWxldCBNYXJ0aW5leg0KPiANCj4gICAgID4N Cj4gDQo+ICAgICA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEhhbnMgTS4tSC4gTGl1 DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg TWFzYW5vYnUgS2F3YXNoaW1hDQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgIAlGaWxlbmFt ZSAgICAgICAgOiBkcmFmdC1pZXRmLXY2b3BzLXRyYW5zaXRpb24taXB2NGFhcy0wNi50eHQNCj4g DQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgCVBhZ2VzICAgICAgICAgICA6IDIxDQo+IA0KPiAg ICAgPg0KPiANCj4gICAgID4gICAgIAlEYXRlICAgICAgICAgICAgOiAyMDE4LTA4LTEwDQo+IA0K PiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgQWJzdHJh Y3Q6DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgICAgIFRoaXMgZG9jdW1lbnQgc3BlY2lm aWVzIHRoZSBJUHY0IHNlcnZpY2UgY29udGludWl0eSByZXF1aXJlbWVudHMNCj4gZm9yDQo+IA0K PiAgICAgPg0KPiANCj4gICAgID4gICAgICAgIGFuIElQdjYgQ3VzdG9tZXIgRWRnZSAoQ0UpIHJv dXRlciwgZWl0aGVyIHByb3ZpZGVkIGJ5IHRoZQ0KPiBzZXJ2aWNlDQo+IA0KPiAgICAgPg0KPiAN Cj4gICAgID4gICAgICAgIHByb3ZpZGVyIG9yIHRocnUgdGhlIHJldGFpbCBtYXJrZXQuDQo+IA0K PiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgICAgU3Bl Y2lmaWNhbGx5LCB0aGlzIGRvY3VtZW50IGV4dGVuZHMgdGhlICJCYXNpYyBSZXF1aXJlbWVudHMg Zm9yDQo+IElQdjYNCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgICAgQ3VzdG9tZXIgRWRn ZSBSb3V0ZXJzIiBpbiBvcmRlciB0byBhbGxvdyB0aGUgcHJvdmlzaW9uaW5nIG9mDQo+IElQdjYN Cj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgICAgdHJhbnNpdGlvbiBzZXJ2aWNlcyBmb3Ig dGhlIHN1cHBvcnQgb2YgIklQdjQgYXMtYS1TZXJ2aWNlIg0KPiAoSVB2NGFhUykNCj4gDQo+ICAg ICA+DQo+IA0KPiAgICAgPiAgICAgICAgYnkgbWVhbnMgb2YgbmV3IHRyYW5zaXRpb24gbWVjaGFu aXNtcy4gIFRoZSBkb2N1bWVudCBvbmx5IGNvdmVycw0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ ICAgICAgICB0cmFuc2l0aW9uIHRlY2hub2xvZ2llcyBmb3IgZGVsaXZlcmluZyBJUHY0IGluIElQ djYtb25seSBhY2Nlc3MNCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgICAgbmV0d29ya3Ms IGNvbW1vbmx5IGNhbGxlZCAiSVB2NCBhcy1hLVNlcnZpY2UiIChJUHY0YWFTKSwgYXMNCj4gcmVx dWlyZWQNCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgICAgaW4gYSB3b3JsZCB3aGVyZSBJ UHY0IGFkZHJlc3NlcyBhcmUgbm8gbG9uZ2VyIGF2YWlsYWJsZSwgc28NCj4gaG9zdHMgaW4NCj4g DQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgICAgdGhlIGN1c3RvbWVyIExBTnMgd2l0aCBJUHY0 LW9ubHkgb3IgSVB2Ni1vbmx5IGFwcGxpY2F0aW9ucyBvcg0KPiANCj4gICAgID4NCj4gDQo+ICAg ICA+ICAgICAgICBkZXZpY2VzLCByZXF1aXJpbmcgdG8gY29tbXVuaWNhdGUgd2l0aCBJUHY0LW9u bHkgc2VydmljZXMgYXQgdGhlDQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgICAgIEludGVy bmV0LCBhcmUgc3RpbGwgYWJsZSB0byBkbyBzby4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0K PiANCj4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgIFRo ZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPiANCj4g ICAgID4NCj4gDQo+ICAgICA+ICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLXY2b3BzLXRyYW5zaXRpb24tDQo+IGlwdjRhYXMvDQo+IA0KPiAgICAgPg0KPiAN Cj4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgVGhlcmUgYXJlIGFsc28gaHRt bGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAg ICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi12Nm9wcy10cmFuc2l0aW9u LWlwdjRhYXMtMDYNCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXY2b3BzLXRyYW5zaXRpb24tDQo+IA0K PiAgICAgPiBpcHY0YWFzLTA2DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ DQo+IA0KPiAgICAgPiAgICAgQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZh aWxhYmxlIGF0Og0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICBodHRwczovL3d3dy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi12Nm9wcy10cmFuc2l0aW9uLQ0KPiBpcHY0YWFz LTA2DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0K PiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiANCj4gICAgID4gc3VibWlz c2lvbg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0DQo+IHRvb2xzLmlldGYub3JnLg0KPiANCj4g ICAgID4NCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4gICAgIEludGVybmV0 LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gDQo+ICAg ICA+DQo+IA0KPiAgICAgPiAgICAgZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8N Cj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+ICAgICBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiANCj4gICAg ID4NCj4gDQo+ICAgICA+ICAgICB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gDQo+ICAgICA+DQo+IA0K PiAgICAgPiAgICAgdjZvcHNAaWV0Zi5vcmcNCj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPiAgICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KPiANCj4gICAgID4N Cj4gDQo+ICAgICA+DQo+IA0KPiAgICAgPg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0K PiAgICAgPg0KPiANCj4gICAgID4gKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKg0KPiANCj4gICAgID4gSVB2NCBpcyBvdmVyDQo+IA0KPiAgICAgPiBBcmUgeW91 IHJlYWR5IGZvciB0aGUgbmV3IEludGVybmV0ID8NCj4gDQo+ICAgICA+IGh0dHA6Ly93d3cuY29u c3VsaW50ZWwuZXMNCj4gDQo+ICAgICA+IFRoZSBJUHY2IENvbXBhbnkNCj4gDQo+ICAgICA+DQo+ IA0KPiAgICAgPiBUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB3 aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBvcg0KPiANCj4gICAgID4gY29uZmlkZW50aWFsLiBUaGUg aW5mb3JtYXRpb24gaXMgaW50ZW5kZWQgdG8gYmUgZm9yIHRoZSBleGNsdXNpdmUgdXNlDQo+IG9m IHRoZQ0KPiANCj4gICAgID4gaW5kaXZpZHVhbChzKSBuYW1lZCBhYm92ZSBhbmQgZnVydGhlciBu b24tZXhwbGljaWx0eSBhdXRob3JpemVkDQo+IGRpc2Nsb3N1cmUsDQo+IA0KPiAgICAgPiBjb3B5 aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0 aW9uLCBldmVuDQo+IGlmDQo+IA0KPiAgICAgPiBwYXJ0aWFsbHksIGluY2x1ZGluZyBhdHRhY2hl ZCBmaWxlcywgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgd2lsbCBiZQ0KPiANCj4gICAgID4g Y29uc2lkZXJlZCBhIGNyaW1pbmFsIG9mZmVuc2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQgYmUNCj4gYXdhcmUNCj4gDQo+ICAgICA+IHRoYXQgYW55IGRpc2Nsb3N1cmUs IGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mDQo+IHRoaXMN Cj4gDQo+ICAgICA+IGluZm9ybWF0aW9uLCBldmVuIGlmIHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0 dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseQ0KPiANCj4gICAgID4gcHJvaGliaXRlZCwgd2lsbCBi ZSBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2ZmZW5zZSwgc28geW91IG11c3QgcmVwbHkgdG8NCj4g dGhlDQo+IA0KPiAgICAgPiBvcmlnaW5hbCBzZW5kZXIgdG8gaW5mb3JtIGFib3V0IHRoaXMgY29t bXVuaWNhdGlvbiBhbmQgZGVsZXRlIGl0Lg0KPiANCj4gICAgID4NCj4gDQo+ICAgICA+DQo+IA0K PiAgICAgPg0KPiANCj4gICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gDQo+ICAgICA+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiANCj4gICAgID4g djZvcHNAaWV0Zi5vcmcNCj4gDQo+ICAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdjZvcHMNCj4gDQo+ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiANCj4gICAgIHY2b3BzIG1haWxpbmcgbGlzdA0KPiANCj4gICAg IHY2b3BzQGlldGYub3JnDQo+IA0KPiAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby92Nm9wcw0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiAqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQo+IElQdjQgaXMgb3Zlcg0KPiBBcmUgeW91 IHJlYWR5IGZvciB0aGUgbmV3IEludGVybmV0ID8NCj4gaHR0cDovL3d3dy5jb25zdWxpbnRlbC5l cw0KPiBUaGUgSVB2NiBDb21wYW55DQo+IA0KPiBUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250 YWlucyBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBvcg0KPiBjb25maWRlbnRp YWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0byBiZSBmb3IgdGhlIGV4Y2x1c2l2ZSB1 c2Ugb2YgdGhlDQo+IGluZGl2aWR1YWwocykgbmFtZWQgYWJvdmUgYW5kIGZ1cnRoZXIgbm9uLWV4 cGxpY2lsdHkgYXV0aG9yaXplZCBkaXNjbG9zdXJlLA0KPiBjb3B5aW5nLCBkaXN0cmlidXRpb24g b3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmDQo+IHBh cnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVk IGFuZCB3aWxsIGJlDQo+IGNvbnNpZGVyZWQgYSBjcmltaW5hbCBvZmZlbnNlLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlDQo+IHRoYXQgYW55IGRpc2Nsb3N1 cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMN Cj4gaW5mb3JtYXRpb24sIGV2ZW4gaWYgcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmls ZXMsIGlzIHN0cmljdGx5DQo+IHByb2hpYml0ZWQsIHdpbGwgYmUgY29uc2lkZXJlZCBhIGNyaW1p bmFsIG9mZmVuc2UsIHNvIHlvdSBtdXN0IHJlcGx5IHRvIHRoZQ0KPiBvcmlnaW5hbCBzZW5kZXIg dG8gaW5mb3JtIGFib3V0IHRoaXMgY29tbXVuaWNhdGlvbiBhbmQgZGVsZXRlIGl0Lg0KPiANCj4g DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K From nobody Fri Aug 10 10:28: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 4C752130DF4; Fri, 10 Aug 2018 10:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.919 X-Spam-Level: X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 nue1esJ95Oox; Fri, 10 Aug 2018 10:28:10 -0700 (PDT) Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) (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 63ABD1286E3; Fri, 10 Aug 2018 10:28:10 -0700 (PDT) Received: by mail-lf1-f52.google.com with SMTP id u202-v6so7094725lff.9; Fri, 10 Aug 2018 10:28:10 -0700 (PDT) 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=58jY1HmV+1otdHguEBaSBqItMaig6+ovd0DrUXzZ44Y=; b=CUb+9Td+t5oGp4EUef+kPZKVWMnHxTdOGW/cLB/TD3GH6cG5KmV7EybAHSWzwV6Lz0 cdPBF6LUkRuexdfKRvvBcCRvWPuVl8tl7dTB4R8JZmjo/EZXIsq9YzYVlsY2s2VC2r7D KJ+Cbn7DON9UZ4zGtRfAfuRM2GEHg31Db/FJKG3yHwFK/SCsWfL+qLcr1E+5Rt81aURa 3hhPOBEm46snZs6T2g5k0FQ6W6R8IRk2jijBQrw6wO74Fbrrj8jhAenlezKIk5hpvzp2 p7i7ABxFH1zutu/hYH7orxZLnf+VR1fAKcCTwjtJ6xnL6XxJMI5VFHwQgBy0GN0wWnxx eeLw== X-Gm-Message-State: AOUpUlGzv10jdp8RUEgf4cgyAaihU2hgmt9o3aL/H7so1RVaX/a25BhL T9LgVRHad3MXVaR13aVBOukavQMv6VZ86wzHfZe0405I X-Google-Smtp-Source: AA+uWPyb404qKnn/QVxmheG1pkSWXe0hO6bxTisN/FdYGSh8G2JNSRmANEM3RGHA2zXk3RJD9CDqFj1PjIwBYY3JWZ4= X-Received: by 2002:a19:c403:: with SMTP id u3-v6mr4866957lff.87.1533922088503; Fri, 10 Aug 2018 10:28:08 -0700 (PDT) MIME-Version: 1.0 References: <153321790308.2265.731201835682425291.idtracker@ietfa.amsl.com> In-Reply-To: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Fri, 10 Aug 2018 10:27:55 -0700 Message-ID: To: Jen Linkova Cc: suresh@kaloom.com, russ@riw.us, draft-ietf-v6ops-conditional-ras@ietf.org, v6ops@ietf.org, v6ops-chairs@ietf.org, The IESG Content-Type: multipart/alternative; boundary="00000000000032d12205731811b5" Archived-At: Subject: Re: [v6ops] Suresh Krishnan's Yes on draft-ietf-v6ops-conditional-ras-06: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2018 17:28:13 -0000 --00000000000032d12205731811b5 Content-Type: text/plain; charset="UTF-8" At Fri, 10 Aug 2018 22:25:50 +1000, Jen Linkova wrote: > I've added a paragraph clarifying that we only modify preferred > lifetime and that RFC4862 does not > allow an RA with both preferred and valid lifetime for the prefix set > to 0 to invalidate the address completely: > > https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-07 To be very accurate, it's still allowed if the RA is authenticated: Neighbor Discovery [RFC3971]). If the Router Advertisement was authenticated, the valid lifetime of the corresponding address should be set to the Valid Lifetime in the received option. (whether v6ops-conditional-ras should be this accurate is a different question, for which I don't have a strong opinion) -- JINMEI, Tatuya --00000000000032d12205731811b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At Fri, 10 Aug 2018 22:25:50 +1000,
Jen Linkova <furry13@gmail.com> wrote:

&= gt; I've added a paragraph clarifying that we only modify preferred
= > lifetime and that RFC4862 does not
> allow an RA with both prefe= rred and valid lifetime for the prefix set
> to 0 to invalidate the a= ddress completely:
>
> https://tools.ietf.org/html/draft-ietf= -v6ops-conditional-ras-07

To be very accurate, it's still al= lowed if the RA is authenticated:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Neighbor Discovery [RFC3971]).=C2=A0 If the Router Ad= vertisement
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 was a= uthenticated, the valid lifetime of the corresponding
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 address should be set to the Valid Lif= etime in the received
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 option.

(whether v6ops-conditional-ras should be this accurat= e is a different
question, for which I don't have a strong opinion)<= br>
--
JINMEI, Tatuya
--00000000000032d12205731811b5-- From nobody Mon Aug 13 07:30: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 E3DE4130F25 for ; Mon, 13 Aug 2018 07:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] 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 7fVFDfdQ5fw0 for ; Mon, 13 Aug 2018 07:30:28 -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 A63D4130EDC for ; Mon, 13 Aug 2018 07:30:28 -0700 (PDT) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w7DESuoZ004065 for ; Mon, 13 Aug 2018 07:30:28 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=sQST5fkpncwZONFVPa9eNPzSCpl9//tcksfmafEtKmw=; b=b++gyG4qjNIuRnAO6768vTERMzBol6XpkGLLxmmRelOkVgL+UiC7qABZ3xnd1B8QVj5x WglX/uoWz8HNCDgklx8XdzTmPXH8Rr9q46Y6RZzxMUmAT1IYQxEmXLFpQV5zotB6qR3m Av8WX8oNFuO9vBwjTpYwPUQms4siXYasA7smGHYlnwsiRG0dt2VEeOi9BUZuNtfW/ViC SmZVC4MOB9KHNDsIu2IoEIoRd2bY+lF49cIi8HarotgdH8muQKHXD55s+hr6rXfXtrEP NkYbM5w03v6DmJt9QglT0h91FzbY/vnFreEVoOeNUrdrCKAjr7VOvFOi6rs+R5asDs6i 5w== Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0056.outbound.protection.outlook.com [216.32.180.56]) by mx0a-00273201.pphosted.com with ESMTP id 2kuacp84xh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 13 Aug 2018 07:30:28 -0700 Received: from CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) by CO1PR05MB332.namprd05.prod.outlook.com (10.141.69.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.1038.17; Mon, 13 Aug 2018 14:30:25 +0000 Received: from CO1PR05MB443.namprd05.prod.outlook.com ([fe80::7de8:5a5d:b33e:cc4]) by CO1PR05MB443.namprd05.prod.outlook.com ([fe80::7de8:5a5d:b33e:cc4%13]) with mapi id 15.20.1038.023; Mon, 13 Aug 2018 14:30:25 +0000 From: Ron Bonica To: "v6ops@ietf.org" Thread-Topic: draft-ietf-v6ops-ipv6rtr-reqs Thread-Index: AdQzEh9YT9HM1V5BR1OBEPByRr4Y1A== Date: Mon, 13 Aug 2018 14:30:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [66.129.241.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO1PR05MB332; 6:oQxg3ONdkwSikBAO2wcQ2OsHuU+OTLvxT9rrgk95uG5ZCHt32zmy0QPgngL7sYmv2ZdUJtXktylRDzlvWhIoG34i6B4p/dvQmKQjIv6sfs9JBCumjIPNohVt0d0dwghTSRRLlXciA9Kao8ttKhfUFRWdEoSLQ9LZEeLVsDQ18SWqGtyDmIZvY3+SOmeZGs7LZIXBY6ER+gih2XGVwL51vNnl+xSLFJR/8LlKtgW12gmPLDQkl7GpQDBRc97vGFjyWGHf8VQPZbUkLLMBv+acBOlSn21LDaGKRffUxdidO2wGAVgLvD3DugJgMPuhXsUVCOUvujXdUiqsYYcX38h04KB1KAvOK+126Fqyzfq45XzoPLz/Nnefnwo/F5P9+tEu67BaWGroS08UDt3Ch46r/0DJuEE4iheqD9fxb7vV073cmOGqZ6qSJSigB1MP4+Vs9p3V53HKohFhw+UluVcAXw==; 5:PNZQw+zWfSwFM6uCw57uXLduNPYJe/rZ9YpRNBGJuPFQXWdAh5EjAm3RBkrDbSlrqGdhzZ0wLVH7xsJVOKGgQq4uOAfDKNwkWBSO4sjmkiMW/gnBKj6LSwo3xb/C9aHtwvVo7ADkcnkvIcuvoY4jkNLpuJ3ac62lwDAN+qR8kGs=; 7:zIZvVuJWJQaSVYRKE92IBZz7IDH/dtcVNLWnR2iAEFU8RgP32gUyS36RurgWDp9+Pw1k51hyYsAYIHK1pC8gwZ9aDKn/pgUliuJmdN5Y0AslZ7GZrWXk9o0uR9TwNLM8I8WvMz4CA7E8uWn2QTHZlOXZH+7j3ugQ6Q4qE+1f7LkH4QZtH8uoPDlphja/+RLQY8UoeWVq2VUiKZ4Xz07RKyqY4wJFvyOhYfoK6ZmDgUpEjIzBr/f6I9hLUZdA427t x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 80beeecd-1cb7-4dda-3c79-08d601294f52 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:CO1PR05MB332; x-ms-traffictypediagnostic: CO1PR05MB332: 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)(93006095)(93001095)(10201501046)(3231311)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:CO1PR05MB332; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB332; x-forefront-prvs: 07630F72AD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(136003)(376002)(346002)(39860400002)(199004)(189003)(6506007)(25786009)(6436002)(486006)(2351001)(106356001)(2900100001)(476003)(186003)(6116002)(97736004)(5250100002)(3846002)(7696005)(66066001)(2906002)(316002)(2501003)(33656002)(99286004)(86362001)(102836004)(81156014)(81166006)(256004)(8936002)(6916009)(8676002)(7736002)(305945005)(26005)(74316002)(478600001)(105586002)(55016002)(14454004)(5660300001)(558084003)(9686003)(53936002)(5640700003)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB332; H:CO1PR05MB443.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: 1bBd9xFpw5fzjptW0WXQ7JZ6FF2HGWfDpPK9oRDzEBOWeMsdrmhBPThvHlMhOk3dZhSjVD4ZXtZW5zMPOhnE75sSDicWEccp+SvWNk4g2yKrGeZQaTFgga+pib3crPpGNk/EVILyFZVuD286/DwMQOHb/zort1vSWtQddJ86Qc8Y++Buyh3BMrd9PEauj7P5umOcFjiwjwt09UWgC431rfBvIIKaVOJBc2SZo5WkuHSfx+hW4c7d4pZfOaREncvMoj4+iTC96HJARnsvrlxjK+nHIwng3ZYVhow6ZRt4NjCEW3RmUSycP9upbEcNNHAZ6+CwC6nnZRaNDujZ/Wk9yp3jTsMbJNppG9XqgWfRue8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 80beeecd-1cb7-4dda-3c79-08d601294f52 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2018 14:30:25.4330 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB332 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-13_06:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=422 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808130156 Archived-At: Subject: [v6ops] draft-ietf-v6ops-ipv6rtr-reqs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 14:30:30 -0000 Folks, Each week between now and IETF 103, we will review and discuss one draft wi= th an eye towards progressing it. This week, please review and comment on draft-ietf-v6ops-ipv6rtr-reqs. Fred and Ron From nobody Mon Aug 13 08:03:19 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 DA0F3130E92; Mon, 13 Aug 2018 08:03:16 -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.83.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <153417259684.25103.4584394151282079076@ietfa.amsl.com> Date: Mon, 13 Aug 2018 08:03:16 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 15:03:17 -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-07.txt Pages : 21 Date : 2018-08-13 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-07 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-ipv4aas-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-transition-ipv4aas-07 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 Aug 13 08:04: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 8BCF7130F63 for ; Mon, 13 Aug 2018 08:04:51 -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 j0GGgFnmEaEN for ; Mon, 13 Aug 2018 08: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 6BB1E130F59 for ; Mon, 13 Aug 2018 08:04:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1534172685; x=1534777485; 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=RpJrT+Az 9T+Yl3xF228EdJjqvhl3FyLiTDLmaaIk9vU=; b=YF+3zY3rmQ1xKeISDadBrM26 Ej3O+VTDJminWV31D1n4eGondOgczJmSMJgSDKPA/NR0A0gxtGiBCFTodnRitLPA ATw9W6HTFHqJ/K+Q4RzjuEK5WPvGOKaxVPQL+RiG23xGB4Yf/JhOigqksOuKrGgS SywqaQ+pHLFwp/e3QjM= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 13 Aug 2018 17:04:45 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 13 Aug 2018 17:04:43 +0200 Received: from [10.20.5.175] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005837546.msg for ; Mon, 13 Aug 2018 17:04:41 +0200 X-MDRemoteIP: 10.8.10.6 X-MDHelo: [10.20.5.175] X-MDArrival-Date: Mon, 13 Aug 2018 17:04:41 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17631f5d43=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.f.0.180709 Date: Mon, 13 Aug 2018 10:04:30 -0500 From: JORDI PALET MARTINEZ To: , "v6ops@ietf.org list" Message-ID: Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-06.txt References: <153390818654.25640.4000190988737382245@ietfa.amsl.com> <7582FCA0-D81F-4AD1-9C4C-5D86C7A8088B@consulintel.es> <787AE7BB302AE849A7480A190F8B93302DFA8C64@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <86A86DDC-77AE-4A72-AC87-ADBDBAED3840@consulintel.es> <787AE7BB302AE849A7480A190F8B93302DFA8C96@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DFA8C96@OPEXCLILMA3.corporate.adroot.infra.ftgroup> 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-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 15:04:58 -0000 Hi Med, I've reviewed again your comments on version 5, and I think we addressed th= em in the version that just submitted: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ Most of them were already resolved, but I missed to respond you in the list= , sorry about that. The main one: we removed the reference and text related to pref64folks-6man= -ra-pref64. One of your comments was regarding the retail models. Since we started this= work we have a clear idea: If you're an ISP, you choose what transition me= chanisms you want in your device, but if you are a vendor, you must have al= l them, so a customer going to retail can purchase a product that will work= in ISP A, B, C, X ... Z. That's one of the main goals, because small ISPs = always buy in the retails, not high volumes, so we also offer a solution fo= r them, regardless of what they want to use. It also offers a solution for = a customer that has purchased his own device and move form ISP A to ISP Z. The other point is a change vs. RFC7084. This happens in several sections, = including DS-Lite. There have been new important requirements since RFC7084= was published and the WG decided to "disconnect" both documents, so it is = perfectly fine to say even is something was SHOULD in RFC7084, now is MUST = if you want to comply with the new document. We hope this clarify all your pending issues, otherwise, let us know please= . Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops en nombre de Fecha: viernes, 10 de agosto de 2018, 9:01 Para: JORDI PALET MARTINEZ ,= "v6ops@ietf.org list" Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-06.txt Re-, =20 Yes, that is a major one...but there are also many other minor ones tha= t I would like to see fixed.=20 =20 The only ones which are fixed in -06 are the ones about UPnP. Thanks.= =20 =20 Cheers, Med =20 > -----Message d'origine----- > De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de JORDI PALET = MARTINEZ > Envoy=C3=A9 : vendredi 10 ao=C3=BBt 2018 15:54 > =C3=80 : v6ops@ietf.org list > Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-0= 6.txt >=20 > Hi Med, >=20 >=20 >=20 > I guess you're referring basically regarding [I-D.pref64folks-6man-ra= - > pref64]. >=20 >=20 >=20 > We know it, and we are waiting for a decision on this from 6man. >=20 >=20 >=20 > I'm happy to remove that if we don't hear anything on that, and also = up to > the indications from Ron and Fred. >=20 >=20 >=20 > Regards, >=20 > Jordi >=20 >=20 >=20 >=20 >=20 >=20 >=20 > =EF=BB=BF-----Mensaje original----- >=20 > De: v6ops en nombre de > >=20 > Fecha: viernes, 10 de agosto de 2018, 8:49 >=20 > Para: JORDI PALET MARTINEZ , > "v6ops@ietf.org" , Ron Bonica >=20 > Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-0= 6.txt >=20 >=20 >=20 > Hi Jordi, >=20 >=20 >=20 > I'm afraid this version does not address the comments I shared on= -05. >=20 >=20 >=20 > Cheers, >=20 > Med >=20 >=20 >=20 > > -----Message d'origine----- >=20 > > De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de JORDI = PALET > MARTINEZ >=20 > > Envoy=C3=A9 : vendredi 10 ao=C3=BBt 2018 15:42 >=20 > > =C3=80 : v6ops@ietf.org; Ron Bonica >=20 > > Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv= 4aas- > 06.txt >=20 > > >=20 > > Hi all, Ron, >=20 > > >=20 > > >=20 > > >=20 > > I just posted the new version, which I think resolves all the i= ssues: >=20 > > >=20 > > >=20 > > >=20 > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition- >=20 > > ipv4aas/?include_text=3D1 >=20 > > >=20 > > >=20 > > >=20 > > We didn't get confirmation from Richard, who has provided text = for the > UPnP >=20 > > section, but I think should be fine (he may be in vacations), i= n case > you >=20 > > want to start already the last call. >=20 > > >=20 > > >=20 > > >=20 > > Regards, >=20 > > >=20 > > Jordi >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > =EF=BB=BF-----Mensaje original----- >=20 > > >=20 > > De: v6ops en nombre de drafts@ietf.org> >=20 > > >=20 > > Responder a: >=20 > > >=20 > > Fecha: viernes, 10 de agosto de 2018, 8:38 >=20 > > >=20 > > Para: >=20 > > >=20 > > CC: >=20 > > >=20 > > Asunto: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas= -06.txt >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > A New Internet-Draft is available from the on-line Internet= -Drafts >=20 > > directories. >=20 > > >=20 > > This draft is a work item of the IPv6 Operations WG of the = IETF. >=20 > > >=20 > > >=20 > > >=20 > > Title : Requirements for IPv6 Customer Ed= ge > Routers to >=20 > > Support IPv4 Connectivity as-a-Service >=20 > > >=20 > > Authors : Jordi Palet Martinez >=20 > > >=20 > > Hans M.-H. Liu >=20 > > >=20 > > Masanobu Kawashima >=20 > > >=20 > > Filename : draft-ietf-v6ops-transition-ipv4aas-06.t= xt >=20 > > >=20 > > Pages : 21 >=20 > > >=20 > > Date : 2018-08-10 >=20 > > >=20 > > >=20 > > >=20 > > Abstract: >=20 > > >=20 > > This document specifies the IPv4 service continuity requ= irements > for >=20 > > >=20 > > an IPv6 Customer Edge (CE) router, either provided by th= e > service >=20 > > >=20 > > provider or thru the retail market. >=20 > > >=20 > > >=20 > > >=20 > > Specifically, this document extends the "Basic Requireme= nts for > IPv6 >=20 > > >=20 > > Customer Edge Routers" in order to allow the provisionin= g of > IPv6 >=20 > > >=20 > > transition services for the support of "IPv4 as-a-Servic= e" > (IPv4aaS) >=20 > > >=20 > > by means of new transition mechanisms. The document onl= y covers >=20 > > >=20 > > transition technologies for delivering IPv4 in IPv6-only= access >=20 > > >=20 > > networks, commonly called "IPv4 as-a-Service" (IPv4aaS),= as > required >=20 > > >=20 > > in a world where IPv4 addresses are no longer available,= so > hosts in >=20 > > >=20 > > the customer LANs with IPv4-only or IPv6-only applicatio= ns or >=20 > > >=20 > > devices, requiring to communicate with IPv4-only service= s at the >=20 > > >=20 > > Internet, are still able to do so. >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > The IETF datatracker status page for this draft is: >=20 > > >=20 > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-transitio= n- > ipv4aas/ >=20 > > >=20 > > >=20 > > >=20 > > There are also htmlized versions available at: >=20 > > >=20 > > https://tools.ietf.org/html/draft-ietf-v6ops-transition-ipv= 4aas-06 >=20 > > >=20 > > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-tran= sition- >=20 > > ipv4aas-06 >=20 > > >=20 > > >=20 > > >=20 > > A diff from the previous version is available at: >=20 > > >=20 > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-transi= tion- > ipv4aas-06 >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > Please note that it may take a couple of minutes from the t= ime of >=20 > > submission >=20 > > >=20 > > until the htmlized version and diff are available at > tools.ietf.org. >=20 > > >=20 > > >=20 > > >=20 > > Internet-Drafts are also available by anonymous FTP at: >=20 > > >=20 > > ftp://ftp.ietf.org/internet-drafts/ >=20 > > >=20 > > >=20 > > >=20 > > _______________________________________________ >=20 > > >=20 > > v6ops mailing list >=20 > > >=20 > > v6ops@ietf.org >=20 > > >=20 > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > ********************************************** >=20 > > IPv4 is over >=20 > > Are you ready for the new Internet ? >=20 > > http://www.consulintel.es >=20 > > The IPv6 Company >=20 > > >=20 > > This electronic message contains information which may be privi= leged or >=20 > > confidential. The information is intended to be for the exclusi= ve use > of the >=20 > > individual(s) named above and further non-explicilty authorized > disclosure, >=20 > > copying, distribution or use of the contents of this informatio= n, even > if >=20 > > partially, including attached files, is strictly prohibited and= will be >=20 > > considered a criminal offense. If you are not the intended reci= pient be > aware >=20 > > that any disclosure, copying, distribution or use of the conten= ts of > this >=20 > > information, even if partially, including attached files, is st= rictly >=20 > > prohibited, will be considered a criminal offense, so you must = reply to > the >=20 > > original sender to inform about this communication and delete i= t. >=20 > > >=20 > > >=20 > > >=20 > > _______________________________________________ >=20 > > v6ops mailing list >=20 > > v6ops@ietf.org >=20 > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ >=20 > v6ops mailing list >=20 > v6ops@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 >=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 the > individual(s) named above and further non-explicilty authorized discl= osure, > copying, distribution or use of the contents of this information, eve= n 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. >=20 >=20 >=20 > _______________________________________________ > 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 =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 Aug 13 10:25: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 3426F130FE4 for ; Mon, 13 Aug 2018 10:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] 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 QHNM_Qer5cO1 for ; Mon, 13 Aug 2018 10:25:27 -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 943E2130FF4 for ; Mon, 13 Aug 2018 10:25:27 -0700 (PDT) Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w7DHJKx4015786 for ; Mon, 13 Aug 2018 10:25:27 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=hzzdgqydausJSh5hiThBIOylM7LxLZz5T76Z97vXcRM=; b=Zer12FhTDSqpeIiufxTIBLVkNhdT46WCKQ4kKruqYXF9JBbQq7KpJcZXMqbbuy44LUdX k/sQ0OV5Q4K8wsYE0JUdS8JR1PPi3wKV++tvzEMK0FrL4N/NoscjjWS/2NNGjwqxaaMo NofYdt/Sp/uybFCvFRxn5HdqrxV3V6w/gADug2l4KlV6J4SeCjegAVQmmMhzIv8Cji6g oGGq80t3rgsIdZ8wtngdgttrqnWhNczxKS7SGzuioWfWULMhtZt/0nZPc4T2eVJMvSC4 ad+M9UhTDeFferJcnCiRQeQjsb71SxZREr2m6DTKQB197biKwkDEaQnFIW0B9FgcfAHZ 7g== Received: from nam05-co1-obe.outbound.protection.outlook.com (mail-co1nam05lp0080.outbound.protection.outlook.com [216.32.181.80]) by mx0a-00273201.pphosted.com with ESMTP id 2ku8wh0kh5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 13 Aug 2018 10:25:27 -0700 Received: from CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) by CO1PR05MB361.namprd05.prod.outlook.com (10.141.51.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.1038.17; Mon, 13 Aug 2018 17:25:24 +0000 Received: from CO1PR05MB443.namprd05.prod.outlook.com ([fe80::7de8:5a5d:b33e:cc4]) by CO1PR05MB443.namprd05.prod.outlook.com ([fe80::7de8:5a5d:b33e:cc4%13]) with mapi id 15.20.1038.023; Mon, 13 Aug 2018 17:25:24 +0000 From: Ron Bonica To: "v6ops@ietf.org" Thread-Topic: draft-ietf-v6ops-nat64-deployment Thread-Index: AdQzKhQZCcChfCugSfm4f9lvydHvVA== Date: Mon, 13 Aug 2018 17:25:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [66.129.241.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO1PR05MB361; 6:Kt8ePHjXRQobNis/A9BzObk2mU8LwuXHIsYdodzsheoIDfGj7gYG4W0BXflMYeZYGbE3gyp9QQylOmKm+T3Iz2Jz8ZZb7O8oI1UNZLWcjUWaGRzb9EtNzcgwbMQRQ0JoJJFl35i/d6ZQX2vHT3V1TAqMXGN2+kLJ2LAlPHDcFGwHA6vu1/kDRxvN4iY0mwCx3TWice/OioJzSa9GX6xUFnohXNNMn3r2ruSMlKghlwnF4hcvFN6Cmq3U3P7Z8iPPEXowsfmpPBKjlxKPCeZrMGa5o2HmSIZex+HcWxEMK2C4L7KTtJ38yUoH7eAHlaieG0TwJWvpM4Pq1+HZTUSWqzLY9UNpVFFlYGt1HoO/r6xmDtMCxFJ74GcMoCEgFNnLvIEjj0flyhm7SIvFB0uOxw6yprOz50hQXu0jZbvgZivuj+WCkKEUwwe0FxwKXxpV1mLDBa6MUwxTwMkl0aDNqg==; 5:HXOW9LAuR5ZDPDqa73thlODClPaw1geAS+KjZ7H/8mUHyC7c4GY2vJHZNqqQ0Kv0O2Av3G0P19botJwB71puPi3YS+srGG/y6a8YVUPllYS3SkD04pH6v3pCsDQ150dyt4hHMCB0Hxg6dm9IOQcRnHAw3E4fac6q4AB7ycSa3so=; 7:Hn4MVsyBxIPckA7FiBkqyQtWoQaBaVlhBZJtB6JPIg+vXwgEj7Xg1aDrnDIWNQ+8Z+/SYBMUZ2eqxCPUjLLj790SNUjRU5COiLUu5vqh5ZpmxouBmldyqhiFd4f785WRO1C2TLtMZlaxRftS/MazxjtkXyyppffu5+dthf97bLuCaf6HyCkE+ZInQR7wnMP6PIwhgkKomVz8ItUooI+9M6Em02l1WUPcYMlHM/jt8sA/oNywAYdRI5BbC/Jrolda x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 1dc99a66-d698-4ebb-562d-08d60141c10b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600074)(711020)(4618075)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:CO1PR05MB361; x-ms-traffictypediagnostic: CO1PR05MB361: 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)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(3231311)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:CO1PR05MB361; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB361; x-forefront-prvs: 07630F72AD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(396003)(366004)(346002)(376002)(199004)(189003)(54164003)(51444003)(6916009)(256004)(486006)(53936002)(33656002)(7696005)(26005)(99286004)(9686003)(476003)(6116002)(5660300001)(81156014)(2351001)(6506007)(2906002)(6436002)(102836004)(186003)(25786009)(55016002)(5640700003)(8676002)(3846002)(8936002)(81166006)(66066001)(478600001)(97736004)(316002)(86362001)(2900100001)(5250100002)(105586002)(2501003)(305945005)(74316002)(68736007)(7736002)(106356001)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB361; H:CO1PR05MB443.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: IdbXtM+npdEX+rSgYIyZNin7AQ1pD8KkG0a1x+jDhaFtPH++SF3Kthz6R2E0D6+TEEUFeJMRmC4L03w8RyBuD3rKP3/kNiQeNjr3BuLRqHAhhmxk/W+Uv6+kC/uIj2qa/tbwaAZIoZ8JbihZ6HSucBzg6uUEoP47olL8L/h85iOZ2Za2joZ8GTiqL53KoqLKAOMJdAJGSc35Cw+XtljhBL84PPrq1u6J9GtGGgbdxGQsAhsA/OzANVHNwMKX3v7tFpiUooGlngenMZxHq6y383mIw6C0cU1m++f6/i7V012Y019zHeAFbCgP4Cw37MUu736pq1K/ewG7mr5BnIit9Rc+rhRx+rmMSsr53RpTsdw= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 1dc99a66-d698-4ebb-562d-08d60141c10b X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2018 17:25:24.1345 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB361 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-13_07:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=615 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808130177 Archived-At: Subject: [v6ops] draft-ietf-v6ops-nat64-deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 17:25:37 -0000 Folks, This concludes the week of review for draft-ietf-v6ops-nat64-deployment. Th= anks to all who read and commented on the text. We only had a few comments, and I think that all are addressable. So, I wou= ld ask the authors to continue work on the draft. Also, please complete the= appendices (I see a few TBD's). We can revisit the draft after IETF 103. Ron From nobody Mon Aug 13 10:25:48 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 1671213105D for ; Mon, 13 Aug 2018 10:25:42 -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 u5qW-NICh73J for ; Mon, 13 Aug 2018 10:25:37 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 23BA5130FD0 for ; Mon, 13 Aug 2018 10:25:34 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id b15-v6so28577928oib.10 for ; Mon, 13 Aug 2018 10:25:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=ZCUmrFZBQiPuF3446yA9MlXTZaq3872nSXkuxXf3P+I=; b=ZSMjf1erYCpD6HvFmuNA/3YFiuwg8WrG3x8PWpeli9wSZ10W8LWPGSMz6sNGMvGEiG znhcpbL6coMe9NRg5rV5T+UXkN+Mum/BluCYrKTqzAbxfsPtarOUZn3hDVAARBXwwMqx WvW00wALQxyOedIu0wvjALbMq4VoPyD8O1sNAgxWr88aGgDuDBwyWKE9uGt4zyjbhiuY Tw8+Y/f2VVrumL+dVctvGjrZlvielRbBS3aMXR7im5xDxxrQnbcOqqBe/wscIlz4/+9V yxopewn1un3BPzMJkZcRt0NA1ejxxy1WMJyjxBMmSSTgdIM0f5J+rO+8uVHAYYHilEVK BRAQ== 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:subject:date:references:to :in-reply-to:message-id; bh=ZCUmrFZBQiPuF3446yA9MlXTZaq3872nSXkuxXf3P+I=; b=aPUaqf9BSNG+KgxZlTJJmrdINeusvblgzBY07rUaed042BAFwuCTwmfO1dxfsmi1zm m6vP7ms/3mo4VmxBJer9Lm0gGl5x4jONOY5ETVJUMGehmSGnrFJqcSm52vQkn/zyFz1V Ib+LsMCc0H6J5fSQkA4aUIJhGYy754FB0C+lC5BTR/urrwSbgO9iG/FJIn740DGs1+pX OLSyrqwVmArfHog6Fkrpuo8lQvefIFHdVowDu7OZjgCKI7JpuBz7yflHxdyLI0f3cJP1 honxsvbaQQQuRiEtQmnIiekNqOKfB8J6pYjedzhYpxdJGuEtBx0mX9eTSYRtLo9Tk1mO 0T5w== X-Gm-Message-State: AOUpUlG/GB0w+uGfWdUNDK+sNnMJd+7LI9oq9kwzacngjskeqmCm9fWB wIblqb2DwITujEH0L4kS+dGnnNYw X-Google-Smtp-Source: AA+uWPxkKzOQ8Qspbeu7d1amaHJALkaauK1L46PuMyt8LwFXV7nbyCWoPu6mmcE2qufzEjz7uDCQdw== X-Received: by 2002:aca:e6d4:: with SMTP id d203-v6mr17889456oih.311.1534181133304; Mon, 13 Aug 2018 10:25:33 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::1039? ([2600:8802:5600:1546::1039]) by smtp.gmail.com with ESMTPSA id f4-v6sm26145813oic.52.2018.08.13.10.25.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Aug 2018 10:25:32 -0700 (PDT) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_DE2FDC2F-EEB2-41BC-820C-11D43087EC52"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 13 Aug 2018 10:25:30 -0700 References: To: "v6ops@ietf.org" In-Reply-To: Message-Id: <6BDEDE43-8392-4E3A-ACB1-D64F88F03F00@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ipv6rtr-reqs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 17:25:46 -0000 --Apple-Mail=_DE2FDC2F-EEB2-41BC-820C-11D43087EC52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Aug 13, 2018, at 7:30 AM, Ron Bonica wrote: >=20 > Folks, >=20 > Each week between now and IETF 103, we will review and discuss one = draft with an eye towards progressing it. >=20 > This week, please review and comment on draft-ietf-v6ops-ipv6rtr-reqs. FYI: diffs from IETF 102 are at = https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-ipv6rtr-reqs-04.txt= . --Apple-Mail=_DE2FDC2F-EEB2-41BC-820C-11D43087EC52 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+AFAltxvwoACgkQEhdRnd2G P+DB8g//egofV6ECwytMODVKpnhe4GDC+4JItrcKsC0Ve245HgHs1cGE+H5I4JHv JywmB6eaT/PxM5QbQXpNSgQ6o4OmS1IuChgRrs+5BMFoDP/xs1OJg7saSFuqcNwZ vMpMRrS4YxXbVn9KFGj53VCLChcs8G6VA/UZFhpaEoWyIxZwhKzIuOAoaF+7R/kl RIZsucRSqwPsBJKPFmClgZ3OEXayL1rV0RCmuA/C4PKVmYR/Ci0x25NVUe4LbxHO M/QTUf1UCML1Xah9YCzm0QzMyy9lw82vbj1TeRpPNinMVbPH829RT6WClEQbPtai Pw6b7m9fyOwdlchXP7LKb2BpAPrscMgt7kPwrAATGLNTiYwK21Tp8tM6KZnnX/FJ QchkYPyb3r/A/2q6ZEv5S1fHYUQrcjSSArxQoHNvGvk6SI8f1SVF54G66wO2brMC ETBxW/a+Ca8jbTQvtk3Ak7iHUY59o8N+0qab9sXbpZlhp3TIzW7o1OQm0kg63eH/ iBvtagPrMCKTBhCKMkUGqBGs/Mxnbz10tQclK3D7DiBhY3YZxcSwuVDSJ2w6TWg6 r4LEpSYcO/NywEiaUrqcFgb6Dm59+A8/75uM2XeJ/fGZ5o3cBZVkmsIAIQZNnGSp es+y2utFe0xBeK2BWzdNuSeQ8DafECWNv5Em7E8JC7iuzyb6N/w= =GnsH -----END PGP SIGNATURE----- --Apple-Mail=_DE2FDC2F-EEB2-41BC-820C-11D43087EC52-- From nobody Mon Aug 13 13:56:21 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 8C6121310A8 for ; Mon, 13 Aug 2018 13:56:19 -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 BVeDjHuu_igj for ; Mon, 13 Aug 2018 13:56:18 -0700 (PDT) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 E48BC1310A1 for ; Mon, 13 Aug 2018 13:56:17 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id j26-v6so8205894pfi.10 for ; Mon, 13 Aug 2018 13:56:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=i8Pw3IY9mG5onsWyM7AdHGIB1M28FzDcAUe9rqrIteI=; b=KY/Pk583YTqr2XV6sG6fsCxW9xyxv+jDVYrbfgDq9lCSWuhCFPaUsOmV/9AAuZ5lFd 1/BMlFzpKIiFLt5i/dyvgPnrJPCS1chEORWvLiWQrVGHZZycliy+F8vNhXe/6jF7HYhH vPdbACikCyXJP7KITjI5o2M9NB7/cZsIOeCh5i6PP7067rWdJzmF3rhKDV9hqunc73ZI ik5IGVq7ftU70UCj5s7yN3IUjQ9WmlhS9Hc1wQnnsvP1ofTCOytVhH8/6dlDp0u9+ibS N0qpp3dDyQB3xqj+u5D8W6QYrpX/7pnKg7TveHXRMLQpr6uemI5nxZVMbDMI/PcyB5+d GRDg== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=i8Pw3IY9mG5onsWyM7AdHGIB1M28FzDcAUe9rqrIteI=; b=VzJkvL9k4VWd0lFfLlPhuXx73PQkddtf9S3XMyOqRh/oOnff+EW2SNL9m8MSjEaA9B 9YrQMKDbAJf+H/Ktsn3jQgDMJzQMnCnC1B8OOzdk1O1KN/lOrQ/qfh1F8NV54o1k5gTM ZVrIdrGQfUeGNhX1Q6sRyzwAK07QRZA6z/tukk2Cx/QozehB1gZ8VHME9D0OXTc08AIN mrKy1xPQWUplhIaO3QDU2wokIgrE5woA5yPWJCAYC54Cmx5pVE21LsFF7CBrjTL36g5s BIRhUokLEtp4ywC4vNNaL01GPbCGByQDKYYvFOfXnAQ71sTj3Na6KQowDJZSRFYMoGav brBg== X-Gm-Message-State: AOUpUlFzcjRZyKXao991RjSkvVKpYPtwl/BRsG89YxY+bx+p8xMXgj11 E9zBc1X0ut/PNVNBP6vNYYeFcLT9 X-Google-Smtp-Source: AA+uWPyKvbixziuC6DhjBc+Rmdm/e6llMyOmg8/dwaVdjYMIc4GXZUQTgVPood1w5a9XfAGqLFi9+w== X-Received: by 2002:a62:5cc1:: with SMTP id q184-v6mr20582746pfb.241.1534193777267; Mon, 13 Aug 2018 13:56:17 -0700 (PDT) Received: from [192.168.178.30] ([118.148.68.33]) by smtp.gmail.com with ESMTPSA id a15-v6sm30654739pfe.32.2018.08.13.13.56.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Aug 2018 13:56:16 -0700 (PDT) To: Ron Bonica , "v6ops@ietf.org" References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <9d567b8f-70db-0cd5-22dd-e635ca796a11@gmail.com> Date: Tue, 14 Aug 2018 08:56:13 +1200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ipv6rtr-reqs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 20:56:20 -0000 > This week, please review and comment on draft-ietf-v6ops-ipv6rtr-reqs. I think it's in good shape (as an advisory, non-normative document) and just about ready for WGLC. I do wonder whether the document would lose any value if sections 2.1 through 2.3 were deleted. I don't disagree with them, however. Section 2.4 is valuable. Nits: I'd move the Acknowledgments and Contributors sections to the end. s/zccess/access/ Brian From nobody Mon Aug 13 14:22: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 272441310DC for ; Mon, 13 Aug 2018 14:22:43 -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 4YVEKR6ZZgCf for ; Mon, 13 Aug 2018 14:22:41 -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 B9650130E3E for ; Mon, 13 Aug 2018 14:22:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1534195359; x=1534800159; 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=t0OYDhRX nCRdYCVdaFEaX/fN1l95nvJkUdyzddaZEsI=; b=Md15yIzY9PuJNqnZcyE79RiM xYHv/EF+ix4pRiE5CvHmnov7QodKG2pFcn+7xGxNAf25OhnWEBUGRT/1prl2KliI PHhNv5apXotaRpv6ZRyCva7m/Zvcm/704dDoiaRtpw69rZh33mvIx2lucB5/0HwB 9PrFA6dRm9GJk7+viws= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Mon, 13 Aug 2018 23:22:39 +0200 X-Spam-Processed: mail.consulintel.es, Mon, 13 Aug 2018 23:22:38 +0200 Received: from [10.20.5.175] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005837856.msg for ; Mon, 13 Aug 2018 23:22:37 +0200 X-MDRemoteIP: 10.8.10.6 X-MDHelo: [10.20.5.175] X-MDArrival-Date: Mon, 13 Aug 2018 23:22:37 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17631f5d43=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.f.0.180709 Date: Mon, 13 Aug 2018 16:22:29 -0500 From: JORDI PALET MARTINEZ To: Lencse =?UTF-8?B?R8OhYm9y?= , Message-ID: <4E128A44-3B60-42D3-BBEF-222729B40A64@consulintel.es> Thread-Topic: [v6ops] Weekly Review: draft-ietf-v6ops-nat64-deployment References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Weekly Review: draft-ietf-v6ops-nat64-deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2018 21:22:43 -0000 Hi Gabor, I've corrected all your points in a new version that I'm editing. Thanks a = lot! Regarding the NAT64 benchmarking, I fear that if this is going to take half= a year, we can't wait for it, as it may become a showstopper for this docu= ment publication. We can make a -bis or another document at that time. Last issue, I don't see how to make the complete bibliographic data, becaus= e I've already it, and it gets cutdown by the submission system. This is wh= at I've in case you know an alternative way: Methodology for the identification of potential security i= ssues of different IPv6 transition technologies: Threat analysis of DNS64 a= nd stateful NAT64 Computers & Security (Elsevier), vol. 77, no.= 1, pp. 397-411, DOI: 10.1016/j.cose.2018.04.012 Benchmarking DNS64 Implementations: Theory and Practice</t= itle> <author surname=3D"G. Lencse and Y. Kadobayashi"> <organization>Computers Communications (Elsevier), vol. 127, no= . 1, pp. 61-74, September 1, 2018, DOI: 10.1016/j.comcom.2018.05.005</organ= ization> </author> <date month=3D"September" year=3D"2018" /> </front> </reference> Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops <v6ops-bounces@ietf.org> en nombre de Lencse G=C3=A1bor <lencse@h= it.bme.hu> Fecha: lunes, 6 de agosto de 2018, 15:07 Para: <v6ops@ietf.org> Asunto: Re: [v6ops] Weekly Review: draft-ietf-v6ops-nat64-deployment Dear Jordi, =20 I have read draft-ietf-v6ops-nat64-deployment and found a few nits,=20 usually typos. =20 I recommend the following corrections (in the manner: "old text" -->=20 "new text"): =20 1. a. "how as been configured" --> perhaps: "how it has been configured" ? =20 3.1.1 (below Fig. 3) "This is an scenario" --> "This is a scenario" =20 3.1.2 "Furthermore, as indicated in [RFC6877] (464XLAT), can be used in" --> "Furthermore, as indicated in [RFC6877], 464XLAT can be used in" =20 3.3. "In some cases, a "bad" idem is not necessarily" --> "In some cases, a "bad" item is not necessarily" =20 4.1. "they don't perform validation themselves an instead, rely" --> "they don't perform validation themselves and instead, rely" =20 5. "considered de simpler" --> "considered the simpler" =20 13.2. [DNS64-Benchm] G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theory and Practice", September 2018. --> [DNS64-Benchm] G. Lencse and Y. Kadobayashi, "Benchmarking DNS64 Implementations: Theory and Practice", Computer Communications, vol. 127, no. 1, pp. 61-74, September 1, 2018, DOI: 10.1016/j.comcom.2018.05.005 =20 =20 [Threat-DNS64] G. Lencse and Y. Kadobayashi, "Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 a= nd stateful NAT64", September 2018. --> [Threat-DNS64] G. Lencse and Y. Kadobayashi, "Methodology for the identification of potential security issues of different IPv6 transition technologies: Threat analysis of DNS64 a= nd stateful NAT64", Computers & Security (Elsevier), vol. 7= 7, no. 1, pp. 397-411, August 1, 2018, DOI: 10.1016/j.cose.2018.04.012 =20 (Now our papers are fully citable, please include the complete=20 bibliographic data.) =20 Best regards, =20 G=C3=A1bor =20 P.S.: I hope to be able to contribute with NAT64 benchmarking results i= n=20 about a half year. One of my PhD students has implemented an RFC 8219= =20 compliant NAT64 tester. Now it is in a very alpha state, but I hope tha= t=20 we will be able to use it for comparing the performances of several=20 NAT64 implementations during the fall semester. =20 =20 =20 =20 =20 8/6/2018 3:19 PM keltez=C3=A9ssel, Ron Bonica =C3=ADrta: > Folks, > > Each week between now and IETF 103, we will review and discuss one dr= aft with an eye towards progressing it. > > This week, please review and comment on draft-ietf-v6ops-nat64-deploy= ment. > > Fred and Ron > > _______________________________________________ > 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 =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 Aug 13 15:44:49 2018 Return-Path: <internet-drafts@ietf.org> 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 9E1D8126F72; Mon, 13 Aug 2018 15:44:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: <i-d-announce@ietf.org> Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <153420028759.25090.6689047979634098120@ietfa.amsl.com> Date: Mon, 13 Aug 2018 15:44:47 -0700 Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/2_0WZMvxjAL24A43FA15flWrwj8> Subject: [v6ops] I-D Action: draft-ietf-v6ops-nat64-deployment-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 13 Aug 2018 22:44:48 -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 : NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks Author : Jordi Palet Martinez Filename : draft-ietf-v6ops-nat64-deployment-01.txt Pages : 34 Date : 2018-08-13 Abstract: This document describes how NAT64 and 464XLAT can be deployed in an IPv6 network, whether cellular ISP, broadband ISP, or enterprise and the issues to be considered when having an IPv6-only access link, regarding: a) DNS64, b) applications or devices that use literal IPv4 addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-nat64-deployment-01 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nat64-deployment-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-nat64-deployment-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 Aug 13 15:46:40 2018 Return-Path: <prvs=17631f5d43=jordi.palet@consulintel.es> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573EB1310EF for <v6ops@ietfa.amsl.com>; Mon, 13 Aug 2018 15:46: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 p_qYekFZOYPA for <v6ops@ietfa.amsl.com>; Mon, 13 Aug 2018 15:46:36 -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 E39A71310D8 for <v6ops@ietf.org>; Mon, 13 Aug 2018 15:46:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1534200394; x=1534805194; 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=wZ+zefYO0PHK8I49NMSCq ySzMdhnjopk8VmrB62vgEw=; b=UYyMqmPP2k1I2H/PUDpjdncu0jb+IbSAMRjGn i3RJ7QaYkQyhJ/U3f0ZQF29gi1uTv1n1gEikrxIOSbIsgeuKJaU6S45ZCB10CKWM jSGh7yVhmAZTHWtETmRtc/VT9gH3gUDWUR5y/oRGoqVNavy9LDqhtRmv31+OHai3 Qc5yEk= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 14 Aug 2018 00:46:34 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 14 Aug 2018 00:46:33 +0200 Received: from [10.20.5.175] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005837916.msg for <v6ops@ietf.org>; Tue, 14 Aug 2018 00:46:33 +0200 X-MDRemoteIP: 10.8.10.6 X-MDHelo: [10.20.5.175] X-MDArrival-Date: Tue, 14 Aug 2018 00:46:33 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=17631f5d43=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.f.0.180709 Date: Mon, 13 Aug 2018 17:46:25 -0500 From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> To: Ron Bonica <rbonica@juniper.net>, "v6ops@ietf.org" <v6ops@ietf.org> Message-ID: <0A31086B-8FFF-47C2-86E5-571F6DFEEF7B@consulintel.es> Thread-Topic: [v6ops] draft-ietf-v6ops-nat64-deployment Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/xVhnUwg2zHXjOYDEIbhtTalAIaw> Subject: Re: [v6ops] draft-ietf-v6ops-nat64-deployment X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 13 Aug 2018 22:46:38 -0000 Hi Ron, all, I just posted the new version: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/?include= _text=3D1 Hopefully we can get some more people reading the document :-) the next few= weeks. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops <v6ops-bounces@ietf.org> en nombre de Ron Bonica <rbonica@juniper= .net> Fecha: lunes, 13 de agosto de 2018, 12:26 Para: "v6ops@ietf.org" <v6ops@ietf.org> Asunto: [v6ops] draft-ietf-v6ops-nat64-deployment Folks, =20 This concludes the week of review for draft-ietf-v6ops-nat64-deployment= . Thanks to all who read and commented on the text. =20 We only had a few comments, and I think that all are addressable. So, I= would ask the authors to continue work on the draft. Also, please complete= the appendices (I see a few TBD's). =20 We can revisit the draft after IETF 103. =20 = Ron =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 Aug 13 23:36:18 2018 Return-Path: <mohamed.boucadair@orange.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B685F1292AD for <v6ops@ietfa.amsl.com>; Mon, 13 Aug 2018 23:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpVnC71gguH2 for <v6ops@ietfa.amsl.com>; Mon, 13 Aug 2018 23:36:12 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54404126CB6 for <v6ops@ietf.org>; Mon, 13 Aug 2018 23:36:12 -0700 (PDT) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 41qNCZ4rw9zFq1K; Tue, 14 Aug 2018 08:36:10 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.17]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 41qNCZ47RhzCqk4; Tue, 14 Aug 2018 08:36:10 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%18]) with mapi id 14.03.0408.000; Tue, 14 Aug 2018 08:36:10 +0200 From: <mohamed.boucadair@orange.com> To: Ron Bonica <rbonica@juniper.net>, "v6ops@ietf.org" <v6ops@ietf.org> Thread-Topic: draft-ietf-v6ops-ipv6rtr-reqs Thread-Index: AdQzEh9YT9HM1V5BR1OBEPByRr4Y1AAg4ZJw Date: Tue, 14 Aug 2018 06:36:10 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302DFA9AE0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <CO1PR05MB4434A6D22379A22CEDA1113AE390@CO1PR05MB443.namprd05.prod.outlook.com> In-Reply-To: <CO1PR05MB4434A6D22379A22CEDA1113AE390@CO1PR05MB443.namprd05.prod.outlook.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/UCD_DUQ-TW68mO2HWAlyDGiuu4Q> Subject: Re: [v6ops] draft-ietf-v6ops-ipv6rtr-reqs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 14 Aug 2018 06:36:15 -0000 Hi all,=20 Russ, you may update section 5.8 with a pointer to RFC7439 which identifies= some gaps.=20 Also, you may cite in section 3.1 draft-clemm-netmod-nmda-diff which is IMH= O a key feature to compare datastores.=20 Thank you.=20 Cheers, Med > -----Message d'origine----- > De=A0: v6ops [mailto:v6ops-bounces@ietf.org] De la part de Ron Bonica > Envoy=E9=A0: lundi 13 ao=FBt 2018 16:30 > =C0=A0: v6ops@ietf.org > Objet=A0: [v6ops] draft-ietf-v6ops-ipv6rtr-reqs >=20 > Folks, >=20 > Each week between now and IETF 103, we will review and discuss one draft = with > an eye towards progressing it. >=20 > This week, please review and comment on draft-ietf-v6ops-ipv6rtr-reqs. >=20 > Fred and Ron >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Aug 14 00:02:37 2018 Return-Path: <tim.chown@jisc.ac.uk> 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 222AD130DFC for <v6ops@ietfa.amsl.com>; Tue, 14 Aug 2018 00:02:35 -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 (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 WiU7iA8yqwj8 for <v6ops@ietfa.amsl.com>; Tue, 14 Aug 2018 00:02:32 -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 48068126CB6 for <v6ops@ietf.org>; Tue, 14 Aug 2018 00:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1534230150; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QRBpmUJFCRVcoTa05JEUpTRpjq5ip6KoM7TQJGgATO4=; b=eLZwIxXE8dLgNAIFzU4kTWTGtX8OPXgBaTNhizw5x7vtNkNReaZ8ImdkkMfsh81LpexOU3qUUF/m46tcAH/Uni2ZLhJHc1DP5xw4IFt9jelLnVUNHVosiatLPqZx+scquZqZj4FrZhYI2Dl6w47r13HgEcv9pdxN7lZbT2fVbWE= Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-am5eur02lp0151.outbound.protection.outlook.com [213.199.180.151]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-176-RFCUIvddOdKkOmosdlp6Ig-1; Tue, 14 Aug 2018 08:02:28 +0100 Received: from AM0PR07MB4177.eurprd07.prod.outlook.com (52.133.59.156) by AM0PR07MB4498.eurprd07.prod.outlook.com (52.135.151.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1038.17; Tue, 14 Aug 2018 07:02:27 +0000 Received: from AM0PR07MB4177.eurprd07.prod.outlook.com ([fe80::e9fd:e645:4a20:5779]) by AM0PR07MB4177.eurprd07.prod.outlook.com ([fe80::e9fd:e645:4a20:5779%5]) with mapi id 15.20.1038.025; Tue, 14 Aug 2018 07:02:27 +0000 From: Tim Chown <Tim.Chown@jisc.ac.uk> To: Brian E Carpenter <brian.e.carpenter@gmail.com> CC: Ron Bonica <rbonica@juniper.net>, "v6ops@ietf.org" <v6ops@ietf.org> Thread-Topic: [v6ops] draft-ietf-v6ops-ipv6rtr-reqs Thread-Index: AdQzEh9YT9HM1V5BR1OBEPByRr4Y1AANfJ2AABUsAAA= Date: Tue, 14 Aug 2018 07:02:27 +0000 Message-ID: <BA5BF005-D216-40DB-9D5C-84F433C21BE8@jisc.ac.uk> References: <CO1PR05MB4434A6D22379A22CEDA1113AE390@CO1PR05MB443.namprd05.prod.outlook.com> <9d567b8f-70db-0cd5-22dd-e635ca796a11@gmail.com> In-Reply-To: <9d567b8f-70db-0cd5-22dd-e635ca796a11@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.9.1) x-originating-ip: [2001:a88:d510:1101:e5d6:57b5:3127:bdbe] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM0PR07MB4498; 20:vry4M3UzAphuEOxsiIrrLWeJZZBUaA7U/gHfhXPXyp5jOZF7wZL2Tp3vukSnzmfaEkT8M9jcB9IOQSMtP/UDwNfnrTljjs+iwcedpdK0otDNDAIjZuVoEoAS+JGEgWXD0x2V3NLrvnNvU9Ecqe138GeInGAjG/zqXhuGGEano+M= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 308cf5ae-2192-4f7a-40bb-08d601b3e521 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:AM0PR07MB4498; x-ms-traffictypediagnostic: AM0PR07MB4498: x-microsoft-antispam-prvs: <AM0PR07MB44983EBE5BD77DB294CAC535D6380@AM0PR07MB4498.eurprd07.prod.outlook.com> 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)(10201501046)(3002001)(3231311)(944501410)(52105095)(93006095)(93001095)(149027)(150027)(6041310)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:AM0PR07MB4498; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB4498; x-forefront-prvs: 0764C4A8CD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39850400004)(396003)(376002)(366004)(136003)(189003)(199004)(97736004)(5250100002)(256004)(81166006)(53936002)(68736007)(6246003)(14454004)(25786009)(186003)(72206003)(6346003)(53546011)(6506007)(478600001)(46003)(102836004)(6512007)(305945005)(54906003)(446003)(86362001)(2616005)(316002)(6436002)(11346002)(786003)(486006)(99286004)(476003)(6916009)(83716003)(57306001)(6486002)(229853002)(36756003)(105586002)(74482002)(2906002)(5660300001)(8936002)(82746002)(8676002)(50226002)(76176011)(7736002)(39060400002)(81156014)(6116002)(4326008)(33656002)(2900100001)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB4498; H:AM0PR07MB4177.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-microsoft-antispam-message-info: 4y/zkSlt4c8/Y33huDcJ086ZXy3pwTSt3FbF50i4Kk+LnAIRZhth3SmaIp+4xC7Z6dGlEeyenIUf3tdOwV8ssKuBROz8jHz113oMpzMx3t04GDn3mZlS7xciAZ3nfXAuzGiI4Av3kf2Cc1WP+DeoE0f+aRn9TFZJMs+9vBOUisyxjJNxZNlmu2X+YH610TjajVo9VymuVXaHYm0+8SAY2fnNQTKiPYSljG6d+Ag+KCutRgbO162mucG7IgY3Rwt/2WKzhsUzXi+OFzIeG6pAvR9wY58DhFDC96ZmvvYkmxJ4DPkJ2iF+GOpltR3nA+zLxfxte0tFO58O6G4EZ9EUM+xCpqtAC2c77ZWW3L2R1bA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <3242C93C6149FE4FA1A49A0EC021BE21@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 308cf5ae-2192-4f7a-40bb-08d601b3e521 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2018 07:02:27.2688 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4498 X-MC-Unique: RFCUIvddOdKkOmosdlp6Ig-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/hGTkU9RGrDCEVqp68obNLDNJkmM> Subject: Re: [v6ops] draft-ietf-v6ops-ipv6rtr-reqs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 14 Aug 2018 07:02:35 -0000 > On 13 Aug 2018, at 21:56, Brian E Carpenter <brian.e.carpenter@gmail.com>= wrote: >=20 >> This week, please review and comment on draft-ietf-v6ops-ipv6rtr-reqs. >=20 > I think it's in good shape (as an advisory, non-normative document) > and just about ready for WGLC. >=20 > I do wonder whether the document would lose any value if > sections 2.1 through 2.3 were deleted. I don't disagree with > them, however. Section 2.4 is valuable. I really like this section, but I do see that it could be argued that 2.1 t= o 2.3 are superfluous. It would be a shame to lose the text given its qual= ity. Tim From nobody Tue Aug 14 02:18:57 2018 Return-Path: <richard@helix.net.nz> 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 833A2127333 for <v6ops@ietfa.amsl.com>; Tue, 14 Aug 2018 02:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=helix-net-nz.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 AzWwVbnTfLjY for <v6ops@ietfa.amsl.com>; Tue, 14 Aug 2018 02:18:52 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 62066126CB6 for <v6ops@ietf.org>; Tue, 14 Aug 2018 02:18:51 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id 139-v6so18605203itf.0 for <v6ops@ietf.org>; Tue, 14 Aug 2018 02:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mIGFUX+dLk6/c7HG34rA/wPvabKo+0Cv4gjokqZKCnA=; b=QZqO0O3gJDgWmNf0M7mqoT2znArnTQ9Qms86xuFkZ4BiaDwA8od5fcN1/QEqwtrxpD qnf7JWAU8ylxW10CUdJRaCAbltGNX2Id1wK9RI4AwDHHv7MLGtLlKacMog4yxlCYRlFu b/3nB53NANXTpo223sXDXYnMlt9/60mByUMaZmVhzaKXRJsqAxJCMTxCiG64f2xHCmIp kUZYn/cD2c20FT6Z2quOF3mFCEQC0/gQHksp5y5vunI/Sbucu1tT3qDmEC22VSWvOgBM mhZhaPdvOH+r2nqX4FOd+BgHquHlLwbuS4hp8OSqb7WbRI2Hdx3nNZz/PrkfhbaQ52/1 JWMg== 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:content-transfer-encoding; bh=mIGFUX+dLk6/c7HG34rA/wPvabKo+0Cv4gjokqZKCnA=; b=CTfu6Cfl6C1pdhzMCeycwTiEoa6qF2uBCJ7ixPzAhhSjfpDg9qc9GfgYQmR5iXOUL+ wBLTdfgBoRPriAno54qeLqAr6t9SqS+uMhUyH1j/p6RrZXoUqepzfE1N+49oU/bwP/1c 1Vo/am/SX/PTOZL/h/OPnfnHS1IaOATTBZF8dEhrEEgGjvjW8661bKDCToEra/Mkczvu ZKMxMZm+8Klu6TR61QvZF1EZGXonEtL5ylvi4qoWXSzqevHnvGH8pelp/XWRN8GkhpTH wYiYGT9f3Md9fQSao1PF7U9xLM6zQdnGUDUBqM5Q8lp2+5AQ3zU1rHGePFFP7SfbGNBw feuQ== X-Gm-Message-State: AOUpUlG3DuUEa6guMJrENMSghxq9QRA4nfTL+ZFcQ2GVLnCwQQSssCB9 4Q2I+f0ZABbFnV4aAoaiErtxIcQdQyY= X-Google-Smtp-Source: AA+uWPyiKAWdhrOlJLcAOPWcqTc25ud4VmyEd8Cp3k71FfW/QPjCUonCO+OKeV6cyutz9Fnomjf22Q== X-Received: by 2002:a24:36c9:: with SMTP id l192-v6mr13136743itl.62.1534238331113; Tue, 14 Aug 2018 02:18:51 -0700 (PDT) Received: from mail-it0-f54.google.com (mail-it0-f54.google.com. [209.85.214.54]) by smtp.gmail.com with ESMTPSA id f15-v6sm6687284ioh.64.2018.08.14.02.18.50 for <v6ops@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Aug 2018 02:18:50 -0700 (PDT) Received: by mail-it0-f54.google.com with SMTP id 139-v6so18605137itf.0 for <v6ops@ietf.org>; Tue, 14 Aug 2018 02:18:50 -0700 (PDT) X-Received: by 2002:a24:ec2:: with SMTP id 185-v6mr13541491ite.81.1534238330079; Tue, 14 Aug 2018 02:18:50 -0700 (PDT) MIME-Version: 1.0 References: <787AE7BB302AE849A7480A190F8B93302DF66859@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <CAHL_VyCLrvH0wiSkietOdsCgAQkapfHsUAtfARXmLsjUzpchFg@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93302DF66983@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2D09D61DDFA73D4C884805CC7865E6114DE43A3D@GAALPA1MSGUSRBF.ITServices.sbc.com> <CAHL_VyAZbT8WSn11MY2RrnXszWmScjSY_8Gk0Bb1xdB=5bMt2g@mail.gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DE4D923@GAALPA1MSGUSRBF.ITServices.sbc.com> <CAHL_VyDJWrTeu6whXw85W1g1tF_UoHDmT5u4MaVJUWqph3tqow@mail.gmail.com> <19402025-57D9-4F6A-99FE-8563CAD41CE9@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DE6901D@GAALPA1MSGUSRBF.ITServices.sbc.com> <FFF71FE6-2011-43EE-A2ED-A2F0BD78B09D@consulintel.es> In-Reply-To: <FFF71FE6-2011-43EE-A2ED-A2F0BD78B09D@consulintel.es> From: Richard Patterson <richard@helix.net.nz> Date: Tue, 14 Aug 2018 10:18:39 +0100 X-Gmail-Original-Message-ID: <CAHL_VyCOt0Ao+Ei382tFVWBxd-OR+_thgjXT32rwNJaiwxDA1w@mail.gmail.com> Message-ID: <CAHL_VyCOt0Ao+Ei382tFVWBxd-OR+_thgjXT32rwNJaiwxDA1w@mail.gmail.com> To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Cc: bs7652@att.com, "v6ops@ietf.org list" <v6ops@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/hJGXOjP2Lwxg88l6_tgsr8dwP58> Subject: Re: [v6ops] Review of draft-ietf-v6ops-transition-ipv4aas-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 14 Aug 2018 09:18:56 -0000 Hi Jordi, Barbara, I think that satisfactorily covers the cases when both port mapping functions must be rejected. I think, however, I'd still like to see a small paragraph recommending a successful response to an AddAnyPortMapping() request for an unavailable port. Perhaps something like: An AddPortMapping() request for a port that is not available SHOULD result in a successful mapping with an alternative "NewReservedPort" value from within the configured port set range, or as assigned by PCP as per [RFC6970], Section 5.6.1. -Richard On Thu, 9 Aug 2018 at 21:23, JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote: > > Let's see if I got it right: > > > > 5. UPnP Support > > > > If the UPnP WANIPConnection:2 service [UPnP-WANIPC] is enabled on a > > CE router, but cannot be associated with an IPv4 interface > > established by an IPv4aaS mechanism or cannot determine which ports > > are available (through PCP or access to a configured port set, if the > > IPv4aaS mechanism limits the available ports), an AddPortMapping() or > > AddAnyPortMapping() action MUST be rejected with error code 729 > > "ConflictWithOtherMechanisms". > > > > An AddPortMapping() request for a port that is not available MUST > > result in "ConflictInMappingEntry". > > > > Note that IGD:1 and its WANIPConnection:1 service have been > > deprecated by OCF. > > > > [UPnP-WANIPC] > > UPnP Forum, "WANIPConnection:2 Service", December 2010, > > <http://upnp.org/specs/gw/ > > UPnP-gw-WANIPConnection-v2-Service.pdf>. > > > > Regards, > > Jordi > > > > > > > > =EF=BB=BF-----Mensaje original----- > > De: "STARK, BARBARA H" <bs7652@att.com> > > Fecha: jueves, 9 de agosto de 2018, 15:07 > > Para: 'JORDI PALET MARTINEZ' <jordi.palet@consulintel.es>, Richard Patter= son <richard@helix.net.nz> > > CC: "v6ops@ietf.org list" <v6ops@ietf.org> > > Asunto: RE: [v6ops] Review of draft-ietf-v6ops-transition-ipv4aas-05 > > > > > > > > > Hi Richard, Barbara, > > > > > > Thanks and sorry, I'm late reacting to this, working in a new versi= on during > > > the weekend, following Ron advise, in order to go for a last-call. > > > > > > Let me try to summarize what you are saying with a proposed text (b= asic > > > idea, remove superfluous text and only state what may be not obviou= s for an > > > implementor, that already must know about UPnP and has read the res= t of > > > the document ...). Let me know if I missed anything: > > ---------- snip --------- > > > New text: > > > 5. UPnP Support > > > > > > If the [UPnP WANIPConnection:2] service is enabled on a CE router, > > > but cannot be associated with an IPv4 interface established by an > > > IPv4aas mechanism or cannot interwork with PCP or a configured > > > port set, an AddPortMapping() or AddAnyPortMapping() action > > > MUST be rejected with error code 729 "ConflictWithOtherMechanisms". > > > Note that IGD:1 and its WANIPConnection:1 service have been > > > deprecated by OCF. > > > > I think Richard had some concerns with this language (which is the la= nguage I proposed). I went and found what Richard said: > > > > <RP> "interwork with [...] a configured port set" is too vague for m= y liking. It's not clear that this means it should reject > > AddPortMapping() requests for a port outside of the port set, or prov= ide an alternative port when requested with AddAnyPortMapping(). > > I'd like to see this elaborated a bit more on. > > Whilst IGD:1 is deprecated, it is what's out there so we need to make= sure to capture the AddPortMapping() behaviour correctly. Even when newer= CPEs start supporting IGD:2 (most are still dragging their heals IME), it = requires applications to also alter their behaviour to make use of the new = AddAnyPortMapping() function.</RP> > > > > To address Richard's first concern, perhaps replace "or cannot interw= ork with PCP or a configured port set" with "or cannot determine which port= s are available (through PCP or access to a configured port set, if the IPv= aas mechanism limits the available ports)". > > > > To address AddPortMapping() failures, I suggest adding a sentence (be= fore the last sentence) that says "An AddPortMapping() request for a port t= hat is not available MUST result in "ConflictInMappingEntry." > > > > Barbara > > > > > > > > > ********************************************** > 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. > > > From nobody Tue Aug 14 06:26:42 2018 Return-Path: <richard@helix.net.nz> 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 05CC2130E98 for <v6ops@ietfa.amsl.com>; Tue, 14 Aug 2018 06:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=helix-net-nz.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 BcBPG8lh7jZq for <v6ops@ietfa.amsl.com>; Tue, 14 Aug 2018 06:26:36 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 BDB0F130E95 for <v6ops@ietf.org>; Tue, 14 Aug 2018 06:26:36 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id l7-v6so14309751iok.6 for <v6ops@ietf.org>; Tue, 14 Aug 2018 06:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Nlli0LIGWWyRQYT5RC3FDqW6v0ZLmnJnR7dNtsLTg7g=; b=Ws/X/lrI4c7/XdXeg2VISqBL78aUE3jRQEeE2JAIEBZLvDbl6k6eySHXi6m9SYVyQs UZnf+oUjLAiYvMlXRL14syZJBTmCjvsIzSfce5JaRLT+vOC/OoKz2DZNH1tp0nHpeqht 7SsO6Wrmr3pgmez1ixoE8cyisOvopiRlI85hzt4pNw9+Q/9oodLcA89V5dI+sICQjqeZ Vbqnpkpu4Uo1bZr4XUxRzzkEGopqmkiNA18JR8aUy8u8t7yanGf4PA91A2+7Y+Y/yQnu CBMo9NDF9vLshv5BcJU+SIexg/TYL7kbvjcpR07VlzZNJoGFL2BFTdFp5XrOjdpyACYJ /kXg== 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:content-transfer-encoding; bh=Nlli0LIGWWyRQYT5RC3FDqW6v0ZLmnJnR7dNtsLTg7g=; b=aYda9PT5TmP200V66zumTJj+zntnNnFgwa1CIiygrIXz/bFVbjMAT/Kho1m6Eb0QLo 4XZfOltoJOQ9QNOrtnEmUQmOvrNnDkUlOYBnSpcUD3At7XvTlELfDM2esH3mCLqSaHwm 1gig60V56XR7+eSiJ/LSiyMrghVRmx5ud25Kwx9swSm6X950EjALzjHQgiVkTvckAZk0 tR8zNH1MEG5S2NMPlhPrVLWr8sbdhyWnNf9yJUG6/tl/vOHMwo4fRDxwcP9QaO/+Y1vT WTUvjhD/L+utDcZTUoQPVMW0bHywG4DRQUT5miHZHaWh/F1WASVcvQnoNFsZOQQmh6bg LmBg== X-Gm-Message-State: AOUpUlEew0TN+UrhhvsSkGcWZDlFqxHEh4kT3WIePtMbm71gjBqNHTot 0vgWvROIg0pORUQlK9BzJDlFUG0GcgLuxQ== X-Google-Smtp-Source: AA+uWPzyR12eeXIRAXBesZqBceb+8Mvx/AXKykyPnlqvIY/AIfLGdqcSIxBi1NtD8lELL/qjdCKK4A== X-Received: by 2002:a5e:8916:: with SMTP id k22-v6mr19530997ioj.9.1534253195258; Tue, 14 Aug 2018 06:26:35 -0700 (PDT) Received: from mail-io0-f181.google.com (mail-io0-f181.google.com. [209.85.223.181]) by smtp.gmail.com with ESMTPSA id b85-v6sm6781198itd.37.2018.08.14.06.26.34 for <v6ops@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Aug 2018 06:26:35 -0700 (PDT) Received: by mail-io0-f181.google.com with SMTP id l7-v6so14309698iok.6 for <v6ops@ietf.org>; Tue, 14 Aug 2018 06:26:34 -0700 (PDT) X-Received: by 2002:a5e:9745:: with SMTP id h5-v6mr1819267ioq.257.1534253194260; Tue, 14 Aug 2018 06:26:34 -0700 (PDT) MIME-Version: 1.0 References: <787AE7BB302AE849A7480A190F8B93302DF66859@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <CAHL_VyCLrvH0wiSkietOdsCgAQkapfHsUAtfARXmLsjUzpchFg@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93302DF66983@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2D09D61DDFA73D4C884805CC7865E6114DE43A3D@GAALPA1MSGUSRBF.ITServices.sbc.com> <CAHL_VyAZbT8WSn11MY2RrnXszWmScjSY_8Gk0Bb1xdB=5bMt2g@mail.gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DE4D923@GAALPA1MSGUSRBF.ITServices.sbc.com> <CAHL_VyDJWrTeu6whXw85W1g1tF_UoHDmT5u4MaVJUWqph3tqow@mail.gmail.com> <19402025-57D9-4F6A-99FE-8563CAD41CE9@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DE6901D@GAALPA1MSGUSRBF.ITServices.sbc.com> <FFF71FE6-2011-43EE-A2ED-A2F0BD78B09D@consulintel.es> <CAHL_VyCOt0Ao+Ei382tFVWBxd-OR+_thgjXT32rwNJaiwxDA1w@mail.gmail.com> In-Reply-To: <CAHL_VyCOt0Ao+Ei382tFVWBxd-OR+_thgjXT32rwNJaiwxDA1w@mail.gmail.com> From: Richard Patterson <richard@helix.net.nz> Date: Tue, 14 Aug 2018 14:26:23 +0100 X-Gmail-Original-Message-ID: <CAHL_VyDTFpf2MKq-rT3UPZgLguYdsQw+-sC9kSdGGTxRKfRY1g@mail.gmail.com> Message-ID: <CAHL_VyDTFpf2MKq-rT3UPZgLguYdsQw+-sC9kSdGGTxRKfRY1g@mail.gmail.com> To: "v6ops@ietf.org list" <v6ops@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/E-T7WFiItpOkosAbCrh2K8c09aM> Subject: Re: [v6ops] Review of draft-ietf-v6ops-transition-ipv4aas-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 14 Aug 2018 13:26:40 -0000 Apologies, my proposed paragraph should say AddAnyPortMapping() not AddPortMapping() (I've updated the quote in this email) On Tue, 14 Aug 2018 at 10:18, Richard Patterson <richard@helix.net.nz> wrot= e: > > Hi Jordi, Barbara, > > I think that satisfactorily covers the cases when both port mapping > functions must be rejected. I think, however, I'd still like to see a > small paragraph recommending a successful response to an > AddAnyPortMapping() request for an unavailable port. Perhaps > something like: > > An AddAnyPortMapping() request for a port that is not available SHOULD > result in a successful mapping with an alternative "NewReservedPort" > value from within the configured port set range, or as assigned by PCP > as per [RFC6970], Section 5.6.1. > > -Richard > On Thu, 9 Aug 2018 at 21:23, JORDI PALET MARTINEZ > <jordi.palet@consulintel.es> wrote: > > > > Let's see if I got it right: > > > > > > > > 5. UPnP Support > > > > > > > > If the UPnP WANIPConnection:2 service [UPnP-WANIPC] is enabled on a > > > > CE router, but cannot be associated with an IPv4 interface > > > > established by an IPv4aaS mechanism or cannot determine which ports > > > > are available (through PCP or access to a configured port set, if th= e > > > > IPv4aaS mechanism limits the available ports), an AddPortMapping() o= r > > > > AddAnyPortMapping() action MUST be rejected with error code 729 > > > > "ConflictWithOtherMechanisms". > > > > > > > > An AddPortMapping() request for a port that is not available MUST > > > > result in "ConflictInMappingEntry". > > > > > > > > Note that IGD:1 and its WANIPConnection:1 service have been > > > > deprecated by OCF. > > > > > > > > [UPnP-WANIPC] > > > > UPnP Forum, "WANIPConnection:2 Service", December 2010, > > > > <http://upnp.org/specs/gw/ > > > > UPnP-gw-WANIPConnection-v2-Service.pdf>. > > > > > > > > Regards, > > > > Jordi > > > > > > > > > > > > > > > > =EF=BB=BF-----Mensaje original----- > > > > De: "STARK, BARBARA H" <bs7652@att.com> > > > > Fecha: jueves, 9 de agosto de 2018, 15:07 > > > > Para: 'JORDI PALET MARTINEZ' <jordi.palet@consulintel.es>, Richard Patt= erson <richard@helix.net.nz> > > > > CC: "v6ops@ietf.org list" <v6ops@ietf.org> > > > > Asunto: RE: [v6ops] Review of draft-ietf-v6ops-transition-ipv4aas-05 > > > > > > > > > > > > > > > > > Hi Richard, Barbara, > > > > > > > > > > Thanks and sorry, I'm late reacting to this, working in a new ver= sion during > > > > > the weekend, following Ron advise, in order to go for a last-call= . > > > > > > > > > > Let me try to summarize what you are saying with a proposed text = (basic > > > > > idea, remove superfluous text and only state what may be not obvi= ous for an > > > > > implementor, that already must know about UPnP and has read the r= est of > > > > > the document ...). Let me know if I missed anything: > > > > ---------- snip --------- > > > > > New text: > > > > > 5. UPnP Support > > > > > > > > > > If the [UPnP WANIPConnection:2] service is enabled on a CE router= , > > > > > but cannot be associated with an IPv4 interface established by an > > > > > IPv4aas mechanism or cannot interwork with PCP or a configured > > > > > port set, an AddPortMapping() or AddAnyPortMapping() action > > > > > MUST be rejected with error code 729 "ConflictWithOtherMechanisms= ". > > > > > Note that IGD:1 and its WANIPConnection:1 service have been > > > > > deprecated by OCF. > > > > > > > > I think Richard had some concerns with this language (which is the = language I proposed). I went and found what Richard said: > > > > > > > > <RP> "interwork with [...] a configured port set" is too vague for= my liking. It's not clear that this means it should reject > > > > AddPortMapping() requests for a port outside of the port set, or pr= ovide an alternative port when requested with AddAnyPortMapping(). > > > > I'd like to see this elaborated a bit more on. > > > > Whilst IGD:1 is deprecated, it is what's out there so we need to ma= ke sure to capture the AddPortMapping() behaviour correctly. Even when new= er CPEs start supporting IGD:2 (most are still dragging their heals IME), i= t requires applications to also alter their behaviour to make use of the ne= w AddAnyPortMapping() function.</RP> > > > > > > > > To address Richard's first concern, perhaps replace "or cannot inte= rwork with PCP or a configured port set" with "or cannot determine which po= rts are available (through PCP or access to a configured port set, if the I= Pvaas mechanism limits the available ports)". > > > > > > > > To address AddPortMapping() failures, I suggest adding a sentence (= before the last sentence) that says "An AddPortMapping() request for a port= that is not available MUST result in "ConflictInMappingEntry." > > > > > > > > Barbara > > > > > > > > > > > > > > > > > > ********************************************** > > 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 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. > > > > > > From nobody Tue Aug 14 06:49:16 2018 Return-Path: <bs7652@att.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81049130E42 for <v6ops@ietfa.amsl.com>; Tue, 14 Aug 2018 06:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 rOTo6oeyOkdC for <v6ops@ietfa.amsl.com>; Tue, 14 Aug 2018 06:49:14 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 485D812F1A6 for <v6ops@ietf.org>; Tue, 14 Aug 2018 06:49:14 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w7EDj7N5034163; Tue, 14 Aug 2018 09:49:08 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 2kuys18xf5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 14 Aug 2018 09:49:07 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w7EDn7G6011160; Tue, 14 Aug 2018 09:49:07 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [135.47.91.176]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w7EDn29m010973; Tue, 14 Aug 2018 09:49:02 -0400 Received: from zlp30487.vci.att.com (zlp30487.vci.att.com [127.0.0.1]) by zlp30487.vci.att.com (Service) with ESMTP id 28EDA401404E; Tue, 14 Aug 2018 13:49:02 +0000 (GMT) Received: from GAALPA1MSGHUBAH.ITServices.sbc.com (unknown [130.8.218.157]) by zlp30487.vci.att.com (Service) with ESMTPS id 173084014049; Tue, 14 Aug 2018 13:49:02 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.5]) by GAALPA1MSGHUBAH.ITServices.sbc.com ([130.8.218.157]) with mapi id 14.03.0408.000; Tue, 14 Aug 2018 09:49:01 -0400 From: "STARK, BARBARA H" <bs7652@att.com> To: "'Richard Patterson'" <richard@helix.net.nz>, "v6ops@ietf.org list" <v6ops@ietf.org> Thread-Topic: [v6ops] Review of draft-ietf-v6ops-transition-ipv4aas-05 Thread-Index: AdQgS3QgQiNxrFhHTyqVBUzs4Ev5DQAKEf+AAAFoKQAAAuaD4AA2avYAAEx/aQAAMcH0gAMu/ikAAAEMToAACiBGgADkP1SAAAim6IAAB6+xkA== Date: Tue, 14 Aug 2018 13:49:01 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DE6EE35@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <787AE7BB302AE849A7480A190F8B93302DF66859@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <CAHL_VyCLrvH0wiSkietOdsCgAQkapfHsUAtfARXmLsjUzpchFg@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93302DF66983@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2D09D61DDFA73D4C884805CC7865E6114DE43A3D@GAALPA1MSGUSRBF.ITServices.sbc.com> <CAHL_VyAZbT8WSn11MY2RrnXszWmScjSY_8Gk0Bb1xdB=5bMt2g@mail.gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DE4D923@GAALPA1MSGUSRBF.ITServices.sbc.com> <CAHL_VyDJWrTeu6whXw85W1g1tF_UoHDmT5u4MaVJUWqph3tqow@mail.gmail.com> <19402025-57D9-4F6A-99FE-8563CAD41CE9@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DE6901D@GAALPA1MSGUSRBF.ITServices.sbc.com> <FFF71FE6-2011-43EE-A2ED-A2F0BD78B09D@consulintel.es> <CAHL_VyCOt0Ao+Ei382tFVWBxd-OR+_thgjXT32rwNJaiwxDA1w@mail.gmail.com> <CAHL_VyDTFpf2MKq-rT3UPZgLguYdsQw+-sC9kSdGGTxRKfRY1g@mail.gmail.com> In-Reply-To: <CAHL_VyDTFpf2MKq-rT3UPZgLguYdsQw+-sC9kSdGGTxRKfRY1g@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.246.231] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-14_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=898 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808140142 Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/-ukV5fzIPvHHILagdBB5sLxlX-8> Subject: Re: [v6ops] Review of draft-ietf-v6ops-transition-ipv4aas-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 14 Aug 2018 13:49:16 -0000 PiA+ICBBbiBBZGRBbnlQb3J0TWFwcGluZygpIHJlcXVlc3QgZm9yIGEgcG9ydCB0aGF0IGlzIG5v dCBhdmFpbGFibGUNCj4gPiBTSE9VTEQgcmVzdWx0IGluIGEgc3VjY2Vzc2Z1bCBtYXBwaW5nIHdp dGggYW4gYWx0ZXJuYXRpdmUNCj4gIk5ld1Jlc2VydmVkUG9ydCINCj4gPiB2YWx1ZSBmcm9tIHdp dGhpbiB0aGUgY29uZmlndXJlZCBwb3J0IHNldCByYW5nZSwgb3IgYXMgYXNzaWduZWQgYnkgUENQ DQo+ID4gYXMgcGVyIFtSRkM2OTcwXSwgU2VjdGlvbiA1LjYuMS4NCg0KV0ZNLiANCkJhcmJhcmEN Cg== From nobody Tue Aug 14 07:46:56 2018 Return-Path: <prvs=176429812c=jordi.palet@consulintel.es> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0C9130DC9 for <v6ops@ietfa.amsl.com>; Tue, 14 Aug 2018 07:46:54 -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 VndF32_XaS1W for <v6ops@ietfa.amsl.com>; Tue, 14 Aug 2018 07:46: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 5B2DE12426A for <v6ops@ietf.org>; Tue, 14 Aug 2018 07:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1534258008; x=1534862808; 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=UtZj6Fca hcl1P0BtoGaFZ6D6QTcFL4DwkcV7+rcAzOw=; b=lXboIZ7PyXsOplSW2kdUkUMR PEW0Ujq8h5ktnr2kkShQLLzTFOIT792a8KDI5ux4twZJ+u7Nc/nm8cYhJuLBYv8S OJ1VGRw884G4/YPWFQDFY/bancTh1q3qZ0U9JJnoIjdkb1iZo6k6AVHDQ+5CN4HN Ddf9dAx+Ep6knpDl/KU= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 14 Aug 2018 16:46:48 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 14 Aug 2018 16:46:48 +0200 Received: from [10.20.5.175] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005838937.msg for <v6ops@ietf.org>; Tue, 14 Aug 2018 16:46:47 +0200 X-MDRemoteIP: 10.8.10.6 X-MDHelo: [10.20.5.175] X-MDArrival-Date: Tue, 14 Aug 2018 16:46:47 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=176429812c=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.f.0.180709 Date: Tue, 14 Aug 2018 09:46:34 -0500 From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> To: "STARK, BARBARA H" <bs7652@att.com>, 'Richard Patterson' <richard@helix.net.nz>, "v6ops@ietf.org list" <v6ops@ietf.org> Message-ID: <A7BF9912-C5DB-4979-9F3A-A191E784356E@consulintel.es> Thread-Topic: [v6ops] Review of draft-ietf-v6ops-transition-ipv4aas-05 References: <787AE7BB302AE849A7480A190F8B93302DF66859@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <CAHL_VyCLrvH0wiSkietOdsCgAQkapfHsUAtfARXmLsjUzpchFg@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93302DF66983@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <2D09D61DDFA73D4C884805CC7865E6114DE43A3D@GAALPA1MSGUSRBF.ITServices.sbc.com> <CAHL_VyAZbT8WSn11MY2RrnXszWmScjSY_8Gk0Bb1xdB=5bMt2g@mail.gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DE4D923@GAALPA1MSGUSRBF.ITServices.sbc.com> <CAHL_VyDJWrTeu6whXw85W1g1tF_UoHDmT5u4MaVJUWqph3tqow@mail.gmail.com> <19402025-57D9-4F6A-99FE-8563CAD41CE9@consulintel.es> <2D09D61DDFA73D4C884805CC7865E6114DE6901D@GAALPA1MSGUSRBF.ITServices.sbc.com> <FFF71FE6-2011-43EE-A2ED-A2F0BD78B09D@consulintel.es> <CAHL_VyCOt0Ao+Ei382tFVWBxd-OR+_thgjXT32rwNJaiwxDA1w@mail.gmail.com> <CAHL_VyDTFpf2MKq-rT3UPZgLguYdsQw+-sC9kSdGGTxRKfRY1g@mail.gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DE6EE35@GAALPA1MSGUSRBF.ITServices.sbc.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DE6EE35@GAALPA1MSGUSRBF.ITServices.sbc.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/-lG-m9szXxVRuLi1uHxDmMKgBiU> Subject: Re: [v6ops] Review of draft-ietf-v6ops-transition-ipv4aas-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 14 Aug 2018 14:46:55 -0000 Thanks a lot Richard/Barbara. Then the final text for this section will be: 5. UPnP Support If the UPnP WANIPConnection:2 service [UPnP-WANIPC] is enabled on a CE router, but cannot be associated with an IPv4 interface established by an IPv4aaS mechanism or cannot determine which ports are available (through PCP or access to a configured port set, if the IPv4aaS mechanism limits the available ports), an AddPortMapping() or AddAnyPortMapping() action MUST be rejected with error code 729 "ConflictWithOtherMechanisms". An AddPortMapping() request for a port that is not available MUST result in "ConflictInMappingEntry". An AddAnyPortMapping() request for a port that is not available SHOULD result in a successful mapping with an alternative "NewReservedPort" value from within the configured port set range, or as assigned by PCP as per [RFC6970], Section 5.6.1. Note that IGD:1 and its WANIPConnection:1 service have been deprecated by OCF. I will wait a few hours before posting it, just in case we find anything el= se. Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: "STARK, BARBARA H" <bs7652@att.com> Fecha: martes, 14 de agosto de 2018, 8:49 Para: 'Richard Patterson' <richard@helix.net.nz>, "v6ops@ietf.org list" <v6= ops@ietf.org> CC: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Asunto: RE: [v6ops] Review of draft-ietf-v6ops-transition-ipv4aas-05 > > An AddAnyPortMapping() request for a port that is not available > > SHOULD result in a successful mapping with an alternative > "NewReservedPort" > > value from within the configured port set range, or as assigned by = PCP > > as per [RFC6970], Section 5.6.1. =20 WFM.=20 Barbara =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 Aug 14 10:53:41 2018 Return-Path: <fredbaker.ietf@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BB6130EB7 for <v6ops@ietfa.amsl.com>; Tue, 14 Aug 2018 10:53:39 -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 tltHmcwWgDaH for <v6ops@ietfa.amsl.com>; Tue, 14 Aug 2018 10:53:37 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 849C91277C8 for <v6ops@ietf.org>; Tue, 14 Aug 2018 10:53:37 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id s24-v6so10542039edr.8 for <v6ops@ietf.org>; Tue, 14 Aug 2018 10:53:37 -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=lUgSOAVVFiWQY55y6uwP7eQG5svNFzTa1e9LrMFojlQ=; b=s/rTitPt69IlXus8na9pu2PAWGBMYJ1/7aDEmgaZGFIFJOLj5KTs5Cw41NCTlMmDJl v7TZfG0VvLhcGZJwBGVgOyHhTcUCcPcFgXlCkueNsjyYh++d7EPm7qcO1SDc5XWUwZ2z uS5B17jZstBmU9aREgB2D+kj7P6Z0eAdd1P8MKqaV5Fz3v6VtdAB1rkAszXH5bSOhVtu lS8yC/CzKR9b3gYK6P1S8HJsqh7Fwn7+P51lIB9Lh4b0rJy52ZsiXAO1EB9muyYhcLkv 5Quk9NqdJHHdaZ2wn4iQzB/PTqzRGfeiGue+daWj75I9fUTPZxLI2wqmoI+d9CY7Jrxf Ztjw== 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=lUgSOAVVFiWQY55y6uwP7eQG5svNFzTa1e9LrMFojlQ=; b=tofZdIMHe2fSZVCYZ2OFXxFFAHtEy4rFax9Gq7Dqk4hKlfY+9WHbVFBDFD7wW/ks8X b61gay3QcUm1nEi2fmF4ZZ67NAUw5ZLbJEzqeCX3r3L9T4GRb3IzVoUZbiGmigqISm/A 4uWuaSwuEyLhgq0fJxMvrYjB3cbqGAzrby+nPtTEGVU6tAnq4H339AyiSIS2woxPputx k0LKPwZ61GePs5seSytMT1Ebs6j7jFcUDZrBoGCS6LbOKjhnwkYi5YGb44c4o+m0b21M Us/uu42F0cJVVufHaPS2gzc+6V05Dp5iAeRGR7tQgw/Z47Q0/FAmXcU4SGVAygWpr1n6 53gQ== X-Gm-Message-State: AOUpUlFRd966Nc5ieLVpdXrtXdaxCaepCoIKjHP6fs/jA0hg0hGfigF4 4AVNNCCeW7cQtpWULUTTo9Q= X-Google-Smtp-Source: AA+uWPwF5rO1KoIIz3mD8fo0+hQjXgBEPikNVGcMNYxL7Qp33ZJJhYuU27jwiTHDfa+A7ze7fFoITw== X-Received: by 2002:a50:93c5:: with SMTP id o63-v6mr28365094eda.154.1534269216146; Tue, 14 Aug 2018 10:53:36 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::1046? ([2600:8802:5600:1546::1046]) by smtp.gmail.com with ESMTPSA id a15-v6sm22495649edd.47.2018.08.14.10.53.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Aug 2018 10:53:35 -0700 (PDT) From: Fred Baker <fredbaker.ietf@gmail.com> Message-Id: <ABE2A63E-6D39-446E-9524-1B43E3FFEBD8@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_D321824B-655D-4D81-AD76-DB124948BF99"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 14 Aug 2018 10:53:31 -0700 In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DFA9AE0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Cc: Ron Bonica <rbonica@juniper.net>, "v6ops@ietf.org" <v6ops@ietf.org> To: Mohamed Boucadair <mohamed.boucadair@orange.com> References: <CO1PR05MB4434A6D22379A22CEDA1113AE390@CO1PR05MB443.namprd05.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302DFA9AE0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/I20UxAc5KEhO_0pbqZrIMtntHxU> Subject: Re: [v6ops] draft-ietf-v6ops-ipv6rtr-reqs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 14 Aug 2018 17:53:40 -0000 --Apple-Mail=_D321824B-655D-4D81-AD76-DB124948BF99 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Aug 13, 2018, at 11:36 PM, mohamed.boucadair@orange.com wrote: >=20 > Also, you may cite in section 3.1 draft-clemm-netmod-nmda-diff which = is IMHO a key feature to compare datastores. Speaking for myself, I'd be happier with the reference if it were a = working group draft. This is an individual submission that was just = posted on June 12. I moved from NetConf (where it was = draft-clemm-netconf-nmda-diff) to NetMod, per the minutes, and is likely = to get adopted. But it sounds like there is a fair bit of work that = remains to be done on it. = https://datatracker.ietf.org/meeting/102/materials/minutes-102-netmod-00 = --------------------------------------------------------------------------= ------ The fact that there is a highway to hell and a stairway to heaven is an = interesting comment on projected traffic volume... --Apple-Mail=_D321824B-655D-4D81-AD76-DB124948BF99 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+AFAltzFxsACgkQEhdRnd2G P+BcDA//VVq9lbRFHlh1pJXXbVSq9WLz+oBLsO30LD4S8mDM8cZgpuTUSsw6qGYG ClztaHX0kX5Zp4aGfUTXljUgQ7Qf25GZi03tdbRzkeNF3W+dFUVAq3wwPUyvZm8j xmV+l7aH8euCeTi9ivavdO7belUQIQyPBiuTd6nRA4Szel98mD2cKimARuPqCT3P nKsG1684ZvFk2433HgQ2hnsj6M+HiT3nPdMyfL/v3RpqZN/AH+fkb/EJE7aCKB6T LEaE2wgJ2iaYeCPCIb8K0+AJ9hfBSNOToN/dlqvfNEjw0lPW5OYVuXLtd8e9+i7P Fq7D2BCOnnCU8KjQbNTiNeXKdaF/LlywN+9vKsXcxZoXDv1i94O28lMQTbI5FjXW V9dB/8x57x8Ymz5oUXSf+vMhXQGPetjm0BuM7HGYsurUCjm72CVY6kVtrM7QN6l9 7BHC2W8cWqS9SIV4Yegha3S2GKhKOzpgRunzuqCZ4sS8Nnfx2Y6R9+RTEwduDIa6 xVy7IUa+vIeTrBvJ1ePoHOodxuZzjv1fMwwGpx5JFyGMuVHGcA6ZatnpDs6KCSUk 1lCM35l7qCSB4b3AROwQO/9BEM9wFvaEypcKqYZ/TYHySF8YoNcGNmTvkFP+TXAi K71Yp9cJhEsVKI5QSrQBqF0wj2h5wkahkGi16qEFd1i66jGBiB4= =MfeY -----END PGP SIGNATURE----- --Apple-Mail=_D321824B-655D-4D81-AD76-DB124948BF99-- From nobody Tue Aug 14 11:09:40 2018 Return-Path: <internet-drafts@ietf.org> 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 12641130DE6; Tue, 14 Aug 2018 11:09:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: <i-d-announce@ietf.org> Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <153427017905.27196.15270699680348428229@ietfa.amsl.com> Date: Tue, 14 Aug 2018 11:09:39 -0700 Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/8zIgo1f3GBkj5P2JYzIb87MxhV0> Subject: [v6ops] I-D Action: draft-ietf-v6ops-nat64-deployment-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 14 Aug 2018 18:09:39 -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 : NAT64/464XLAT Deployment Guidelines in Operator and Enterprise Networks Author : Jordi Palet Martinez Filename : draft-ietf-v6ops-nat64-deployment-02.txt Pages : 34 Date : 2018-08-14 Abstract: This document describes how NAT64 and 464XLAT can be deployed in an IPv6 network, whether cellular ISP, broadband ISP, or enterprise and the issues to be considered when having an IPv6-only access link, regarding: a) DNS64, b) applications or devices that use literal IPv4 addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-nat64-deployment-02 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nat64-deployment-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-nat64-deployment-02 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 Tue Aug 14 11:16:08 2018 Return-Path: <prvs=176429812c=jordi.palet@consulintel.es> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE444130E9D for <v6ops@ietfa.amsl.com>; Tue, 14 Aug 2018 11:16:06 -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 0aZDcTsfgSlt for <v6ops@ietfa.amsl.com>; Tue, 14 Aug 2018 11:16: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 C0D63130DE6 for <v6ops@ietf.org>; Tue, 14 Aug 2018 11:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1534270560; x=1534875360; 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=lGIWyj4f 4KAkk46yr+fnUE3mw/rG1wGW7dyEAa+J9JU=; b=BnAUQ8+Dh3Pqy3OsqOYVnrxe Iz3J6WdHjyHHEuH190PYZo+ROuTbhc4y2+2215muS3bPBLY1qXKvzgLNgrm70lKd fI5lZS9kKW1eFctNq7AA706mBliaeCOCNTCETMqDRwChmQQCWacVZJPz0wkNKzIP SYaJs9sB3xWVErTMOVc= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Tue, 14 Aug 2018 20:16:00 +0200 X-Spam-Processed: mail.consulintel.es, Tue, 14 Aug 2018 20:15:59 +0200 Received: from [10.20.5.175] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005839133.msg for <v6ops@ietf.org>; Tue, 14 Aug 2018 20:15:58 +0200 X-MDRemoteIP: 10.8.10.6 X-MDHelo: [10.20.5.175] X-MDArrival-Date: Tue, 14 Aug 2018 20:15:58 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=176429812c=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.f.0.180709 Date: Tue, 14 Aug 2018 13:15:47 -0500 From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> To: <v6ops@ietf.org> Message-ID: <53F35FA4-BFF1-4F54-BC91-EFAC2F65691C@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-nat64-deployment-02.txt References: <153427017905.27196.15270699680348428229@ietfa.amsl.com> In-Reply-To: <153427017905.27196.15270699680348428229@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/zNgkG7bwN6vYoBqrS36WrE9ARj8> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-nat64-deployment-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 14 Aug 2018 18:16:07 -0000 Hi all, I need to explain about this new version in just one day ... https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/?include= _text=3D1 Some week ago, Med (thousand excuses to him) provided many inputs to this d= ocument, but for some reason when I opened the doc with the track of change= s, I only saw the comments but not changes ... So, after double-checking, I've implemented most of his inputs. Is not a big change in the sense of "changing" the document direction, just= removing some not appropriate normative language and clarifications on the= text here and there. Thanks again for the inputs! Hopefully other folks can soon provide additional complete reviews, special= ly the two that volunteered in the last meeting ... Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops <v6ops-bounces@ietf.org> en nombre de <internet-drafts@ietf.org> Responder a: <v6ops@ietf.org> Fecha: martes, 14 de agosto de 2018, 13:10 Para: <i-d-announce@ietf.org> CC: <v6ops@ietf.org> Asunto: [v6ops] I-D Action: draft-ietf-v6ops-nat64-deployment-02.txt =20 A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the IPv6 Operations WG of the IETF. =20 Title : NAT64/464XLAT Deployment Guidelines in Operat= or and Enterprise Networks Author : Jordi Palet Martinez Filename : draft-ietf-v6ops-nat64-deployment-02.txt Pages : 34 Date : 2018-08-14 =20 Abstract: This document describes how NAT64 and 464XLAT can be deployed in an IPv6 network, whether cellular ISP, broadband ISP, or enterprise and the issues to be considered when having an IPv6-only access link, regarding: a) DNS64, b) applications or devices that use literal IPv= 4 addresses or non-IPv6 compliant APIs, and c) IPv4-only hosts or applications. =20 =20 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-nat64-deployment/ =20 There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-nat64-deployment-02 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nat64-deployment= -02 =20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-nat64-deployment-0= 2 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =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 Aug 15 08:45:20 2018 Return-Path: <suresh.krishnan@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691A0131069; Wed, 15 Aug 2018 08:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 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, FREEMAIL_REPLY=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 YtqJjGwl-at3; Wed, 15 Aug 2018 08:45:02 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 28411130FE9; Wed, 15 Aug 2018 08:45:01 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id h23-v6so2484626ita.5; Wed, 15 Aug 2018 08:45:01 -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=+uKyF4XsfD5n/yXKIqZ71SWh36KUy9rqOoOjZUmqr8Y=; b=COLds982gt2UmgZyhIjuL3JYOmqFWYhSdep8F2LIU8xskJW5g2Q3D87aLz5cAbHUst cmkUzsyVMIvYnfnDcIzuvEhx69u65g8ljFIj+D96xmP+KM5dAUjnEAWdXRNIBZRrAGih OC7f9EPe1htKHYkZcJdLvd1MVF0W7JgbMwSLVYga2kWC/15CgrTaecSIwUhQhIVHRywU IzNnqGk7X/S0gMaThfG1P5g+jRjXSB3XGRCx5BociGOK9sw7fWom8QUM7n2+bnrSZh0T aRYYr8T4YgJDBDmFvHqeb4aCNqosBsSNArdgrkizUBhX5XNcARv3eOamhOeXwd9kvdKx 9pVw== 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=+uKyF4XsfD5n/yXKIqZ71SWh36KUy9rqOoOjZUmqr8Y=; b=oJ8XkyIKI/FLbF+LPJa21dhYI2NCXfrrSxQfGAYQCK4CI6s4OKda/2V3UnqkdTD/R1 roPUUowyHAkgAJSp3XjrbEGzgLF5yAD3lgLidFp90oLcHpFL5WU21izPuPSGkLiiTHn+ e0grw4zlRLF4a8w1OkMbKl5cQkOryTNhR9gjF5OuV19UVHJRf1z5WAk3iuWJx6f6XN6w 8PMVoejI+ho8EKh7vBMWq82c7xYBeP7rsWPD6zEacjpo5h7fhe5REBaaCNrB7jQUipmc zg0BMhJqO686pvwjK+/Emr3sKGOKVJ528zoZRHpnwbsmf+WXnYtIp+GnJPXO7/AsXk6R dZyA== X-Gm-Message-State: AOUpUlGJC1o6GcUR3Q9qVCbySbtZb3paq7FZjSSTQOz8ErOn1wCDbwjc Uum7emQQmf4dqJZh+k11alrG5Yt2BG4= X-Google-Smtp-Source: AA+uWPx8tVdg50xkv58qowysnKI+8/fw2VAuQHYqu6S3MuTIjdREO0eNm15vZDz+NOucdvDTYn6a9A== X-Received: by 2002:a02:4dda:: with SMTP id t87-v6mr23527889jad.51.1534347900386; Wed, 15 Aug 2018 08:45:00 -0700 (PDT) Received: from [10.0.0.15] (45-19-110-76.lightspeed.tukrga.sbcglobal.net. [45.19.110.76]) by smtp.gmail.com with ESMTPSA id m7-v6sm9191648iog.30.2018.08.15.08.44.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Aug 2018 08:44:59 -0700 (PDT) From: Suresh Krishnan <suresh.krishnan@gmail.com> Message-Id: <1DCC2206-60F2-4B21-BEE2-02C36E6A5CC2@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_14004EDF-1D78-41AB-89FE-2718FCB6D4A9" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 15 Aug 2018 11:44:58 -0400 In-Reply-To: <CAJE_bqeEUKWBA1St3du0aJ=KQJenj-j0XGXwiPQGk9CZJN24Gg@mail.gmail.com> Cc: Jen Linkova <furry13@gmail.com>, v6ops@ietf.org, russ@riw.us, v6ops-chairs@ietf.org, draft-ietf-v6ops-conditional-ras@ietf.org, The IESG <iesg@ietf.org> To: =?utf-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp> References: <153321790308.2265.731201835682425291.idtracker@ietfa.amsl.com> <CAFU7BAQVqWajKtnsAZ4Ys52BZS7hkoD2E0vmB-Dg=+pYndxCMQ@mail.gmail.com> <CAJE_bqeEUKWBA1St3du0aJ=KQJenj-j0XGXwiPQGk9CZJN24Gg@mail.gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/LzXBq91xLKFBck9-0CKcJhw3oBg> Subject: Re: [v6ops] Suresh Krishnan's Yes on draft-ietf-v6ops-conditional-ras-06: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 15 Aug 2018 15:45:04 -0000 --Apple-Mail=_14004EDF-1D78-41AB-89FE-2718FCB6D4A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Jinmei-san, > On Aug 10, 2018, at 1:27 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 = <jinmei@wide.ad.jp <mailto:jinmei@wide.ad.jp>> wrote: >=20 > At Fri, 10 Aug 2018 22:25:50 +1000, > Jen Linkova <furry13@gmail.com <mailto:furry13@gmail.com>> wrote: >=20 > > I've added a paragraph clarifying that we only modify preferred > > lifetime and that RFC4862 does not > > allow an RA with both preferred and valid lifetime for the prefix = set > > to 0 to invalidate the address completely: > >=20 > > https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-07 = <https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-07> >=20 > To be very accurate, it's still allowed if the RA is authenticated: >=20 > Neighbor Discovery [RFC3971]). If the Router Advertisement > was authenticated, the valid lifetime of the corresponding > address should be set to the Valid Lifetime in the received > option. >=20 > (whether v6ops-conditional-ras should be this accurate is a different > question, for which I don't have a strong opinion) Yes. You are absolutely correct, but given the lack of deployment of = SEND this pretty much means that this will be a no-op. To allow for = wiggle room we can add something like =E2=80=9Cin most cases=E2=80=9D to = qualify the new text regarding valid lifetime. Thanks Suresh= --Apple-Mail=_14004EDF-1D78-41AB-89FE-2718FCB6D4A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><meta= http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8" = class=3D""><div style=3D"word-wrap: break-word; -webkit-nbsp-mode: = space; line-break: after-white-space;" class=3D"">Hi Jinmei-san,<br = class=3D""><div class=3D""><br class=3D""><blockquote type=3D"cite" = class=3D""><div class=3D"">On Aug 10, 2018, at 1:27 PM, =E7=A5=9E=E6=98=8E= =E9=81=94=E5=93=89 <<a href=3D"mailto:jinmei@wide.ad.jp" = class=3D"">jinmei@wide.ad.jp</a>> wrote:</div><br = class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" = class=3D"">At Fri, 10 Aug 2018 22:25:50 +1000,<br class=3D"">Jen Linkova = <<a href=3D"mailto:furry13@gmail.com" = class=3D"">furry13@gmail.com</a>> wrote:<br class=3D""><br = class=3D"">> I've added a paragraph clarifying that we only modify = preferred<br class=3D"">> lifetime and that RFC4862 does not<br = class=3D"">> allow an RA with both preferred and valid lifetime for = the prefix set<br class=3D"">> to 0 to invalidate the address = completely:<br class=3D"">> <br class=3D"">> <a = href=3D"https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-07" = class=3D"">https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-07= </a><br class=3D""><br class=3D"">To be very accurate, it's still = allowed if the RA is authenticated:<br class=3D""><br = class=3D"">          = Neighbor Discovery [RFC3971]).  If the Router Advertisement<br = class=3D"">          was = authenticated, the valid lifetime of the corresponding<br = class=3D"">          = address should be set to the Valid Lifetime in the received<br = class=3D"">          = option.<br class=3D""><br class=3D"">(whether v6ops-conditional-ras = should be this accurate is a different<br class=3D"">question, for which = I don't have a strong opinion)<br class=3D""></div></div></blockquote><div= class=3D""><br class=3D""></div>Yes. You are absolutely correct, but = given the lack of deployment of SEND this pretty much means that this = will be a no-op. To allow for wiggle room we can add something like = =E2=80=9Cin most cases=E2=80=9D to qualify the new text regarding valid = lifetime.</div><div class=3D""><br class=3D""></div><div = class=3D"">Thanks</div><div class=3D"">Suresh</div></div></body></html>= --Apple-Mail=_14004EDF-1D78-41AB-89FE-2718FCB6D4A9-- From nobody Wed Aug 15 08:47:05 2018 Return-Path: <suresh.krishnan@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B29130FC7; Wed, 15 Aug 2018 08:46:54 -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 V5jXXtRr55cD; Wed, 15 Aug 2018 08:46:49 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 A2F6E128CF3; Wed, 15 Aug 2018 08:46:49 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id l14-v6so1333256iob.7; Wed, 15 Aug 2018 08:46:49 -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=gA1FtWUyQdl4YVK/MUzfA3aSHWRXYmFeDKmIylxF1Qg=; b=J9QDppYoFkBSfoiyD6rPoUPJUgwDT3/NPs4+lCpzm0TS6gyEu9Vj7306Jr3p/j46jE qU/UyLQUtkuqnfBp4/T8unb/e30qgR7sv/RJJ/78epuPIndNdz6vayYwZrTAPaFaqz5k st+MLPfxATMJ30Z89VyUhYh8S/HeTgU/KlalXjRaUiREhmNDu726rq6DYTBy8bcYIDbr TlrH9HeSH51m8bA9cvVPQ+zpCzR2FBkkD/kcM4GHIs078U4aCEYqxRT+5esHrUhcUsIz YNpYAYro36OUjjOBjN/WnbrxZpq0b19h4AA9jcCKjs33RPyiD/h5KazNMYWs7whmjM8E hb8w== 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=gA1FtWUyQdl4YVK/MUzfA3aSHWRXYmFeDKmIylxF1Qg=; b=fs5hjhrCgmxgHSsSizzpOjyxWYqBMqanaf/RPpgEtYUsceIdCpzJs7qKbno9jioZ0O KJAp39XWTlJ9Lhg1okOUAWtIykO57Z72Zfcv6ev/Z7SalEXOnsdFn3O/5CUY5PnO0Qer pfgkrtLg70WXkXc3tUAsaxZRs30f6Xb3ZK6h4muIHaFJBh2T3d5X04C0kKbUk2MUSDH9 r2hb27dXewphEjyI0B/CpgqFB2SbgEFlcpuMtfvoWA5Sn4b23IBCQ1frWvO0lWg5wCBP 5YEM/X3jK+w7xTlFPy44iZrmrE/c+uTDe/1kgRLjpZfwUaOqsQ2hVlTnFnX/tb5k/l8e Es6Q== X-Gm-Message-State: AOUpUlFt9GskS4UH6VExdcBIjGLiUDTk6ZZQRMXRTXp3mUXjSVRr3FAe t1dZ+xx3nbYt0Ef835vZ4N9/GcaoJC8= X-Google-Smtp-Source: AA+uWPzMbEqU8jVJD4GO4kHEUcE4W8jopXZAZkiHq8GLEES6JcTAfFGJ3jheTwnhUnbashsFJtE6VQ== X-Received: by 2002:a6b:510f:: with SMTP id f15-v6mr15852274iob.107.1534348008791; Wed, 15 Aug 2018 08:46:48 -0700 (PDT) Received: from [10.0.0.15] (45-19-110-76.lightspeed.tukrga.sbcglobal.net. [45.19.110.76]) by smtp.gmail.com with ESMTPSA id h123-v6sm1163049itb.32.2018.08.15.08.46.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Aug 2018 08:46:48 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Suresh Krishnan <suresh.krishnan@gmail.com> In-Reply-To: <CAFU7BAQVqWajKtnsAZ4Ys52BZS7hkoD2E0vmB-Dg=+pYndxCMQ@mail.gmail.com> Date: Wed, 15 Aug 2018 11:46:46 -0400 Cc: The IESG <iesg@ietf.org>, Russ White <russ@riw.us>, v6ops-chairs@ietf.org, V6 Ops List <v6ops@ietf.org>, draft-ietf-v6ops-conditional-ras@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8498D5D0-A130-4BFE-B256-BCCE15A86015@gmail.com> References: <153321790308.2265.731201835682425291.idtracker@ietfa.amsl.com> <CAFU7BAQVqWajKtnsAZ4Ys52BZS7hkoD2E0vmB-Dg=+pYndxCMQ@mail.gmail.com> To: Jen Linkova <furry13@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/wdpJc-j3z2Akih33adLC4izj4l0> Subject: Re: [v6ops] Suresh Krishnan's Yes on draft-ietf-v6ops-conditional-ras-06: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 15 Aug 2018 15:46:55 -0000 Hi Jen, > On Aug 10, 2018, at 8:25 AM, Jen Linkova <furry13@gmail.com> wrote: >=20 > Hi Suresh, >=20 > On Thu, Aug 2, 2018 at 11:51 PM, Suresh Krishnan <suresh@kaloom.com> = wrote: >> * Section 3.1.1. >>=20 >> I think a reference to RFC3704 (specifically written for describing = ingress >> filtering for multihomed networks) might be a good addition here to = RFC2827 >=20 > Done! >=20 >> * Sections 3.2.1., 3.2.2. etc. >>=20 >> =3D> I think it is important to specify (at least the bounds of) the = valid >> lifetimes here as well. e.g. when the preferred lifetime is getting = set to zero >> it is important to specify that the valid lifetime is set to a non = zero value >> so that the host will form an address at all (even though it will not = be used >> when there are preferred addresses). This is important to reduce the = potential >> packet losses when the preferred uplink goes down. >=20 > I've added a paragraph clarifying that we only modify preferred > lifetime and that RFC4862 does not > allow an RA with both preferred and valid lifetime for the prefix set > to 0 to invalidate the address completely: >=20 > https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-07 >=20 >> * Section 3.2.2. >>=20 >> I think there is some text missing here about VRRP priorities here. = There seems >> to be an assumption in the draft that the uplink A failure will lead = to R1 >> becoming backup ("If ISP_A uplink is down, then R1 becomes a = backup.") and this >> is not obvious at all. There needs to be a priority change with = interface >> tracking if this has to happen and the backup has to take over as the = master. >=20 > I've rephrased it to: > "R1 is the VRRP master by default (when ISP_A uplink is up). If ISP_A > uplink is down, then R1 becomes a backup (the VRRP interface status > tracking is expected to be used to automatically modify the VRRP > priorities and trigger the mastership switchover). " >=20 >=20 > Please let me know if the new version does not address your comments! Looks good to me with the minor clarification that Jinmei-san proposed. = Thanks for addressing these comments. Regards Suresh From nobody Wed Aug 15 14:32:55 2018 Return-Path: <iesg-secretary@ietf.org> 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 45A1E1310CB; Wed, 15 Aug 2018 14:32:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG <iesg-secretary@ietf.org> To: "IETF-Announce" <ietf-announce@ietf.org> X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG <iesg@ietf.org>, v6ops@ietf.org, russ@riw.us, v6ops-chairs@ietf.org, draft-ietf-v6ops-conditional-ras@ietf.org, Russ White <russ@riw.us>, warren@kumari.net, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <153436875627.3147.5618355354303091233.idtracker@ietfa.amsl.com> Date: Wed, 15 Aug 2018 14:32:36 -0700 Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/lRzf9iSFMnwLG7wzII8feaDJuiU> Subject: [v6ops] Document Action: 'Using Conditional Router Advertisements for Enterprise Multihoming' to Informational RFC (draft-ietf-v6ops-conditional-ras-07.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 15 Aug 2018 21:32:40 -0000 The IESG has approved the following document: - 'Using Conditional Router Advertisements for Enterprise Multihoming' (draft-ietf-v6ops-conditional-ras-07.txt) as Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Warren Kumari and Ignas Bagdonas. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-conditional-ras/ Technical Summary This document describes using IPv6's RA capabilities to enable simple multihoming for networks connected to two or more upstream Internet Service Providers (ISPs). This document describes tying the advertisement of available address space through the RA to hosts in a network in response to the availability of upstream connectivity, including sample policies. Working Group Summary The v6ops working group discussed this draft extensively, and the authors made several changes to account for working group input. The document did not raise any controversy; the authors addressed all the comments quickly. Document Quality The overall quality of the document is good; the writing style is easily readable, and the explanations are clear. Personnel Russ White is the shepherd. Warren Kumari is RAD! From nobody Thu Aug 16 07:19:21 2018 Return-Path: <internet-drafts@ietf.org> 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 88AD1130E0D; Thu, 16 Aug 2018 07:19:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: <i-d-announce@ietf.org> Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <153442915450.12038.2447808527381840133@ietfa.amsl.com> Date: Thu, 16 Aug 2018 07:19:14 -0700 Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/tIzAQRZqck28D6k3CasH37Rwz40> Subject: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 16 Aug 2018 14:19:15 -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-08.txt Pages : 21 Date : 2018-08-16 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-ipv4aas-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-transition-ipv4aas-08 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 Thu Aug 16 07:23:23 2018 Return-Path: <prvs=176655b8cb=jordi.palet@consulintel.es> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03BF8130E81 for <v6ops@ietfa.amsl.com>; Thu, 16 Aug 2018 07:23:22 -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 IIAyqbdQvFvT for <v6ops@ietfa.amsl.com>; Thu, 16 Aug 2018 07:23:19 -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 2E4CA1277C8 for <v6ops@ietf.org>; Thu, 16 Aug 2018 07:23:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1534429397; x=1535034197; 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=UetK5gS3 Sc8Oy3tHvzyJX1ToUAOsH/q71ec9uNFj+WQ=; b=EhzvxLDuKWxI136+/BV0aT0s 8AM/B4zkYz/DJ9pYmHSekMdAdKGTNTU239ALSX56C4BS04kfDRyk8FsXxt8nubCE SsaJi9u4Um/+T9ICi/Np32OJBMY9zhah31GI2sw1i2wgIEfFhvigPaPZiq2ZrFOc 5iVbOJSUN6JO+kl+6Wg= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Thu, 16 Aug 2018 16:23:17 +0200 X-Spam-Processed: mail.consulintel.es, Thu, 16 Aug 2018 16:23:16 +0200 Received: from [10.20.5.175] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005842167.msg for <v6ops@ietf.org>; Thu, 16 Aug 2018 16:23:16 +0200 X-MDRemoteIP: 10.8.10.6 X-MDHelo: [10.20.5.175] X-MDArrival-Date: Thu, 16 Aug 2018 16:23:16 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=176655b8cb=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.0.180812 Date: Thu, 16 Aug 2018 09:23:07 -0500 From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> To: <v6ops@ietf.org>, Ron Bonica <rbonica@juniper.net> Message-ID: <6FE02493-D59B-4851-ADF0-3D300438778B@consulintel.es> Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-08.txt References: <153442915450.12038.2447808527381840133@ietfa.amsl.com> In-Reply-To: <153442915450.12038.2447808527381840133@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/agUj1PZm_T-zs7abWyYxl8_3u8w> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 16 Aug 2018 14:23:22 -0000 Hi Ron, all, As indicated a couple of days ago when updated the UPnP section, and after = nobody else provided new inputs, we have submitted a new version, which we = believe is ready for the last-call. Thanks! Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops <v6ops-bounces@ietf.org> en nombre de <internet-drafts@ietf.org> Responder a: <v6ops@ietf.org> Fecha: jueves, 16 de agosto de 2018, 9:20 Para: <i-d-announce@ietf.org> CC: <v6ops@ietf.org> Asunto: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-08.txt =20 A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. This draft is a work item of the IPv6 Operations WG of the IETF. =20 Title : Requirements for IPv6 Customer Edge Routers t= o Support IPv4 Connectivity as-a-Service Authors : Jordi Palet Martinez Hans M.-H. Liu Masanobu Kawashima Filename : draft-ietf-v6ops-transition-ipv4aas-08.txt Pages : 21 Date : 2018-08-16 =20 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. =20 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. =20 =20 The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/ =20 There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-transition-ipv4aas-08 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-ipv4a= as-08 =20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-v6ops-transition-ipv4aas= -08 =20 =20 Please note that it may take a couple of minutes from the time of submi= ssion until the htmlized version and diff are available at tools.ietf.org. =20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =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 Aug 16 14:22:37 2018 Return-Path: <fredbaker.ietf@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C0A12F295 for <v6ops@ietfa.amsl.com>; Thu, 16 Aug 2018 14:22:35 -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 0w6oS5j2xcUp for <v6ops@ietfa.amsl.com>; Thu, 16 Aug 2018 14:22:33 -0700 (PDT) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 BD254130F32 for <v6ops@ietf.org>; Thu, 16 Aug 2018 14:22:32 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id x5-v6so3451087edr.0 for <v6ops@ietf.org>; Thu, 16 Aug 2018 14:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=DDQ1xXJZJT4VI84F7kyWTYBR8xoSGYDBVeibSGxJTWA=; b=T87bdBq1GaR5mKoKqjf9L1+AV1D/2+za6U7OYruH1OoKlPFTOBqksbTlQDJZ9mWvJj H27ZKlX0o7bmTXLlLPNm1EPc3vCbMCvhg30W8hRkwa8Z2gLbi8WDO2fGvwq0Lg3pUzZB vbsRlZ13ncnxQ3FRNZPq+fL2oNg1z2ADj9tH1/ysk7KUL+iAHqex+lcjRPVa1tDrwxi9 edswL8cMeDr0EqOfucbV0B2/x79qCSB7r1tEn/3eUFuSattR7B4dNfU5pS++XOuQs3WI 16VNFBqrOP6LjIsyd0TKKUh4DSgcD6PLrqKLylmNZc6cCIgCDPeS3v6Lm4I3mMca6u+3 IYvg== 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:subject:date:references:to :in-reply-to:message-id; bh=DDQ1xXJZJT4VI84F7kyWTYBR8xoSGYDBVeibSGxJTWA=; b=cQ40j5nv57/uVGrkdKdJ9OeVjCxL2RGkvjoTp9WOBD4HpXxlO5K/tDNkFnsjkKORWL SgTrrDYV+WkGe8pJJGIBnwZT9BV0UWoy5nDRYX81lH3mLtMHhYobLougLBa6g0Qs+qPG n3rMq1v+hyaVCNwCqo70ZuLiwI3EdkP0IkoFXDQg1R/ziQX4upQuzSrki6hB7FEN+WOl n0DtnbRTWG8aL1JGldNpv/GC65Zukex4j94urPv0L+s4ZodPIsyZ02dOt8hyXNFQcbJx E30aCibe+6Kh2dF3jZOhed9MOkmWG79wJ8I7jV8K3BJ5Zx7tnK1CbxZztSk5DegMgU4U oFBA== X-Gm-Message-State: AOUpUlGYJEwbCZZUGymaIpuMpLiM/jEn4rzhHRTVaWvUZSITFWqaDWzQ qzDWLAFFsrlmHd6LtEs6rl7i2QR/ X-Google-Smtp-Source: AA+uWPwnB0SJtEPVGIIfxdwRY1Gy1WwGAjr4PfvRIhI1qjI8PSpYhKxxgx0pDL05i8Ek6dj/2F5cTQ== X-Received: by 2002:a50:b7a4:: with SMTP id h33-v6mr39086253ede.96.1534454551018; Thu, 16 Aug 2018 14:22:31 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::1049? ([2600:8802:5600:1546::1049]) by smtp.gmail.com with ESMTPSA id s27-v6sm1449839edb.73.2018.08.16.14.22.29 for <v6ops@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Aug 2018 14:22:30 -0700 (PDT) From: Fred Baker <fredbaker.ietf@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_962B7867-FC9E-408E-9D2F-279D0634633B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 16 Aug 2018 14:22:26 -0700 References: <153443912996.12204.13310672598806696421.idtracker@ietfa.amsl.com> To: "v6ops@ietf.org list" <v6ops@ietf.org> In-Reply-To: <153443912996.12204.13310672598806696421.idtracker@ietfa.amsl.com> Message-Id: <C072C9A4-693B-4AFE-BE64-93E6A6092D84@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/rBBPHlQxo0PSsWn3CKTRxanxcEQ> Subject: [v6ops] FW: [Rift] NomCom 2018: Call for nominations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 16 Aug 2018 21:22:35 -0000 --Apple-Mail=_962B7867-FC9E-408E-9D2F-279D0634633B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FYI Cheers, Fred =EF=BB=BFOn 8/16/18, 10:07, "ietf on behalf of NomCom Chair 2018" = <ietf-bounces@ietf.org on behalf of nomcom-chair-2018@ietf.org> wrote: The 2018-19 Nominating Committee (NomCom) is seeking nominations from = now until September 30, 2018. The open positions being considered by this = year's NomCom can be found at the end of this email and also on this year's = NomCom website: https://datatracker.ietf.org/nomcom/2018/ Nominations may be made by selecting the Nominate link at the top of = the NomCom 2018 home page, or by visiting the following URL: https://datatracker.ietf.org/nomcom/2018/nominate/ Note: Nominations made using the web tool require an ietf.org = datatracker account. You can create a datatracker ietf.org account if you don't = have one already by visiting the following URL: https://datatracker.ietf.org/accounts/create/ If you are unable to use the web form, nominations may instead be = made by email to nomcom-18 at ietf dot org. If using email, please include = the word "Nominate" in the Subject and indicate in the email who is being = nominated, their email address (to confirm acceptance of the nomination), and = the position for which you are making the nomination. If you are = nominating someone other than yourself, please tell us if we may tell the = nominee that you were the one who made the nomination. If you wish to nominate = someone via email for more than one position, please use separate emails to do = so. Self-nomination is welcome! Willing nominees will be asked to fill out a questionnaire specific = to the position for which they are nominated. The questionnaires will be = available on August 31, 2018 and have a submission deadline of October 5, 2018. NomCom 2018-19 will follow the policy for "Open Disclosure of Willing Nominees" described in BCP 10/RFC 7437. As stated in RFC 7437: "The = list of nominees willing to be considered for positions under review in the = current NomCom cycle is not confidential". Willing nominees for each position = will be listed in a publicly accessible way, e.g., anyone with a datatracker = account may access the lists. Additionally, the nomination form asks if we = may share your own name with the nominee. In all other ways, the = confidentiality requirements of BCP 10 remain in effect. All feedback and all NomCom deliberations will remain confidential and will not be disclosed. There is a field on the form you can mark in order to allow the = NomCom to tell the nominee that you were the one who made the nomination. This = defaults to =E2=80=9Cno=E2=80=9D - so if you don't mark the field we won=E2=80=99= t tell. In order to ensure time to collect sufficient community feedback = about each of the willing nominees, nominations must be received by the NomCom = on or before September 30, 2018. Please submit your nominations as early as possible for the sake of = your nominees. Note that nominations should not wait for management = permission, as it is easier to decline the nomination than put one in late. The NomCom appoints individuals to fill the IETF Chair (IESG General = AD) and the open slots on the IAB and the IESG. The IAOC position is not = being filled this year, and the call for nominations related to the IETF LLC will = be coming in the next few weeks. The list of people and posts whose = terms end with the March 2019 IETF meeting, and thus the positions for which = this NomCom is responsible, follows: IAB - Jari Arkko - Gabriel Montenegro - Mark Nottingham - Robert Sparks - Jeff Tantsura - Suzanne Woolf IESG Chair - Alissa Cooper, GEN (IETF Chair) IESG - Ben Campbell, ART - Terry Manderson, INT * - Warren Kumari, OPS - Deborah Brungard, RTG - Alvaro Retana, RTG - Eric Rescorla, SEC - Spencer Dawkins, TSV * *- have indicated that they do not intend to accept a renomination. = This information is always up to date on = https://datatracker.ietf.org/nomcom/2018/ Please be resourceful in identifying possible candidates for these = positions, as developing our talent is a very crucial requirement for the IETF, = and also, please consider accepting a nomination. You'll find extensive information about specific positions, developed by the IAB and IESG = under individual tabs at: https://datatracker.ietf.org/nomcom/2018/requirements/ In addition to nominations, the NomCom seeks community input on the = positions themselves. We need and welcome the community's views and input on = the jobs within each organization. If you have ideas on the positions' responsibilities (more, less, different), please let us know. Please send suggestions and feedback about this to nomcom-18 at ietf = dot org. Thank you for your help in identifying qualified nominees! regards, -scott. Scott Mansfield scott dot mansfield at ericsson dot com nomcom-chair-2018 at ietf dot org --Apple-Mail=_962B7867-FC9E-408E-9D2F-279D0634633B 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+AFAlt16xIACgkQEhdRnd2G P+DF+hAAjFzmIR5hQ+4wW5z9rb2dcuzadRk/f9ywvRKULz2XgpxffI/D8aqmLFx+ tvAS3st+zWc0H5Ug1Is99inVOGiElB5/8CVvXyJBPWPoCZc5L4SejljfWnv1Ffm5 17n6n+Wf4Vc0+6Bwr8w6M4PCX3pAQXsSLizlYBtasaAdKdp6lfSV+hWVRa3jagTI J884Wn9nIQZyz56/X+TyBRA46OJRecyE9Qh6jl1k87dT64iv7c2dJBlyeHIdpRr4 vbBN1F+ED0g2SEQuVFtdhX/C9VYmMVxjNmrkeFQ929os+Bl3ytAdQsSOD2w+FPDP Qk+ESJ+sct1pJerncPHGznHM3/KDdGYYyGZ20Fd5kaUWaIAdtZoAz0IVANMtem9s 4h+5/wOW8m0Y8zwB7cfnXtrfQAvEJeH5cHZMCUTwVwoOLiE06Bht3qKIsLpaJ4Qq Ulbq2IV+jgoZPwX8JE0IBeQP0bF+1iu2sdnn2OO/CMYaOg9WZFNCZCxT2JgtZXgK x0gH33VXTewPi8vghvj3rXwvvjAyf0XXRSXGHDAt0XsUy+eplSTUlVW+PRXCfmsI ymPuiEE1iRjtaUVvcIGL3TcszFHJtN1B9WZ0wAKr6sMWFm8vSyOVK47OW2ZvwVeJ jO629/dinJZMvus7cMwQ081AUsAqhLgwQd8OB+EoTdyuskC5+Fc= =aWS9 -----END PGP SIGNATURE----- --Apple-Mail=_962B7867-FC9E-408E-9D2F-279D0634633B-- From nobody Fri Aug 17 11:06:28 2018 Return-Path: <fredbaker.ietf@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE6D130FE6 for <v6ops@ietfa.amsl.com>; Fri, 17 Aug 2018 11:06:19 -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 iSEHk-0iX489 for <v6ops@ietfa.amsl.com>; Fri, 17 Aug 2018 11:06:16 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 3C6D1130E14 for <v6ops@ietf.org>; Fri, 17 Aug 2018 11:06:15 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id 13-v6so15463220ois.1 for <v6ops@ietf.org>; Fri, 17 Aug 2018 11:06:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=mx11/iDo1zHpk7bs2/4bdg1LERzL2HTevaZ5ildLoxc=; b=S4++8l42sV/yWw4So4RbVAAvhvsXVl7m8MlpHArUPHNoXkXFh2g3A1i4oUWu2h0WP+ 3fOxPKaD6dv6V7xoiuKZdxYfH/W2uwDNVeZVE+Aw2W90JIS26Z/1Xy99VFo06kIpsass wduLCi6P3f7nbIbVCICZpu17LbGjR8PKAk/QIQJt614GKwxms9s2XfJY5Cideka35Nii 6Yj0icI5Q9RN/JraffK+xDMLHNkjZ1K1w5Y7uxWCX+xGI/WuJT/IW/f37aRImAnb6Q13 x4BP1q1JWyGBgmgtgRNUCA4tqkO1HECQiYEVIITaLvQvSxaBfiNdR+WyMGeo0nWPCqOu Hvxg== 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:subject:message-id:date:to; bh=mx11/iDo1zHpk7bs2/4bdg1LERzL2HTevaZ5ildLoxc=; b=X3p7WY4oKnvHCkR2totxklUf546PX0oDy1jLae2cp0g4QJem19Cp5BZuqF0jsWAUYF k3pP1XfIjlagIP933g9zBc3GgjOsQmb6OSz1DLW1OAJ1RwMp2bTLmmVfkTAvE2fYaNnC SrYr0epx0jKVMNCRAPLyP8BLF6rvz3GVdRMy5MHvkzfCouT/d9noSXJjdd7XN+6Xficx eCgg/CGhsMxJGMZ5p2f83sGUWI5kVPyhBnGaOS6WxMc0zCn8QW/yTgjldZ+JwAZ9H3EB CNda/1PyOracxEiWsaxpVA8lOaobA2S+ujbcBaNOTvCufcV6ZAzuS7WX8U06EsNwlhfM Mq2w== X-Gm-Message-State: AOUpUlEAtcuJ3bvw+Pu6GwzIwUbYvZZ4WYYvGeiZzZwVdPRghupTA0AP F5FbbCgplvdTa73U5tiRe2PjA6ge X-Google-Smtp-Source: AA+uWPw4JgeM2qohUybG5Nc0oldW48aKCsbKrtnu4G1Ci2HuSMW7BfeMmV3S4PIZp+BUJoCWhrpx0g== X-Received: by 2002:aca:4083:: with SMTP id n125-v6mr3334138oia.167.1534529174423; Fri, 17 Aug 2018 11:06:14 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::104a? ([2600:8802:5600:1546::104a]) by smtp.gmail.com with ESMTPSA id q124-v6sm2659552oif.8.2018.08.17.11.06.13 for <v6ops@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Aug 2018 11:06:13 -0700 (PDT) From: Fred Baker <fredbaker.ietf@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_39FC8486-7414-47D3-B102-359A35AD9816"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> Date: Fri, 17 Aug 2018 11:06:11 -0700 To: "v6ops@ietf.org list" <v6ops@ietf.org> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/tVgJs8-qxclW6D2zao3m0zyf118> Subject: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 17 Aug 2018 18:06:26 -0000 --Apple-Mail=_39FC8486-7414-47D3-B102-359A35AD9816 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ron and I just had our bi-weekly phone call, and identified a topic that = might be interesting and useful. We'd like to invite a draft from people = that are deploying IPv6-only networks or parts of networks identifying = the problems they are experiencing that the IETF might be in a position = to address. The objective, as always, is to solve problems preventing = such a deployment in time for vendors and open source to provide = solutions. = --------------------------------------------------------------------------= ------ Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win. Sun Tzu --Apple-Mail=_39FC8486-7414-47D3-B102-359A35AD9816 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+AFAlt3DpMACgkQEhdRnd2G P+BUkhAAjWob3DcII0SnyToA7yPrG3CFHHu5B+OT0PRzKMK9yYXyrg4QY2gC5JiK jnwd1edxThsID2xAVjcAAQ/CbFRKsW0ZhQqGM2PrSOcl76l14nhDY2NAg1Z/U5BD jV2oLmGPE4Ex+f2QoXCyZqhCvN474vJRM7OjpKpK8qyoi25jX4oyf7FZbuEcytvS amyTIA8x2NFmf/Ax5ncw7Dx+N9ZGd8BKnsvJgJzwsQvVApeZY8Lh3WAppbpagkZB Y0w8Ie6gepCIlkH8c1Lo1nQhGvDpt/dpj/Jcd5Dus55KzVhzht3ibtC4Vaimqfr7 nGcZybB59J/2QSSFNqPEnX6kuLER9knIYdzxu1a4e4BOTKpYqVxucNWv5W9O9y2K cTWI9PIMB6mtyMNxc1EA8k8H8Xe4QxqI5Y3lvs4Vt+oZ4RvXFpi85gdqaf8EZBtF frq4JXwzaTOX2jgl/4T3UmAqvskKBfV/PbYvd0Q0/gt7Y8zVNnueZMxCtrZgm4sG Q+tUdR7kwu0AKuZJH3VX05o7eArly5Vm067pvoQBEb6y4oVQOHhtFdvlIhxuqXhG u5BkjvhymvGaPnEndp0I982/ZEIzYF5lC51ioLNpva/u6ldGwKDOezaNesTlTpaP oYdqmmiEmCfmCDxnSVdmi0/FRKWDYzA/EwQJ12Q0Zls1tQuh5KI= =wRBh -----END PGP SIGNATURE----- --Apple-Mail=_39FC8486-7414-47D3-B102-359A35AD9816-- From nobody Fri Aug 17 11:23:22 2018 Return-Path: <lee@asgard.org> 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 514F1130E4C for <v6ops@ietfa.amsl.com>; Fri, 17 Aug 2018 11:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 7p1rwMSPgkMS for <v6ops@ietfa.amsl.com>; Fri, 17 Aug 2018 11:23:11 -0700 (PDT) Received: from atl4mhob09.registeredsite.com (atl4mhob09.registeredsite.com [209.17.115.47]) (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 D9588130FFF for <v6ops@ietf.org>; Fri, 17 Aug 2018 11:23:10 -0700 (PDT) Received: from mailpod.hostingplatform.com (atl4qobmail01pod6.registeredsite.com [10.30.71.209]) by atl4mhob09.registeredsite.com (8.14.4/8.14.4) with ESMTP id w7HIN8l4029212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <v6ops@ietf.org>; Fri, 17 Aug 2018 14:23:08 -0400 Received: (qmail 13741 invoked by uid 0); 17 Aug 2018 18:23:08 -0000 X-TCPREMOTEIP: 174.64.33.182 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.2.104?) (lee@asgard.org@174.64.33.182) by 0 with ESMTPA; 17 Aug 2018 18:23:08 -0000 To: v6ops@ietf.org References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> From: Lee Howard <lee@asgard.org> Message-ID: <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> Date: Fri, 17 Aug 2018 14:23:02 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> Content-Type: multipart/alternative; boundary="------------91DBB650422F452217441553" Content-Language: en-US Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/7IkLq6ZXERbyoZUlByKZ_uLmJLE> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 17 Aug 2018 18:23:20 -0000 This is a multi-part message in MIME format. --------------91DBB650422F452217441553 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Problems I've encountered (off the top of my head): * Documentation assumes/uses IPv4 * Listeners only configured for IPv4 * Software repos that are IPv4-only * CA/CRL/OCSP that are IPv4-only * VPN software that is unaware of IPv6, so client is split tunnel when on a dual-stack network * No IPv6 support in openssl (is there a better troubleshooting tool I should use?) * Mail is still a mess * Bugs in home gateways * Chicken-and-egg provisioning/OSS need to run IPv6, but routers and firewalls have to run IPv6 to get to them. I've made it through most router configuration (I always have to tell engineers that router-id is an integer not an IPv4 address; it sure looks like an address; oh, and it has to be manually configured in an IPv6-only network). That's all very operational; is that the sort of stuff you're thinking? If so, I'll go ahead and start a draft and see who else wants to contribute. Most of it is temporary (I hope) or related to other people not deploying, so I 'm not sure whether this is what you have in mind. Lee On 08/17/2018 02:06 PM, Fred Baker wrote: > Ron and I just had our bi-weekly phone call, and identified a topic that might be interesting and useful. We'd like to invite a draft from people that are deploying IPv6-only networks or parts of networks identifying the problems they are experiencing that the IETF might be in a position to address. The objective, as always, is to solve problems preventing such a deployment in time for vendors and open source to provide solutions. > -------------------------------------------------------------------------------- > Victorious warriors win first and then go to war, > Defeated warriors go to war first and then seek to win. > Sun Tzu > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --------------91DBB650422F452217441553 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=windows-1252"> </head> <body text="#000000" bgcolor="#FFFFFF"> Problems I've encountered (off the top of my head):<br> <ul> <li>Documentation assumes/uses IPv4</li> <li>Listeners only configured for IPv4</li> <li>Software repos that are IPv4-only</li> <li>CA/CRL/OCSP that are IPv4-only</li> <li>VPN software that is unaware of IPv6, so client is split tunnel when on a dual-stack network</li> <li>No IPv6 support in openssl (is there a better troubleshooting tool I should use?)</li> <li>Mail is still a mess</li> <li>Bugs in home gateways</li> <li>Chicken-and-egg provisioning/OSS need to run IPv6, but routers and firewalls have to run IPv6 to get to them.<br> </li> </ul> <p>I've made it through most router configuration (I always have to tell engineers that router-id is an integer not an IPv4 address; it sure looks like an address; oh, and it has to be manually configured in an IPv6-only network).</p> <p>That's all very operational; is that the sort of stuff you're thinking? If so, I'll go ahead and start a draft and see who else wants to contribute. Most of it is temporary (I hope) or related to other people not deploying, so I 'm not sure whether this is what you have in mind. <br> </p> Lee<br> <br> <br> <div class="moz-cite-prefix">On 08/17/2018 02:06 PM, Fred Baker wrote:<br> </div> <blockquote type="cite" cite="mid:9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com"> <pre wrap="">Ron and I just had our bi-weekly phone call, and identified a topic that might be interesting and useful. We'd like to invite a draft from people that are deploying IPv6-only networks or parts of networks identifying the problems they are experiencing that the IETF might be in a position to address. The objective, as always, is to solve problems preventing such a deployment in time for vendors and open source to provide solutions. -------------------------------------------------------------------------------- Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win. Sun Tzu </pre> <br> <fieldset class="mimeAttachmentHeader"></fieldset> <br> <pre wrap="">_______________________________________________ v6ops mailing list <a class="moz-txt-link-abbreviated" href="mailto:v6ops@ietf.org">v6ops@ietf.org</a> <a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/v6ops">https://www.ietf.org/mailman/listinfo/v6ops</a> </pre> </blockquote> <br> </body> </html> --------------91DBB650422F452217441553-- From nobody Fri Aug 17 11:57:06 2018 Return-Path: <jinmei.tatuya@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6962A130E6A for <v6ops@ietfa.amsl.com>; Fri, 17 Aug 2018 11:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.918 X-Spam-Level: X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, 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 hnJdDrJH9QJu for <v6ops@ietfa.amsl.com>; Fri, 17 Aug 2018 11:57:02 -0700 (PDT) Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) (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 3E6C7130DC3 for <v6ops@ietf.org>; Fri, 17 Aug 2018 11:57:02 -0700 (PDT) Received: by mail-lj1-f182.google.com with SMTP id w16-v6so7122281ljh.12 for <v6ops@ietf.org>; Fri, 17 Aug 2018 11:57:02 -0700 (PDT) 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=0zxIqnbC3TBWjWHLMCZImFuf+xUaxUUpHJ32NeeHhtc=; b=TIcZAxMF0+YrAQYDcxWSZiBPDn2Fpu5mxgZzkDa4dD7uvxsGDnOao3cXAXMKAekkBx bTPrWBfXHk7Pj443USRUlADQ5apHMZDQegkYqs176TI25LCR6QWjKm2xBfQnGoWhHN8n 3Y2SdQFtg7e6E/DWgr/IyCh4DKWo1z6zfSyOWDr3RNdDDiN4CRhTUxgcOEUBIATG/8qS zgrxj0DCihlw53koSH3Xl8XKgnyU2ryNX8k70PudOj7FVitxJ8HQRnJt9vtM4ixKpghn zqjL0Frc5AnRMplGxPpDpcF9Br8fWSx+evQrxHSkv6g7CQRZbqtypmhmLJBiGaxeWQW2 q9cg== X-Gm-Message-State: AOUpUlE3A7A/S3tPH2fTiJu7yDIJSVf1eEiNHrYW1VQLlMhWrbizZClC hIDYZ5eXxCYhFEJMXKuoNYn1zy3JmLRoJsiXu0W9PwXG X-Google-Smtp-Source: AA+uWPyXW88dtGbHKcmxRUZZIfQJvuquwtviNSEMNVNwaW3u7PQepGr2n3eEggk8uVM1nsJFo3Aw0HTZrtQ8K8bb0Rw= X-Received: by 2002:a2e:7113:: with SMTP id m19-v6mr24332003ljc.66.1534532220291; Fri, 17 Aug 2018 11:57:00 -0700 (PDT) MIME-Version: 1.0 References: <CO1PR05MB4436E9F2079B50141B88143AE2B0@CO1PR05MB443.namprd05.prod.outlook.com> In-Reply-To: <CO1PR05MB4436E9F2079B50141B88143AE2B0@CO1PR05MB443.namprd05.prod.outlook.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp> Date: Fri, 17 Aug 2018 11:56:48 -0700 Message-ID: <CAJE_bqcGAF2K9m7F4BHhZLvbhNcodak7Pzycjb9B+qwM9eS2jw@mail.gmail.com> To: Ronald Bonica <rbonica@juniper.net> Cc: v6ops@ietf.org Content-Type: multipart/alternative; boundary="000000000000e31e250573a61f92" Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/wQqCZkM04zz56ow8DrLdYOL_ztA> Subject: Re: [v6ops] Call for Adoption: draft-templin-v6ops-pdhost X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 17 Aug 2018 18:57:04 -0000 --000000000000e31e250573a61f92 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 26, 2018 at 10:25 AM Ron Bonica <rbonica@juniper.net> wrote: > This draft initiates a two week call for adoption on > draft-templin-v6ops-pdhost. Please respond by August 9, 2018. Belated, but as chairs seem to seek more input, I've read draft-templin-v6ops-pdhost-21. I don't have a strong opinion on whether to adopt it at v6ops. But I have some general observations: - On one hand, applying prefix delegation to a "host" type of node seems to be a straightforward extension to the original usage described in Section 5 of RFC3633. In that sense the need for having a separate document is not so clear to me (but I'm not saying this as an objection to the adoption - as I noted above I don't have a strong opinion on that decision). - On the other hand, this document seems to introduce new protocol behaviors without saying it's updating the corresponding existing standard (see specific cases below). These could be considered non-trivial protocol updates and it may make this document worth publication. But in that case I'd wonder whether this should rather belong to 6man and rather aim to be a standards track document. - It assumes nearly silently that a requesting node can skip DAD in the upstream link if the prefix is "delegated": In contrast, a node that configures addresses from a delegated prefix can assign them without invoking MLD/DAD on an upstream interface, since the prefix has been delegated to the node for its own exclusive use and is not shared with any other nodes. Although this logic may be justifiable, I believe this should actually be specified as an update to RFC4862. In my interpretation RFC4862 requires nodes to perform DAD quite strongly even when it's operationally reasonable to assume duplicates are less likely to happen. If we want to override it, IMO we should specify it as a standard protocol behavior, e.g., as defined in Section 5.1 of RFC4862: Default: 1, but may be overridden by a link-type specific value in the document that covers issues related to the transmission of IP over a particular link type (e.g., [RFC2464]). - In Section 8, it talks about somewhat awkward behavior of the requesting node: + it sends NS to the upstream link (not prohibited by RFC4861 but a bit awkward for a "router) + it sets the router flag to true in NA (btw I don't see why it needs to do it) + it receives a redirect and updates its neighbor cache. This may be in a gray zone, but I'd consider it a possible violation of the following part of RFC4861: A router MUST NOT update its routing tables upon receipt of a Redirect. - This document describes the model where addresses are assigned to the upstream interface (Figure 3). I would suggest clarifying how it's not considered a violation of the following part of RFC3633: [...] the requesting router MUST NOT assign any delegated prefixes or subnets from the delegated prefix(es) to the link through which it received the DHCP message from the delegating router. - Now that this document talks about various ways of delegating a prefix, I guess the term "prefix delegation" might be confusing, since it would be easy to assume RFC3633 is used. Maybe we should use a different term, e.g., "prefix assignment". - In Section 12, the definition of "trusted/untrusted networks" and how a node determines it are not clear to me: In all cases, the node must decide whether or not to send DUs according to the specific operational scenario. In trusted networks, the node should send DU messages to provide useful information to potential correspondents. In untrusted networks, the node can refrain from sending DU messages to avoid providing sensitive information to potential attackers. -- JINMEI, Tatuya --000000000000e31e250573a61f92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">On Thu, Jul 26, 2018 at 10:25 AM Ron Bonica <<a href=3D= "mailto:rbonica@juniper.net">rbonica@juniper.net</a>> wrote:<br><br>>= =C2=A0=C2=A0=C2=A0 This draft initiates a two week call for adoption on<br>= >=C2=A0=C2=A0=C2=A0 draft-templin-v6ops-pdhost. Please respond by August= 9, 2018.<br><br>Belated, but as chairs seem to seek more input, I've r= ead<br>draft-templin-v6ops-pdhost-21.<br><br>I don't have a strong opin= ion on whether to adopt it at v6ops.=C2=A0 But I<br>have some general obser= vations:<br><br>- On one hand, applying prefix delegation to a "host&q= uot; type of node<br>=C2=A0 seems to be a straightforward extension to the = original usage<br>=C2=A0 described in Section 5 of RFC3633.=C2=A0 In that s= ense the need for<br>=C2=A0 having a separate document is not so clear to m= e (but I'm not saying<br>=C2=A0 this as an objection to the adoption - = as I noted above I don't have<br>=C2=A0 a strong opinion on that decisi= on).<br><br>- On the other hand, this document seems to introduce new proto= col<br>=C2=A0 behaviors without saying it's updating the corresponding = existing<br>=C2=A0 standard (see specific cases below).=C2=A0 These could b= e considered<br>=C2=A0 non-trivial protocol updates and it may make this do= cument worth<br>=C2=A0 publication.=C2=A0 But in that case I'd wonder w= hether this should rather<br>=C2=A0 belong to 6man and rather aim to be a s= tandards track document.<br><br>- It assumes nearly silently that a request= ing node can skip DAD in<br>=C2=A0 the upstream link if the prefix is "= ;delegated":<br><br>=C2=A0=C2=A0 In contrast, a node that configures a= ddresses from a delegated prefix<br>=C2=A0=C2=A0 can assign them without in= voking MLD/DAD on an upstream interface,<br>=C2=A0=C2=A0 since the prefix h= as been delegated to the node for its own exclusive<br>=C2=A0=C2=A0 use and= is not shared with any other nodes.<br><br>=C2=A0 Although this logic may = be justifiable, I believe this should<br>=C2=A0 actually be specified as an= update to RFC4862.=C2=A0 In my interpretation<br>=C2=A0 RFC4862 requires n= odes to perform DAD quite strongly even when it's<br>=C2=A0 operational= ly reasonable to assume duplicates are less likely to<br>=C2=A0 happen.=C2= =A0 If we want to override it, IMO we should specify it as a<br>=C2=A0 stan= dard protocol behavior, e.g., as defined in Section 5.1 of<br>=C2=A0 RFC486= 2:<br><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Default: 1, but may be overridden = by a link-type specific value in<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the docu= ment that covers issues related to the transmission of IP<br>=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 over a particular link type (e.g., [RFC2464]).<br><br>- = In Section 8, it talks about somewhat awkward behavior of the<br>=C2=A0 req= uesting node:<br>=C2=A0 + it sends NS to the upstream link (not prohibited = by RFC4861 but<br>=C2=A0=C2=A0=C2=A0 a bit awkward for a "router)<br>= =C2=A0 + it sets the router flag to true in NA (btw I don't see why it<= br>=C2=A0=C2=A0=C2=A0 needs to do it)<br>=C2=A0 + it receives a redirect an= d updates its neighbor cache.=C2=A0 This may<br>=C2=A0=C2=A0=C2=A0 be in a = gray zone, but I'd consider it a possible violation of the<br>=C2=A0=C2= =A0=C2=A0 following part of RFC4861:<br><br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = A router MUST NOT update its routing tables upon receipt of a<br>=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 Redirect.<br><br>- This document describes the model = where addresses are assigned to<br>=C2=A0 the upstream interface (Figure 3)= .=C2=A0 I would suggest clarifying how<br>=C2=A0 it's not considered a = violation of the following part of RFC3633:<br><br>=C2=A0=C2=A0 [...] the r= equesting router MUST<br>=C2=A0=C2=A0 NOT assign any delegated prefixes or = subnets from the delegated<br>=C2=A0=C2=A0 prefix(es) to the link through w= hich it received the DHCP message<br>=C2=A0=C2=A0 from the delegating route= r.<br><br>- Now that this document talks about various ways of delegating a= <br>=C2=A0 prefix, I guess the term "prefix delegation" might be = confusing,<br>=C2=A0 since it would be easy to assume RFC3633 is used.=C2= =A0 Maybe we should<br>=C2=A0 use a different term, e.g., "prefix assi= gnment".<br><br>- In Section 12, the definition of "trusted/untru= sted networks" and<br>=C2=A0 how a node determines it are not clear to= me:<br><br>=C2=A0=C2=A0 In all cases, the node must decide whether or not = to send DUs<br>=C2=A0=C2=A0 according to the specific operational scenario.= =C2=A0 In trusted networks,<br>=C2=A0=C2=A0 the node should send DU message= s to provide useful information to<br>=C2=A0=C2=A0 potential correspondents= .=C2=A0 In untrusted networks, the node can<br>=C2=A0=C2=A0 refrain from se= nding DU messages to avoid providing sensitive<br>=C2=A0=C2=A0 information = to potential attackers.<br><br>--<br>JINMEI, Tatuya<br></div> --000000000000e31e250573a61f92-- From nobody Fri Aug 17 13:02:11 2018 Return-Path: <bzeeb-lists@lists.zabbadoz.net> 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 1DAB6130FA2 for <v6ops@ietfa.amsl.com>; Fri, 17 Aug 2018 13:02:09 -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] 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 k-XUCwoUTfue for <v6ops@ietfa.amsl.com>; Fri, 17 Aug 2018 13:02:07 -0700 (PDT) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7193130E06 for <v6ops@ietf.org>; Fri, 17 Aug 2018 13:02:06 -0700 (PDT) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 7D27725D37D1 for <v6ops@ietf.org>; Fri, 17 Aug 2018 20:02:04 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 81022D1F84D for <v6ops@ietf.org>; Fri, 17 Aug 2018 20:02:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id fqUh6XJZ7Syt for <v6ops@ietf.org>; Fri, 17 Aug 2018 20:02:02 +0000 (UTC) Received: from [192.168.124.1] (fresh-ayiya.sbone.de [IPv6:fde9:577b:c1a9:f001::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 2F68BD1F835 for <v6ops@ietf.org>; Fri, 17 Aug 2018 20:02:01 +0000 (UTC) From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: list <v6ops@ietf.org> Date: Fri, 17 Aug 2018 20:02:01 +0000 X-Mailer: MailMate (2.0BETAr6116) Message-ID: <F4EA189B-20F1-4B9F-B9F8-E5FB74A70A0D@lists.zabbadoz.net> In-Reply-To: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/BG0wbXuWlKoWy9nvLMdjpIPi6Xk> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 17 Aug 2018 20:02:09 -0000 On 17 Aug 2018, at 18:06, Fred Baker wrote: > Ron and I just had our bi-weekly phone call, and identified a topic > that might be interesting and useful. We'd like to invite a draft from > people that are deploying IPv6-only networks or parts of networks > identifying the problems they are experiencing that the IETF might be > in a position to address. The objective, as always, is to solve > problems preventing such a deployment in time for vendors and open > source to provide solutions. (a) I think the IETF is the wrong place; I gave a talk in 2011 at a BSD conference after I went v6-only, I saw talks at UKNOF (or UK IPv6 c. meeting), .. I am sure the “NOG”s are doing similar. (b) for the last 8 years it’s been working fantastic including a multi-site v6-only VPN; bash your vendors, open bug reports, if not. (c) the two major problem is “fear of breaking things” or “being ignorant to IPv6” rather than just doing and dealing with it. /bz From nobody Fri Aug 17 13:57:41 2018 Return-Path: <brian.e.carpenter@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E4B130F3F for <v6ops@ietfa.amsl.com>; Fri, 17 Aug 2018 13:57:40 -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 aCRxA6BojGDs for <v6ops@ietfa.amsl.com>; Fri, 17 Aug 2018 13:57:38 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 BC48B130F34 for <v6ops@ietf.org>; Fri, 17 Aug 2018 13:57:38 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id v66-v6so2750112pgb.10 for <v6ops@ietf.org>; Fri, 17 Aug 2018 13:57:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:cc:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=B2P9hR8KM+hM2/TAFfF1cLurukfqr/xwrWCF1EMi1Sk=; b=SdyMP6IfNdteknDXAW/qEbfKA7MMTR4JPeZAx0iYYFByud5O9yFJnntild7YFb1nPT dNrYPTp5j+a2q9X/gIGT43Nylo+mRsrHpxTRghecHUwtEJYr0A9QbJ2z9J1deZ1k3qQS piJoox5S1R+tenxwCK6mrR3txRDi7oYP+A5ju0TroF4jezPVfO6MC3vH4dMunOlVvhTh Qpnk1Q1kMetasEwHP6NHxcHJAbRQzfh9k4gMALfgnAK6bRaYAqKxkrpBQc7+q+cWOHLK 3jY0trO8w84EwkS4xc2+V+JTao5mxdmKbURP5pnQ0Se+B2AhzrASVEjoDnuLx0VzGqtF bhDA== 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:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=B2P9hR8KM+hM2/TAFfF1cLurukfqr/xwrWCF1EMi1Sk=; b=T+/mGKUvYDK7Gcxe8h3xNsTCCrDN56TGp5pj1Ka+jbI1pSTxRUhvrLbwZZ7lajgAp1 fdQLMSTqZHmKqbgOIph+lteRi+71IOpFCYtU8mJoVXKBcBLeGfUXVSqOEZyOuQIYlee+ Mgnl9WjglF/pMe8xJvbwrq0izm69IvM+JJmV5o7QqgPXCb/OD/eIid/U3BbJZjv8wiz+ fO74cW0oRXUMApl+t3HtNIWbuUq+PNNqkob78JQ78SdhG4hUMqHO10YkfBwW+PC9VIe4 xURcS00jrFHZGVrRKXRusoSBkz8Ssm9ax8s2nBuyEmNDb0r7VHQ6CJxbLLF2C3kfLIWm k9mA== X-Gm-Message-State: AOUpUlHtZtfMNhn+ij+yF6ACmtLqv9nh8eiE46y4FE2M41NKUwunPEfA JW1peJnGALuAB+JHM8XtsB4xzozy X-Google-Smtp-Source: AA+uWPzFc5lE8dHZZi5bRrHfG8qycX4canLeOJEFe23OSKOzbNDTA4yBfFjeVofTMTL68yN6rGBEgw== X-Received: by 2002:a63:144b:: with SMTP id 11-v6mr34831813pgu.219.1534539458034; Fri, 17 Aug 2018 13:57:38 -0700 (PDT) Received: from [192.168.178.30] ([118.148.68.33]) by smtp.gmail.com with ESMTPSA id t9-v6sm2794332pgi.87.2018.08.17.13.57.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Aug 2018 13:57:36 -0700 (PDT) To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <F4EA189B-20F1-4B9F-B9F8-E5FB74A70A0D@lists.zabbadoz.net> From: Brian E Carpenter <brian.e.carpenter@gmail.com> Cc: v6ops@ietf.org Message-ID: <0fffcc15-35e1-d9a0-5da0-0706f9fda0bc@gmail.com> Date: Sat, 18 Aug 2018 08:57:31 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <F4EA189B-20F1-4B9F-B9F8-E5FB74A70A0D@lists.zabbadoz.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/hIyWGMlwuJafxy9TNJQuq_Afqa8> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 17 Aug 2018 20:57:40 -0000 On 2018-08-18 08:02, Bjoern A. Zeeb wrote: > On 17 Aug 2018, at 18:06, Fred Baker wrote: >=20 >> Ron and I just had our bi-weekly phone call, and identified a topic=20 >> that might be interesting and useful. We'd like to invite a draft from= =20 >> people that are deploying IPv6-only networks or parts of networks=20 >> identifying the problems they are experiencing that the IETF might be = >> in a position to address. The objective, as always, is to solve=20 >> problems preventing such a deployment in time for vendors and open=20 >> source to provide solutions. >=20 > (a) I think the IETF is the wrong place; I gave a talk in 2011 at a BS= D=20 > conference after I went v6-only, I saw talks at UKNOF (or UK IPv6 c.=20 > meeting), .. I am sure the =E2=80=9CNOG=E2=80=9Ds are doing similar. The wrong place for collecting info? Possibly. The wrong place for fixing implementations? Certainly. The wrong place for collating info, fixing standards and BCPs? I don't th= ink so. >=20 > (b) for the last 8 years it=E2=80=99s been working fantastic including = a=20 > multi-site v6-only VPN; bash your vendors, open bug reports, if not. Well, try setting a major hotel network to IPv6-only and see what happens= =2E.. > (c) the two major problem is =E2=80=9Cfear of breaking things=E2=80=9D = or =E2=80=9Cbeing=20 > ignorant to IPv6=E2=80=9D rather than just doing and dealing with it. I do agree with you (and Lee) that most of the issues are implementation or deployment related. However, who besides the IETF is going to do the job of collating information and figuring out if any standards or BCPs are at fault or lacking? Brian From nobody Fri Aug 17 14:23:30 2018 Return-Path: <lee@asgard.org> 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 E2386130E1F for <v6ops@ietfa.amsl.com>; Fri, 17 Aug 2018 14:23:28 -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 hKZTo5S9UEzV for <v6ops@ietfa.amsl.com>; Fri, 17 Aug 2018 14:23:26 -0700 (PDT) Received: from atl4mhob02.registeredsite.com (atl4mhob02.registeredsite.com [209.17.115.40]) (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 4F421130DE2 for <v6ops@ietf.org>; Fri, 17 Aug 2018 14:23:26 -0700 (PDT) Received: from mailpod.hostingplatform.com (atl4qobmail03pod6.registeredsite.com [10.30.71.211]) by atl4mhob02.registeredsite.com (8.14.4/8.14.4) with ESMTP id w7HLNMC7019719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <v6ops@ietf.org>; Fri, 17 Aug 2018 17:23:22 -0400 Received: (qmail 22317 invoked by uid 0); 17 Aug 2018 21:23:22 -0000 X-TCPREMOTEIP: 174.64.33.182 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.2.104?) (lee@asgard.org@174.64.33.182) by 0 with ESMTPA; 17 Aug 2018 21:23:22 -0000 To: v6ops@ietf.org References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <F4EA189B-20F1-4B9F-B9F8-E5FB74A70A0D@lists.zabbadoz.net> <0fffcc15-35e1-d9a0-5da0-0706f9fda0bc@gmail.com> From: Lee Howard <lee@asgard.org> Message-ID: <a7fa01c8-f62a-4ec5-a7d2-8f116934efb0@asgard.org> Date: Fri, 17 Aug 2018 17:23:21 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <0fffcc15-35e1-d9a0-5da0-0706f9fda0bc@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/LbGxaO9C5VrWF8irjZYDqkyW1EY> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 17 Aug 2018 21:23:29 -0000 On 08/17/2018 04:57 PM, Brian E Carpenter wrote: > > The wrong place for collecting info? Possibly. > The wrong place for fixing implementations? Certainly. > The wrong place for collating info, fixing standards and BCPs? I don't think so. Operational BCPs have a better home in BCOP. > I do agree with you (and Lee) that most of the issues are > implementation or deployment related. However, who besides the > IETF is going to do the job of collating information and figuring > out if any standards or BCPs are at fault or lacking? Will writing this draft  identify any faulty or lacking standards or BCPs that would not have been found and reported otherwise? Anyone who is testing IPv6-only systems or networks and who is on v6ops already knows how to say, "Hey, this doesn't look right." Is anyone going to do more testing than they otherwise would have because of this document? Are any bugs going to get reported that otherwise wouldn't have? If implementations are buggy, we report them to the implementor. Sure, they usually ignore us and tell us IPv6 isn't important. Would that change? If deployments are buggy, . . . well, that's a broken network. I know how to wring a vendor's neck. If this is point-in-time advice that IPv6-only is frustrating for $ListOfReasons, okay, I'll work on it. That seems like operational/deployment advice, and is in charter. I don't think it has much utility beyond a point in time, though. Or it could be a name-and-shame list. Not sure that's what we want. Lee > > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Aug 17 14:33:56 2018 Return-Path: <bzeeb-lists@lists.zabbadoz.net> 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 06FAA130FC2 for <v6ops@ietfa.amsl.com>; Fri, 17 Aug 2018 14:33:55 -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] 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 j-0NfkvFOScr for <v6ops@ietfa.amsl.com>; Fri, 17 Aug 2018 14:33:53 -0700 (PDT) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CF85130FBB for <v6ops@ietf.org>; Fri, 17 Aug 2018 14:33:53 -0700 (PDT) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 2CC4925D38A5; Fri, 17 Aug 2018 21:33:50 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 79A78D1F84D; Fri, 17 Aug 2018 21:33:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id E0WeEK4DqLgk; Fri, 17 Aug 2018 21:33:48 +0000 (UTC) Received: from [192.168.124.1] (fresh-ayiya.sbone.de [IPv6:fde9:577b:c1a9:f001::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 91965D1F835; Fri, 17 Aug 2018 21:33:47 +0000 (UTC) From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: "Brian E Carpenter" <brian.e.carpenter@gmail.com> Cc: v6ops@ietf.org Date: Fri, 17 Aug 2018 21:33:45 +0000 X-Mailer: MailMate (2.0BETAr6116) Message-ID: <33E6D0A3-C0CB-46AE-BEB8-EE5E67AE98B6@lists.zabbadoz.net> In-Reply-To: <0fffcc15-35e1-d9a0-5da0-0706f9fda0bc@gmail.com> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <F4EA189B-20F1-4B9F-B9F8-E5FB74A70A0D@lists.zabbadoz.net> <0fffcc15-35e1-d9a0-5da0-0706f9fda0bc@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/FcDNrS2E08pXbI6sCjxnV4deulw> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 17 Aug 2018 21:33:55 -0000 On 17 Aug 2018, at 20:57, Brian E Carpenter wrote: >> (c) the two major problem is “fear of breaking things” or >> “being >> ignorant to IPv6” rather than just doing and dealing with it. > > I do agree with you (and Lee) that most of the issues are > implementation or deployment related. However, who besides the > IETF is going to do the job of collating information and figuring > out if any standards or BCPs are at fault or lacking? People who swear over the RFC texts and think “if you had to implement that you’d never write that”. Sadly that feedback loop is too late unless you want more instead of less text. /bz From nobody Fri Aug 17 14:55:56 2018 Return-Path: <tom@herbertland.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B39130FDC for <v6ops@ietfa.amsl.com>; Fri, 17 Aug 2018 14:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.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 x217vSoS1bdu for <v6ops@ietfa.amsl.com>; Fri, 17 Aug 2018 14:55:53 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 16E2B130FDB for <v6ops@ietf.org>; Fri, 17 Aug 2018 14:55:52 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id n6-v6so10375227qtl.4 for <v6ops@ietf.org>; Fri, 17 Aug 2018 14:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ycpgog2GnLOdEPjkLLC1PQE+LDsia1zSXaeHarZn/7o=; b=yy4tt0gWxU0TpeSEsFvRCUdLuLaOrj7Wpw2K8V+58U5a/bC3dv6BQyYfgwY8mOvDSl 7m7nTFoWZPNqxW1r6TI8vhhqloyj6Ivmelg2US919OV8BslMXAfpGldPxSI/8RYLzAfd 5hAMtm66pTjKD1xqUYpANifujBCD7kY1Gsz7bZXmYclXGAFxeGF2UQWpLEYkXWNuMeKR zhilTV1QPYPvwIv9DvF+TmNixI+Aji5f4iMopeB1FP51zlXgIpqic2uoscqDgWmtaCKK BLGCb7Lm8gdCCaiHZZhM1OwwV+Cz/y2XbM+LF6GeqtoJOkmT8ZLHRTe4wUEJ1jX8CMuv +a2Q== 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=ycpgog2GnLOdEPjkLLC1PQE+LDsia1zSXaeHarZn/7o=; b=JU4DEUaogLCRL++sQpbiTCp+Jnil0Bz8/thOIX/hcI1sjxI+tT2KKWKz6fJwAM5g1m pTcI3Kx/5bX4aDhfhQGe2FHQ9p3p9JZ8TmDlqkx4AvGy5VdjSl+HBQY7VRpaJo2t2ssf CLWTe5vtk4pBxLJoaZWIO0KbuQetA56A2boZLWktg54sv8R4kzw4Dz6dDpyjPaN4/dxL 6b5xY6Y0rmK8bmg9/ZzHrQ5Wo5K9RcRQfmFLyHj7+1Rha3Ph43aKco3LAxWZkPmK+7ot vpKLQpsXR/c8V0KgsZqgT/uQzz0JM0+l+9wS8iG/iRRHL6DsOToUKd9yM5L8+EY15Twp n63Q== X-Gm-Message-State: AOUpUlGAHMYL151D67a2b6tuORq3zwDwDOu3+rO+4Bl+RIaQ6RatbQ1j BK12AuWF0GTjgaeHbNB3AFmGUtoHmb8/uj/gcyRl9Q== X-Google-Smtp-Source: AA+uWPzb6QPFFbSQNV/pvcwn7HOeOgkTJ4HpsD+DMkWT1xDZWjezFh6fYMymlD+tjEqIK28kipFanhgF7ln1n+Bxqaw= X-Received: by 2002:ac8:7412:: with SMTP id p18-v6mr2137237qtq.400.1534542952005; Fri, 17 Aug 2018 14:55:52 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:3304:0:0:0:0:0 with HTTP; Fri, 17 Aug 2018 14:55:51 -0700 (PDT) In-Reply-To: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> From: Tom Herbert <tom@herbertland.com> Date: Fri, 17 Aug 2018 14:55:51 -0700 Message-ID: <CALx6S35BznytJ48P36YaUi8DNM4nP3HbzBBxjT0HZcsw4G0eYw@mail.gmail.com> To: Fred Baker <fredbaker.ietf@gmail.com> Cc: "v6ops@ietf.org list" <v6ops@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/hm4VT6TNEFmBksP5zNyMt9sx38k> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 17 Aug 2018 21:55:55 -0000 On Fri, Aug 17, 2018 at 11:06 AM, Fred Baker <fredbaker.ietf@gmail.com> wro= te: > Ron and I just had our bi-weekly phone call, and identified a topic that = might be interesting and useful. We'd like to invite a draft from people th= at are deploying IPv6-only networks or parts of networks identifying the pr= oblems they are experiencing that the IETF might be in a position to addres= s. The objective, as always, is to solve problems preventing such a deploym= ent in time for vendors and open source to provide solutions. I believe that Facebook was one of the first major datacenter operators to go IPv6-only. It was "bumpy", and the problems were well documented like in https://www.internetsociety.org/resources/deploy360/2014/case-study-faceboo= k-moving-to-an-ipv6-only-internal-network/. I don't know if they turned that into a draft. Tom > -------------------------------------------------------------------------= ------- > Victorious warriors win first and then go to war, > Defeated warriors go to war first and then seek to win. > Sun Tzu > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Fri Aug 17 18:01:41 2018 Return-Path: <xiechf.bri@chinatelecom.cn> 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 E928C130DFE for <v6ops@ietfa.amsl.com>; Fri, 17 Aug 2018 18:01:39 -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 wHOqMOyUii2d for <v6ops@ietfa.amsl.com>; Fri, 17 Aug 2018 18:01:37 -0700 (PDT) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.226]) by ietfa.amsl.com (Postfix) with ESMTP id E43461294D7 for <v6ops@ietf.org>; Fri, 17 Aug 2018 18:01:35 -0700 (PDT) HMM_SOURCE_IP: 172.18.0.218:41339.254861450 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-114.250.157.119 (unknown [172.18.0.218]) by chinatelecom.cn (HERMES) with SMTP id 81AFD280090; Sat, 18 Aug 2018 09:01:26 +0800 (CST) Received: from DANGMM9A10 ([114.250.157.119]) by App0025 with ESMTP id 0be448a2-4637-4f70-895f-c78d4500eb7a for fredbaker.ietf@gmail.com; Sat Aug 18 09:01:30 2018 X-filter-score: filter<0> X-Real-From: xiechf.bri@chinatelecom.cn X-Receive-IP: 114.250.157.119 X-MEDUSA-Status: 0 Date: Sat, 18 Aug 2018 09:01:21 +0800 From: "xiechf.bri@chinatelecom.cn" <xiechf.bri@chinatelecom.cn> To: fredbaker.ietf <fredbaker.ietf@gmail.com>, v6ops <v6ops@ietf.org> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 8, 379[cn] Mime-Version: 1.0 Message-ID: <201808180901206509165@chinatelecom.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart282613080872_=----" Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/IWO7A_py2rD-V7WZdCedoFe4Q1A> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 18 Aug 2018 01:01:40 -0000 This is a multi-part message in MIME format. ------=_001_NextPart282613080872_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGksIEZyZWQsIA0KSSB0aGluayB0aGlzIGlzIGEgdmVyeSBnb29kIHBvaW50LiBBY3R1YWxseSB3 ZSBoYXZlIGRvbmUgdGhpcyB3b3JrIGluIG91ciBuZXR3b3JrIGFuZCBpdCBpcyBjYXBhYmxlIHRv IElQdjYtb25seSBhY2Nlc3MgdG8gbW9iaWxlIHVzZXJzIGluIHNvbWUgYXJlYSwgYWxndGhvdWdo IGl0IGlzIGluIHRoZSBlYXJseSBzdGFnZSAuICBJZiBwb3NzaWJsZSwgSSBob3BlIEkgY2FuIGpv aW4gdGhpcyBkcmFmdC4NClRoYW5rIHlvdSENCg0KQ2hvbmdmZW5nDQoNCg0KDQp4aWVjaGYuYnJp QGNoaW5hdGVsZWNvbS5jbg0KIA0KRnJvbTogRnJlZCBCYWtlcg0KRGF0ZTogMjAxOC0wOC0xOCAw MjowNg0KVG86IHY2b3BzQGlldGYub3JnIGxpc3QNClN1YmplY3Q6IFt2Nm9wc10gVGhpbmtpbmcg YWJvdXQgcHJvYmxlbXMgaW4gSVB2Ni1vbmx5IG5ldHdvcmtzDQpSb24gYW5kIEkganVzdCBoYWQg b3VyIGJpLXdlZWtseSBwaG9uZSBjYWxsLCBhbmQgaWRlbnRpZmllZCBhIHRvcGljIHRoYXQgbWln aHQgYmUgaW50ZXJlc3RpbmcgYW5kIHVzZWZ1bC4gV2UnZCBsaWtlIHRvIGludml0ZSBhIGRyYWZ0 IGZyb20gcGVvcGxlIHRoYXQgYXJlIGRlcGxveWluZyBJUHY2LW9ubHkgbmV0d29ya3Mgb3IgcGFy dHMgb2YgbmV0d29ya3MgaWRlbnRpZnlpbmcgdGhlIHByb2JsZW1zIHRoZXkgYXJlIGV4cGVyaWVu Y2luZyB0aGF0IHRoZSBJRVRGIG1pZ2h0IGJlIGluIGEgcG9zaXRpb24gdG8gYWRkcmVzcy4gVGhl IG9iamVjdGl2ZSwgYXMgYWx3YXlzLCBpcyB0byBzb2x2ZSBwcm9ibGVtcyBwcmV2ZW50aW5nIHN1 Y2ggYSBkZXBsb3ltZW50IGluIHRpbWUgZm9yIHZlbmRvcnMgYW5kIG9wZW4gc291cmNlIHRvIHBy b3ZpZGUgc29sdXRpb25zLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClZpY3RvcmlvdXMgd2Fy cmlvcnMgd2luIGZpcnN0IGFuZCB0aGVuIGdvIHRvIHdhciwNCkRlZmVhdGVkIHdhcnJpb3JzIGdv IHRvIHdhciBmaXJzdCBhbmQgdGhlbiBzZWVrIHRvIHdpbi4NCiAgICAgU3VuIFR6dQ0KIA0KIA0K IA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnY2b3Bz IG1haWxpbmcgbGlzdA0KdjZvcHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdjZvcHMNCg== ------=_001_NextPart282613080872_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charse= t=3DISO-8859-1"><style>body { line-height: 1.5; }blockquote { margin-top: = 0px; margin-bottom: 0px; margin-left: 0.5em; }body { font-size: 10.5pt; fo= nt-family: 'Microsoft YaHei UI'; color: rgb(0, 0, 0); line-height: 1.5; }<= /style></head><body>=0A<div><span></span>Hi, Fred, </div><div>I think= this is a very good point. Actually we have done this work in our network= and it is capable to IPv6-only access to mobile users in some area, algth= ough it is in the early stage .  If possible, I hope I can join this = draft.</div><div>Thank you!</div><div><br></div><div>Chongfeng</div>=0A<di= v><br></div><hr style=3D"width: 210px; height: 1px;" color=3D"#b5c4df" siz= e=3D"1" align=3D"left">=0A<div><span><div style=3D"MARGIN: 10px; FONT-FAMI= LY: verdana; FONT-SIZE: 10pt"><div>xiechf.bri@chinatelecom.cn</div></div><= /span></div>=0A<blockquote style=3D"margin-top: 0px; margin-bottom: 0px; m= argin-left: 0.5em;"><div> </div><div style=3D"border:none;border-top:= solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm"><div style=3D"PADDING-RIGHT= : 8px; PADDING-LEFT: 8px; FONT-SIZE: 12px;FONT-FAMILY:tahoma;COLOR:#000000= ; BACKGROUND: #efefef; PADDING-BOTTOM: 8px; PADDING-TOP: 8px"><div><b>From= :</b> <a href=3D"mailto:fredbaker.ietf@gmail.com">Fred Baker</a></div= ><div><b>Date:</b> 2018-08-18 02:06</div><div><b>To:</b> <a= href=3D"mailto:v6ops@ietf.org">v6ops@ietf.org list</a></div><div><b>Subje= ct:</b> [v6ops] Thinking about problems in IPv6-only networks</div></= div></div><div><div>Ron and I just had our bi-weekly phone call, and ident= ified a topic that might be interesting and useful. We'd like to invite a = draft from people that are deploying IPv6-only networks or parts of networ= ks identifying the problems they are experiencing that the IETF might be i= n a position to address. The objective, as always, is to solve problems pr= eventing such a deployment in time for vendors and open source to provide = solutions.</div>=0A<div>--------------------------------------------------= ------------------------------</div>=0A<div>Victorious warriors win first = and then go to war,</div>=0A<div>Defeated warriors go to war first and the= n seek to win.</div>=0A<div>     Sun Tzu</div>=0A<div>=  </div>=0A<div> </div>=0A<div> </div>=0A<div>______________= _________________________________</div>=0A<div>v6ops mailing list</div>=0A= <div>v6ops@ietf.org</div>=0A<div>https://www.ietf.org/mailman/listinfo/v6o= ps</div>=0A</div></blockquote>=0A</body></html> ------=_001_NextPart282613080872_=------ From nobody Fri Aug 17 18:09:57 2018 Return-Path: <prvs=1768a4f347=jordi.palet@consulintel.es> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FB1130F72 for <v6ops@ietfa.amsl.com>; Fri, 17 Aug 2018 18:09:55 -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 GPCdJPbvhzp3 for <v6ops@ietfa.amsl.com>; Fri, 17 Aug 2018 18:09:53 -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 10BF9130F1F for <v6ops@ietf.org>; Fri, 17 Aug 2018 18:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1534554590; x=1535159390; 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=8PwluGZQ mDsXdT706CuNegIPkOc1eqhlSx1ycdgcIUM=; b=vJTXGI0kl0izGi8l+iz2jc3t gO9Pstio/xxbOJ0HewETnjSOU7pyXwGrNhh8uqkUP2t0adsSIsa9tclvOK6fcRUT 4NSBQP7HZDZe/jxE5YxHuqpJd2L1fbVuH7oDxJmmPcNAWJhULPXC9g/0TDviK8kz ewFKl2eIvNWhYg5mclM= X-MDAV-Result: clean X-MDAV-Processed: mail.consulintel.es, Sat, 18 Aug 2018 03:09:50 +0200 X-Spam-Processed: mail.consulintel.es, Sat, 18 Aug 2018 03:09:50 +0200 Received: from [10.20.5.175] by mail.consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50005843813.msg for <v6ops@ietf.org>; Sat, 18 Aug 2018 03:09:50 +0200 X-MDRemoteIP: 10.8.10.6 X-MDHelo: [10.20.5.175] X-MDArrival-Date: Sat, 18 Aug 2018 03:09:50 +0200 X-Authenticated-Sender: jordi.palet@consulintel.es X-Return-Path: prvs=1768a4f347=jordi.palet@consulintel.es X-Envelope-From: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ietf.org User-Agent: Microsoft-MacOutlook/10.10.0.180812 Date: Fri, 17 Aug 2018 20:09:41 -0500 From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> To: Fred Baker <fredbaker.ietf@gmail.com>, "v6ops@ietf.org list" <v6ops@ietf.org> Message-ID: <3BE77332-B5FA-48F3-B881-45F60DA6643B@consulintel.es> Thread-Topic: [v6ops] Thinking about problems in IPv6-only networks References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> In-Reply-To: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/ybruioaPhRXOmrCZPTn9Hl4L7_Q> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 18 Aug 2018 01:09:55 -0000 Hi Fred, I will be happy to join, but first I think we need to clarify what is IPv6-= only in the scope of this document/work ... Are we talking about a network that in the "customer" LANs doesn't have ANY= IPv4 and never connects to any "IPv4-only remote site". Are the access links IPv6-only ? Or the LANs are IPv6 only, but the access = links are dual-stack? Or the LAN's don't have IPv4, but apps, running IPv6 can connect to remote = "IPv4-only sites" (so the network or the access provider) has a NAT64 or eq= uivalent mechanism? I recall we tried to clarify this definition in a previous document, and I = still see everybody reading different things ... Regards, Jordi =20 =20 =EF=BB=BF-----Mensaje original----- De: v6ops <v6ops-bounces@ietf.org> en nombre de Fred Baker <fredbaker.ietf@= gmail.com> Fecha: viernes, 17 de agosto de 2018, 13:06 Para: "v6ops@ietf.org list" <v6ops@ietf.org> Asunto: [v6ops] Thinking about problems in IPv6-only networks Ron and I just had our bi-weekly phone call, and identified a topic tha= t might be interesting and useful. We'd like to invite a draft from people = that are deploying IPv6-only networks or parts of networks identifying the = problems they are experiencing that the IETF might be in a position to addr= ess. The objective, as always, is to solve problems preventing such a deplo= yment in time for vendors and open source to provide solutions. -----------------------------------------------------------------------= --------- Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win. Sun Tzu =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 Fri Aug 17 19:30:11 2018 Return-Path: <brian.e.carpenter@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4EC130FF3 for <v6ops@ietfa.amsl.com>; Fri, 17 Aug 2018 19:30:10 -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 lo8jQSEX4Td5 for <v6ops@ietfa.amsl.com>; Fri, 17 Aug 2018 19:30:08 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 63C58130FCD for <v6ops@ietf.org>; Fri, 17 Aug 2018 19:30:08 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id w10-v6so4332430pgv.2 for <v6ops@ietf.org>; Fri, 17 Aug 2018 19:30:08 -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=lPjs3oxL1HYK5fEBh/kDjC22f4GU47Ib5QWph2G3WGM=; b=NJ4k0HzOKrqqMbkvia6DLyYKE/tnIadv2PQB4XeTc3EieOFyEebqsEmqd3CXznt4jG AQgqDFwgeKd9bbAZ+H8Rr6ivYKMorzjyXa5A+He7OTe0/lmG52yI4a9oTSjUik98IWui /TgM067YV7gi0Sgj9+pgTLKQHhsL9GEZmc/KbDvFHODzmRTS4+wqMhNgHSeU/KObVlz4 JVpOX0uckh7Z0KoYWud1lsguZhesTzV/iUFFTi7+YcC6zuMdSfjCyMJAs15GVz9MJXfC B1FoaowRfQUTy2Ik8US6u7BT6gggmYNRu0ZPmCguZtcCAdDPWRSjnySSQUj34aGvxpEf 513Q== 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=lPjs3oxL1HYK5fEBh/kDjC22f4GU47Ib5QWph2G3WGM=; b=Hajl7e7ASXocyeHRbRCUrglY6lS2QHf6tBkSEg3HgV5kIGy/MUNXHGLwAFZfL1X49f krG3QutjjEqJ4fV5roVXC+5UsYiKH0+Dlhl0i0X/5efEzZPmYF1038w6LaNY4b2MfoQ9 geKbeporWdn4/YYoSUrP+9+XZXyI8Fx+mheLh8Sm8yTpHE6izZ+I/K7nl9b7gZ7cZn1X pv8HtRfORG2uWDnBJRXar1ITQLHI5I/Uoq8Ixcm5gcU36FXJf0GOWl+WoTJA9lf42wU3 aIyOuCV/+FtjNzklckaOyqGRYBrnMjGGkAPT2xtkCX+4I88kbw9Tf77uIixRvYpY0cU2 4roA== X-Gm-Message-State: AOUpUlE+LNOSkf5QRP7XO63ErxeU0KqqEJRa9sFH5Y2rQbAqolqArp63 TNf7JHodPXGa6bcuaGAFvRrgt1Tb X-Google-Smtp-Source: AA+uWPyGPMIZ/IiInG5SdPi6r3cA8CbrbJAFS0ZXlIDr6SkcXYnEGy8DcF+S53wY4VaPykxMiCkRkg== X-Received: by 2002:a65:48cd:: with SMTP id o13-v6mr1677845pgs.99.1534559407634; Fri, 17 Aug 2018 19:30:07 -0700 (PDT) Received: from [192.168.178.30] ([118.148.68.33]) by smtp.gmail.com with ESMTPSA id c1-v6sm3715072pfi.142.2018.08.17.19.30.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Aug 2018 19:30:06 -0700 (PDT) To: Lee Howard <lee@asgard.org>, v6ops@ietf.org References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <F4EA189B-20F1-4B9F-B9F8-E5FB74A70A0D@lists.zabbadoz.net> <0fffcc15-35e1-d9a0-5da0-0706f9fda0bc@gmail.com> <a7fa01c8-f62a-4ec5-a7d2-8f116934efb0@asgard.org> From: Brian E Carpenter <brian.e.carpenter@gmail.com> Message-ID: <182de4c5-751d-59a1-5fe3-2594d375d50f@gmail.com> Date: Sat, 18 Aug 2018 14:30:01 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <a7fa01c8-f62a-4ec5-a7d2-8f116934efb0@asgard.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/_lFj8u9HRN7bDp2acLkeMRxYFV0> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 18 Aug 2018 02:30:10 -0000 On 2018-08-18 09:23, Lee Howard wrote: >=20 >=20 > On 08/17/2018 04:57 PM, Brian E Carpenter wrote: >> >> The wrong place for collecting info? Possibly. >> The wrong place for fixing implementations? Certainly. >> The wrong place for collating info, fixing standards and BCPs? I don't= think so. > Operational BCPs have a better home in BCOP. Yes, that dividing line is a judgment call. IMNSHO anything that affects implementers is probably more effective in an RFC. =20 >> I do agree with you (and Lee) that most of the issues are >> implementation or deployment related. However, who besides the >> IETF is going to do the job of collating information and figuring >> out if any standards or BCPs are at fault or lacking? >=20 > Will writing this draft=C2=A0 identify any faulty or lacking standards = or=20 > BCPs that would not have been found and reported otherwise? Anyone who = > is testing IPv6-only systems or networks and who is on v6ops already=20 > knows how to say, "Hey, this doesn't look right." > Is anyone going to do more testing than they otherwise would have=20 > because of this document? > Are any bugs going to get reported that otherwise wouldn't have? I don't know, and I fear that the only way to find out is to try it. > If implementations are buggy, we report them to the implementor. Sure, = > they usually ignore us and tell us IPv6 isn't important. Would that cha= nge? > If deployments are buggy, . . . well, that's a broken network. I know=20 > how to wring a vendor's neck. >=20 > If this is point-in-time advice that IPv6-only is frustrating for=20 > $ListOfReasons, okay, I'll work on it. That seems like=20 > operational/deployment advice, and is in charter. I don't think it has = > much utility beyond a point in time, though. Agreed. =20 > Or it could be a name-and-shame list. Not sure that's what we want. I'm fairly sure we don't want that. Brian From nobody Fri Aug 17 21:39:52 2018 Return-Path: <alejandroacostaalamo@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340C4130E1B for <v6ops@ietfa.amsl.com>; Fri, 17 Aug 2018 21:39:51 -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 uPzBqUFhSG1t for <v6ops@ietfa.amsl.com>; Fri, 17 Aug 2018 21:39:49 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 DE058130DEF for <v6ops@ietf.org>; Fri, 17 Aug 2018 21:39:48 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id e19-v6so10982078qtp.8 for <v6ops@ietf.org>; Fri, 17 Aug 2018 21:39:48 -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-transfer-encoding:content-language; bh=pMi88vGVmWVfccLVspq3zlSuYkzCTlz6X048uc7PJbc=; b=YXOdCqqWXTt/JHCxob5tyJ4Rr3pk+eOnG1NUTZjaQ61buJ4KS4SfJ0DWJmD4vNLpR8 Dp3RDRjPU+ReicwSZE6IZnGhENNmKJyXY8AKls3jDTY2f5YjnIUNcM+ZLY1ocswtGL8c N6SaJAwq5FtPEB9h7GnttvwcElQWLwiYhIaqvtF8AsHQqfZo/31xyl9H6iKhceekAH7I aYFwHu33I/aOVMvzii4TVCovhEPNZVMXnVCXzA75NQOjP4pZo1Wvn/lIvMbm7nxDt2tP paC04MizHbM0YgfhQ2aAQh88x48b2NiCPulfZlkxsbs3WWD2G5WlCLMufZovjaeZGu9F YP+A== 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-transfer-encoding :content-language; bh=pMi88vGVmWVfccLVspq3zlSuYkzCTlz6X048uc7PJbc=; b=qbqreTOy2Nh29I7rj7NdZvDyq/wSAtXAOaFxfIdxGvgWOUtsj65AjJYA2KibirTUxD DlB84KV0N3TR/9PiFG80zZlqiPFbbyEUHqdfmDzKvArzmc/xWtynfRAm3ZFUgzVWXm2P Eq23gR5dojs8N8onKm/A39Zcte8l3/botmJ3g4aR7oYmCWqmW8+VFM4t2DgXga/zoTYB d7Ba8CxbIGPjxG8q7RQ/5lsPdPlX6HsZDt6294VyAh42jRwSZNFCH+BeRgVYK4qazz6R 8V87EifKUUt15N0Y5isO3tCyQoxl2F9xbE5S4dFrm9B5fFsGLGS2OFGJlhLhmhfbteIe QHVw== X-Gm-Message-State: AOUpUlFpIePYbN069fsEZGFKIluKX3NYtxljSwZZGmj4bhITV0ciHGBz S/7y0AZg2YiMmpc8Kh2lk+ISYpBu X-Google-Smtp-Source: ANB0VdZHwtYKDbvw0aULoeHu8ycPaxmmdjYkOJPawFU8SgHg7D1OWri2zjN2bHMqyiY4mD2Zdg5jkw== X-Received: by 2002:aed:3d71:: with SMTP id h46-v6mr4765398qtf.416.1534567187845; Fri, 17 Aug 2018 21:39:47 -0700 (PDT) Received: from MacBook-Pro-de-admin-alejandro.local ([190.186.112.196]) by smtp.gmail.com with ESMTPSA id f23-v6sm1387016qtc.65.2018.08.17.21.39.44 for <v6ops@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Aug 2018 21:39:46 -0700 (PDT) To: v6ops@ietf.org References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <3BE77332-B5FA-48F3-B881-45F60DA6643B@consulintel.es> From: Alejandro Acosta <alejandroacostaalamo@gmail.com> Message-ID: <1de47c03-7b13-8ae4-72dc-ed17ffc42cfb@gmail.com> Date: Sat, 18 Aug 2018 00:39:41 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <3BE77332-B5FA-48F3-B881-45F60DA6643B@consulintel.es> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: es-ES Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/hOp2glLKRG6RxbGfqUDYpS4Yj2U> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 18 Aug 2018 04:39:51 -0000 good point El 17/8/18 a las 21:09, JORDI PALET MARTINEZ escribió: > Hi Fred, > > I will be happy to join, but first I think we need to clarify what is IPv6-only in the scope of this document/work ... > > Are we talking about a network that in the "customer" LANs doesn't have ANY IPv4 and never connects to any "IPv4-only remote site". > > Are the access links IPv6-only ? Or the LANs are IPv6 only, but the access links are dual-stack? > > Or the LAN's don't have IPv4, but apps, running IPv6 can connect to remote "IPv4-only sites" (so the network or the access provider) has a NAT64 or equivalent mechanism? > > I recall we tried to clarify this definition in a previous document, and I still see everybody reading different things ... > > Regards, > Jordi > > > > -----Mensaje original----- > De: v6ops <v6ops-bounces@ietf.org> en nombre de Fred Baker <fredbaker.ietf@gmail.com> > Fecha: viernes, 17 de agosto de 2018, 13:06 > Para: "v6ops@ietf.org list" <v6ops@ietf.org> > Asunto: [v6ops] Thinking about problems in IPv6-only networks > > Ron and I just had our bi-weekly phone call, and identified a topic that might be interesting and useful. We'd like to invite a draft from people that are deploying IPv6-only networks or parts of networks identifying the problems they are experiencing that the IETF might be in a position to address. The objective, as always, is to solve problems preventing such a deployment in time for vendors and open source to provide solutions. > -------------------------------------------------------------------------------- > Victorious warriors win first and then go to war, > Defeated warriors go to war first and then seek to win. > Sun Tzu > > _______________________________________________ > 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 From nobody Sat Aug 18 07:39:26 2018 Return-Path: <mackermann@bcbsm.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669CA130E82 for <v6ops@ietfa.amsl.com>; Sat, 18 Aug 2018 07:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.08 X-Spam-Level: X-Spam-Status: No, score=-4.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.onmicrosoft.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 FZSkMZPuHKY1 for <v6ops@ietfa.amsl.com>; Sat, 18 Aug 2018 07:39:19 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (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 40A1C130E63 for <v6ops@ietf.org>; Sat, 18 Aug 2018 07:39:18 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 3ED651C11A0 for <v6ops@ietf.org>; Sat, 18 Aug 2018 09:39:17 -0500 (CDT) Received: from imsva1.bcbsm.com (inetmta03.bcbsm.com [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id 6B0281C10DB; Sat, 18 Aug 2018 09:39:16 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1A1B092069; Sat, 18 Aug 2018 10:39:16 -0400 (EDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E51EC92065; Sat, 18 Aug 2018 10:39:15 -0400 (EDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (unknown [207.46.163.21]) by imsva1.bcbsm.com (Postfix) with ESMTPS; Sat, 18 Aug 2018 10:39:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ABDqRNCqxlECOIip2YytPKA0im5q2SODDze1zF4Znqo=; b=AfJq9HzarzrygQ3xDvU3qtCitPh9Cg7ePGgfjFEadCCVWkmD0BEzTa3Xhz38jo6Qc+SbwQm1JBwBq5u1D5gR9z6IAtcSGjTBHBGwqH0vrdJc/fEd5l7NMVnluyzeYU4Kg2aVXCBkFY6FAcjabTCJXf17/D+47aq0lv1uLpK/DIk= Received: from CY1PR14MB0842.namprd14.prod.outlook.com (10.169.21.22) by CY1PR14MB0235.namprd14.prod.outlook.com (10.163.93.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1059.21; Sat, 18 Aug 2018 14:39:14 +0000 Received: from CY1PR14MB0842.namprd14.prod.outlook.com ([fe80::8509:57ad:a26d:8587]) by CY1PR14MB0842.namprd14.prod.outlook.com ([fe80::8509:57ad:a26d:8587%5]) with mapi id 15.20.1059.021; Sat, 18 Aug 2018 14:39:14 +0000 From: "Ackermann, Michael" <MAckermann@bcbsm.com> To: Lee Howard <lee@asgard.org>, "v6ops@ietf.org" <v6ops@ietf.org> Thread-Topic: [v6ops] Thinking about problems in IPv6-only networks Thread-Index: AQHUNlUR1MIQXO7tq0itqOecqz/S1qTEQgAAgAFTbuA= Date: Sat, 18 Aug 2018 14:39:14 +0000 Message-ID: <CY1PR14MB0842EF6B6158406170D8B893D73C0@CY1PR14MB0842.namprd14.prod.outlook.com> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> In-Reply-To: <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=MAckermann@bcbsm.com; x-originating-ip: [165.225.0.90] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR14MB0235; 20:36VcC/0IrZhI4LoljB0NjECtJSw6P6SIHZrlUWDJd+w6623rroPXtoIuDpGOsTWPoiQurM7vOKoGZ3SXFT/rbIG4/Feesxl9Cv9d1AJbg5+DwUxGvyaJCTerrgxsbHpj5Yag0M7eGKOLgW11MIhrTHQ8VEv0qWqPMPig3NRO9iA= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: fe5d5c85-ac01-4296-d6cd-08d605185eb7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7167020)(7153060)(7193020); SRVR:CY1PR14MB0235; x-ms-traffictypediagnostic: CY1PR14MB0235: x-microsoft-antispam-prvs: <CY1PR14MB0235E0D02D5404D1F3420872D73C0@CY1PR14MB0235.namprd14.prod.outlook.com> x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231311)(944501410)(52105095)(10201501046)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(201708071742011)(7699016); SRVR:CY1PR14MB0235; BCL:0; PCL:0; RULEID:; SRVR:CY1PR14MB0235; x-forefront-prvs: 076804FE30 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(136003)(346002)(396003)(376002)(199004)(189003)(478600001)(6436002)(81156014)(606006)(229853002)(14454004)(72206003)(966005)(76176011)(81166006)(7696005)(5660300001)(486006)(99286004)(476003)(446003)(7736002)(11346002)(5250100002)(2501003)(110136005)(33656002)(74316002)(8676002)(97736004)(8936002)(316002)(80792005)(26005)(6116002)(790700001)(186003)(256004)(54896002)(6306002)(14444005)(9686003)(3846002)(236005)(106356001)(53936002)(6246003)(105586002)(2906002)(86362001)(55236004)(2900100001)(55016002)(102836004)(25786009)(6506007)(53546011)(68736007)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR14MB0235; H:CY1PR14MB0842.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: bcbsm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: tJ+s5YiM6J2HwYB71mcn9vqjo6aaxwNdICQR88tmTE1HmATrP6nmIwlUQUq6YBMXlZ/C0psinEM0MTwVw48eDUq4NbTTK8Nyget8PJL47WsTn2tHmH3YlAkQIz8EXeUNorSFoyFE8gZxE/rXJn05KRP27dOtVdqQTDGciNZGbMKC5okd2fNNVgKbHx55iPoyKU5iIHjy6p9FayaSEyKHA5FNU767O9cgd0S1GcQWFvYTN9zf2kgFSekD/f6btQ524DvrN6KNc/PP6j+GJK5g40/Ef7jMzEN3TktqQCn9RR/iOY6+oUIqjOOm+KnQ+eeRXtApnQYPQJg6nH1c0zBrYv7eQ96CrWY6uf4THTn/sfo= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR14MB0842EF6B6158406170D8B893D73C0CY1PR14MB0842namp_" MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-Network-Message-Id: fe5d5c85-ac01-4296-d6cd-08d605185eb7 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Aug 2018 14:39:14.4714 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR14MB0235 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm01.z120.zixworks.com X-VPM-GROUP-ID: c5a4758a-0957-4482-896b-048687b5387a X-VPM-MSG-ID: 1a2da8e6-9a7d-47ee-b5ee-303dffd8842b X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/YdLIOXR4x7L5s7DCOmHSX4c9B-4> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 18 Aug 2018 14:39:24 -0000 --_000_CY1PR14MB0842EF6B6158406170D8B893D73C0CY1PR14MB0842namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lee This is good info. I hope a related draft gets developed and would be = happy to contribute if it does. Thanks Mike From: v6ops <v6ops-bounces=40ietf.org> On Behalf Of Lee Howard Sent: Friday, August 17, 2018 2:23 PM To: v6ops=40ietf.org Subject: Re: =5Bv6ops=5D Thinking about problems in IPv6-only networks Problems I've encountered (off the top of my head): * Documentation assumes/uses IPv4 * Listeners only configured for IPv4 * Software repos that are IPv4-only * CA/CRL/OCSP that are IPv4-only * VPN software that is unaware of IPv6, so client is split tunnel when = on a dual-stack network * No IPv6 support in openssl (is there a better troubleshooting tool I = should use?) * Mail is still a mess * Bugs in home gateways * Chicken-and-egg provisioning/OSS need to run IPv6, but routers and = firewalls have to run IPv6 to get to them. I've made it through most router configuration (I always have to tell = engineers that router-id is an integer not an IPv4 address; it sure looks = like an address; oh, and it has to be manually configured in an IPv6-only = network). That's all very operational; is that the sort of stuff you're thinking? If = so, I'll go ahead and start a draft and see who else wants to contribute. = Most of it is temporary (I hope) or related to other people not deploying, = so I 'm not sure whether this is what you have in mind. Lee On 08/17/2018 02:06 PM, Fred Baker wrote: Ron and I just had our bi-weekly phone call, and identified a topic that = might be interesting and useful. We'd like to invite a draft from people = that are deploying IPv6-only networks or parts of networks identifying the = problems they are experiencing that the IETF might be in a position to = address. The objective, as always, is to solve problems preventing such a = deployment in time for vendors and open source to provide solutions. ---------------------------------------------------------------------------= ----- Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win. Sun Tzu _______________________________________________ v6ops mailing list v6ops=40ietf.org<mailto:v6ops=40ietf.org> https://www.ietf.org/mailman/listinfo/v6ops The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. --_000_CY1PR14MB0842EF6B6158406170D8B893D73C0CY1PR14MB0842namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D=22urn:schemas-microsoft-com:vml=22 = xmlns:o=3D=22urn:schemas-microsoft-com:office:office=22 = xmlns:w=3D=22urn:schemas-microsoft-com:office:word=22 = xmlns:m=3D=22http://schemas.microsoft.com/office/2004/12/omml=22 = xmlns=3D=22http://www.w3.org/TR/REC-html40=22> <head> <meta http-equiv=3D=22Content-Type=22 content=3D=22text/html; = charset=3Dus-ascii=22> <meta name=3D=22Generator=22 content=3D=22Microsoft Word 15 (filtered = medium)=22> <style><=21-- /* Font Definitions */ =40font-face =09=7Bfont-family:Wingdings; =09panose-1:5 0 0 0 0 0 0 0 0 0;=7D =40font-face =09=7Bfont-family:=22Cambria Math=22; =09panose-1:2 4 5 3 5 4 6 3 2 4;=7D =40font-face =09=7Bfont-family:Calibri; =09panose-1:2 15 5 2 2 2 4 3 2 4;=7D =40font-face =09=7Bfont-family:Consolas; =09panose-1:2 11 6 9 2 2 4 3 2 4;=7D /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal =09=7Bmargin:0in; =09margin-bottom:.0001pt; =09font-size:11.0pt; =09font-family:=22Calibri=22,sans-serif; =09color:black;=7D a:link, span.MsoHyperlink =09=7Bmso-style-priority:99; =09color:blue; =09text-decoration:underline;=7D a:visited, span.MsoHyperlinkFollowed =09=7Bmso-style-priority:99; =09color:purple; =09text-decoration:underline;=7D pre =09=7Bmso-style-priority:99; =09mso-style-link:=22HTML Preformatted Char=22; =09margin:0in; =09margin-bottom:.0001pt; =09font-size:10.0pt; =09font-family:=22Courier New=22; =09color:black;=7D p.msonormal0, li.msonormal0, div.msonormal0 =09=7Bmso-style-name:msonormal; =09mso-margin-top-alt:auto; =09margin-right:0in; =09mso-margin-bottom-alt:auto; =09margin-left:0in; =09font-size:11.0pt; =09font-family:=22Calibri=22,sans-serif; =09color:black;=7D span.HTMLPreformattedChar =09=7Bmso-style-name:=22HTML Preformatted Char=22; =09mso-style-priority:99; =09mso-style-link:=22HTML Preformatted=22; =09font-family:Consolas; =09color:black;=7D span.EmailStyle21 =09=7Bmso-style-type:personal-reply; =09font-family:=22Calibri=22,sans-serif; =09color:windowtext;=7D =2EMsoChpDefault =09=7Bmso-style-type:export-only; =09font-size:10.0pt;=7D =40page WordSection1 =09=7Bsize:8.5in 11.0in; =09margin:1.0in 1.0in 1.0in 1.0in;=7D div.WordSection1 =09=7Bpage:WordSection1;=7D /* List Definitions */ =40list l0 =09=7Bmso-list-id:69620742; =09mso-list-template-ids:2090749026;=7D =40list l0:level1 =09=7Bmso-level-number-format:bullet; =09mso-level-text:=5CF0B7; =09mso-level-tab-stop:.5in; =09mso-level-number-position:left; =09text-indent:-.25in; =09mso-ansi-font-size:10.0pt; =09font-family:Symbol;=7D =40list l0:level2 =09=7Bmso-level-number-format:bullet; =09mso-level-text:o; =09mso-level-tab-stop:1.0in; =09mso-level-number-position:left; =09text-indent:-.25in; =09mso-ansi-font-size:10.0pt; =09font-family:=22Courier New=22; =09mso-bidi-font-family:=22Times New Roman=22;=7D =40list l0:level3 =09=7Bmso-level-number-format:bullet; =09mso-level-text:=5CF0A7; =09mso-level-tab-stop:1.5in; =09mso-level-number-position:left; =09text-indent:-.25in; =09mso-ansi-font-size:10.0pt; =09font-family:Wingdings;=7D =40list l0:level4 =09=7Bmso-level-number-format:bullet; =09mso-level-text:=5CF0A7; =09mso-level-tab-stop:2.0in; =09mso-level-number-position:left; =09text-indent:-.25in; =09mso-ansi-font-size:10.0pt; =09font-family:Wingdings;=7D =40list l0:level5 =09=7Bmso-level-number-format:bullet; =09mso-level-text:=5CF0A7; =09mso-level-tab-stop:2.5in; =09mso-level-number-position:left; =09text-indent:-.25in; =09mso-ansi-font-size:10.0pt; =09font-family:Wingdings;=7D =40list l0:level6 =09=7Bmso-level-number-format:bullet; =09mso-level-text:=5CF0A7; =09mso-level-tab-stop:3.0in; =09mso-level-number-position:left; =09text-indent:-.25in; =09mso-ansi-font-size:10.0pt; =09font-family:Wingdings;=7D =40list l0:level7 =09=7Bmso-level-number-format:bullet; =09mso-level-text:=5CF0A7; =09mso-level-tab-stop:3.5in; =09mso-level-number-position:left; =09text-indent:-.25in; =09mso-ansi-font-size:10.0pt; =09font-family:Wingdings;=7D =40list l0:level8 =09=7Bmso-level-number-format:bullet; =09mso-level-text:=5CF0A7; =09mso-level-tab-stop:4.0in; =09mso-level-number-position:left; =09text-indent:-.25in; =09mso-ansi-font-size:10.0pt; =09font-family:Wingdings;=7D =40list l0:level9 =09=7Bmso-level-number-format:bullet; =09mso-level-text:=5CF0A7; =09mso-level-tab-stop:4.5in; =09mso-level-number-position:left; =09text-indent:-.25in; =09mso-ansi-font-size:10.0pt; =09font-family:Wingdings;=7D ol =09=7Bmargin-bottom:0in;=7D ul =09=7Bmargin-bottom:0in;=7D --></style><=21--=5Bif gte mso 9=5D><xml> <o:shapedefaults v:ext=3D=22edit=22 spidmax=3D=221026=22 /> </xml><=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D><xml> <o:shapelayout v:ext=3D=22edit=22> <o:idmap v:ext=3D=22edit=22 data=3D=221=22 /> </o:shapelayout></xml><=21=5Bendif=5D--> </head> <body bgcolor=3D=22white=22 lang=3D=22EN-US=22 link=3D=22blue=22 = vlink=3D=22purple=22> <div class=3D=22WordSection1=22> <p class=3D=22MsoNormal=22><span = style=3D=22color:windowtext=22>Lee<o:p></o:p></span></p> <p class=3D=22MsoNormal=22><span style=3D=22color:windowtext=22>This is = good info.     I hope a related draft gets developed = and would be happy to contribute if it does.  <o:p></o:p></span></p> <p class=3D=22MsoNormal=22><span = style=3D=22color:windowtext=22>Thanks<o:p></o:p></span></p> <p class=3D=22MsoNormal=22><span = style=3D=22color:windowtext=22>Mike<o:p></o:p></span></p> <p class=3D=22MsoNormal=22><span = style=3D=22color:windowtext=22><o:p> </o:p></span></p> <p class=3D=22MsoNormal=22><span = style=3D=22color:windowtext=22><o:p> </o:p></span></p> <div> <div style=3D=22border:none;border-top:solid =23E1E1E1 1.0pt;padding:3.0pt = 0in 0in 0in=22> <p class=3D=22MsoNormal=22><b><span = style=3D=22color:windowtext=22>From:</span></b><span = style=3D=22color:windowtext=22> v6ops <v6ops-bounces=40ietf.org> <b>On Behalf Of </b>Lee Howard<br> <b>Sent:</b> Friday, August 17, 2018 2:23 PM<br> <b>To:</b> v6ops=40ietf.org<br> <b>Subject:</b> Re: =5Bv6ops=5D Thinking about problems in IPv6-only = networks<o:p></o:p></span></p> </div> </div> <p class=3D=22MsoNormal=22><o:p> </o:p></p> <p class=3D=22MsoNormal=22>Problems I've encountered (off the top of my = head):<o:p></o:p></p> <ul type=3D=22disc=22> <li class=3D=22MsoNormal=22 = style=3D=22mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 = level1 lfo1=22> Documentation assumes/uses IPv4<o:p></o:p></li><li class=3D=22MsoNormal=22 = style=3D=22mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 = level1 lfo1=22> Listeners only configured for IPv4<o:p></o:p></li><li = class=3D=22MsoNormal=22 = style=3D=22mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 = level1 lfo1=22> Software repos that are IPv4-only<o:p></o:p></li><li = class=3D=22MsoNormal=22 = style=3D=22mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 = level1 lfo1=22> CA/CRL/OCSP that are IPv4-only<o:p></o:p></li><li class=3D=22MsoNormal=22 = style=3D=22mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 = level1 lfo1=22> VPN software that is unaware of IPv6, so client is split tunnel when on a = dual-stack network<o:p></o:p></li><li class=3D=22MsoNormal=22 = style=3D=22mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 = level1 lfo1=22> No IPv6 support in openssl (is there a better troubleshooting tool I = should use?)<o:p></o:p></li><li class=3D=22MsoNormal=22 = style=3D=22mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 = level1 lfo1=22> Mail is still a mess<o:p></o:p></li><li class=3D=22MsoNormal=22 = style=3D=22mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 = level1 lfo1=22> Bugs in home gateways<o:p></o:p></li><li class=3D=22MsoNormal=22 = style=3D=22mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 = level1 lfo1=22> Chicken-and-egg provisioning/OSS need to run IPv6, but routers and = firewalls have to run IPv6 to get to them.<o:p></o:p></li></ul> <p>I've made it through most router configuration (I always have to tell = engineers that router-id is an integer not an IPv4 address; it sure looks = like an address; oh, and it has to be manually configured in an IPv6-only = network).<o:p></o:p></p> <p>That's all very operational; is that the sort of stuff you're thinking? = If so, I'll go ahead and start a draft and see who else wants to = contribute. Most of it is temporary (I hope) or related to other people = not deploying, so I 'm not sure whether this is what you have in mind. <o:p></o:p></p> <p class=3D=22MsoNormal=22 style=3D=22margin-bottom:12.0pt=22>Lee<br> <br> <o:p></o:p></p> <div> <p class=3D=22MsoNormal=22>On 08/17/2018 02:06 PM, Fred Baker = wrote:<o:p></o:p></p> </div> <blockquote style=3D=22margin-top:5.0pt;margin-bottom:5.0pt=22> <pre>Ron and I just had our bi-weekly phone call, and identified a topic = that might be interesting and useful. We'd like to invite a draft from = people that are deploying IPv6-only networks or parts of networks = identifying the problems they are experiencing that the IETF might be in a = position to address. The objective, as always, is to solve problems = preventing such a deployment in time for vendors and open source to = provide solutions.<o:p></o:p></pre> <pre>----------------------------------------------------------------------= ----------<o:p></o:p></pre> <pre>Victorious warriors win first and then go to war,<o:p></o:p></pre> <pre>Defeated warriors go to war first and then seek to = win.<o:p></o:p></pre> <pre>     Sun Tzu<o:p></o:p></pre> <pre><o:p> </o:p></pre> <p class=3D=22MsoNormal=22><br> <br> <br> <o:p></o:p></p> <pre>_______________________________________________<o:p></o:p></pre> <pre>v6ops mailing list<o:p></o:p></pre> <pre><a = href=3D=22mailto:v6ops=40ietf.org=22>v6ops=40ietf.org</a><o:p></o:p></pre> <pre><a = href=3D=22https://www.ietf.org/mailman/listinfo/v6ops=22>https://www.ietf.o= rg/mailman/listinfo/v6ops</a><o:p></o:p></pre> </blockquote> <p class=3D=22MsoNormal=22><o:p> </o:p></p> </div> </body> </html> <BR> <html> <p>The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies.</p> <p>Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association.</p> </html> --_000_CY1PR14MB0842EF6B6158406170D8B893D73C0CY1PR14MB0842namp_-- From nobody Sat Aug 18 08:18:35 2018 Return-Path: <cb.list6@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5DA130E8A for <v6ops@ietfa.amsl.com>; Sat, 18 Aug 2018 08:18:34 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ILlWEYKgS9Hh for <v6ops@ietfa.amsl.com>; Sat, 18 Aug 2018 08:18:32 -0700 (PDT) Received: from mail-yw1-xc35.google.com (mail-yw1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (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 9E4F8130E62 for <v6ops@ietf.org>; Sat, 18 Aug 2018 08:18:32 -0700 (PDT) Received: by mail-yw1-xc35.google.com with SMTP id q129-v6so5433193ywg.8 for <v6ops@ietf.org>; Sat, 18 Aug 2018 08:18:32 -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=8wm/DcD+9//LhbIlM50k1KPNOziVpOPaQp/uwYS5dZI=; b=uIbwaSOj/jHwG8vh5j+cn+I0Q8iMKmcTGz9CuXjhCChP7A+8mp6t7LP7RVNsJ3Tiot +5bjVZJePVq5OUDQgSoOWN5D9m+5BKSW1Gbgr0+WlTqyLtKNw1hwDaISCqls9lgwQr8X VHEpo8NkTjmbvW0Sko7ITYH59gEbudeHf7TLikB0lgn8t2Nmi9a76sDBweCFCW746UjG a5GaGuphKX83n1MEwNmzf7nCgUZIzH3clquty1cfIPQ+ljMqLjp7XcMaeuqkxgLEMpO2 T8/QcsKKNYyTkOhPkI+JM3zEAKGluZF0GZccMnMy8Af+Oeg44MOQwETj+8gGkafZ20x8 vvFA== 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=8wm/DcD+9//LhbIlM50k1KPNOziVpOPaQp/uwYS5dZI=; b=KjNM0jcZzBIPlLRETbQJWIZxsXXdEYcjg2CcJZqKe7pj5E2PfrCtA2sLHxMyxYH+IT hvIKy9g9deI8zM1+lG6TcgwhaOvn/mNkZUEdPS7a0FOc1aY2vQgKF0CaHjkXkSwmkSGW 9MeMaP4Ew45CA8qoBZ/yPHkPkjwVlbiirpD+XlTsVG6L4TNr8JUDPNImeCHRWYiJ4+Qc 2BnLKQmJc7UAOm0yYGen93vYd9gEMU/FPmbkix2v536g5iaYG9kbWKU/9vryaXE3vS7q 100UDR3cZy7X0lbyn0EQnRVZDha+9Dz/1ctFuEjvByNQoTdugnvXO7SI72yCmuWDXPk8 x6sA== X-Gm-Message-State: AOUpUlF2p3U7TxI+9Gb2l0EY61bSoKhZb0HNFfbX03uJ6LxD827/WJdz 280OK2PFBwUevmwNJSCyZrz2GWd3yENb4D61+E29Pg== X-Google-Smtp-Source: AA+uWPwmhEkXOTUuUdkcTzo/FxSO0COEYa8f1s/khljZZ5IDGfvmmUZu3GZ7rG0KkqShc7CVlC2GOsUcyM15MvPPIGQ= X-Received: by 2002:a81:7050:: with SMTP id l77-v6mr22212402ywc.226.1534605511819; Sat, 18 Aug 2018 08:18:31 -0700 (PDT) MIME-Version: 1.0 References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> In-Reply-To: <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> From: Ca By <cb.list6@gmail.com> Date: Sat, 18 Aug 2018 08:18:20 -0700 Message-ID: <CAD6AjGQ_OBFGJb_C+mP_87nu7q_oXPrTvxhaV_=RcubeHtMy2Q@mail.gmail.com> To: Lee Howard <lee@asgard.org> Cc: v6ops@ietf.org Content-Type: multipart/alternative; boundary="0000000000006706620573b730fd" Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/gLMRoCNWyaL2CW0o6DoF_1rjrIs> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 18 Aug 2018 15:18:34 -0000 --0000000000006706620573b730fd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 17, 2018 at 11:24 AM Lee Howard <lee@asgard.org> wrote: > Problems I've encountered (off the top of my head): > > - Documentation assumes/uses IPv4 > - Listeners only configured for IPv4 > - Software repos that are IPv4-only > - CA/CRL/OCSP that are IPv4-only > - VPN software that is unaware of IPv6, so client is split tunnel when > on a dual-stack network > - No IPv6 support in openssl (is there a better troubleshooting tool I > should use?) > - Mail is still a mess > - Bugs in home gateways > - Chicken-and-egg provisioning/OSS need to run IPv6, but routers and > firewalls have to run IPv6 to get to them. > > Sounds challenging. Twitter also does not work on ipv6-only. In my world, ipv6-only Android and iOS have been relatively painless and certainly achievable, and this experience has been repeated in other networks too. Rogers in Canada recently moved to ipv6-only iOS Going back to Jordi=E2=80=99s point, what does ipv6-only mean? Certainly A= ndroid and iOS have integrations with NAT64 that makes them work well on an ipv6-only access network. I once read Windows 10 has CLAT client, but i have never used it myself. So, maybe the draft needs to outline the obvious. Ipv6-only networks that want to provide consumer internet service need an integration point such as a B4 or a CLAT, which have both been deployed at scale for years, and thus have a body of knowlege to justify a bcp. Second, perhaps a seperate draft, outlines a catalog of services that require a B4 or CLAT and how to minimize their use. For me, i would be interested in hearing how the ipv6-only enterprise networks that have been trumpeted at FB, Cisco and Comcast are doing. We should avoid the fruitless dicsussion of how many ipv6 angels can dance on the head of an ipv4 pin. > - > > I've made it through most router configuration (I always have to tell > engineers that router-id is an integer not an IPv4 address; it sure looks > like an address; oh, and it has to be manually configured in an IPv6-only > network). > > That's all very operational; is that the sort of stuff you're thinking? I= f > so, I'll go ahead and start a draft and see who else wants to contribute. > Most of it is temporary (I hope) or related to other people not deploying= , > so I 'm not sure whether this is what you have in mind. > > Lee > > > On 08/17/2018 02:06 PM, Fred Baker wrote: > > Ron and I just had our bi-weekly phone call, and identified a topic that = might be interesting and useful. We'd like to invite a draft from people th= at are deploying IPv6-only networks or parts of networks identifying the pr= oblems they are experiencing that the IETF might be in a position to addres= s. The objective, as always, is to solve problems preventing such a deploym= ent in time for vendors and open source to provide solutions. > -------------------------------------------------------------------------= ------- > Victorious warriors win first and then go to war, > Defeated warriors go to war first and then seek to win. > Sun Tzu > > > > > _______________________________________________ > v6ops mailing listv6ops@ietf.orghttps://www.ietf.org/mailman/listinfo/v6o= ps > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --0000000000006706620573b730fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div><br></div><div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri,= Aug 17, 2018 at 11:24 AM Lee Howard <<a href=3D"mailto:lee@asgard.org">= lee@asgard.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" st= yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> =20 =20 =20 <div text=3D"#000000" bgcolor=3D"#FFFFFF"> Problems I've encountered (off the top of my head):<br> <ul> <li>Documentation assumes/uses IPv4</li> <li>Listeners only configured for IPv4</li> <li>Software repos that are IPv4-only</li> <li>CA/CRL/OCSP that are IPv4-only</li> <li>VPN software that is unaware of IPv6, so client is split tunnel when on a dual-stack network</li> <li>No IPv6 support in openssl (is there a better troubleshooting tool I should use?)</li> <li>Mail is still a mess</li> <li>Bugs in home gateways</li> <li>Chicken-and-egg provisioning/OSS need to run IPv6, but routers and firewalls have to run IPv6 to get to them.</li></ul></div></blo= ckquote><div dir=3D"auto"><br></div><div dir=3D"auto">Sounds challenging.= =C2=A0 Twitter also does not work on ipv6-only.=C2=A0</div><div dir=3D"auto= "><br></div><div dir=3D"auto">In my world, ipv6-only Android and iOS have b= een relatively painless and certainly achievable, and this experience has b= een repeated in other networks too. Rogers in Canada recently moved to ipv6= -only iOS</div><div dir=3D"auto"><br></div><div dir=3D"auto">Going back to = Jordi=E2=80=99s point, what does ipv6-only mean?=C2=A0 Certainly Android an= d iOS have integrations with NAT64 that makes them work well on an ipv6-onl= y access network.=C2=A0 I once read Windows 10 has CLAT client, but i have = never used it myself.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"au= to">So, maybe the draft needs to outline the obvious. Ipv6-only networks th= at want to provide consumer internet service need an integration point such= as a B4 or a CLAT, which have both been deployed at scale for years, and t= hus have a body of knowlege to justify a bcp. Second, perhaps a seperate dr= aft, outlines a catalog of services that require a B4 or CLAT and how to mi= nimize their use.=C2=A0 For me, i would be interested in hearing how the ip= v6-only enterprise networks that have been trumpeted at FB, Cisco and Comca= st are doing.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">We s= hould avoid the fruitless dicsussion of how many ipv6 angels can dance on t= he head of an ipv4 pin.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"= auto"><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e= x;border-left:1px #ccc solid;padding-left:1ex"><div text=3D"#000000" bgcolo= r=3D"#FFFFFF"><ul><li><br> </li> </ul> <p>I've made it through most router configuration (I always have to tell engineers that router-id is an integer not an IPv4 address; it sure looks like an address; oh, and it has to be manually configured in an IPv6-only network).</p> <p>That's all very operational; is that the sort of stuff you'r= e thinking? If so, I'll go ahead and start a draft and see who else wants to contribute. Most of it is temporary (I hope) or related to other people not deploying, so I 'm not sure whether this is what you have in mind. <br></p></div><div text=3D"#000000" bgcolor=3D= "#FFFFFF"><p> </p> Lee<br> <br> <br> <div class=3D"m_-2424208830044243082moz-cite-prefix">On 08/17/2018 02:0= 6 PM, Fred Baker wrote:<br> </div> <blockquote type=3D"cite"> <pre>Ron and I just had our bi-weekly phone call, and identified a to= pic that might be interesting and useful. We'd like to invite a draft f= rom people that are deploying IPv6-only networks or parts of networks ident= ifying the problems they are experiencing that the IETF might be in a posit= ion to address. The objective, as always, is to solve problems preventing s= uch a deployment in time for vendors and open source to provide solutions. ---------------------------------------------------------------------------= ----- Victorious warriors win first and then go to war, Defeated warriors go to war first and then seek to win. Sun Tzu </pre> <br> <fieldset class=3D"m_-2424208830044243082mimeAttachmentHeader"></fiel= dset> <br> <pre>_______________________________________________ v6ops mailing list <a class=3D"m_-2424208830044243082moz-txt-link-abbreviated" href=3D"mailto:= v6ops@ietf.org" target=3D"_blank">v6ops@ietf.org</a> <a class=3D"m_-2424208830044243082moz-txt-link-freetext" href=3D"https://ww= w.ietf.org/mailman/listinfo/v6ops" target=3D"_blank">https://www.ietf.org/m= ailman/listinfo/v6ops</a> </pre> </blockquote> <br> </div> _______________________________________________<br> v6ops mailing list<br> <a href=3D"mailto:v6ops@ietf.org" target=3D"_blank">v6ops@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/v6ops" rel=3D"noreferrer" = target=3D"_blank">https://www.ietf.org/mailman/listinfo/v6ops</a><br> </blockquote></div></div> --0000000000006706620573b730fd-- From nobody Sat Aug 18 15:02:07 2018 Return-Path: <fredbaker.ietf@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06CAE130F1D for <v6ops@ietfa.amsl.com>; Sat, 18 Aug 2018 15:01:34 -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 ZGvcpoMVNoE9 for <v6ops@ietfa.amsl.com>; Sat, 18 Aug 2018 15:01:32 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 7CF95130F18 for <v6ops@ietf.org>; Sat, 18 Aug 2018 15:01:32 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id b16-v6so19871402oic.9 for <v6ops@ietf.org>; Sat, 18 Aug 2018 15:01:32 -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=CKQANVSOELj72RrD3BXXBPmjg8TN5lIshud7JBCqSRY=; b=IdyW2aAvDGZuEByYBmRonPBh4Bw1nsx8N7gIo13U1xNgtrlc1tj2rpzP0IZQu2AKTG MI+zVHP+7S0FrGCSxL+n0M7jWrQWyUfnlyulwjvJA9oZLAmL47cEWjr3gUhuc7e/sTkG 4W738yWHr3w2SGuD2+G+5JANbh/7Qnioq+1/acs0pYrge8FplmMpbAghFTsRTmuwS27w WSL2PzCDTl6el98awWe7rzxxQHroLtKg9TFs2ajk+pIYQsVKEstarqFbLPbgUWn60f3G RugN8YFoEqwx5xIXpcAt4PTe7wadmT+5SRYACxI6mPUSAOldo4SWuwRMmtb08i6b8bjX ghag== 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=CKQANVSOELj72RrD3BXXBPmjg8TN5lIshud7JBCqSRY=; b=QKDFscf348lHoveWIIIB6sHqFOGfdtxPFMKelhQkJOB3N4LePbbPDGvZM0bxFBCDE/ 2C/P+iBcJTz4DS3wLIUXgNopCL7UHq2FJQPQTWV9iZqMPPPI8zs1++WrkajTbrojCl4L XGxUnitDZTK4SBqCJ4vfNo69DFPCe7wYCXxlQnAeMTlZkCDDghUQvv0484DW3tszOz7i 4O/ZnxaK473zqQP9QVa3RcgOog1ZdZ+XJBFBnEeouDiYsblEIX+U0YGUcnaFLQXwRbsp lD5UzYA6XQ39aIIjpvCC2RZJ5iXMTg32SmjEVeQOzhpeUegrom3fN/tPu3mSusjetTqY osGw== X-Gm-Message-State: AOUpUlGg1LyY8hYgR9mrVsB2uEpz5/aNgS99qL1w7KGrSvEUjluw8Ej/ yltjkSczbUYfg1jQyjPehffpttJV X-Google-Smtp-Source: AA+uWPxgmNDIPxs4b4XTcKUmh7f0zKPH/SKb+PDlaYRdsSm1sqQJmsfWvnbfYbuEA68sjNdhucl++g== X-Received: by 2002:aca:3882:: with SMTP id f124-v6mr8493823oia.195.1534629691866; Sat, 18 Aug 2018 15:01:31 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::104a? ([2600:8802:5600:1546::104a]) by smtp.gmail.com with ESMTPSA id x5-v6sm5633008oix.3.2018.08.18.15.01.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Aug 2018 15:01:31 -0700 (PDT) From: Fred Baker <fredbaker.ietf@gmail.com> Message-Id: <5F25D89E-4E3F-4F3E-B9F2-DC9F29291EA1@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_F59EBA3D-68F5-4E05-8C3C-E56797807DAB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sat, 18 Aug 2018 15:01:29 -0700 In-Reply-To: <a7fa01c8-f62a-4ec5-a7d2-8f116934efb0@asgard.org> Cc: v6ops@ietf.org To: Lee Howard <Lee@asgard.org> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <F4EA189B-20F1-4B9F-B9F8-E5FB74A70A0D@lists.zabbadoz.net> <0fffcc15-35e1-d9a0-5da0-0706f9fda0bc@gmail.com> <a7fa01c8-f62a-4ec5-a7d2-8f116934efb0@asgard.org> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/bM-TmudPoTzFnLiF3WXv7MuzKDQ> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 18 Aug 2018 22:01:34 -0000 --Apple-Mail=_F59EBA3D-68F5-4E05-8C3C-E56797807DAB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Aug 17, 2018, at 2:23 PM, Lee Howard <Lee@asgard.org> wrote: >=20 > If this is point-in-time advice that IPv6-only is frustrating for = $ListOfReasons, okay, I'll work on it. That seems like = operational/deployment advice, and is in charter. I don't think it has = much utility beyond a point in time, though. That's pretty much what we had in mind. That said, we have been wrong = before. --Apple-Mail=_F59EBA3D-68F5-4E05-8C3C-E56797807DAB 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+AFAlt4lzkACgkQEhdRnd2G P+CZTA//TAYb+y+37rtQ4h8BNct5eLtMpKBViUp/q5M902aBYr0Lg6Uhcg+OdxQI 49JmcWKrZmsIJt5cquxCfK4XTKmTaN6xjWloC8uLd9poWqQEaxOfqZcGhcq5nDjr ysIiySyWVbuXKE5vfVu6Mw+naClpwNxSdf4D6qJ9ULGJoKBiu5N31w4KZ2IDYZ7f vZ0vAkGYNJBqs42khsTc7k1iJgoQHuiVjF0estohe4A3Q+4tHsHFbX9E9WM+LT+a A+hWHeNxlZxvLdGi44/ek0+V+50aVGBGzuCzUujVHMVA4jJ9IMcuLtiiYhXwt83p ld1QNyqULO1rrc86qDV2uF/zaUBMS9fQeQdlAk2gz991UQ0YmpJHWtVAMhZ3PQNO HW51l15dNHJIk0yLMuX3+iOzo1E2x2QC46VsR1WCBJuyWDihSGZFC87NLFKNjDe3 OZfROADJVLzKlcRJ0vKNv5WcB73qsin/OkgSjU0IJixXAiicRxvMUow5M0YCb/b0 00ytet5Hd+YcQby7ULxG7gwGpvhZDAxCUv3AVt6pjig8LvgZbkoQLO6G1XVn7v6Y zHMiGfbMUBZLMc8v6IS3bQlh0BqG8Y2KDtENDkMjpSuSm06AUv95Xb8dEvHRZ0F3 gC/Qgrplpqhrwpp8F+U4FHi2XbbVUh88L4pBRGFg3PuFAu8D9Bw= =hudN -----END PGP SIGNATURE----- --Apple-Mail=_F59EBA3D-68F5-4E05-8C3C-E56797807DAB-- From nobody Sun Aug 19 07:22:12 2018 Return-Path: <bzeeb-lists@lists.zabbadoz.net> 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 B8567128CE4 for <v6ops@ietfa.amsl.com>; Sun, 19 Aug 2018 07:22:10 -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] 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 abEfvY70SDYq for <v6ops@ietfa.amsl.com>; Sun, 19 Aug 2018 07:22:09 -0700 (PDT) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFB47127598 for <v6ops@ietf.org>; Sun, 19 Aug 2018 07:22:08 -0700 (PDT) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id AA43725D3888; Sun, 19 Aug 2018 14:22:05 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id D37A4D1F83A; Sun, 19 Aug 2018 14:22:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id JWJlsTQDAOu7; Sun, 19 Aug 2018 14:22:03 +0000 (UTC) Received: from [192.168.124.1] (fresh-ayiya.sbone.de [IPv6:fde9:577b:c1a9:f001::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id E2BD1D1F833; Sun, 19 Aug 2018 14:22:02 +0000 (UTC) From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: "Ca By" <cb.list6@gmail.com> Cc: v6ops@ietf.org Date: Sun, 19 Aug 2018 14:22:01 +0000 X-Mailer: MailMate (2.0BETAr6116) Message-ID: <E345387F-6C1D-49D4-8B03-52D04498DDA5@lists.zabbadoz.net> In-Reply-To: <CAD6AjGQ_OBFGJb_C+mP_87nu7q_oXPrTvxhaV_=RcubeHtMy2Q@mail.gmail.com> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> <CAD6AjGQ_OBFGJb_C+mP_87nu7q_oXPrTvxhaV_=RcubeHtMy2Q@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/n5_sXyfhJefXZDGNQrVP1euOyr8> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 19 Aug 2018 14:22:11 -0000 On 18 Aug 2018, at 15:18, Ca By wrote: > So, maybe the draft needs to outline the obvious. Ipv6-only networks that > want to provide consumer internet service need an integration point such as > a B4 or a CLAT, which have both been deployed at scale for years, and thus > have a body of knowlege to justify a bcp. Second, perhaps a seperate draft, > outlines a catalog of services that require a B4 or CLAT and how to > minimize their use. But don’t we have enough RFCs on these topics already? > For me, i would be interested in hearing how the > ipv6-only enterprise networks that have been trumpeted at FB, Cisco and > Comcast are doing. Or Microsoft .. but these things are all discusses at other places. They have been and still are. Presentations are online, slides available to some degree. Look at the country and intl IPv6 conferences, the *NOGs, .. The IETF does not have to rehash all this, do we? From nobody Sun Aug 19 09:28:39 2018 Return-Path: <fredbaker.ietf@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0206130E71 for <v6ops@ietfa.amsl.com>; Sun, 19 Aug 2018 09:28:37 -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 L6X7NjtRZjEo for <v6ops@ietfa.amsl.com>; Sun, 19 Aug 2018 09:28:36 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3888130E51 for <v6ops@ietf.org>; Sun, 19 Aug 2018 09:28:35 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id b16-v6so21862468oic.9 for <v6ops@ietf.org>; Sun, 19 Aug 2018 09:28: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=VrxLgCnxdcidqZnAs9mN20AAWK+WclstHe/j6zNKScs=; b=V1GYAkUI6Q0go8BjHFNmznq8geatPaFISa6wouQdwoww9gEe0AwWNeIzanaHD1qC22 bdZoOpjDo16Qacaun+3ZIn5LZHVemPh0VSh4ZXlMZ9bbCH2kTRD8pD/jzBl/ojxD5KEj 5n6ptMJgpzrCW1S1TrtGGY3IOCzhae7hBAdi2ApcSbtOUlFdCw10h4boiBrH7iDQKcy/ T07VfQdguu9NYmXFiupf66dE1ssCm2yWQiwbjRVEZgjLFxtoLNRCb7FTRIHcEr5E2pYO JIrsftBAMosSCKnD6g9shlYpCW2fODAL5tqAyTleygntfjFa05pxd9PvUDkRN+K8D4tQ dMtA== 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=VrxLgCnxdcidqZnAs9mN20AAWK+WclstHe/j6zNKScs=; b=Ks8MsP0RID2G/lseh3moSMl1arP/7Vdg3UqOw4n+xEaXgI0bs+tYaY9Rv+/fuFK5BQ j+fwNRsUQ4Ng8SyndzffOjizNYSf4CDyF/pxrl12Roh6/dbuFReCcUXm+mX5P/aCKm1J F/FOlnqftruKKSUcqo84wyNN4qp+D3Zc2KOtpoHkj5+Js1EJPqdymYIKQq2/UMEgcWwe 4+nD5Qw9lWVvWMr8v4Gr+mrYiMd6Ox/6ts3k/7mXAk3nuT3ejJZnryZJJnwrKO9KcwLJ XDvBgdgShnEpWlTQMjDhxK5T5ACD0z85P3rnLoxhU6CmVtc56RIcAzNfIrpT2oiMHe5p vHFA== X-Gm-Message-State: AOUpUlHtB5LPs7UnG735OYnaFcHdieM2lE7vLsNAqJzWy5p3r0LE832n jniW1mlmATXiAPyIGXcZJjXWsxlb X-Google-Smtp-Source: AA+uWPzMxlLN/D/Atf04DRLbakaDHaBA5I3yi3kcp04MAasTv+FqpMKQ5cDa7WkLT5nggvijCUTZxw== X-Received: by 2002:aca:3ad4:: with SMTP id h203-v6mr10082392oia.294.1534696115237; Sun, 19 Aug 2018 09:28:35 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::104a? ([2600:8802:5600:1546::104a]) by smtp.gmail.com with ESMTPSA id s3-v6sm13003749oif.22.2018.08.19.09.28.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Aug 2018 09:28:34 -0700 (PDT) From: Fred Baker <fredbaker.ietf@gmail.com> Message-Id: <87CD2261-3226-47FA-BE60-ED0924B68A07@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_8B156569-8DF1-4A84-BBE3-72D752DB4D7E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sun, 19 Aug 2018 09:28:31 -0700 In-Reply-To: <3BE77332-B5FA-48F3-B881-45F60DA6643B@consulintel.es> Cc: "v6ops@ietf.org list" <v6ops@ietf.org> To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <3BE77332-B5FA-48F3-B881-45F60DA6643B@consulintel.es> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/D0kYbxklZ6Mx9xmPnIydGvejm2M> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 19 Aug 2018 16:28:38 -0000 --Apple-Mail=_8B156569-8DF1-4A84-BBE3-72D752DB4D7E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think this is something the draft might discuss. To me, "IPv6-only" = means that the object in question is using only IPv6. If it's an = application, it doesn't have or can't use anything else. If it's a host, = it doesn't have an IPv4 address, whether it can use one or not. If it's = a network, only IPv6 is deployed in it. At whatever scale is under = discussion, IPv4 is not a factor and IPv6 has replaced it. Making it more complicated than that doesn't help, IMHO. > On Aug 17, 2018, at 6:09 PM, JORDI PALET MARTINEZ = <jordi.palet@consulintel.es> wrote: >=20 > Hi Fred, >=20 > I will be happy to join, but first I think we need to clarify what is = IPv6-only in the scope of this document/work ... >=20 > Are we talking about a network that in the "customer" LANs doesn't = have ANY IPv4 and never connects to any "IPv4-only remote site". >=20 > Are the access links IPv6-only ? Or the LANs are IPv6 only, but the = access links are dual-stack? >=20 > Or the LAN's don't have IPv4, but apps, running IPv6 can connect to = remote "IPv4-only sites" (so the network or the access provider) has a = NAT64 or equivalent mechanism? >=20 > I recall we tried to clarify this definition in a previous document, = and I still see everybody reading different things ... >=20 > Regards, > Jordi >=20 >=20 >=20 > =EF=BB=BF-----Mensaje original----- > De: v6ops <v6ops-bounces@ietf.org> en nombre de Fred Baker = <fredbaker.ietf@gmail.com> > Fecha: viernes, 17 de agosto de 2018, 13:06 > Para: "v6ops@ietf.org list" <v6ops@ietf.org> > Asunto: [v6ops] Thinking about problems in IPv6-only networks >=20 > Ron and I just had our bi-weekly phone call, and identified a topic = that might be interesting and useful. We'd like to invite a draft from = people that are deploying IPv6-only networks or parts of networks = identifying the problems they are experiencing that the IETF might be in = a position to address. The objective, as always, is to solve problems = preventing such a deployment in time for vendors and open source to = provide solutions. > = --------------------------------------------------------------------------= ------ > Victorious warriors win first and then go to war, > Defeated warriors go to war first and then seek to win. > Sun Tzu >=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 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. >=20 >=20 >=20 = --------------------------------------------------------------------------= ------ The fact that there is a highway to hell and a stairway to heaven is an = interesting comment on projected traffic volume... --Apple-Mail=_8B156569-8DF1-4A84-BBE3-72D752DB4D7E 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+AFAlt5mq8ACgkQEhdRnd2G P+COWw//cx3vyvA+V9aGlAtVE9OkzcpQvePXx/Pj9DDJ78HMW11s3HteS2P5sPQL d1pHr+s1a2YLcENCLrfO67eKcevEI1iThSwsID2IuifgcaI5WtQS8vdaJ96puaPN Itq0Mz5xNFqBjw5n0lOExMzDfVZr/Dhe5h69fgLRQ3Kan1xwPcPIpJoeQ9Qq1k/v oG146okoANvIyRF02GcJycmPPPb7lJSsyKNJ522GEZ+lm03mhuRXPycsxBeGS+KI WtJsVOCEnkdzsxhyHJaxDcr5/D+ubyOmQbIe4c3SacJgJz2v9agQFZ1MUmnEx5F2 EB5Dv1pPNt+r6S8NAUy8oZ64efyxFR2zqCDTO81zEYFvHwT/z42WIyWmAZ21RmwP +QPkC/YcaE3gqTUurG7qt4kqMKsMHhu9dSsOdG/hAxzyEr3rjPJV7cN9zdRZf+Gt KuZaUJRyRS7DcTukRVzgzD2VDlw9C9BV6sUjejgna0oSR6NN8tExZrnD1t5zjyV1 d6IdMNFw+HoQeOzJnV/3z6Y3VRMcWBWU+gf3aibQ9Q/7DiduBb5z01567xNhyT0j 6QstZezvKyB81QJFjp/EsIqQoISARGO8MRTFzvIaUXiC3kKNbLdTt34EwULK1bxQ yKGoazhbe1tqafa0N62AhYMT+ZxTRMvXLnDV5/3Lg43I02t2lnM= =3D/s -----END PGP SIGNATURE----- --Apple-Mail=_8B156569-8DF1-4A84-BBE3-72D752DB4D7E-- From nobody Sun Aug 19 13:00:32 2018 Return-Path: <fredbaker.ietf@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C7D130DD4 for <v6ops@ietfa.amsl.com>; Sun, 19 Aug 2018 13:00:31 -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 x8aYShrpEMcg for <v6ops@ietfa.amsl.com>; Sun, 19 Aug 2018 13:00:30 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::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 53638130DC9 for <v6ops@ietf.org>; Sun, 19 Aug 2018 13:00:30 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id j205-v6so22344623oib.4 for <v6ops@ietf.org>; Sun, 19 Aug 2018 13:00:30 -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=Erm7xHYxTSMIjOk/jjv9vremDINyog6aoiGhEmQzXbY=; b=OD8wqDD6XDTJ0qcAmiVbH+zQZ93u7SCnHAD/dYQlyS0soPRhxZX8tR5D9l94yu4UiZ Xx+WQDpbQoyd7qoZxYJOWoc98AWeKlmPbSyERO9TBQaeyWC8c2wVR31RSziTKxnR1cdN UDbUhz86gf5xfxlCMKDSXYFF/z+QCEVJJQs6HpVa+220YXAL/HFtSYVB/lDXNrJ43Yt4 yj0CNp/di+926Lwb8eBq0E6QY/Ejp1ju4cRG8o3E6iDvIWrk9j8JCD8NetLGlivyPQq2 VPFpYqNqAripKUVQMrqpg4CLBNJcDX+ow5SPsJcs8YEGgfwp04Ep7Vw/OTz/DeCvHzn8 SyLg== 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=Erm7xHYxTSMIjOk/jjv9vremDINyog6aoiGhEmQzXbY=; b=nzIaAAg3AT8fMBNzV0vX3jtVPfvpmHXh9lWVAnB1Ew7YcX7Nl5CJ0/lqfZwnZFXtJt Dx/Ws46GcwUQjrx6nVl0pBGE9y91HBGmYtsa5L0ROBlQOoREBTIPhNsSpKY2PhqBiLGa D8eS16rhIUs0J5o+CxICf0fnK2kW1tx7Kt5eqDthXyJA3ZiDkSfFaHP+GhWFcm6rj2E6 OYe3I8EJ0/OctH+jSClU7RG+V+DsEuKT6M0mSqsYi1Nc2C1BH3tdB/p0XEQ0ZrLyCRJ0 yrV3J1z3ZPsIFmVGNp3OfurM15ZoQZJanTGTTAAvWTzTVA67oGX+wcQKnEKPfbXlSzwD 6yZA== X-Gm-Message-State: AOUpUlEVfRsYZJcs4mkmf8tOHCNNlTpTI/xDoUeO7jcb6pX0C/vvOPFs m5lK7G36Y1heWfqq8ChIwFy6FSFq X-Google-Smtp-Source: ANB0Vdblq/mYiqH3xDTGM5oLFDWMinOP7kLns/2Mwt4WzB8YLWIwuGhUoo23dzOoW2GM7keK9YM3fQ== X-Received: by 2002:aca:4ac6:: with SMTP id x189-v6mr11677890oia.211.1534708829584; Sun, 19 Aug 2018 13:00:29 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::104a? ([2600:8802:5600:1546::104a]) by smtp.gmail.com with ESMTPSA id o125-v6sm14131610oig.44.2018.08.19.13.00.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Aug 2018 13:00:28 -0700 (PDT) From: Fred Baker <fredbaker.ietf@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_4C81637F-F986-48B1-9F42-D2EAFBC3EAEB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Sun, 19 Aug 2018 13:00:26 -0700 Message-Id: <9A50FB3F-319E-46FB-9396-BA775189C34B@gmail.com> To: "v6ops@ietf.org list" <v6ops@ietf.org> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/JXrMq00N2D7tHA0ZFLD3xOaFQXU> Subject: [v6ops] WGLC for draft-ietf-v6ops-transition-ipv4aas X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Sun, 19 Aug 2018 20:00:32 -0000 --Apple-Mail=_4C81637F-F986-48B1-9F42-D2EAFBC3EAEB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is to initiate a two week WGLC on = draft-ietf-v6ops-transition-ipv4aas-08.txt. There has been quite a bit = of discussion recently, and the author thinks the issues have settled = out. So the question is: are we done? Are there remaining issues? Where = does this draft stand? --Apple-Mail=_4C81637F-F986-48B1-9F42-D2EAFBC3EAEB 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+AFAlt5zFoACgkQEhdRnd2G P+A+wBAAwisrecCugp/DmhhRzbst+1ud8fy5Aoe4ud+NRD4lQElQUyPaYWPdQ9Cq MEw6kmLci4xJyjUE9iXyw7BGZSeCilju6hIBsC7jvD8KDl0T0ykZ3WJo4hAp0Luh Av/1WBZZ57TQPLjZJxIcsk6tBodY6xYOkKYuh2sGw/o/emYC2BXqGFGZOFsq7fjA b45OlyKFSwOr0bEWD3G9DamOKBfuHV+jORPKhFm+YYcM3fbrV56o2CdjRRSO1QFL urHhLpl4b5Zn2nqufziRCcCQzsFeVKsh9SWfH8ln7500sEZQ2KQrc8aP1wYVGqCw l3wxwx2MLE0DpLb61XBxx4QmgBJ/l3wsPG2P6vYbd1zxyHXSBDKZvsZOBZ8xwIGW afEdzCEfJJRxRPY/8AvlMQWGoA6eeHrnnsp2WN2HWWOogtv9hp9ce6YUCAo3Xxt5 1d827UcUviinHkfWZJwKAK7IWd1wdD8YdqMqKLKhrE7WGPuW+5kF6RwrAs8fjwHA RatVksqFUKTmXq652rCSqD5UUiRy7aUGJ2wZywG48NRpZasMG5bzEL2RlelOumDj TXAtBoIDvOPrFeZwGTWWCbxRABiKbLBH2p1wTI6R3RLWV1ttVkgqlY+wYGpBUjVS ziy/rN5u2t/FWJXEa+zVtzSsPJP6/X7TXFOmbzs5oO+bgYEle1c= =HVZ/ -----END PGP SIGNATURE----- --Apple-Mail=_4C81637F-F986-48B1-9F42-D2EAFBC3EAEB-- From nobody Sun Aug 19 22:48:49 2018 Return-Path: <furry13@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3710F130DE9; Sun, 19 Aug 2018 22:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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] 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 BBBL1MfSTJwW; Sun, 19 Aug 2018 22:48:39 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 B24C9130E79; Sun, 19 Aug 2018 22:48:38 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id c21-v6so166495lfh.3; Sun, 19 Aug 2018 22:48:38 -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:content-transfer-encoding; bh=uaoC9UZFxhiJUiFR5iT3PDXzu240J9woyLtqjOTwXsE=; b=SYIGhxiHgKYyuOw2Bj0dckQH/Vw7DWzykoyBj2VAjIs2IETe2qDK+1arvXAGMbatsz HA8RmwY3aciKBncwHDdwQDleBS+oOLDSVbgynlY4xm4UZ9QyHScxxAw8jxx4qHkzyU2G pnXKmuuPkTZcTjDI8pS70t7aX6AHY315JdcWadHBuyCuwc23iJr3Lv5y1AY7qOp3HziG a/8llnu3AHZwfaCYm8kg1l6Eqr52gTnK2nZTXRqd4b+ckcM6QTQiFYggz2MC8jxVlEkQ 5lRMeLgjRqyav9A4AfcqZ7DTqFYRPS0kJxMegUVUFVdt8HI4sCbJ79eZ/kXtyGWWXEsn AyQw== 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:content-transfer-encoding; bh=uaoC9UZFxhiJUiFR5iT3PDXzu240J9woyLtqjOTwXsE=; b=jQ701ouCi68QUDuUTbB56SJIxu+8FJbqxQwW0R0EOSqk76T7LW7aizcU7L5/udDNcg 97WJE6dZ4yevR+eEdqqOx0J2EynYcgO8cB+phO/m84Agr6IOPKPm65P9wcLfvfSv2Mpg McsAhPQplgkRMuFMOkZYkCbYt8ims0ye3py1duPwbnthWw+tN0QZ0ZnyYIT+BsF4CR1q yPtb3LSdHxE5bmiEBJb6QNtNo1yimUi066+7FNWgB9q/PtvqxkEfmA/jN9F0HBjTPe2U USLA8S26VbsLhHHFMBG4etzEGvatVjzJAlUXNY+IVvRuCrWHagPG98dqcn9KWTJflt7/ Q42A== X-Gm-Message-State: AOUpUlEf+P7pf97X8kAfYjRPWwhQ17zxh2adnPU95TjVYXLwoZ7233TY fXbMyLeLuj/yACdIO/4gh9mjPxfrfEYw7BQc+X+dLn3w X-Google-Smtp-Source: AA+uWPxNuwObbfUIS9GQRkhfYUMKhruPbsMkDUdX3xODzQKt7Yfo1f3QGeoJqN4AHgxTlbytcna2N2xa6X7ygsRxv8k= X-Received: by 2002:a19:5410:: with SMTP id i16-v6mr7097282lfb.122.1534744116647; Sun, 19 Aug 2018 22:48:36 -0700 (PDT) MIME-Version: 1.0 References: <153321790308.2265.731201835682425291.idtracker@ietfa.amsl.com> <CAFU7BAQVqWajKtnsAZ4Ys52BZS7hkoD2E0vmB-Dg=+pYndxCMQ@mail.gmail.com> <CAJE_bqeEUKWBA1St3du0aJ=KQJenj-j0XGXwiPQGk9CZJN24Gg@mail.gmail.com> In-Reply-To: <CAJE_bqeEUKWBA1St3du0aJ=KQJenj-j0XGXwiPQGk9CZJN24Gg@mail.gmail.com> From: Jen Linkova <furry13@gmail.com> Date: Mon, 20 Aug 2018 15:48:23 +1000 Message-ID: <CAFU7BARASt=sx9gFASe6HMs8fk3_mDkKekhEmVNrZXBDJYs8Pg@mail.gmail.com> To: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp> Cc: Suresh Krishnan <suresh@kaloom.com>, Russ White <russ@riw.us>, draft-ietf-v6ops-conditional-ras@ietf.org, V6 Ops List <v6ops@ietf.org>, v6ops-chairs@ietf.org, The IESG <iesg@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/QNvavE7BTUxRl3Z-D6auVBAubkw> Subject: Re: [v6ops] Suresh Krishnan's Yes on draft-ietf-v6ops-conditional-ras-06: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 20 Aug 2018 05:48:40 -0000 Hi Jinmei-san, On Sat, Aug 11, 2018 at 3:28 AM =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinme= i@wide.ad.jp> wrote: > > I've added a paragraph clarifying that we only modify preferred > > lifetime and that RFC4862 does not > > allow an RA with both preferred and valid lifetime for the prefix set > > to 0 to invalidate the address completely: > To be very accurate, it's still allowed if the RA is authenticated: Oops, that's what happens when I'm trying to submit a new version in hurry, just a few hours before disappearing for vacation...;( Yes, you are absolutely right...Thanks for pointing this out! I was going to add that text but forgot :( The draft meant to say "Actually it would not even be possible for unauthenticated RAs (which is the most common deployment scenario) as Section 5.5.3 of [RFC4862] prevents hosts from setting valid lifetime for addresses to zero unless RAs are authenticated." instead of "Actually it would not even be possible as Section 5.5.3 of [RFC4862] prevents hosts from setting valid lifetime for addresses to zero." > (whether v6ops-conditional-ras should be this accurate is a different > question, for which I don't have a strong opinion) Well, I believe it should make the correct statement, so I'll update the te= xt! --=20 SY, Jen Linkova aka Furry From nobody Sun Aug 19 23:48:34 2018 Return-Path: <furry13@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D0C130EE9 for <v6ops@ietfa.amsl.com>; Sun, 19 Aug 2018 23:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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] 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 1crDnxNPrJol for <v6ops@ietfa.amsl.com>; Sun, 19 Aug 2018 23:48:30 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 A2F04130EE5 for <v6ops@ietf.org>; Sun, 19 Aug 2018 23:48:29 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id v22-v6so10068163lfe.8 for <v6ops@ietf.org>; Sun, 19 Aug 2018 23:48:29 -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:content-transfer-encoding; bh=ksu83FpwFr5IQsULlziF+dqU3iUX6iR9P564FowvgtI=; b=dCxIdy7O2H3ucNZzjQeyUPgkAmpZHGAbbiqQZV+p1KxZ/brF9PUBDQi5cCZ7HLZKbN UMd42qjX3Ao0ddfVuDWCJ3kXorMl2ANH4Id5ZJVXKfll4Mu07qFiowYATURiQRJVs5zi GPGuN0wIvOq5jFlmA0iQACS5JR7ozkDraQxtplS+NifVRrJVSjDG02Vmi+fBfTLIyVFg JxSucf52oH28KEyGZ/bny8ch1k5hSrURJTkcZdpJWxoypzNLCgm0N+a8ARq6xCi+sW5h 43P/LiNvUWdk72hLeqRM/SBnnnipUX7DjslxxKgEUOJi3cSNZ8i7WVqKTO+G8UCnu5hR 1bdA== 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:content-transfer-encoding; bh=ksu83FpwFr5IQsULlziF+dqU3iUX6iR9P564FowvgtI=; b=TGrIbA2MjvzrnwH9e3ww6doma0dqP84RhiQyS33KwaVVZj9DX5CpNHLgN9gbUzyr+t ow5Ti7IiG5Ijo/26ut49Le3quVK2Z+PXB3w/UOylI/UVfx/cu1jCTlFRPtr/9K1eSkY8 gW6Se/uebuf4Wy+qWK8LEzlIdG2U3Dj1OqKeUvYXxx83VdAH/sFZLo0FgVO0gO7zkzyt nbhzz6Nhtf6rUnK9VXthLSnsAPkyrHs5xJCU4IhjT1GfkHICQkU8oaaTcjSDK7Xd+sAs BVKkA8elr+3COcN5wkpqps3nez/arR+q+yztjBSnmFAMRTu/HUeK5TKGppJp9rZe7vBx W5BA== X-Gm-Message-State: AOUpUlFHrORgoldYUkRYaf1ctH6m8XzK2Exe9IRWm84+5QDk9j7uRT4c z6gDfVDh4NFjXn/WtxLducQj2kmXiqJ0uUL1LDs= X-Google-Smtp-Source: AA+uWPz5+5pkQmsEHTlPq+fxPVi5788JbE8fCwMV+ti0JvCMznSJ9LQ7VPywqeOYdrZIViVzM9M81FTt0WC0juvhoOc= X-Received: by 2002:a19:5410:: with SMTP id i16-v6mr7251259lfb.122.1534747707776; Sun, 19 Aug 2018 23:48:27 -0700 (PDT) MIME-Version: 1.0 References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <3BE77332-B5FA-48F3-B881-45F60DA6643B@consulintel.es> In-Reply-To: <3BE77332-B5FA-48F3-B881-45F60DA6643B@consulintel.es> From: Jen Linkova <furry13@gmail.com> Date: Mon, 20 Aug 2018 16:48:15 +1000 Message-ID: <CAFU7BAQ-evhj+SJAZAmC9MwC_HDAq6nmN_Xym+Lu5bKF6KEkjw@mail.gmail.com> To: jordi.palet=40consulintel.es@dmarc.ietf.org Cc: Fred Baker <fredbaker.ietf@gmail.com>, V6 Ops List <v6ops@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/cw8vvV7GzblSMnp95d_ISKnikvA> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 20 Aug 2018 06:48:32 -0000 On Sat, Aug 18, 2018 at 11:10 AM JORDI PALET MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> wrote: > I will be happy to join, but first I think we need to clarify what is IPv= 6-only in the scope of this document/work ... > > Are we talking about a network that in the "customer" LANs doesn't have A= NY IPv4 and never connects to any "IPv4-only remote site". > > Are the access links IPv6-only ? Or the LANs are IPv6 only, but the acces= s links are dual-stack? I'd read 'IPv6-only network' as a network which only carries IPv6 packets. So if you are saying 'IPv6-only LAN' I'd expect the LAN in question do not have any IPv4 addresses assigned (ex. IPv4 link-local). If you are saying 'IPv6-only backbone' I'd assume that routers have only IPv6 addresses. Obviously such a network might be connected to other IPv4-only or dual-stack networks. Examples: IPv6-only LAN can be connected to dual-stack backbone or ISP. I suspect that confusion is caused by the fact that sometimes we called a network 'IPv6-only' when only part of that network is actually IPv6-only (e.g. instead of saying 'ISP X is deploying IPv6-only network' we might want to say 'ISP X is deploying IPV6-only backbone/access network'. > Or the LAN's don't have IPv4, but apps, running IPv6 can connect to remot= e "IPv4-only sites" (so the network or the access provider) has a NAT64 or = equivalent mechanism? I do not believe we need to tie the IP level network capabilities with what applications can or can not do. DNS64, NAT64 and other mechanisms are add-ons to an IPv6 network allowing devices to access IPv4 destinations, *if needed*. It's quite possible that devices do not need such access at all, or only some devices on such network need it. > =EF=BB=BF-----Mensaje original----- > De: v6ops <v6ops-bounces@ietf.org> en nombre de Fred Baker <fredbaker.iet= f@gmail.com> > Fecha: viernes, 17 de agosto de 2018, 13:06 > Para: "v6ops@ietf.org list" <v6ops@ietf.org> > Asunto: [v6ops] Thinking about problems in IPv6-only networks > > Ron and I just had our bi-weekly phone call, and identified a topic t= hat might be interesting and useful. We'd like to invite a draft from peopl= e that are deploying IPv6-only networks or parts of networks identifying th= e problems they are experiencing that the IETF might be in a position to ad= dress. The objective, as always, is to solve problems preventing such a dep= loyment in time for vendors and open source to provide solutions. > ---------------------------------------------------------------------= ----------- > Victorious warriors win first and then go to war, > Defeated warriors go to war first and then seek to win. > Sun Tzu > > _______________________________________________ > 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 --=20 SY, Jen Linkova aka Furry From nobody Sun Aug 19 23:54:55 2018 Return-Path: <furry13@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94331130EEA for <v6ops@ietfa.amsl.com>; Sun, 19 Aug 2018 23:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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] 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 PQ4tYCxBtYmr for <v6ops@ietfa.amsl.com>; Sun, 19 Aug 2018 23:54:52 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::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 F08B2130EAE for <v6ops@ietf.org>; Sun, 19 Aug 2018 23:54:51 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id u7-v6so10732280lji.3 for <v6ops@ietf.org>; Sun, 19 Aug 2018 23:54:51 -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:content-transfer-encoding; bh=cyBWDoyZ7Txw6sLYR44rx7jqgnUOndo+BjQIRpdcZO8=; b=hqNOddou1VcdwUEMDJL3TBsJtpOXrrMTED9yQLAyPXgiNn8d9SwMfyCwH3edDKPDXL WHplG816B1cHL30v+vOZ+V7GZn976DKULnsmW0ldOcN13/HZ2gb6Aex7gr2+AS/KuMwr FHprga+zMgcoKxLpE4+kMbuDFaD/58/BWx7N2t1lsvsIS0BOs3dCsmSkB16UzETDpFWg JLTWdWtirlo0oChllaWtuibUSodXRxciSEyXsR6U4n+vvmbN0Q7JaPr8u99rClInlZ1k RuUXBJ2B10PaBDPPAvGr7jug8RiOkQFCH+5VDTnVfpsILhfimob72tWnZwXr/9L/vZei RQYQ== 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:content-transfer-encoding; bh=cyBWDoyZ7Txw6sLYR44rx7jqgnUOndo+BjQIRpdcZO8=; b=d24qgaq4oyEtaeYr5kgpXZQJnymFG8Rwvpvfg4x91NwHPwtt00yTD0PPgGiDcVZypc qJFLZSuIx3jzs4KsDmp7BmRtWxOOz22i3umA0JTS6IaVFzKTCw4T8jZIsxsRdFu+1aWX t6fYa348f3QoT/EEv5zDVqVZNgeyn80zoL42h56BTFlJMDPNkWR0aj91mWke2CRVWWvb /EqwjVhow7aLp5Sh95GonLIT9Dwn/Fzdi13BSsA0HZ+h8aduuEiqLmSiWtzxUzwD4yfb NEWrq3uGIrzmFRsQzuXmLFD0K8o3xeEuYMtO/hH77ClNvuKGmstVDi7pfhZwVkAE1bN4 A6bw== X-Gm-Message-State: AOUpUlHTQALBdY4P5KmfaXs3aF8wJR1lyXDAlkTIe/9oYGJbGoxTHcGd dVpBuyEFEf7cwuTTiNvpfnxCM948xmzwfCXpfd6PuepO X-Google-Smtp-Source: AA+uWPyLSDlTehCjYfsvPNkeUHpsAx5Fc5btOwDTPnlGFm3rL1XQ7rBZhinRHMYVWTDCiT7VahLLhq/4/H85c+rbOuU= X-Received: by 2002:a2e:8743:: with SMTP id q3-v6mr13638644ljj.139.1534748090186; Sun, 19 Aug 2018 23:54:50 -0700 (PDT) MIME-Version: 1.0 References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> In-Reply-To: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> From: Jen Linkova <furry13@gmail.com> Date: Mon, 20 Aug 2018 16:54:37 +1000 Message-ID: <CAFU7BASXTSjGUe9BvaoumCXHzE8FWoNb_Ap=LM-KdNccrNku8w@mail.gmail.com> To: Fred Baker <fredbaker.ietf@gmail.com> Cc: V6 Ops List <v6ops@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/fwuXVZKENtsO7gYOxrLjI6Dzsm8> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 20 Aug 2018 06:54:54 -0000 On Sat, Aug 18, 2018 at 4:06 AM Fred Baker <fredbaker.ietf@gmail.com> wrote= : > > Ron and I just had our bi-weekly phone call, and identified a topic that = might be interesting and useful. We'd like to invite a draft from people th= at are deploying IPv6-only networks or parts of networks identifying the pr= oblems they are experiencing that the IETF might be in a position to addres= s. *A* draft? ;) Or multiple drafts? I'm not convinced that all problems need to go to one draft because they might be of completely different nature. -- SY, Jen Linkova aka Furry From nobody Mon Aug 20 08:46:37 2018 Return-Path: <rbonica@juniper.net> 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 4A6AF130DC2 for <v6ops@ietfa.amsl.com>; Mon, 20 Aug 2018 08:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] 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 XGxTDGsfRB2j for <v6ops@ietfa.amsl.com>; Mon, 20 Aug 2018 08:46:33 -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 53F76130E61 for <v6ops@ietf.org>; Mon, 20 Aug 2018 08:46:33 -0700 (PDT) Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w7KFhvEW008698 for <v6ops@ietf.org>; Mon, 20 Aug 2018 08:46:33 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=HW39t95JFItaqq3wcGMUrREtmTLZf6UCvb3DkpAcAaQ=; b=BYqv2ATEfgAnVFTvcwAfitt1Lho6whmXablzNzkbLGT7A7WitlIUad6MxH69I8Gzrlov oXuMpVMeZZ4Nl98uP4onjor4x+ttRkQl6cOhJ8/JTf/eIZG3xqHwjtSi9yyFw46p5ZFC 9caDjmqkwjeMFC8JHk4JBk9AezQ4cijoaRdlthwxwf9CHHCtVegOd+QO5GeYK36Vc2Ci 0kW32j2V8PrmCL+J3+rTWAbRqxnShwBIadSfDdY2py8as43fGVHepO3X31ApTCVCasRJ p8+98ZtPQWeyKIPFW8uCGZv0c2qODp0Ea2grn/fZzyMAdseA7WcCNkpvScPJMOyIslln Dw== Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp0183.outbound.protection.outlook.com [216.32.181.183]) by mx0a-00273201.pphosted.com with ESMTP id 2kxf5pu5hr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for <v6ops@ietf.org>; Mon, 20 Aug 2018 08:46:33 -0700 Received: from CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) by CO1PR05MB409.namprd05.prod.outlook.com (10.141.74.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.1059.20; Mon, 20 Aug 2018 15:46:30 +0000 Received: from CO1PR05MB443.namprd05.prod.outlook.com ([fe80::7de8:5a5d:b33e:cc4]) by CO1PR05MB443.namprd05.prod.outlook.com ([fe80::7de8:5a5d:b33e:cc4%13]) with mapi id 15.20.1059.023; Mon, 20 Aug 2018 15:46:30 +0000 From: Ron Bonica <rbonica@juniper.net> To: "v6ops@ietf.org" <v6ops@ietf.org> Thread-Topic: draft-palet-v6ops-p2p-links Thread-Index: AdQ4nOeCySo3DBY1THGj3udxkHm8XQ== Date: Mon, 20 Aug 2018 15:46:29 +0000 Message-ID: <CO1PR05MB44306922CFFF446DEB0FFE5AE320@CO1PR05MB443.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO1PR05MB409; 6:QMZVyCjBucUkwDEM4eEaAm0lbLIWTvPJwu25klEcFvIYcSKs9rgjTVy8EIbIF1fX3Q3ngiEzTiOP1+IaNiqgob6Khpzb2D36ecDH8HDBJyVK/BO1QR8LvhRqBpZWOT5L7Xx2ZdyObJjh/j33LjyBl1DoG0Hs/tXArnYhfD4t1H2A7bDrwy7CUpp9aHxYpwAzTfCr5QgthVADlj21SXbcNFbTrEyqctxSESAthWzbk+Jobwh61o3fdSgXv/YJODC+kN52J/y2WcjLHx2vSsruxqM8ASYWM6Y0Ceb0qA93OyElvyRTDgnnN0n86iRmDhYOG2DAgCk7ENQAYWKX5kEuFrTViUGusSoRkWeWTcAIDoaYZYfaHen5S0Yf8jL4JxgCq/nI01VVub44dd3a1BKswGKxam2W3mCtmnxTBTcD9bkzqVXuuVpepD1DtqbRlJT79sqQosaPtuVlhi7+hR6RfA==; 5:Fz0yj9fdeFID8G7XOKqL8GniPJi82UpM29+Rgt0rZLjjmcJa4/Zcf3nkO9C2UgrCWgRFzHyBFlBxZIGQi6idCCfNm7NKdqcg8EArYN96lnw8vJj2TZMn2X/63bjXkxNd98nWBTX+DUYNUDtXdGeGQh7K/3yxzRmyKTSzbJGtozY=; 7:dWBTiO4zTNAebfQKUe1YPDnf+9vtUCD7y1Laa9SW2yIzA/6WsRuCKuhBuRtH4SzcKytUC0+QyeMuXpvedDqQCHMl612iOV9O5ovsbrB7qmxm8TZwMKaclhM4AsuTuVZsLaEdj+0jcMoWDHz7IOi3E5e7SKnbULgzPxu1tAxA2ij5rfoqnBpxErKs5mKWaaWDWI1C356P6SdOn6DT2hm6W6pBundJzLSOS4A4DVEUXtqsHA+425GI/csYDqCk4mg1 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 247a40e2-2507-476e-3bf7-08d606b418f0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(5600074)(711020)(4618075)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:CO1PR05MB409; x-ms-traffictypediagnostic: CO1PR05MB409: x-microsoft-antispam-prvs: <CO1PR05MB409DA293F4F4139C6A2489CAE320@CO1PR05MB409.namprd05.prod.outlook.com> 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)(8121501046)(5005006)(3231311)(944501410)(52105095)(10201501046)(93006095)(93001095)(3002001)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201708071742011)(7699016); SRVR:CO1PR05MB409; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB409; x-forefront-prvs: 0770F75EA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(39860400002)(376002)(396003)(346002)(189003)(199004)(256004)(478600001)(14454004)(8676002)(558084003)(26005)(5250100002)(81156014)(2501003)(105586002)(102836004)(97736004)(7736002)(74316002)(2900100001)(316002)(7696005)(33656002)(66066001)(99286004)(305945005)(8936002)(486006)(6116002)(476003)(86362001)(5660300001)(3846002)(2906002)(6916009)(186003)(55016002)(5640700003)(53936002)(81166006)(9686003)(6436002)(25786009)(2351001)(6506007)(68736007)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB409; H:CO1PR05MB443.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: fPkKsyAONyz/q0isuv7WHIUTXxf1f3/tXPEP8BIzIJgtc++grtRSqbPZ0oCO6gEV7SVIoC9btEQaF/w4yD46NR59Bn1Kxtn4eeR03rEx1yhVixd1CpOK6bl3bCTuyV19ihScM2jle11P5BwuSsoS/n2ew9FHmaqpERjLbKERgwFY2bXI+64QCWHuh48Iyman/IVF0RHtDUFKQqvf4Z+DyMjgyhBXBJr8PkIut5psGReq02X8bz7Vvx1XR7go8AdaDmgrjSnhVPso6yEQDSKAUkvk9LlJUsQHYmPfYRmnahwHDzwBUAAYEGX6et/2d0R27rogfkGG1HtgIXJLjHfnuLDF8aRfyy2TtSs9UwRxOOg= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 247a40e2-2507-476e-3bf7-08d606b418f0 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2018 15:46:29.8968 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB409 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-20_05:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=482 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808200168 Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/DK3ieiRq5fCHVUu_ekbqpnsWI0Q> Subject: [v6ops] draft-palet-v6ops-p2p-links X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 20 Aug 2018 15:46:36 -0000 Folks, Each week between now and IETF 103, we will review and discuss one draft wi= th an eye towards progressing it. This week, please review and comment on draft-palet-v6ops-p2p-links. Fred and Ron From nobody Mon Aug 20 09:07:36 2018 Return-Path: <Fred.L.Templin@boeing.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B99130934 for <v6ops@ietfa.amsl.com>; Mon, 20 Aug 2018 09:07:35 -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 Wok4KQ2jhdMa for <v6ops@ietfa.amsl.com>; Mon, 20 Aug 2018 09:07:32 -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 AEA6A130E46 for <v6ops@ietf.org>; Mon, 20 Aug 2018 09:07:32 -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 w7KG2VGt027511; Mon, 20 Aug 2018 09:02:31 -0700 Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id w7KG2TX7027480 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 20 Aug 2018 09:02:30 -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.1367.3; Mon, 20 Aug 2018 09:02:29 -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.1367.000; Mon, 20 Aug 2018 09:02:28 -0700 From: "Templin (US), Fred L" <Fred.L.Templin@boeing.com> To: =?utf-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>, Ronald Bonica <rbonica@juniper.net> CC: "v6ops@ietf.org" <v6ops@ietf.org> Thread-Topic: [v6ops] Call for Adoption: draft-templin-v6ops-pdhost Thread-Index: AQHUNlwkxWShYdbmOEC/qYUxQLabkaTIv4lQ Date: Mon, 20 Aug 2018 16:02:28 +0000 Message-ID: <4249cc58213844df97ffb751189557ff@XCH15-06-08.nw.nos.boeing.com> References: <CO1PR05MB4436E9F2079B50141B88143AE2B0@CO1PR05MB443.namprd05.prod.outlook.com> <CAJE_bqcGAF2K9m7F4BHhZLvbhNcodak7Pzycjb9B+qwM9eS2jw@mail.gmail.com> In-Reply-To: <CAJE_bqcGAF2K9m7F4BHhZLvbhNcodak7Pzycjb9B+qwM9eS2jw@mail.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_4249cc58213844df97ffb751189557ffXCH150608nwnosboeingcom_" MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/7bNUKKEF0ChTtgdWoqtVBWNeOhs> Subject: Re: [v6ops] Call for Adoption: draft-templin-v6ops-pdhost X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 20 Aug 2018 16:07:35 -0000 --_000_4249cc58213844df97ffb751189557ffXCH150608nwnosboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2VlIGJlbG93IGZvciBmb2xsb3ctdXBzIHRvIHRoZSBwb2ludHMgeW91IGhhdmUgcmFpc2VkLg0K DQpGcmVkDQoNCkZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mID8/Pz8NClNlbnQ6IEZyaWRheSwgQXVndXN0IDE3LCAyMDE4IDExOjU3IEFNDQpU bzogUm9uYWxkIEJvbmljYSA8cmJvbmljYUBqdW5pcGVyLm5ldD4NCkNjOiB2Nm9wc0BpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFt2Nm9wc10gQ2FsbCBmb3IgQWRvcHRpb246IGRyYWZ0LXRlbXBsaW4t djZvcHMtcGRob3N0DQoNCk9uIFRodSwgSnVsIDI2LCAyMDE4IGF0IDEwOjI1IEFNIFJvbiBCb25p Y2EgPHJib25pY2FAanVuaXBlci5uZXQ8bWFpbHRvOnJib25pY2FAanVuaXBlci5uZXQ+PiB3cm90 ZToNCg0KPiAgICBUaGlzIGRyYWZ0IGluaXRpYXRlcyBhIHR3byB3ZWVrIGNhbGwgZm9yIGFkb3B0 aW9uIG9uDQo+ICAgIGRyYWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0LiBQbGVhc2UgcmVzcG9uZCBi eSBBdWd1c3QgOSwgMjAxOC4NCg0KQmVsYXRlZCwgYnV0IGFzIGNoYWlycyBzZWVtIHRvIHNlZWsg bW9yZSBpbnB1dCwgSSd2ZSByZWFkDQpkcmFmdC10ZW1wbGluLXY2b3BzLXBkaG9zdC0yMS4NCg0K SSBkb24ndCBoYXZlIGEgc3Ryb25nIG9waW5pb24gb24gd2hldGhlciB0byBhZG9wdCBpdCBhdCB2 Nm9wcy4gIEJ1dCBJDQpoYXZlIHNvbWUgZ2VuZXJhbCBvYnNlcnZhdGlvbnM6DQoNCi0gT24gb25l IGhhbmQsIGFwcGx5aW5nIHByZWZpeCBkZWxlZ2F0aW9uIHRvIGEgImhvc3QiIHR5cGUgb2Ygbm9k ZQ0KICBzZWVtcyB0byBiZSBhIHN0cmFpZ2h0Zm9yd2FyZCBleHRlbnNpb24gdG8gdGhlIG9yaWdp bmFsIHVzYWdlDQogIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDUgb2YgUkZDMzYzMy4gIEluIHRoYXQg c2Vuc2UgdGhlIG5lZWQgZm9yDQogIGhhdmluZyBhIHNlcGFyYXRlIGRvY3VtZW50IGlzIG5vdCBz byBjbGVhciB0byBtZSAoYnV0IEknbSBub3Qgc2F5aW5nDQogIHRoaXMgYXMgYW4gb2JqZWN0aW9u IHRvIHRoZSBhZG9wdGlvbiAtIGFzIEkgbm90ZWQgYWJvdmUgSSBkb24ndCBoYXZlDQogIGEgc3Ry b25nIG9waW5pb24gb24gdGhhdCBkZWNpc2lvbikuDQoNCi0gT24gdGhlIG90aGVyIGhhbmQsIHRo aXMgZG9jdW1lbnQgc2VlbXMgdG8gaW50cm9kdWNlIG5ldyBwcm90b2NvbA0KICBiZWhhdmlvcnMg d2l0aG91dCBzYXlpbmcgaXQncyB1cGRhdGluZyB0aGUgY29ycmVzcG9uZGluZyBleGlzdGluZw0K ICBzdGFuZGFyZCAoc2VlIHNwZWNpZmljIGNhc2VzIGJlbG93KS4gIFRoZXNlIGNvdWxkIGJlIGNv bnNpZGVyZWQNCiAgbm9uLXRyaXZpYWwgcHJvdG9jb2wgdXBkYXRlcyBhbmQgaXQgbWF5IG1ha2Ug dGhpcyBkb2N1bWVudCB3b3J0aA0KICBwdWJsaWNhdGlvbi4gIEJ1dCBpbiB0aGF0IGNhc2UgSSdk IHdvbmRlciB3aGV0aGVyIHRoaXMgc2hvdWxkIHJhdGhlcg0KICBiZWxvbmcgdG8gNm1hbiBhbmQg cmF0aGVyIGFpbSB0byBiZSBhIHN0YW5kYXJkcyB0cmFjayBkb2N1bWVudC4NCg0KLSBJdCBhc3N1 bWVzIG5lYXJseSBzaWxlbnRseSB0aGF0IGEgcmVxdWVzdGluZyBub2RlIGNhbiBza2lwIERBRCBp bg0KICB0aGUgdXBzdHJlYW0gbGluayBpZiB0aGUgcHJlZml4IGlzICJkZWxlZ2F0ZWQiOg0KDQog ICBJbiBjb250cmFzdCwgYSBub2RlIHRoYXQgY29uZmlndXJlcyBhZGRyZXNzZXMgZnJvbSBhIGRl bGVnYXRlZCBwcmVmaXgNCiAgIGNhbiBhc3NpZ24gdGhlbSB3aXRob3V0IGludm9raW5nIE1MRC9E QUQgb24gYW4gdXBzdHJlYW0gaW50ZXJmYWNlLA0KICAgc2luY2UgdGhlIHByZWZpeCBoYXMgYmVl biBkZWxlZ2F0ZWQgdG8gdGhlIG5vZGUgZm9yIGl0cyBvd24gZXhjbHVzaXZlDQogICB1c2UgYW5k IGlzIG5vdCBzaGFyZWQgd2l0aCBhbnkgb3RoZXIgbm9kZXMuDQoNCiAgQWx0aG91Z2ggdGhpcyBs b2dpYyBtYXkgYmUganVzdGlmaWFibGUsIEkgYmVsaWV2ZSB0aGlzIHNob3VsZA0KICBhY3R1YWxs eSBiZSBzcGVjaWZpZWQgYXMgYW4gdXBkYXRlIHRvIFJGQzQ4NjIuDQoNCj4+IFRoZSBwdXJwb3Nl IG9mIHRoaXMgZG9jdW1lbnQgaXMgbm90IHRvIHVwZGF0ZSBSRkM0ODYyLiBJZiB0aGUgZGVsZWdh dGVkDQo+PiBwcmVmaXggYW5kL29yIGFkZHJlc3NlcyBkZXJpdmVkIGZyb20gdGhlIHByZWZpeCBh cmUgdG8gYmUgYXNzaWduZWQgdG8NCj4+IGludGVyZmFjZXMgb3RoZXIgdGhhbiB0aGUgdXBzdHJl YW0gaW50ZXJmYWNlIChpLmUuLCB0aGUgaW50ZXJmYWNlIG92ZXINCj4+IHdoaWNoIHRoZSBwcmVm aXggd2FzIHJlY2VpdmVkKSB0aGVuIGl0IGlzIGEgZmFjdCB0aGF0IG5vIERBRCBpcyBuZWVkZWQN Cj4+IG9uIHRoZSB1cHN0cmVhbSBpbnRlcmZhY2UuIFNvLCB5b3VyIHBvaW50IHdvdWxkIHNlZW0g dG8gYmUgbGltaXRlZCB0bw0KPj4gdGhlIGNhc2Ugd2hlcmUgdGhlIG5vZGUgYXNzaWducyBhZGRy ZXNzZXMgdG8gdGhlIHVwc3RyZWFtIGludGVyZmFjZS4NCj4+DQo+PiBJbiB0aGF0IGNhc2UsIGhv d2V2ZXIsIEkgYmVsaWV2ZSB0aGF0IFJGQzQ4NjIgaXMgaW5jb3JyZWN0IGluIHNheWluZw0KPj4g dGhhdCBEQUQgbXVzdCBiZSB1c2VkIGZvciBhbGwgYWRkcmVzcyBhc3NpZ25tZW50cyB0byBhbiBp bnRlcmZhY2UNCj4+IGJlY2F1c2UgaXQgaGFzIGFuIHVuc3Bva2VuIGFzc3VtcHRpb24gdGhhdCB0 aGUgcHJlZml4ZXMgZnJvbSB3aGljaA0KPj4gdGhlIGFkZHJlc3NlcyBhcmUgZGVyaXZlZCBhcmUg b24tbGluayAob3IgcG9zc2libHkgb24tbGluaykuIEluIHRoZSBjYXNlDQo+PiBvZiBhZGRyZXNz IGFzc2lnbm1lbnQgZnJvbSBhIGRlbGVnYXRlZCBwcmVmaXgsIHRoZSBwcmVmaXggaXMga25vd24N Cj4+IHRvIGJlIG9mZi1saW5rIGFuZCBoZW5jZSBEQUQgaXMgdW5uZWNlc3NhcnkuDQo+Pg0KPj4g SSBiZWxpZXZlIHRoaXMgcG9pbnQgY2FuIGJlIGFkZHJlc3NlZCBpbiB0d28gY29tcGxpbWVudGFy eSBhY3Rpb25zOg0KPj4NCj4+IDEpIEluIHRoaXMgZG9jdW1lbnQsIG1ha2UgaXQgY2xlYXIgdGhh dCBEQUQgYXZvaWRhbmNlIGlzIGZvciBhc3NpZ25tZW50DQo+PiAgICBvZiBhZGRyZXNzZXMgdG8g aW50ZXJmYWNlcyBvdGhlciB0aGFuIHRoZSB1cHN0cmVhbSBpbnRlcmZhY2UgYW5kIHJlbWFpbg0K Pj4gICAgc2lsZW50IG9uIERBRCBhdm9pZGFuY2UgZm9yIGFzc2lnbm1lbnQgdG8gdGhlIHVwc3Ry ZWFtIGludGVyZmFjZS4NCj4+DQo+PiAyKSBQdWJsaXNoIGFuIGVycmF0dW0gZm9yIFJGQzQ4NjIg dG8gc2F5IHRoYXQgdGhlIERBRCBwcm9jZWR1cmVzDQo+PiAgICAgYXBwbHkgb25seSBmb3IgYWRk cmVzc2VzIGRlcml2ZWQgZnJvbSBwcmVmaXhlcyB0aGF0IGFyZSBrbm93bg0KPj4gICAgIHRvIGJl IG9uLWxpbmsgb3IgY291bGQgcG9zc2libHkgYmUgb24tbGluay4NCj4+DQo+PiBOb3RlIHRoYXQg YWN0aW9uIDEpIGRvZXMgbm90IGRlcGVuZCBvbiBhY3Rpb24gMiksIGFuZCB0aGUgdHdvIGFjdGlv bnMNCj4+IGNvdWxkIGdvIGZvcndhcmQgaW5kZXBlbmRlbnRseS4NCg0KSW4gbXkgaW50ZXJwcmV0 YXRpb24NCiAgUkZDNDg2MiByZXF1aXJlcyBub2RlcyB0byBwZXJmb3JtIERBRCBxdWl0ZSBzdHJv bmdseSBldmVuIHdoZW4gaXQncw0KICBvcGVyYXRpb25hbGx5IHJlYXNvbmFibGUgdG8gYXNzdW1l IGR1cGxpY2F0ZXMgYXJlIGxlc3MgbGlrZWx5IHRvDQogIGhhcHBlbi4gIElmIHdlIHdhbnQgdG8g b3ZlcnJpZGUgaXQsIElNTyB3ZSBzaG91bGQgc3BlY2lmeSBpdCBhcyBhDQogIHN0YW5kYXJkIHBy b3RvY29sIGJlaGF2aW9yLCBlLmcuLCBhcyBkZWZpbmVkIGluIFNlY3Rpb24gNS4xIG9mDQogIFJG QzQ4NjI6DQoNCiAgICAgIERlZmF1bHQ6IDEsIGJ1dCBtYXkgYmUgb3ZlcnJpZGRlbiBieSBhIGxp bmstdHlwZSBzcGVjaWZpYyB2YWx1ZSBpbg0KICAgICAgdGhlIGRvY3VtZW50IHRoYXQgY292ZXJz IGlzc3VlcyByZWxhdGVkIHRvIHRoZSB0cmFuc21pc3Npb24gb2YgSVANCiAgICAgIG92ZXIgYSBw YXJ0aWN1bGFyIGxpbmsgdHlwZSAoZS5nLiwgW1JGQzI0NjRdKS4NCg0KPj4gVGhpcyBkb2N1bWVu dCBkb2VzIG5vdCBuZWVkIHRvIGRpc2N1c3MgRHVwQWRkckRldGVjdFRyYW5zbWl0cy4NCg0KLSBJ biBTZWN0aW9uIDgsIGl0IHRhbGtzIGFib3V0IHNvbWV3aGF0IGF3a3dhcmQgYmVoYXZpb3Igb2Yg dGhlDQogIHJlcXVlc3Rpbmcgbm9kZToNCiAgKyBpdCBzZW5kcyBOUyB0byB0aGUgdXBzdHJlYW0g bGluayAobm90IHByb2hpYml0ZWQgYnkgUkZDNDg2MSBidXQNCiAgICBhIGJpdCBhd2t3YXJkIGZv ciBhICJyb3V0ZXIpDQogICsgaXQgc2V0cyB0aGUgcm91dGVyIGZsYWcgdG8gdHJ1ZSBpbiBOQSAo YnR3IEkgZG9uJ3Qgc2VlIHdoeSBpdA0KICAgIG5lZWRzIHRvIGRvIGl0KQ0KICArIGl0IHJlY2Vp dmVzIGEgcmVkaXJlY3QgYW5kIHVwZGF0ZXMgaXRzIG5laWdoYm9yIGNhY2hlLiAgVGhpcyBtYXkN CiAgICBiZSBpbiBhIGdyYXkgem9uZSwgYnV0IEknZCBjb25zaWRlciBpdCBhIHBvc3NpYmxlIHZp b2xhdGlvbiBvZiB0aGUNCiAgICBmb2xsb3dpbmcgcGFydCBvZiBSRkM0ODYxOg0KDQogICAgICBB IHJvdXRlciBNVVNUIE5PVCB1cGRhdGUgaXRzIHJvdXRpbmcgdGFibGVzIHVwb24gcmVjZWlwdCBv ZiBhDQogICAgICBSZWRpcmVjdC4NCg0KLSBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyB0aGUgbW9k ZWwgd2hlcmUgYWRkcmVzc2VzIGFyZSBhc3NpZ25lZCB0bw0KICB0aGUgdXBzdHJlYW0gaW50ZXJm YWNlIChGaWd1cmUgMykuLiAgSSB3b3VsZCBzdWdnZXN0IGNsYXJpZnlpbmcgaG93DQogIGl0J3Mg bm90IGNvbnNpZGVyZWQgYSB2aW9sYXRpb24gb2YgdGhlIGZvbGxvd2luZyBwYXJ0IG9mIFJGQzM2 MzM6DQoNCiAgIFsuLi5dIHRoZSByZXF1ZXN0aW5nIHJvdXRlciBNVVNUDQogICBOT1QgYXNzaWdu IGFueSBkZWxlZ2F0ZWQgcHJlZml4ZXMgb3Igc3VibmV0cyBmcm9tIHRoZSBkZWxlZ2F0ZWQNCiAg IHByZWZpeChlcykgdG8gdGhlIGxpbmsgdGhyb3VnaCB3aGljaCBpdCByZWNlaXZlZCB0aGUgREhD UCBtZXNzYWdlDQogICBmcm9tIHRoZSBkZWxlZ2F0aW5nIHJvdXRlci4NCg0KPj4gVGhpcyBjYW4g YmUgY2xhcmlmaWVkIGJ5IGNpdGluZyB0aGUgdGV4dCB5b3UgaGF2ZSBxdW90ZWQgdG8gc3RhdGUg dGhhdA0KPj4gb25seSBhZGRyZXNzZXMgYXJlIGFzc2lnbmVkIGFuZCBub3QgcHJlZml4ZXMgb3Ig c3VibmV0cy4gVGhlcmVmb3JlLA0KPj4gaXQgaXMgbm90IGEgdmlvbGF0aW9uIG9mIFJGQzM2MzMu DQoNCi0gTm93IHRoYXQgdGhpcyBkb2N1bWVudCB0YWxrcyBhYm91dCB2YXJpb3VzIHdheXMgb2Yg ZGVsZWdhdGluZyBhDQogIHByZWZpeCwgSSBndWVzcyB0aGUgdGVybSAicHJlZml4IGRlbGVnYXRp b24iIG1pZ2h0IGJlIGNvbmZ1c2luZywNCiAgc2luY2UgaXQgd291bGQgYmUgZWFzeSB0byBhc3N1 bWUgUkZDMzYzMyBpcyB1c2VkLiAgTWF5YmUgd2Ugc2hvdWxkDQogIHVzZSBhIGRpZmZlcmVudCB0 ZXJtLCBlLmcuLCAicHJlZml4IGFzc2lnbm1lbnQiLg0KDQo+PiBUaGUgdGVybSBwcmVmaXggZGVs ZWdhdGlvbiBoYXMgYmVlbiB1c2VkIGluIHRoZSBkaXNjdXNzaW9ucyBvZiB0aGlzDQo+PiBkb2N1 bWVudCBzaW5jZSB0aGUgZmlyc3QgdmVyc2lvbiB3YXMgcHVibGlzaGVkIDMgeWVhcnMgYWdvLiBO byBvbmUNCj4+IGVsc2UgaGFzIGV4cHJlc3NlZCBjb25mdXNpb24sIGFuZCBJTUhPIOKAnHByZWZp eCBkZWxlZ2F0aW9u4oCdIGlzIG1vcmUNCj4+IGNvcnJlY3QgYW5kIGxlc3MgY29uZnVzaW5nIHRo YW4g4oCccHJlZml4IGFzc2lnbm1lbnTigJ0uDQoNCi0gSW4gU2VjdGlvbiAxMiwgdGhlIGRlZmlu aXRpb24gb2YgInRydXN0ZWQvdW50cnVzdGVkIG5ldHdvcmtzIiBhbmQNCiAgaG93IGEgbm9kZSBk ZXRlcm1pbmVzIGl0IGFyZSBub3QgY2xlYXIgdG8gbWU6DQoNCiAgIEluIGFsbCBjYXNlcywgdGhl IG5vZGUgbXVzdCBkZWNpZGUgd2hldGhlciBvciBub3QgdG8gc2VuZCBEVXMNCiAgIGFjY29yZGlu ZyB0byB0aGUgc3BlY2lmaWMgb3BlcmF0aW9uYWwgc2NlbmFyaW8uICBJbiB0cnVzdGVkIG5ldHdv cmtzLA0KICAgdGhlIG5vZGUgc2hvdWxkIHNlbmQgRFUgbWVzc2FnZXMgdG8gcHJvdmlkZSB1c2Vm dWwgaW5mb3JtYXRpb24gdG8NCiAgIHBvdGVudGlhbCBjb3JyZXNwb25kZW50cy4uICBJbiB1bnRy dXN0ZWQgbmV0d29ya3MsIHRoZSBub2RlIGNhbg0KICAgcmVmcmFpbiBmcm9tIHNlbmRpbmcgRFUg bWVzc2FnZXMgdG8gYXZvaWQgcHJvdmlkaW5nIHNlbnNpdGl2ZQ0KICAgaW5mb3JtYXRpb24gdG8g cG90ZW50aWFsIGF0dGFja2Vycy4NCg0KPj4gSSBkb27igJl0IG1pbmQgZGVsZXRpbmcgdGhhdCBw YXJhZ3JhcGguIFdvdWxkIHRoYXQgYWRkcmVzcyB0aGUgY29uY2Vybj8NCg0KLS0NCkpJTk1FSSwg VGF0dXlhDQo= --_000_4249cc58213844df97ffb751189557ffXCH150608nwnosboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCglt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9t OjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNw YW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPlNlZSBiZWxvdyBmb3IgZm9sbG93LXVwcyB0byB0aGUgcG9pbnRzIHlvdSBoYXZlIHJhaXNl ZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkZyZWQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGlu IDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPj8/Pz88YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBdWd1c3QgMTcsIDIwMTggMTE6 NTcgQU08YnI+DQo8Yj5Ubzo8L2I+IFJvbmFsZCBCb25pY2EgJmx0O3Jib25pY2FAanVuaXBlci5u ZXQmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiB2Nm9wc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW3Y2b3BzXSBDYWxsIGZvciBBZG9wdGlvbjogZHJhZnQtdGVtcGxpbi12Nm9wcy1wZGhv c3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gVGh1LCBKdWwgMjYsIDIwMTggYXQgMTA6MjUgQU0gUm9uIEJvbmljYSAmbHQ7PGEgaHJlZj0i bWFpbHRvOnJib25pY2FAanVuaXBlci5uZXQiPnJib25pY2FAanVuaXBlci5uZXQ8L2E+Jmd0OyB3 cm90ZTo8YnI+DQo8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoaXMgZHJhZnQgaW5pdGlh dGVzIGEgdHdvIHdlZWsgY2FsbCBmb3IgYWRvcHRpb24gb248YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGRyYWZ0LXRlbXBsaW4tdjZvcHMtcGRob3N0LiBQbGVhc2UgcmVzcG9uZCBieSBBdWd1 c3QgOSwgMjAxOC48YnI+DQo8YnI+DQpCZWxhdGVkLCBidXQgYXMgY2hhaXJzIHNlZW0gdG8gc2Vl ayBtb3JlIGlucHV0LCBJJ3ZlIHJlYWQ8YnI+DQpkcmFmdC10ZW1wbGluLXY2b3BzLXBkaG9zdC0y MS48YnI+DQo8YnI+DQpJIGRvbid0IGhhdmUgYSBzdHJvbmcgb3BpbmlvbiBvbiB3aGV0aGVyIHRv IGFkb3B0IGl0IGF0IHY2b3BzLiZuYnNwOyBCdXQgSTxicj4NCmhhdmUgc29tZSBnZW5lcmFsIG9i c2VydmF0aW9uczo8YnI+DQo8YnI+DQotIE9uIG9uZSBoYW5kLCBhcHBseWluZyBwcmVmaXggZGVs ZWdhdGlvbiB0byBhICZxdW90O2hvc3QmcXVvdDsgdHlwZSBvZiBub2RlPGJyPg0KJm5ic3A7IHNl ZW1zIHRvIGJlIGEgc3RyYWlnaHRmb3J3YXJkIGV4dGVuc2lvbiB0byB0aGUgb3JpZ2luYWwgdXNh Z2U8YnI+DQombmJzcDsgZGVzY3JpYmVkIGluIFNlY3Rpb24gNSBvZiBSRkMzNjMzLiZuYnNwOyBJ biB0aGF0IHNlbnNlIHRoZSBuZWVkIGZvcjxicj4NCiZuYnNwOyBoYXZpbmcgYSBzZXBhcmF0ZSBk b2N1bWVudCBpcyBub3Qgc28gY2xlYXIgdG8gbWUgKGJ1dCBJJ20gbm90IHNheWluZzxicj4NCiZu YnNwOyB0aGlzIGFzIGFuIG9iamVjdGlvbiB0byB0aGUgYWRvcHRpb24gLSBhcyBJIG5vdGVkIGFi b3ZlIEkgZG9uJ3QgaGF2ZTxicj4NCiZuYnNwOyBhIHN0cm9uZyBvcGluaW9uIG9uIHRoYXQgZGVj aXNpb24pLjxicj4NCjxicj4NCi0gT24gdGhlIG90aGVyIGhhbmQsIHRoaXMgZG9jdW1lbnQgc2Vl bXMgdG8gaW50cm9kdWNlIG5ldyBwcm90b2NvbDxicj4NCiZuYnNwOyBiZWhhdmlvcnMgd2l0aG91 dCBzYXlpbmcgaXQncyB1cGRhdGluZyB0aGUgY29ycmVzcG9uZGluZyBleGlzdGluZzxicj4NCiZu YnNwOyBzdGFuZGFyZCAoc2VlIHNwZWNpZmljIGNhc2VzIGJlbG93KS4mbmJzcDsgVGhlc2UgY291 bGQgYmUgY29uc2lkZXJlZDxicj4NCiZuYnNwOyBub24tdHJpdmlhbCBwcm90b2NvbCB1cGRhdGVz IGFuZCBpdCBtYXkgbWFrZSB0aGlzIGRvY3VtZW50IHdvcnRoPGJyPg0KJm5ic3A7IHB1YmxpY2F0 aW9uLiZuYnNwOyBCdXQgaW4gdGhhdCBjYXNlIEknZCB3b25kZXIgd2hldGhlciB0aGlzIHNob3Vs ZCByYXRoZXI8YnI+DQombmJzcDsgYmVsb25nIHRvIDZtYW4gYW5kIHJhdGhlciBhaW0gdG8gYmUg YSBzdGFuZGFyZHMgdHJhY2sgZG9jdW1lbnQuPGJyPg0KPGJyPg0KLSBJdCBhc3N1bWVzIG5lYXJs eSBzaWxlbnRseSB0aGF0IGEgcmVxdWVzdGluZyBub2RlIGNhbiBza2lwIERBRCBpbjxicj4NCiZu YnNwOyB0aGUgdXBzdHJlYW0gbGluayBpZiB0aGUgcHJlZml4IGlzICZxdW90O2RlbGVnYXRlZCZx dW90Ozo8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsgSW4gY29udHJhc3QsIGEgbm9kZSB0aGF0IGNv bmZpZ3VyZXMgYWRkcmVzc2VzIGZyb20gYSBkZWxlZ2F0ZWQgcHJlZml4PGJyPg0KJm5ic3A7Jm5i c3A7IGNhbiBhc3NpZ24gdGhlbSB3aXRob3V0IGludm9raW5nIE1MRC9EQUQgb24gYW4gdXBzdHJl YW0gaW50ZXJmYWNlLDxicj4NCiZuYnNwOyZuYnNwOyBzaW5jZSB0aGUgcHJlZml4IGhhcyBiZWVu IGRlbGVnYXRlZCB0byB0aGUgbm9kZSBmb3IgaXRzIG93biBleGNsdXNpdmU8YnI+DQombmJzcDsm bmJzcDsgdXNlIGFuZCBpcyBub3Qgc2hhcmVkIHdpdGggYW55IG90aGVyIG5vZGVzLjxicj4NCjxi cj4NCiZuYnNwOyBBbHRob3VnaCB0aGlzIGxvZ2ljIG1heSBiZSBqdXN0aWZpYWJsZSwgSSBiZWxp ZXZlIHRoaXMgc2hvdWxkPGJyPg0KJm5ic3A7IGFjdHVhbGx5IGJlIHNwZWNpZmllZCBhcyBhbiB1 cGRhdGUgdG8gUkZDNDg2Mi48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mZ3Q7Jmd0OyBUaGUgcHVycG9zZSBvZiB0 aGlzIGRvY3VtZW50IGlzIG5vdCB0byB1cGRhdGUgUkZDNDg2Mi4gSWYgdGhlIGRlbGVnYXRlZDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4mZ3Q7Jmd0OyBwcmVmaXggYW5kL29yIGFkZHJlc3NlcyBkZXJpdmVk IGZyb20gdGhlIHByZWZpeCBhcmUgdG8gYmUgYXNzaWduZWQgdG88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Jmd0OyZndDsgaW50ZXJmYWNlcyBvdGhlciB0aGFuIHRoZSB1cHN0cmVhbSBpbnRlcmZhY2UgKGku ZS4sIHRoZSBpbnRlcmZhY2Ugb3ZlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mZ3Q7Jmd0OyB3aGljaCB0 aGUgcHJlZml4IHdhcyByZWNlaXZlZCkgdGhlbiBpdCBpcyBhIGZhY3QgdGhhdCBubyBEQUQgaXMg bmVlZGVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZndDsmZ3Q7IG9uIHRoZSB1cHN0cmVhbSBpbnRlcmZh Y2UuIFNvLCB5b3VyIHBvaW50IHdvdWxkIHNlZW0gdG8gYmUgbGltaXRlZCB0bzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mZ3Q7Jmd0OyB0aGUgY2FzZSB3aGVyZSB0aGUgbm9kZSBhc3NpZ25zIGFkZHJlc3Nl cyB0byB0aGUgdXBzdHJlYW0gaW50ZXJmYWNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mZ3Q7Jmd0Ozxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mZ3Q7Jmd0OyBJbiB0aGF0IGNhc2UsIGhvd2V2ZXIsIEkg YmVsaWV2ZSB0aGF0IFJGQzQ4NjIgaXMgaW5jb3JyZWN0IGluIHNheWluZzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj4mZ3Q7Jmd0OyB0aGF0IERBRCBtdXN0IGJlIHVzZWQgZm9yIGFsbCBhZGRyZXNzIGFzc2ln bm1lbnRzIHRvIGFuIGludGVyZmFjZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mZ3Q7Jmd0OyBiZWNhdXNl IGl0IGhhcyBhbiB1bnNwb2tlbiBhc3N1bXB0aW9uIHRoYXQgdGhlIHByZWZpeGVzIGZyb20gd2hp Y2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jmd0OyZndDsgdGhlIGFkZHJlc3NlcyBhcmUgZGVyaXZlZCBh cmUgb24tbGluayAob3IgcG9zc2libHkgb24tbGluaykuIEluIHRoZSBjYXNlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPiZndDsmZ3Q7IG9mIGFkZHJlc3MgYXNzaWdubWVudCBmcm9tIGEgZGVsZWdhdGVkIHBy ZWZpeCwgdGhlIHByZWZpeCBpcyBrbm93bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mZ3Q7Jmd0OyB0byBi ZSBvZmYtbGluayBhbmQgaGVuY2UgREFEIGlzIHVubmVjZXNzYXJ5LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mZ3Q7Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mZ3Q7Jmd0OyBJIGJlbGlldmUgdGhp cyBwb2ludCBjYW4gYmUgYWRkcmVzc2VkIGluIHR3byBjb21wbGltZW50YXJ5IGFjdGlvbnM6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZndDsmZ3Q7 IDEpIEluIHRoaXMgZG9jdW1lbnQsIG1ha2UgaXQgY2xlYXIgdGhhdCBEQUQgYXZvaWRhbmNlIGlz IGZvciBhc3NpZ25tZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7IG9mIGFkZHJlc3NlcyB0byBpbnRlcmZhY2VzIG90aGVyIHRoYW4gdGhlIHVwc3RyZWFtIGlu dGVyZmFjZSBhbmQgcmVtYWluPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHNpbGVudCBvbiBEQUQgYXZvaWRhbmNlIGZvciBhc3NpZ25tZW50IHRvIHRoZSB1cHN0 cmVhbSBpbnRlcmZhY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZndDsmZ3Q7PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZndDsmZ3Q7IDIpIFB1Ymxpc2ggYW4gZXJyYXR1bSBmb3IgUkZDNDg2MiB0byBz YXkgdGhhdCB0aGUgREFEIHByb2NlZHVyZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jmd0OyZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgYXBwbHkgb25seSBmb3IgYWRkcmVzc2VzIGRlcml2ZWQgZnJv bSBwcmVmaXhlcyB0aGF0IGFyZSBrbm93bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDt0byBiZSBvbi1saW5rIG9yIGNvdWxkIHBvc3NpYmx5IGJlIG9u LWxpbmsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZndDsmZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PiZndDsmZ3Q7IE5vdGUgdGhhdCBhY3Rpb24gMSkgZG9lcyBub3QgZGVwZW5kIG9uIGFjdGlvbiAy KSwgYW5kIHRoZSB0d28gYWN0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mZ3Q7Jmd0OyBjb3VsZCBn byBmb3J3YXJkIGluZGVwZW5kZW50bHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIG15IGludGVycHJldGF0aW9uPGJy Pg0KJm5ic3A7IFJGQzQ4NjIgcmVxdWlyZXMgbm9kZXMgdG8gcGVyZm9ybSBEQUQgcXVpdGUgc3Ry b25nbHkgZXZlbiB3aGVuIGl0J3M8YnI+DQombmJzcDsgb3BlcmF0aW9uYWxseSByZWFzb25hYmxl IHRvIGFzc3VtZSBkdXBsaWNhdGVzIGFyZSBsZXNzIGxpa2VseSB0bzxicj4NCiZuYnNwOyBoYXBw ZW4uJm5ic3A7IElmIHdlIHdhbnQgdG8gb3ZlcnJpZGUgaXQsIElNTyB3ZSBzaG91bGQgc3BlY2lm eSBpdCBhcyBhPGJyPg0KJm5ic3A7IHN0YW5kYXJkIHByb3RvY29sIGJlaGF2aW9yLCBlLmcuLCBh cyBkZWZpbmVkIGluIFNlY3Rpb24gNS4xIG9mPGJyPg0KJm5ic3A7IFJGQzQ4NjI6PGJyPg0KPGJy Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERlZmF1bHQ6IDEsIGJ1dCBtYXkgYmUg b3ZlcnJpZGRlbiBieSBhIGxpbmstdHlwZSBzcGVjaWZpYyB2YWx1ZSBpbjxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgZG9jdW1lbnQgdGhhdCBjb3ZlcnMgaXNzdWVzIHJl bGF0ZWQgdG8gdGhlIHRyYW5zbWlzc2lvbiBvZiBJUDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBvdmVyIGEgcGFydGljdWxhciBsaW5rIHR5cGUgKGUuZy4sIFtSRkMyNDY0XSku PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Jmd0OyZndDsgVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBuZWVkIHRvIGRp c2N1c3MgRHVwQWRkckRldGVjdFRyYW5zbWl0cy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCi0gSW4gU2VjdGlvbiA4LCBpdCB0YWxrcyBhYm91dCBz b21ld2hhdCBhd2t3YXJkIGJlaGF2aW9yIG9mIHRoZTxicj4NCiZuYnNwOyByZXF1ZXN0aW5nIG5v ZGU6PGJyPg0KJm5ic3A7ICYjNDM7IGl0IHNlbmRzIE5TIHRvIHRoZSB1cHN0cmVhbSBsaW5rIChu b3QgcHJvaGliaXRlZCBieSBSRkM0ODYxIGJ1dDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBhIGJp dCBhd2t3YXJkIGZvciBhICZxdW90O3JvdXRlcik8YnI+DQombmJzcDsgJiM0MzsgaXQgc2V0cyB0 aGUgcm91dGVyIGZsYWcgdG8gdHJ1ZSBpbiBOQSAoYnR3IEkgZG9uJ3Qgc2VlIHdoeSBpdDxicj4N CiZuYnNwOyZuYnNwOyZuYnNwOyBuZWVkcyB0byBkbyBpdCk8YnI+DQombmJzcDsgJiM0MzsgaXQg cmVjZWl2ZXMgYSByZWRpcmVjdCBhbmQgdXBkYXRlcyBpdHMgbmVpZ2hib3IgY2FjaGUuJm5ic3A7 IFRoaXMgbWF5PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IGJlIGluIGEgZ3JheSB6b25lLCBidXQg SSdkIGNvbnNpZGVyIGl0IGEgcG9zc2libGUgdmlvbGF0aW9uIG9mIHRoZTxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyBmb2xsb3dpbmcgcGFydCBvZiBSRkM0ODYxOjxicj4NCjxicj4NCiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBIHJvdXRlciBNVVNUIE5PVCB1cGRhdGUgaXRzIHJvdXRp bmcgdGFibGVzIHVwb24gcmVjZWlwdCBvZiBhPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFJlZGlyZWN0Ljxicj4NCjxicj4NCi0gVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhl IG1vZGVsIHdoZXJlIGFkZHJlc3NlcyBhcmUgYXNzaWduZWQgdG88YnI+DQombmJzcDsgdGhlIHVw c3RyZWFtIGludGVyZmFjZSAoRmlndXJlIDMpLi4mbmJzcDsgSSB3b3VsZCBzdWdnZXN0IGNsYXJp ZnlpbmcgaG93PGJyPg0KJm5ic3A7IGl0J3Mgbm90IGNvbnNpZGVyZWQgYSB2aW9sYXRpb24gb2Yg dGhlIGZvbGxvd2luZyBwYXJ0IG9mIFJGQzM2MzM6PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7IFsu Li5dIHRoZSByZXF1ZXN0aW5nIHJvdXRlciBNVVNUPGJyPg0KJm5ic3A7Jm5ic3A7IE5PVCBhc3Np Z24gYW55IGRlbGVnYXRlZCBwcmVmaXhlcyBvciBzdWJuZXRzIGZyb20gdGhlIGRlbGVnYXRlZDxi cj4NCiZuYnNwOyZuYnNwOyBwcmVmaXgoZXMpIHRvIHRoZSBsaW5rIHRocm91Z2ggd2hpY2ggaXQg cmVjZWl2ZWQgdGhlIERIQ1AgbWVzc2FnZTxicj4NCiZuYnNwOyZuYnNwOyBmcm9tIHRoZSBkZWxl Z2F0aW5nIHJvdXRlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZndDsmZ3Q7IFRoaXMgY2FuIGJlIGNsYXJpZmllZCBieSBjaXRpbmcgdGhl IHRleHQgeW91IGhhdmUgcXVvdGVkIHRvIHN0YXRlIHRoYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jmd0 OyZndDsgb25seSBhZGRyZXNzZXMgYXJlIGFzc2lnbmVkIGFuZCBub3QgcHJlZml4ZXMgb3Igc3Vi bmV0cy4gVGhlcmVmb3JlLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mZ3Q7Jmd0OyBpdCBpcyBub3QgYSB2 aW9sYXRpb24gb2YgUkZDMzYzMy4NCjwvc3Bhbj48YnI+DQo8YnI+DQotIE5vdyB0aGF0IHRoaXMg ZG9jdW1lbnQgdGFsa3MgYWJvdXQgdmFyaW91cyB3YXlzIG9mIGRlbGVnYXRpbmcgYTxicj4NCiZu YnNwOyBwcmVmaXgsIEkgZ3Vlc3MgdGhlIHRlcm0gJnF1b3Q7cHJlZml4IGRlbGVnYXRpb24mcXVv dDsgbWlnaHQgYmUgY29uZnVzaW5nLDxicj4NCiZuYnNwOyBzaW5jZSBpdCB3b3VsZCBiZSBlYXN5 IHRvIGFzc3VtZSBSRkMzNjMzIGlzIHVzZWQuJm5ic3A7IE1heWJlIHdlIHNob3VsZDxicj4NCiZu YnNwOyB1c2UgYSBkaWZmZXJlbnQgdGVybSwgZS5nLiwgJnF1b3Q7cHJlZml4IGFzc2lnbm1lbnQm cXVvdDsuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj4mZ3Q7Jmd0OyBUaGUgdGVybSBwcmVmaXggZGVsZWdhdGlvbiBoYXMgYmVlbiB1c2VkIGlu IHRoZSBkaXNjdXNzaW9ucyBvZiB0aGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZndDsmZ3Q7IGRvY3Vt ZW50IHNpbmNlIHRoZSBmaXJzdCB2ZXJzaW9uIHdhcyBwdWJsaXNoZWQgMyB5ZWFycyBhZ28uIE5v IG9uZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mZ3Q7Jmd0OyBlbHNlIGhhcyBleHByZXNzZWQgY29uZnVz aW9uLCBhbmQgSU1ITyDigJxwcmVmaXggZGVsZWdhdGlvbuKAnSBpcyBtb3JlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPiZndDsmZ3Q7IGNvcnJlY3QgYW5kIGxlc3MgY29uZnVzaW5nIHRoYW4g4oCccHJlZml4 IGFzc2lnbm1lbnTigJ0uPC9zcGFuPjxicj4NCjxicj4NCi0gSW4gU2VjdGlvbiAxMiwgdGhlIGRl ZmluaXRpb24gb2YgJnF1b3Q7dHJ1c3RlZC91bnRydXN0ZWQgbmV0d29ya3MmcXVvdDsgYW5kPGJy Pg0KJm5ic3A7IGhvdyBhIG5vZGUgZGV0ZXJtaW5lcyBpdCBhcmUgbm90IGNsZWFyIHRvIG1lOjxi cj4NCjxicj4NCiZuYnNwOyZuYnNwOyBJbiBhbGwgY2FzZXMsIHRoZSBub2RlIG11c3QgZGVjaWRl IHdoZXRoZXIgb3Igbm90IHRvIHNlbmQgRFVzPGJyPg0KJm5ic3A7Jm5ic3A7IGFjY29yZGluZyB0 byB0aGUgc3BlY2lmaWMgb3BlcmF0aW9uYWwgc2NlbmFyaW8uJm5ic3A7IEluIHRydXN0ZWQgbmV0 d29ya3MsPGJyPg0KJm5ic3A7Jm5ic3A7IHRoZSBub2RlIHNob3VsZCBzZW5kIERVIG1lc3NhZ2Vz IHRvIHByb3ZpZGUgdXNlZnVsIGluZm9ybWF0aW9uIHRvPGJyPg0KJm5ic3A7Jm5ic3A7IHBvdGVu dGlhbCBjb3JyZXNwb25kZW50cy4uJm5ic3A7IEluIHVudHJ1c3RlZCBuZXR3b3JrcywgdGhlIG5v ZGUgY2FuPGJyPg0KJm5ic3A7Jm5ic3A7IHJlZnJhaW4gZnJvbSBzZW5kaW5nIERVIG1lc3NhZ2Vz IHRvIGF2b2lkIHByb3ZpZGluZyBzZW5zaXRpdmU8YnI+DQombmJzcDsmbmJzcDsgaW5mb3JtYXRp b24gdG8gcG90ZW50aWFsIGF0dGFja2Vycy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZndDsmZ3Q7IEkgZG9u4oCZdCBtaW5kIGRlbGV0aW5n IHRoYXQgcGFyYWdyYXBoLiBXb3VsZCB0aGF0IGFkZHJlc3MgdGhlIGNvbmNlcm4/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KLS08YnI+DQpKSU5NRUks IFRhdHV5YTxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4249cc58213844df97ffb751189557ffXCH150608nwnosboeingcom_-- From nobody Mon Aug 20 17:14:11 2018 Return-Path: <brian.e.carpenter@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD7D130DF7 for <v6ops@ietfa.amsl.com>; Mon, 20 Aug 2018 17:14:09 -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 9uazjYNbop9n for <v6ops@ietfa.amsl.com>; Mon, 20 Aug 2018 17:14:08 -0700 (PDT) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 43939130DF2 for <v6ops@ietf.org>; Mon, 20 Aug 2018 17:14:08 -0700 (PDT) Received: by mail-pf1-x42c.google.com with SMTP id d4-v6so7597886pfn.0 for <v6ops@ietf.org>; Mon, 20 Aug 2018 17:14:08 -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=plPP8TEunx6TDknJ2z5snv+C9W7gC869A3hYZ9LtXU0=; b=R0KIeJn9jmu+I2wDHgBFK2CDzeY4wa5KhePaU/A6v62zvPC9IUwxr0hBVPGCzoU2ys lo9OPHkWAqPg2VZLzPBe7Fksy4Jhg7E32dIF4yST/yu7N/EL/ApoyVlwQZXY3Osn0nSk 8vplW0l3eiLFUI5Qd7EKOjPzH1MSalRwvBMSZUNOL+A9lEBTua7wjJezTr/0lSNNXYJx GyJ75smzxYuPaOLytRWxwWeBO5Sy1/gkOqstSHu5pYTlo0EhgJ9pjJmiVLFYs7Gh/qpI wdFfywKmz9BOTw3/Cg/wqqqZXi1E/VANEEiR8pb3W3rtXdIhWC8EHTqWyavBhTQhLlI7 S3BQ== 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=plPP8TEunx6TDknJ2z5snv+C9W7gC869A3hYZ9LtXU0=; b=ib7L9i0vL/jBcqFfckMkWwblm32qtJH/RilBSnxRJxBhE6s8rxN2vxx0jDC8FGoQaA Cl9/cMp2ZymAVE95b70KMfxi9ELCRI9u0NFNYSEgPKcQuw13+9BIuCqipSs94Xb148JL zgW+2vu88KLQicRcdcLp4yNq3p75tNjGvL7f9SqGDIZgN1yb2+Z53YSbmVXn48eKHaSb 6xEDtlNWoUKuEPqJauCgHxNaS4Cm8uIei7nmmZZnHfp/yOX8e9qIgcnSP4ocdavH1BS9 KJ7ywlnOX0DNGYqRPU9HbfmMlV1xUVnBnwA0XGh8EdVsa/eX/Mq+xLFmA15NgLPwd+Vq gyXQ== X-Gm-Message-State: AOUpUlHAdC0uNbJ9Nl6k0RKgTwSOdJhKSP7fF4xoieUxoPauqM3wh7Lb lhlIZpRnsFQBl4CLEeCMtBJTpA/p X-Google-Smtp-Source: AA+uWPw4eUv77rsX3A6ewtBSewqaokyUvJPvfTcwF0qc6bqx/ocqdZerbrElEHNRzsNIZZ3sNZTEDw== X-Received: by 2002:a63:4f63:: with SMTP id p35-v6mr45330209pgl.167.1534810447566; Mon, 20 Aug 2018 17:14:07 -0700 (PDT) Received: from [130.216.38.96] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.96]) by smtp.gmail.com with ESMTPSA id y128-v6sm17242133pfb.56.2018.08.20.17.14.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Aug 2018 17:14:06 -0700 (PDT) To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, Ca By <cb.list6@gmail.com> Cc: v6ops@ietf.org References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> <CAD6AjGQ_OBFGJb_C+mP_87nu7q_oXPrTvxhaV_=RcubeHtMy2Q@mail.gmail.com> <E345387F-6C1D-49D4-8B03-52D04498DDA5@lists.zabbadoz.net> From: Brian E Carpenter <brian.e.carpenter@gmail.com> Message-ID: <a9eeba1b-76dc-a69f-aabe-04fa4ddc3a4f@gmail.com> Date: Tue, 21 Aug 2018 12:14:01 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <E345387F-6C1D-49D4-8B03-52D04498DDA5@lists.zabbadoz.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/wJdyq5L7vcGjTR1zHud3-UO9Al8> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 21 Aug 2018 00:14:10 -0000 On 2018-08-20 02:22, Bjoern A. Zeeb wrote: > On 18 Aug 2018, at 15:18, Ca By wrote: >=20 >> So, maybe the draft needs to outline the obvious. Ipv6-only networks t= hat >> want to provide consumer internet service need an integration point su= ch as >> a B4 or a CLAT, which have both been deployed at scale for years, and = thus >> have a body of knowlege to justify a bcp. Second, perhaps a seperate d= raft, >> outlines a catalog of services that require a B4 or CLAT and how to >> minimize their use. >=20 > But don=E2=80=99t we have enough RFCs on these topics already? >=20 >=20 >> For me, i would be interested in hearing how the >> ipv6-only enterprise networks that have been trumpeted at FB, Cisco an= d >> Comcast are doing. >=20 > Or Microsoft .. but these things are all discusses at other places. > They have been and still are. Presentations are online, slides availab= le > to some degree. Look at the country and intl IPv6 conferences, the *NO= Gs, .. > The IETF does not have to rehash all this, do we? Well, first we need to know our objective. I suggest that our objective should be to identify things that the IETF should do to alleviate the alleged problems. Since what we can do is write standards-track, BCP or informational RFCs, the real question is: which of the alleged problems could in fact be fixed by new RFC text? I don't know how to do that except by making a list of the alleged problems and checking off the ones that RFC text could fix. Boring, no? Brian From nobody Tue Aug 21 02:42:01 2018 Return-Path: <otroan@employees.org> 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 2A18D130ED2 for <v6ops@ietfa.amsl.com>; Tue, 21 Aug 2018 02:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 5qKVDDD6bHKt for <v6ops@ietfa.amsl.com>; Tue, 21 Aug 2018 02:41:56 -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 84C7D130DC3 for <v6ops@ietf.org>; Tue, 21 Aug 2018 02:41:56 -0700 (PDT) Received: from astfgl.hanazo.no (219.103.92.62.static.cust.telenor.com [62.92.103.219]) (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 4634A2D4FA7; Tue, 21 Aug 2018 09:41:55 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 3A61043D69B; Tue, 21 Aug 2018 11:41:52 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Ole Troan <otroan@employees.org> In-Reply-To: <a9eeba1b-76dc-a69f-aabe-04fa4ddc3a4f@gmail.com> Date: Tue, 21 Aug 2018 11:41:51 +0200 Cc: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, Ca By <cb.list6@gmail.com>, v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <530DAFF4-D55F-445F-BBFD-68034578983E@employees.org> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> <CAD6AjGQ_OBFGJb_C+mP_87nu7q_oXPrTvxhaV_=RcubeHtMy2Q@mail.gmail.com> <E345387F-6C1D-49D4-8B03-52D04498DDA5@lists.zabbadoz.net> <a9eeba1b-76dc-a69f-aabe-04fa4ddc3a4f@gmail.com> To: Brian E Carpenter <brian.e.carpenter@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/7Z6nlBs9JMyBjg07JcDeBl-pXgg> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 21 Aug 2018 09:41:59 -0000 >>> So, maybe the draft needs to outline the obvious. Ipv6-only networks = that >>> want to provide consumer internet service need an integration point = such as >>> a B4 or a CLAT, which have both been deployed at scale for years, = and thus >>> have a body of knowlege to justify a bcp. Second, perhaps a seperate = draft, >>> outlines a catalog of services that require a B4 or CLAT and how to >>> minimize their use. >>=20 >> But don=E2=80=99t we have enough RFCs on these topics already? >>=20 >>=20 >>> For me, i would be interested in hearing how the >>> ipv6-only enterprise networks that have been trumpeted at FB, Cisco = and >>> Comcast are doing. >>=20 >> Or Microsoft .. but these things are all discusses at other places. >> They have been and still are. Presentations are online, slides = available >> to some degree. Look at the country and intl IPv6 conferences, the = *NOGs, .. >> The IETF does not have to rehash all this, do we? >=20 > Well, first we need to know our objective. I suggest that our > objective should be to identify things that the IETF should > do to alleviate the alleged problems. Since what we can do > is write standards-track, BCP or informational RFCs, the real > question is: which of the alleged problems could in fact be fixed > by new RFC text? >=20 > I don't know how to do that except by making a list of the > alleged problems and checking off the ones that RFC text > could fix. Boring, no? +1 emphasis on _new_. Best regards, Ole= From nobody Tue Aug 21 08:21:42 2018 Return-Path: <adegidio@telecentro.net.ar> 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 53BCA130F15 for <v6ops@ietfa.amsl.com>; Tue, 21 Aug 2018 08:21:30 -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, 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=telecentro.net.ar 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 wgixgT1swdaQ for <v6ops@ietfa.amsl.com>; Tue, 21 Aug 2018 08:21:27 -0700 (PDT) Received: from mail.telecentro.net.ar (mail.telecentro.net.ar [190.55.63.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C64D0130EF6 for <v6ops@ietf.org>; Tue, 21 Aug 2018 08:21:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 8224A3201DFC; Tue, 21 Aug 2018 12:21:24 -0300 (-03) Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id pK7F8ozy_r6m; Tue, 21 Aug 2018 12:21:23 -0300 (-03) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 7208D3201F19; Tue, 21 Aug 2018 12:21:23 -0300 (-03) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.telecentro.net.ar 7208D3201F19 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecentro.net.ar; s=25118654-7AE4-11E8-AD98-8D0B0E6845CD; t=1534864883; bh=3tW/GLJwaAYZkzL1yWNSF6m8yyXgcVx16HuBk/GW7gk=; h=Date:From:To:Message-ID:MIME-Version; b=nRRjnmOyt3gwMwZWTUr+Krkv2AFWJWDpgkpq7gQewR8Jg5VA0nFU+3ZVtaYuxvVjB 8ijrOfI84yInyDcMU+s7+SiA1aNxhaMCyg55EU/9lLwR6YDFpA1o3G49Yqj6N7+dky 0smFfccl8YX0+oU/MFX72LRde1Y55qwM4xSiR6m8zSUVITluFAFFx6P+yv3b2qPvSf JmL5iEcIA69zyWMMjHXZVwDdBLMV1HDMJjzWmKclpvOqpAogzG2QIoIgol0Z1BLYUq eTGAPFmlJgoObfWqM+pMl6sZWhD3ogmndO74NDkwxTQlb7xHltsfCHCGvqYJqvVig7 qKLO38omYFgcw== X-Virus-Scanned: amavisd-new at tclmail6.telecentro.local Received: from mail.telecentro.net.ar ([127.0.0.1]) by localhost (tclmail6.telecentro.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xJGB8QfXcYjR; Tue, 21 Aug 2018 12:21:23 -0300 (-03) Received: from tclmail6.telecentro.local (tclmail6.telecentro.local [10.210.50.96]) by mail.telecentro.net.ar (Postfix) with ESMTP id 396433201EBC; Tue, 21 Aug 2018 12:21:23 -0300 (-03) Date: Tue, 21 Aug 2018 12:21:22 -0300 (ART) From: Alejandro D'Egidio <adegidio@telecentro.net.ar> To: Fred Baker <fredbaker.ietf@gmail.com> Cc: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, "v6ops@ietf.org list" <v6ops@ietf.org> Message-ID: <58654503.37560057.1534864882045.JavaMail.zimbra@telecentro.net.ar> In-Reply-To: <87CD2261-3226-47FA-BE60-ED0924B68A07@gmail.com> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <3BE77332-B5FA-48F3-B881-45F60DA6643B@consulintel.es> <87CD2261-3226-47FA-BE60-ED0924B68A07@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.210.50.96] X-Mailer: Zimbra 8.8.8_GA_3008 (ZimbraWebClient - GC68 (Win)/8.8.8_GA_1703) Thread-Topic: Thinking about problems in IPv6-only networks Thread-Index: y0E4/hO+OUoz3SjdE4OAfPy3ZwUjsQ== Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/QJdxVot2brFuYTJz2WG25WaSNV0> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 21 Aug 2018 15:21:41 -0000 Hello Fred, First at all, I think it could be a good discussion and I would like to hel= p with anything I can. I think the "Ipv6-only networks" is too match general, but I think also it = could be the intention, right? So, from ISP point of view we normally talk about IPv6 networks thinking of= final users (residential customers) o access networks but there are other = parts: -CORE: As we normally have a MPLS Network, we just transport IPv6 as a part= of Internet "service" but we still have an IPv4 Core (IGP, MP-BGP, IDs, et= c). Depending on devices and software releases we can do more or less thing= s. Something very simple, in OSPFv3 router-id is IPv4 -Provisioning: We normally prepare the provisioning system to provide IPv6 = to customers and CPEs but its internal infrastructure keeps in IPv4. -Video: In the world of Video (headend) are using more and more Multicast b= ut in IPv4, most of devices don't even have options for IPv6. -Monitoring and workstations: I have seen some IPv6 implementations in ISPs= to provide it to its customers without having IPv6 in their own PCs and mo= nitoring systems. Firewalls and VPNs are also included. Regards, Alejandro ----- Mensaje original ----- De: "Fred Baker" <fredbaker.ietf@gmail.com> Para: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es> CC: "v6ops@ietf.org list" <v6ops@ietf.org> Enviados: Domingo, 19 de Agosto 2018 13:28:31 Asunto: Re: [v6ops] Thinking about problems in IPv6-only networks I think this is something the draft might discuss. To me, "IPv6-only" means= that the object in question is using only IPv6. If it's an application, it= doesn't have or can't use anything else. If it's a host, it doesn't have a= n IPv4 address, whether it can use one or not. If it's a network, only IPv6= is deployed in it. At whatever scale is under discussion, IPv4 is not a fa= ctor and IPv6 has replaced it. Making it more complicated than that doesn't help, IMHO. > On Aug 17, 2018, at 6:09 PM, JORDI PALET MARTINEZ <jordi.palet@consulinte= l.es> wrote: >=20 > Hi Fred, >=20 > I will be happy to join, but first I think we need to clarify what is IPv= 6-only in the scope of this document/work ... >=20 > Are we talking about a network that in the "customer" LANs doesn't have A= NY IPv4 and never connects to any "IPv4-only remote site". >=20 > Are the access links IPv6-only ? Or the LANs are IPv6 only, but the acces= s links are dual-stack? >=20 > Or the LAN's don't have IPv4, but apps, running IPv6 can connect to remot= e "IPv4-only sites" (so the network or the access provider) has a NAT64 or = equivalent mechanism? >=20 > I recall we tried to clarify this definition in a previous document, and = I still see everybody reading different things ... >=20 > Regards, > Jordi >=20 >=20 >=20 > =EF=BB=BF-----Mensaje original----- > De: v6ops <v6ops-bounces@ietf.org> en nombre de Fred Baker <fredbaker.iet= f@gmail.com> > Fecha: viernes, 17 de agosto de 2018, 13:06 > Para: "v6ops@ietf.org list" <v6ops@ietf.org> > Asunto: [v6ops] Thinking about problems in IPv6-only networks >=20 > Ron and I just had our bi-weekly phone call, and identified a topic th= at might be interesting and useful. We'd like to invite a draft from people= that are deploying IPv6-only networks or parts of networks identifying the= problems they are experiencing that the IETF might be in a position to add= ress. The objective, as always, is to solve problems preventing such a depl= oyment in time for vendors and open source to provide solutions. > ----------------------------------------------------------------------= ---------- > Victorious warriors win first and then go to war, > Defeated warriors go to war first and then seek to win. > Sun Tzu >=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 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. >=20 >=20 >=20 ---------------------------------------------------------------------------= ----- The fact that there is a highway to hell and a stairway to heaven is an int= eresting comment on projected traffic volume... _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Aug 21 09:20:39 2018 Return-Path: <lee@asgard.org> 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 005ED130F3A for <v6ops@ietfa.amsl.com>; Tue, 21 Aug 2018 09:20:26 -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 dAOOfbRJa9SP for <v6ops@ietfa.amsl.com>; Tue, 21 Aug 2018 09:20:24 -0700 (PDT) Received: from atl4mhob06.registeredsite.com (atl4mhob06.registeredsite.com [209.17.115.44]) (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 1B210130F7F for <v6ops@ietf.org>; Tue, 21 Aug 2018 09:20:24 -0700 (PDT) Received: from mailpod.hostingplatform.com (atl4qobmail02pod6.registeredsite.com [10.30.71.210]) by atl4mhob06.registeredsite.com (8.14.4/8.14.4) with ESMTP id w7LGKK5O024688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <v6ops@ietf.org>; Tue, 21 Aug 2018 12:20:20 -0400 Received: (qmail 21924 invoked by uid 0); 21 Aug 2018 16:20:20 -0000 X-TCPREMOTEIP: 174.64.33.182 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.2.104?) (lee@asgard.org@174.64.33.182) by 0 with ESMTPA; 21 Aug 2018 16:20:20 -0000 To: v6ops@ietf.org References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> <CAD6AjGQ_OBFGJb_C+mP_87nu7q_oXPrTvxhaV_=RcubeHtMy2Q@mail.gmail.com> <E345387F-6C1D-49D4-8B03-52D04498DDA5@lists.zabbadoz.net> <a9eeba1b-76dc-a69f-aabe-04fa4ddc3a4f@gmail.com> From: Lee Howard <lee@asgard.org> Message-ID: <e560c82c-085e-60fe-2076-70e3624696c0@asgard.org> Date: Tue, 21 Aug 2018 12:20:19 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <a9eeba1b-76dc-a69f-aabe-04fa4ddc3a4f@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/IcVb_OYLMMNLCk_nZ6fWuPXz2wI> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 21 Aug 2018 16:20:38 -0000 On 08/20/2018 08:14 PM, Brian E Carpenter wrote: > Well, first we need to know our objective. I suggest that our > objective should be to identify things that the IETF should > do to alleviate the alleged problems. Since what we can do > is write standards-track, BCP or informational RFCs, the real > question is: which of the alleged problems could in fact be fixed > by new RFC text? That was exactly the charter of sunset4, which is in a coma from lack of work. > > I don't know how to do that except by making a list of the > alleged problems and checking off the ones that RFC text > could fix. Boring, no? I will boldly assert that there are no RFCs requiring updates in order to deploy IPv6-only. I make that assertion not so much from complete confidence, but as a challenge to prove me wrong. IPv6-only deployment suffers from scarce business drivers, buggy implementations, and vendor support. There's an enterprise "multi-homing" problem that I think has been addressed several ways. There's the interaction of fragmentation headers and DNSSec (or other apps using transport without session management, or anycast; see draft-ietf-intarea-frag-fragile).  I don't think there's more the IETF can do. Lee > > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Aug 21 09:27:13 2018 Return-Path: <mellon@fugue.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E77130F5C for <v6ops@ietfa.amsl.com>; Tue, 21 Aug 2018 09:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.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 rPT9o-WnSWTw for <v6ops@ietfa.amsl.com>; Tue, 21 Aug 2018 09:26:56 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 6AFB4130F7C for <v6ops@ietf.org>; Tue, 21 Aug 2018 09:26:55 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id g141-v6so4840442ita.4 for <v6ops@ietf.org>; Tue, 21 Aug 2018 09:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ejGAPKeRmMiJK3Ggg0zj/mVtIF5Vpv+pGyU0R+4nCq8=; b=JDc/nZpQHlRQ9l2ryyqBMQTX05CdwJFDm9xznE/rMBfs+yJ7prx8rQGTANcHSBxTFP 1Ht9qnyVBc+zuruU3bzeulu9dDNwZt81ZmY4ongOuC1zgOD9izqe6BoYpoVpjHKe+ob8 FEV1zU9WacGf23hFYFaDBFAjlR598e4grph66f9xvfkO019wSYJnhYba1KqK8b07dmnZ 2d5twrBekIotoH9CBKWErC9QpUIi0f+v3QwafvYPZ92YCPqZMU0hqFaiPIhYORIWUhj2 mS9HBHdPxACP8E4wpsN6Yd4eihBkj97R776cBEsxDpMQ33iEHlWcVyhliObMe29kELRS NMnQ== 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=ejGAPKeRmMiJK3Ggg0zj/mVtIF5Vpv+pGyU0R+4nCq8=; b=noP0c2NeZBcHgh16lvklFCzm2vwzE9KVXpM42HDpZpWZqPf6OmEoLzLzIzSNQJOUdk HQ9vWimQEBNA2f/h33sHtfh6Ng+tzdg/UqaDVkCqdJpFuCGI9urpraK8zOA+14oe5ui0 GmuFMu4stpakrCubDEtishA1DLe0ZlQTqqde9Xbia5IPwZFis6aH2UHwbEvN+77RSDth PPq98Ux0Iow7Jz0urgKwodKSk6IhWCLjQocRqGsYed/ajm/1VQKODeDIEMti6f0H1MNO LIENT6/GvQs/MYdwGnktUttg7C0BuNojti9uYM/+T6bxjUrSvdiwtXbMqF9Hinwd43RY pZ5g== X-Gm-Message-State: APzg51Ba2TIDTTVwKwdZifYvwdcW0u8ONnWZYSk7a/Kxx7VAWz4QJLcD 9xDXfYu10PyPqClHgERV320RKaVRms7/UQfw9LaUERt8 X-Google-Smtp-Source: ANB0VdY0ZRN0selVNftXtt0tGeHpMff9pLK4SQIz3HQzkADchJrOacMoHCzd2/itmxh4+iCMB+wBz+Zdl4jPNrvvq3U= X-Received: by 2002:a24:5f92:: with SMTP id r140-v6mr44594itb.95.1534868814618; Tue, 21 Aug 2018 09:26:54 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:a009:0:0:0:0:0 with HTTP; Tue, 21 Aug 2018 09:26:14 -0700 (PDT) In-Reply-To: <e560c82c-085e-60fe-2076-70e3624696c0@asgard.org> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> <CAD6AjGQ_OBFGJb_C+mP_87nu7q_oXPrTvxhaV_=RcubeHtMy2Q@mail.gmail.com> <E345387F-6C1D-49D4-8B03-52D04498DDA5@lists.zabbadoz.net> <a9eeba1b-76dc-a69f-aabe-04fa4ddc3a4f@gmail.com> <e560c82c-085e-60fe-2076-70e3624696c0@asgard.org> From: Ted Lemon <mellon@fugue.com> Date: Tue, 21 Aug 2018 12:26:14 -0400 Message-ID: <CAPt1N1mAELodigHMdNGQEhr0bmHv0oruhAAHNZDjCA4BummBDw@mail.gmail.com> To: Lee Howard <lee@asgard.org> Cc: IPv6 Ops WG <v6ops@ietf.org> Content-Type: multipart/alternative; boundary="0000000000007900100573f47e91" Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/hmLx-Ly1ezVbGtAeuiZV8v30QdQ> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 21 Aug 2018 16:27:11 -0000 --0000000000007900100573f47e91 Content-Type: text/plain; charset="UTF-8" What's the state of SIP over IPv6 these days? On Tue, Aug 21, 2018 at 12:20 PM, Lee Howard <lee@asgard.org> wrote: > > > On 08/20/2018 08:14 PM, Brian E Carpenter wrote: > >> Well, first we need to know our objective. I suggest that our >> objective should be to identify things that the IETF should >> do to alleviate the alleged problems. Since what we can do >> is write standards-track, BCP or informational RFCs, the real >> question is: which of the alleged problems could in fact be fixed >> by new RFC text? >> > > That was exactly the charter of sunset4, which is in a coma from lack of > work. > >> >> I don't know how to do that except by making a list of the >> alleged problems and checking off the ones that RFC text >> could fix. Boring, no? >> > > I will boldly assert that there are no RFCs requiring updates in order to > deploy IPv6-only. > > I make that assertion not so much from complete confidence, but as a > challenge to prove me wrong. > > IPv6-only deployment suffers from scarce business drivers, buggy > implementations, and vendor support. There's an enterprise "multi-homing" > problem that I think has been addressed several ways. There's the > interaction of fragmentation headers and DNSSec (or other apps using > transport without session management, or anycast; see > draft-ietf-intarea-frag-fragile). I don't think there's more the IETF > can do. > > Lee > > > >> 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 > --0000000000007900100573f47e91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">What's the state of SIP over IPv6 these days?</div><di= v class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Aug 21, 2018= at 12:20 PM, Lee Howard <span dir=3D"ltr"><<a href=3D"mailto:lee@asgard= .org" target=3D"_blank">lee@asgard.org</a>></span> wrote:<br><blockquote= class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli= d;padding-left:1ex"><span class=3D""><br> <br> On 08/20/2018 08:14 PM, Brian E Carpenter wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Well, first we need to know our objective. I suggest that our<br> objective should be to identify things that the IETF should<br> do to alleviate the alleged problems. Since what we can do<br> is write standards-track, BCP or informational RFCs, the real<br> question is: which of the alleged problems could in fact be fixed<br> by new RFC text?<br> </blockquote> <br></span> That was exactly the charter of sunset4, which is in a coma from lack of wo= rk.<span class=3D""><br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> I don't know how to do that except by making a list of the<br> alleged problems and checking off the ones that RFC text<br> could fix. Boring, no?<br> </blockquote> <br></span> I will boldly assert that there are no RFCs requiring updates in order to d= eploy IPv6-only.<br> <br> I make that assertion not so much from complete confidence, but as a challe= nge to prove me wrong.<br> <br> IPv6-only deployment suffers from scarce business drivers, buggy implementa= tions, and vendor support. There's an enterprise "multi-homing&quo= t; problem that I think has been addressed several ways. There's the in= teraction of fragmentation headers and DNSSec (or other apps using transpor= t without session management, or anycast; see draft-ietf-intarea-frag-fragi= l<wbr>e).=C2=A0 I don't think there's more the IETF can do.<span cl= ass=3D"HOEnZb"><font color=3D"#888888"><br> <br> Lee</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> <br> =C2=A0 =C2=A0 =C2=A0Brian<br> <br> ______________________________<wbr>_________________<br> v6ops mailing list<br> <a href=3D"mailto:v6ops@ietf.org" target=3D"_blank">v6ops@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/v6ops" rel=3D"noreferrer" = target=3D"_blank">https://www.ietf.org/mailman/l<wbr>istinfo/v6ops</a><br> </blockquote> <br> ______________________________<wbr>_________________<br> v6ops mailing list<br> <a href=3D"mailto:v6ops@ietf.org" target=3D"_blank">v6ops@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/v6ops" rel=3D"noreferrer" = target=3D"_blank">https://www.ietf.org/mailman/l<wbr>istinfo/v6ops</a><br> </div></div></blockquote></div><br></div> --0000000000007900100573f47e91-- From nobody Tue Aug 21 10:06:39 2018 Return-Path: <fredbaker.ietf@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 396C1131002 for <v6ops@ietfa.amsl.com>; Tue, 21 Aug 2018 10:06:27 -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 rZJoTqJlPCH7 for <v6ops@ietfa.amsl.com>; Tue, 21 Aug 2018 10:06:20 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 3A2AE130F69 for <v6ops@ietf.org>; Tue, 21 Aug 2018 10:06:19 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id v8-v6so33302230oie.5 for <v6ops@ietf.org>; Tue, 21 Aug 2018 10:06:19 -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=bEmbH7nSogiBr70PoIRvGDlppW4DBjcXIA+Y6LJYhgs=; b=pD6rrtYv7g1P+C237suPWlXeVCmpAbItLyGglrTOPqoE8ini0a9uoleoBMJfM30Ndo +lJ3B8N02zVxycFPahGulVBqAGyJYbVh0htpKNUjS6fKw5bx8UAY7aksthVKBTLH2sHS bLgQDA36QLXW23DzFoUByqpYhXHrHKITCXsOcq4gz+RxMvYMQDH29P03cqS3fDvbcqth FVN6nXdHgTDSp/ot2eU3JlHHtROPeVSfkN+uCt5WySP2Kw5oTIITMrg1UJZp6lgLUr1o 2OB+bttAm/yH2g6ROjXDmaqQ3Rh00fjelv0VGiAltVEFa+uuIU+bvn49lOvfWilSCSp/ oS8w== 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=bEmbH7nSogiBr70PoIRvGDlppW4DBjcXIA+Y6LJYhgs=; b=F2pM6JiaV09myVHPwqK3zBHpeZ3igU1Kxsc6o9bff9k04c/1VAJrHK1oEScQMtzmiC hWbVxElOxXZ9LK8fJr3U1sLBss0H5vhJT+cdG4akDP+P254cN9WblaKA/0wfBE7h0jSD icB3ZNCDeaZGLE+KiICEeez4TG3bdXD7ivwECxkp6z3pxhL/bk5aZEQvuvVAY0gnV5kN /3oobtRwHLnSOBLhXn63pI5Snove04toUhpHVvLKAmUUYq3pI74J+0N4lkrkBfWYzJhF U209X/hU66gAziSb+Xl9m6YWV2mZb1EEcmlS4wEfw+jfqwS5zyXNgoyKhyeg9UrOEcrS HwBg== X-Gm-Message-State: APzg51CqV8QKDr94jt8J+f2YblmGE8tpI/3GAmKQMlUoGEZX+nleKdaP NsAcUmSkq6ckqqsDj9SpFqg= X-Google-Smtp-Source: ANB0Vdb29BCrpk2KTR8EYszft9RigukB3O+bW7mOK9Z9/KaoIMri/FnXUqInHBDUpG0XhG/qujGhHA== X-Received: by 2002:aca:bf88:: with SMTP id p130-v6mr179829oif.344.1534871178546; Tue, 21 Aug 2018 10:06:18 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::104a? ([2600:8802:5600:1546::104a]) by smtp.gmail.com with ESMTPSA id m11-v6sm19018668oif.27.2018.08.21.10.06.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Aug 2018 10:06:17 -0700 (PDT) From: Fred Baker <fredbaker.ietf@gmail.com> Message-Id: <8643A800-7A79-4D5A-A584-E719294F3530@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_B0F6ED1B-B73D-491B-9333-7DFBEEE307DB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 21 Aug 2018 10:06:15 -0700 In-Reply-To: <58654503.37560057.1534864882045.JavaMail.zimbra@telecentro.net.ar> Cc: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>, "v6ops@ietf.org list" <v6ops@ietf.org> To: Alejandro D'Egidio <adegidio@telecentro.net.ar> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <3BE77332-B5FA-48F3-B881-45F60DA6643B@consulintel.es> <87CD2261-3226-47FA-BE60-ED0924B68A07@gmail.com> <58654503.37560057.1534864882045.JavaMail.zimbra@telecentro.net.ar> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/RHHkQCbqeixTtGneaofbgLfQVVY> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 21 Aug 2018 17:06:37 -0000 --Apple-Mail=_B0F6ED1B-B73D-491B-9333-7DFBEEE307DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 21, 2018, at 8:21 AM, Alejandro D'Egidio = <adegidio@telecentro.net.ar> wrote: >=20 > Hello Fred, > First at all, I think it could be a good discussion and I would like = to help with anything I can. > I think the "Ipv6-only networks" is too match general, but I think = also it could be the intention, right? It may be too general. > So, from ISP point of view we normally talk about IPv6 networks = thinking of final users (residential customers) o access networks but = there are other parts: > -CORE: As we normally have a MPLS Network, we just transport IPv6 as a = part of Internet "service" but we still have an IPv4 Core (IGP, MP-BGP, = IDs, etc). Depending on devices and software releases we can do more or = less things. Something very simple, in OSPFv3 router-id is IPv4 Actually, no. RFC 5340 (OSPF for IPv6, aka OSPFv3) specifies that router = ids and lsids remain 32 bits as in the IPv4 case, but does not specify = that they are IPv4 addresses. Even in OSPFv2, many implementations use = one of the IPv4 addresses of a system by default, but the protocol = simply specifies a 32 bit number. > -Provisioning: We normally prepare the provisioning system to provide = IPv6 to customers and CPEs but its internal infrastructure keeps in = IPv4. > -Video: In the world of Video (headend) are using more and more = Multicast but in IPv4, most of devices don't even have options for IPv6. > -Monitoring and workstations: I have seen some IPv6 implementations in = ISPs to provide it to its customers without having IPv6 in their own PCs = and monitoring systems. Firewalls and VPNs are also included. So, operationally, there is neither intention nor capability to turn = IPv4 off except as a service. Close? > Regards, > Alejandro >=20 > ----- Mensaje original ----- > De: "Fred Baker" <fredbaker.ietf@gmail.com> > Para: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es> > CC: "v6ops@ietf.org list" <v6ops@ietf.org> > Enviados: Domingo, 19 de Agosto 2018 13:28:31 > Asunto: Re: [v6ops] Thinking about problems in IPv6-only networks >=20 > I think this is something the draft might discuss. To me, "IPv6-only" = means that the object in question is using only IPv6. If it's an = application, it doesn't have or can't use anything else. If it's a host, = it doesn't have an IPv4 address, whether it can use one or not. If it's = a network, only IPv6 is deployed in it. At whatever scale is under = discussion, IPv4 is not a factor and IPv6 has replaced it. >=20 > Making it more complicated than that doesn't help, IMHO. >=20 >> On Aug 17, 2018, at 6:09 PM, JORDI PALET MARTINEZ = <jordi.palet@consulintel.es> wrote: >>=20 >> Hi Fred, >>=20 >> I will be happy to join, but first I think we need to clarify what is = IPv6-only in the scope of this document/work ... >>=20 >> Are we talking about a network that in the "customer" LANs doesn't = have ANY IPv4 and never connects to any "IPv4-only remote site". >>=20 >> Are the access links IPv6-only ? Or the LANs are IPv6 only, but the = access links are dual-stack? >>=20 >> Or the LAN's don't have IPv4, but apps, running IPv6 can connect to = remote "IPv4-only sites" (so the network or the access provider) has a = NAT64 or equivalent mechanism? >>=20 >> I recall we tried to clarify this definition in a previous document, = and I still see everybody reading different things ... >>=20 >> Regards, >> Jordi >>=20 >>=20 >>=20 >> =EF=BB=BF-----Mensaje original----- >> De: v6ops <v6ops-bounces@ietf.org> en nombre de Fred Baker = <fredbaker.ietf@gmail.com> >> Fecha: viernes, 17 de agosto de 2018, 13:06 >> Para: "v6ops@ietf.org list" <v6ops@ietf.org> >> Asunto: [v6ops] Thinking about problems in IPv6-only networks >>=20 >> Ron and I just had our bi-weekly phone call, and identified a topic = that might be interesting and useful. We'd like to invite a draft from = people that are deploying IPv6-only networks or parts of networks = identifying the problems they are experiencing that the IETF might be in = a position to address. The objective, as always, is to solve problems = preventing such a deployment in time for vendors and open source to = provide solutions. >> = --------------------------------------------------------------------------= ------ >> Victorious warriors win first and then go to war, >> Defeated warriors go to war first and then seek to win. >> Sun Tzu >>=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 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. >>=20 >>=20 >>=20 >=20 > = --------------------------------------------------------------------------= ------ > The fact that there is a highway to hell and a stairway to heaven is = an interesting comment on projected traffic volume... >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops = --------------------------------------------------------------------------= ------ The fact that there is a highway to hell and a stairway to heaven is an = interesting comment on projected traffic volume... --Apple-Mail=_B0F6ED1B-B73D-491B-9333-7DFBEEE307DB 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+AFAlt8RocACgkQEhdRnd2G P+BSmRAAjNZ2Zxk7D/yxkUE5uL0tczfwc43jjoLPKz84cfbxlLWl0ZT7FQnfJrpJ zpr5WnOUurztw4CLirx0zfyGJzY+Vf/uq2MERxv9wGCRAsdrbRkujx/6RX+raKyk K60I2QAp9LHJ8dfkZqxdVosv8DvFV0lJ9Fo8u2beaX2qp8S3aBO5BhAyfKB0HSEt 1Z5DZtiWp7xZPxbYutreKOOI6Cni2IMysUok0uH7A5vClFSR6rH0c37Ie/F0TViM zvUxTht/3Lx/dDuDFFbBzmigF7uB7dkvTzJyHNS9gaZhmgiqE9qAlDFX/fr8QHzV sY+5yv9Y6G48+Ue/KrISHhyB13tXukfiulgyHK3wAaVk+tG6lobUYgn15iABNpdg EnqwAz6YhnYUNQ7oAC9mzG2bM7fVxYndmrBf0HOwWdaEBGUOsLPClgOE4pZlD/Lt KTsA5DnCw+2RYJYlGIck6qw5ZR3JjtDEldZEreNop1ARzjeAD9dAY24uScwV0gPt 0DCM1lPHu5RAb8Qp81Q6i/lhdQjJH3hP/ax77ENOpUO8GaaIsHdrpkjsJQa2orT8 MLCyttAk5jG4WSjuyccjyeIyMtwKiiBP4MW23xGiD1ZZthd/VAtX3TOOLsqPKARM mkdnFPNb/zOIuboDkfHbB4CiDmKM0z8fDjbK48U58Kk8Tvedkog= =cmxk -----END PGP SIGNATURE----- --Apple-Mail=_B0F6ED1B-B73D-491B-9333-7DFBEEE307DB-- From nobody Tue Aug 21 10:29:04 2018 Return-Path: <lee@asgard.org> 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 4622C130FF2 for <v6ops@ietfa.amsl.com>; Tue, 21 Aug 2018 10:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 5j8vGM52nngv for <v6ops@ietfa.amsl.com>; Tue, 21 Aug 2018 10:28:47 -0700 (PDT) Received: from atl4mhob06.registeredsite.com (atl4mhob06.registeredsite.com [209.17.115.44]) (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 0EBF8130FE1 for <v6ops@ietf.org>; Tue, 21 Aug 2018 10:28:46 -0700 (PDT) Received: from mailpod.hostingplatform.com (atl4qobmail01pod6.registeredsite.com [10.30.71.209]) by atl4mhob06.registeredsite.com (8.14.4/8.14.4) with ESMTP id w7LHSioD010166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <v6ops@ietf.org>; Tue, 21 Aug 2018 13:28:44 -0400 Received: (qmail 10227 invoked by uid 0); 21 Aug 2018 17:28:44 -0000 X-TCPREMOTEIP: 174.64.33.182 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.2.104?) (lee@asgard.org@174.64.33.182) by 0 with ESMTPA; 21 Aug 2018 17:28:44 -0000 To: Ted Lemon <mellon@fugue.com> Cc: IPv6 Ops WG <v6ops@ietf.org> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> <CAD6AjGQ_OBFGJb_C+mP_87nu7q_oXPrTvxhaV_=RcubeHtMy2Q@mail.gmail.com> <E345387F-6C1D-49D4-8B03-52D04498DDA5@lists.zabbadoz.net> <a9eeba1b-76dc-a69f-aabe-04fa4ddc3a4f@gmail.com> <e560c82c-085e-60fe-2076-70e3624696c0@asgard.org> <CAPt1N1mAELodigHMdNGQEhr0bmHv0oruhAAHNZDjCA4BummBDw@mail.gmail.com> From: Lee Howard <lee@asgard.org> Message-ID: <b653c3eb-d9fa-f5a3-e33e-60bd13c00121@asgard.org> Date: Tue, 21 Aug 2018 13:28:43 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <CAPt1N1mAELodigHMdNGQEhr0bmHv0oruhAAHNZDjCA4BummBDw@mail.gmail.com> Content-Type: multipart/alternative; boundary="------------D571A12AD296BABCFD89F8C2" Content-Language: en-US Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/3k9A3QUnzg2BeT9OlLJpNtzeJb0> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 21 Aug 2018 17:29:02 -0000 This is a multi-part message in MIME format. --------------D571A12AD296BABCFD89F8C2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 08/21/2018 12:26 PM, Ted Lemon wrote: > What's the state of SIP over IPv6 these days? It works. If you're communicating between address families, you need a B2BUA as a TrGW (back to back user agent as a translation gateway), which is statefully expensive. I haven't personally implemented it, but I've worked with those who have. Do you know of other gaps? Lee > > On Tue, Aug 21, 2018 at 12:20 PM, Lee Howard <lee@asgard.org > <mailto:lee@asgard.org>> wrote: > > > > On 08/20/2018 08:14 PM, Brian E Carpenter wrote: > > Well, first we need to know our objective. I suggest that our > objective should be to identify things that the IETF should > do to alleviate the alleged problems. Since what we can do > is write standards-track, BCP or informational RFCs, the real > question is: which of the alleged problems could in fact be fixed > by new RFC text? > > > That was exactly the charter of sunset4, which is in a coma from > lack of work. > > > I don't know how to do that except by making a list of the > alleged problems and checking off the ones that RFC text > could fix. Boring, no? > > > I will boldly assert that there are no RFCs requiring updates in > order to deploy IPv6-only. > > I make that assertion not so much from complete confidence, but as > a challenge to prove me wrong. > > IPv6-only deployment suffers from scarce business drivers, buggy > implementations, and vendor support. There's an enterprise > "multi-homing" problem that I think has been addressed several > ways. There's the interaction of fragmentation headers and DNSSec > (or other apps using transport without session management, or > anycast; see draft-ietf-intarea-frag-fragile).  I don't think > there's more the IETF can do. > > Lee > > > >      Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org <mailto:v6ops@ietf.org> > https://www.ietf.org/mailman/listinfo/v6ops > <https://www.ietf.org/mailman/listinfo/v6ops> > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org <mailto:v6ops@ietf.org> > https://www.ietf.org/mailman/listinfo/v6ops > <https://www.ietf.org/mailman/listinfo/v6ops> > > --------------D571A12AD296BABCFD89F8C2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <br> <div class="moz-cite-prefix">On 08/21/2018 12:26 PM, Ted Lemon wrote:<br> </div> <blockquote type="cite" cite="mid:CAPt1N1mAELodigHMdNGQEhr0bmHv0oruhAAHNZDjCA4BummBDw@mail.gmail.com"> <meta http-equiv="content-type" content="text/html; charset=utf-8"> <div dir="ltr">What's the state of SIP over IPv6 these days?</div> </blockquote> <br> It works. If you're communicating between address families, you need a B2BUA as a TrGW (back to back user agent as a translation gateway), which is statefully expensive.<br> <br> I haven't personally implemented it, but I've worked with those who have. <br> <br> Do you know of other gaps?<br> <br> Lee<br> <br> <blockquote type="cite" cite="mid:CAPt1N1mAELodigHMdNGQEhr0bmHv0oruhAAHNZDjCA4BummBDw@mail.gmail.com"> <div class="gmail_extra"><br> <div class="gmail_quote">On Tue, Aug 21, 2018 at 12:20 PM, Lee Howard <span dir="ltr"><<a href="mailto:lee@asgard.org" target="_blank" moz-do-not-send="true">lee@asgard.org</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br> <br> On 08/20/2018 08:14 PM, Brian E Carpenter wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Well, first we need to know our objective. I suggest that our<br> objective should be to identify things that the IETF should<br> do to alleviate the alleged problems. Since what we can do<br> is write standards-track, BCP or informational RFCs, the real<br> question is: which of the alleged problems could in fact be fixed<br> by new RFC text?<br> </blockquote> <br> </span> That was exactly the charter of sunset4, which is in a coma from lack of work.<span class=""><br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> I don't know how to do that except by making a list of the<br> alleged problems and checking off the ones that RFC text<br> could fix. Boring, no?<br> </blockquote> <br> </span> I will boldly assert that there are no RFCs requiring updates in order to deploy IPv6-only.<br> <br> I make that assertion not so much from complete confidence, but as a challenge to prove me wrong.<br> <br> IPv6-only deployment suffers from scarce business drivers, buggy implementations, and vendor support. There's an enterprise "multi-homing" problem that I think has been addressed several ways. There's the interaction of fragmentation headers and DNSSec (or other apps using transport without session management, or anycast; see draft-ietf-intarea-frag-fragil<wbr>e).  I don't think there's more the IETF can do.<span class="HOEnZb"><font color="#888888"><br> <br> Lee</font></span> <div class="HOEnZb"> <div class="h5"><br> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>      Brian<br> <br> ______________________________<wbr>_________________<br> v6ops mailing list<br> <a href="mailto:v6ops@ietf.org" target="_blank" moz-do-not-send="true">v6ops@ietf.org</a><br> <a href="https://www.ietf.org/mailman/listinfo/v6ops" rel="noreferrer" target="_blank" moz-do-not-send="true">https://www.ietf.org/mailman/l<wbr>istinfo/v6ops</a><br> </blockquote> <br> ______________________________<wbr>_________________<br> v6ops mailing list<br> <a href="mailto:v6ops@ietf.org" target="_blank" moz-do-not-send="true">v6ops@ietf.org</a><br> <a href="https://www.ietf.org/mailman/listinfo/v6ops" rel="noreferrer" target="_blank" moz-do-not-send="true">https://www.ietf.org/mailman/l<wbr>istinfo/v6ops</a><br> </div> </div> </blockquote> </div> <br> </div> </blockquote> <br> </body> </html> --------------D571A12AD296BABCFD89F8C2-- From nobody Tue Aug 21 10:30:51 2018 Return-Path: <mellon@fugue.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8414131011 for <v6ops@ietfa.amsl.com>; Tue, 21 Aug 2018 10:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.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 odn7bhco-nF3 for <v6ops@ietfa.amsl.com>; Tue, 21 Aug 2018 10:30:34 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 E0148130F84 for <v6ops@ietf.org>; Tue, 21 Aug 2018 10:30:33 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id 75-v6so627411iou.11 for <v6ops@ietf.org>; Tue, 21 Aug 2018 10:30:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QRiZRiGsyIKNZEDubd75j7qq72Dw3qomJoJ+p5rqrgU=; b=zAmgYphBucovCZ9Bovv35kTOVCHZXo7er6IcQZ04NRNRsjiqSRYrUArIGAWoHXtVxN y4z4T4ZQJc73+oqRpBIRfZgdM0a1ys0NsHaXFOtrinvA9U6OmPCY478a2Unj3Zu2dozY r1nPV9vZdY4+jqdMDIfzcQfq5ntLiiMp++YTBSaSk09ef5JgQcvmbtwbIWo/B+MF/fb7 Yu4YPI4Lm8b0WLZ41KoMT0nFRI5zgJGC/BM4mBI0ts5Pwts2wgIqK28bcRiwf2HhBFhK V4wtGTTF/W99MBynBn1SIjZanAmI6/HoyUDLdhcYkLWodtNwXmEuihJVkDiJ7xd/AJDo 3YJA== 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=QRiZRiGsyIKNZEDubd75j7qq72Dw3qomJoJ+p5rqrgU=; b=ISTzhzISs7dIpM2xNuOS4SvJM4mkI3xir2sUyjAndrYck0/0DP8eShlHTyfN4A+UBw e8tjr2eVpkeZ2sL9tY++rV59PKVqyyDdf4u/q94bdvAB0v+eBQkDozKkPskeTGvkMomW a6jvXfK8fVPStPRyuMjXNWYSD6V00hcHhhAbQ2NCPehxMR7xjqPvm78ROqefXF5pgH9P r1qlVPaDi5dtkC88KDkBvtqrAFvo0I3DDNO/yzi0nTghTzzJA8uahgJocqoTT6FqF1cl haXmVK+Ze0qdFFOi+qN2hprgMtPxUjRVw303Wx+o9e5/wKIm5hSdFjwF40eIcyNuacTr XgrA== X-Gm-Message-State: AOUpUlE0N63sRhQ3HqBn5ORJZzukKYQ7ISkd0UuOyMh4ZKGgJqW2TW6Y WpMFZIYeCznM3//k1QxewnqHgt1PPqr1Lk7mAOwX3Lnb X-Google-Smtp-Source: AA+uWPz11Md3m+4imS5f0ndnzLhLPsb67e/LRTOuYFm8SsIF1oUwavOOAf7O3r9vFHCC6Sydv1Gu5sZjnRFmgzyYQdA= X-Received: by 2002:a6b:dd01:: with SMTP id f1-v6mr42476683ioc.45.1534872633133; Tue, 21 Aug 2018 10:30:33 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:a009:0:0:0:0:0 with HTTP; Tue, 21 Aug 2018 10:29:52 -0700 (PDT) In-Reply-To: <b653c3eb-d9fa-f5a3-e33e-60bd13c00121@asgard.org> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> <CAD6AjGQ_OBFGJb_C+mP_87nu7q_oXPrTvxhaV_=RcubeHtMy2Q@mail.gmail.com> <E345387F-6C1D-49D4-8B03-52D04498DDA5@lists.zabbadoz.net> <a9eeba1b-76dc-a69f-aabe-04fa4ddc3a4f@gmail.com> <e560c82c-085e-60fe-2076-70e3624696c0@asgard.org> <CAPt1N1mAELodigHMdNGQEhr0bmHv0oruhAAHNZDjCA4BummBDw@mail.gmail.com> <b653c3eb-d9fa-f5a3-e33e-60bd13c00121@asgard.org> From: Ted Lemon <mellon@fugue.com> Date: Tue, 21 Aug 2018 13:29:52 -0400 Message-ID: <CAPt1N1mo_DXuCrmecouX3VSFqwJ6cDLphOQK14Q-Vz=_tPOo2g@mail.gmail.com> To: Lee Howard <lee@asgard.org> Cc: IPv6 Ops WG <v6ops@ietf.org> Content-Type: multipart/alternative; boundary="00000000000012e57d0573f562ed" Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Yq8PoTUaggtFRUhHKN_Eca_ZPyo> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 21 Aug 2018 17:30:49 -0000 --00000000000012e57d0573f562ed Content-Type: text/plain; charset="UTF-8" Nope, that's the big one for me. I don't have a SIP provider that supports IPv6. On Tue, Aug 21, 2018 at 1:28 PM, Lee Howard <lee@asgard.org> wrote: > > On 08/21/2018 12:26 PM, Ted Lemon wrote: > > What's the state of SIP over IPv6 these days? > > > It works. If you're communicating between address families, you need a > B2BUA as a TrGW (back to back user agent as a translation gateway), which > is statefully expensive. > > I haven't personally implemented it, but I've worked with those who have. > > Do you know of other gaps? > > Lee > > > > On Tue, Aug 21, 2018 at 12:20 PM, Lee Howard <lee@asgard.org> wrote: > >> >> >> On 08/20/2018 08:14 PM, Brian E Carpenter wrote: >> >>> Well, first we need to know our objective. I suggest that our >>> objective should be to identify things that the IETF should >>> do to alleviate the alleged problems. Since what we can do >>> is write standards-track, BCP or informational RFCs, the real >>> question is: which of the alleged problems could in fact be fixed >>> by new RFC text? >>> >> >> That was exactly the charter of sunset4, which is in a coma from lack of >> work. >> >>> >>> I don't know how to do that except by making a list of the >>> alleged problems and checking off the ones that RFC text >>> could fix. Boring, no? >>> >> >> I will boldly assert that there are no RFCs requiring updates in order to >> deploy IPv6-only. >> >> I make that assertion not so much from complete confidence, but as a >> challenge to prove me wrong. >> >> IPv6-only deployment suffers from scarce business drivers, buggy >> implementations, and vendor support. There's an enterprise "multi-homing" >> problem that I think has been addressed several ways. There's the >> interaction of fragmentation headers and DNSSec (or other apps using >> transport without session management, or anycast; see >> draft-ietf-intarea-frag-fragile). I don't think there's more the IETF >> can do. >> >> Lee >> >> >> >>> 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 >> > > > --00000000000012e57d0573f562ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Nope, that's the big one for me.=C2=A0 =C2=A0I don'= ;t have a SIP provider that supports IPv6.</div><div class=3D"gmail_extra">= <br><div class=3D"gmail_quote">On Tue, Aug 21, 2018 at 1:28 PM, Lee Howard = <span dir=3D"ltr"><<a href=3D"mailto:lee@asgard.org" target=3D"_blank">l= ee@asgard.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" st= yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> =20 =20 =20 <div text=3D"#000000" bgcolor=3D"#FFFFFF"><span class=3D""> <br> <div class=3D"m_7467364132449938368moz-cite-prefix">On 08/21/2018 12:26= PM, Ted Lemon wrote:<br> </div> <blockquote type=3D"cite"> =20 <div dir=3D"ltr">What's the state of SIP over IPv6 these days?</d= iv> </blockquote> <br></span> It works. If you're communicating between address families, you nee= d a B2BUA as a TrGW (back to back user agent as a translation gateway), which is statefully expensive.<br> <br> I haven't personally implemented it, but I've worked with those= who have. <br> <br> Do you know of other gaps?<span class=3D"HOEnZb"><font color=3D"#888888= "><br> <br> Lee</font></span><div><div class=3D"h5"><br> <br> <blockquote type=3D"cite"> <div class=3D"gmail_extra"><br> <div class=3D"gmail_quote">On Tue, Aug 21, 2018 at 12:20 PM, Lee Howard <span dir=3D"ltr"><<a href=3D"mailto:lee@asgard.org" ta= rget=3D"_blank">lee@asgard.org</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord= er-left:1px #ccc solid;padding-left:1ex"><span><br> <br> On 08/20/2018 08:14 PM, Brian E Carpenter wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex"> Well, first we need to know our objective. I suggest that our<br> objective should be to identify things that the IETF should<br> do to alleviate the alleged problems. Since what we can do<br> is write standards-track, BCP or informational RFCs, the real<br> question is: which of the alleged problems could in fact be fixed<br> by new RFC text?<br> </blockquote> <br> </span> That was exactly the charter of sunset4, which is in a coma from lack of work.<span><br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;= border-left:1px #ccc solid;padding-left:1ex"> <br> I don't know how to do that except by making a list of the<br> alleged problems and checking off the ones that RFC text<br= > could fix. Boring, no?<br> </blockquote> <br> </span> I will boldly assert that there are no RFCs requiring updates in order to deploy IPv6-only.<br> <br> I make that assertion not so much from complete confidence, but as a challenge to prove me wrong.<br> <br> IPv6-only deployment suffers from scarce business drivers, buggy implementations, and vendor support. There's an enterprise "multi-homing" problem that I think has be= en addressed several ways. There's the interaction of fragmentation headers and DNSSec (or other apps using transport without session management, or anycast; see draft-ietf-intarea-frag-fragil<wbr>e).=C2=A0 I don't think there's more the IETF can do.<span class=3D"m_7467364132449= 938368HOEnZb"><font color=3D"#888888"><br> <br> Lee</font></span> <div class=3D"m_7467364132449938368HOEnZb"> <div class=3D"m_7467364132449938368h5"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e= x;border-left:1px #ccc solid;padding-left:1ex"> <br> =C2=A0 =C2=A0 =C2=A0Brian<br> <br> ______________________________<wbr>_________________<br> v6ops mailing list<br> <a href=3D"mailto:v6ops@ietf.org" target=3D"_blank">v6ops= @ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/v6ops" r= el=3D"noreferrer" target=3D"_blank">https://www.ietf.org/mailman/l<wbr>isti= nfo/v6ops</a><br> </blockquote> <br> ______________________________<wbr>_________________<br> v6ops mailing list<br> <a href=3D"mailto:v6ops@ietf.org" target=3D"_blank">v6ops@i= etf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/v6ops" rel= =3D"noreferrer" target=3D"_blank">https://www.ietf.org/mailman/l<wbr>istinf= o/v6ops</a><br> </div> </div> </blockquote> </div> <br> </div> </blockquote> <br> </div></div></div> </blockquote></div><br></div> --00000000000012e57d0573f562ed-- From nobody Tue Aug 21 11:57:45 2018 Return-Path: <farmer@umn.edu> 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 D0BFA130E9C for <v6ops@ietfa.amsl.com>; Tue, 21 Aug 2018 11:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, 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=umn.edu 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 ftniUwjbHFXv for <v6ops@ietfa.amsl.com>; Tue, 21 Aug 2018 11:57:41 -0700 (PDT) Received: from mta-p8.oit.umn.edu (mta-p8.oit.umn.edu [134.84.196.208]) (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 72003130E79 for <v6ops@ietf.org>; Tue, 21 Aug 2018 11:57:41 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p8.oit.umn.edu (Postfix) with ESMTP id C1342D45 for <v6ops@ietf.org>; Tue, 21 Aug 2018 18:57:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p8.oit.umn.edu ([127.0.0.1]) by localhost (mta-p8.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oo9bYIqZbKOH for <v6ops@ietf.org>; Tue, 21 Aug 2018 13:57:39 -0500 (CDT) Received: from mail-vk0-f71.google.com (mail-vk0-f71.google.com [209.85.213.71]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p8.oit.umn.edu (Postfix) with ESMTPS id 81D8DC6C for <v6ops@ietf.org>; Tue, 21 Aug 2018 13:57:39 -0500 (CDT) Received: by mail-vk0-f71.google.com with SMTP id h81-v6so8503229vke.13 for <v6ops@ietf.org>; Tue, 21 Aug 2018 11:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HJB31idLmj+ewXD0hCc98lU52x7jUXYXFvSBfcEKyAI=; b=VtIbeCxwKXXxn18i4dj0Dx52A+jPsSZIya0QVbgSO+siyCV/yWkdO3Ygs9DGYUXZtc JIjg8PJrLYoF20hMRqEg3URj4eALrDVybGVXGrz01tLkSWoRipPVq+unLch/6QDrVV66 CuWhUbivH0D+S0dVEgf/4Gg85LxWjcwifhTOavYCOzEtSG79daOY66S/y69h4bDjTfMb +TOj+9DWGplhVXs5MIwCG3ORkvhV0awlFKJs3dAGHj/QxUuBJ0VRbQ636PWtctNceHIn J8hZddr06P7SvJQ1QNWteI7XONFKR7FXpixiRbohiLONlORpaXiwHSmEw3JJVKLpe2Iz /Diw== 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=HJB31idLmj+ewXD0hCc98lU52x7jUXYXFvSBfcEKyAI=; b=F4qmJ6uor+5ehHHBY75aLbf7FZbEFCYKvsiZ1KkLZa/MlzriLAHEZHDj+lYtCJrZ1n o51zoZ42M9/AQiSL1FCB/ixtsSlv0vsSiTL+bDXctuZ8vw6xd2z1OF5R4p1zcERwdHyL /0tBykuBPrtNnkHbFJg3GTGlTQG5OoeG+GWWKyVbw8TqPc5+aPWhLA66+s2Xl4EEW6F5 ZEsGfo62CTdEwgr8HPbyBwHoKSoQaBrtCc2Q1XsJrkQwVP9L8ZkTnbXuum82ON7RkJji 0aBvKH0oLk5/0SH7socVEcm0vCv6loCvnsYKF+vlBK6imxnQPF3f4PSNmhPM5pz0QkOV ei+A== X-Gm-Message-State: AOUpUlE2KUGI/cTOkzvUsdT1AGlbGWJBB89kcaB59w89EgiSxGDbpqrD r6bMl2ZCUWk7hW4Oo3OSFZB940wIs8Oww056Ao+OviP7wyLIa1vLyjrc0+h0L+o13raSxXYRibL Z0v4xTdkAdGjkpEQCsp1kFzcPWQ== X-Received: by 2002:a9f:3f4b:: with SMTP id i11-v6mr24279969uaj.152.1534877858483; Tue, 21 Aug 2018 11:57:38 -0700 (PDT) X-Google-Smtp-Source: AA+uWPz06dbQv+we36NaUE28yzRqDE39OkQ9dWXYVYTRmY/n89nJQjR7UTryOBwziNOMtbZdAsrOx43c1SCC7A1LMBE= X-Received: by 2002:a9f:3f4b:: with SMTP id i11-v6mr24279941uaj.152.1534877858108; Tue, 21 Aug 2018 11:57:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a67:3bc7:0:0:0:0:0 with HTTP; Tue, 21 Aug 2018 11:57:37 -0700 (PDT) In-Reply-To: <3BE77332-B5FA-48F3-B881-45F60DA6643B@consulintel.es> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <3BE77332-B5FA-48F3-B881-45F60DA6643B@consulintel.es> From: David Farmer <farmer@umn.edu> Date: Tue, 21 Aug 2018 13:57:37 -0500 Message-ID: <CAN-Dau3JZOq+9jAt-oj3R0T3nC5Qy1tnyC_9r1U8GjTTWb88Lw@mail.gmail.com> To: JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org> Cc: Fred Baker <fredbaker.ietf@gmail.com>, "v6ops@ietf.org list" <v6ops@ietf.org> Content-Type: multipart/alternative; boundary="00000000000081a9c60573f699a6" Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/QUwXMkITd_6VtiD0Xlm62pKIIcE> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 21 Aug 2018 18:57:44 -0000 --00000000000081a9c60573f699a6 Content-Type: text/plain; charset="UTF-8" On Fri, Aug 17, 2018 at 8:09 PM, JORDI PALET MARTINEZ < jordi.palet=40consulintel.es@dmarc.ietf.org> wrote: > Hi Fred, > > I will be happy to join, but first I think we need to clarify what is > IPv6-only in the scope of this document/work ... > > Are we talking about a network that in the "customer" LANs doesn't have > ANY IPv4 and never connects to any "IPv4-only remote site". > > Are the access links IPv6-only ? Or the LANs are IPv6 only, but the access > links are dual-stack? > > Or the LAN's don't have IPv4, but apps, running IPv6 can connect to remote > "IPv4-only sites" (so the network or the access provider) has a NAT64 or > equivalent mechanism? > > I recall we tried to clarify this definition in a previous document, and I > still see everybody reading different things ... > I don't think there is a single answer to this question, it is context dependent. In an ISP context, since CE routers are fairly typical. I think the IPv6-only designation means IPv6-only from the customer edge through the ISP's backbone, to the ISP's internet edge. Allowing IPv4 on the customer LAN, probably with something like 464XLAT/CLAT in the CE router. With NAT64 occurring near the ISP Internet edge. However, larger enterprises don't commonly have CE routers. Larger enterprise access LANs frequently connect directly to enterprise backbone routers or layer 3 switches that don't typically include features like 464XLAT/CLAT. Again with NAT64 occurring near the enterprise Internet edge. So at least in my opinion in the context of these larger enterprises, the LAN is included in the IPv6-only designation and if there is 464XLAT/CLAT function, it needs to occur in the enterprise host itself or it needs a bump-in-the-host. There is another option, but at least in my enterprise environment it isn't practical, all applications could be IPv6 enabled. Whereas very small enterprises or SOHO environments will have a CE router and the LAN may not matter in the IPv6-only designation. Then again there are ISP environments without CE routers, like an IPv6-only Public WiFi, in this case, the LAN is probably included in the IPv6-only designation. And again, if there is a the 464XLAT/CLAT function, it needs to occur in the host itself or the host needs a bump-in-the-host, or all applications need to be IPv6 enabled. So, I guess the question I have, as a network operator is, do most host OSes either implement a 464XLAT/CLAT function or a bump-in-the-host or require all applications to be IPv6 enabled? I'm not sure it is the IETF's job to provide this information, but it will be useful if we expect IPv6-only deployments to proceed. I'm not saying there can't be gaps, but as a network operator, I need to understand what the gaps are before I can proceed with production IPv6-only deployments. Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --00000000000081a9c60573f699a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><br></div><div><div class=3D"gmail_extra"><div class= =3D"gmail_quote">On Fri, Aug 17, 2018 at 8:09 PM, JORDI PALET MARTINEZ <spa= n dir=3D"ltr"><<a href=3D"mailto:jordi.palet=3D40consulintel.es@dmarc.ie= tf.org" target=3D"_blank">jordi.palet=3D40consulintel.es@<wbr>dmarc.ietf.or= g</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi= n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex= ">Hi Fred,<br> <br> I will be happy to join, but first I think we need to clarify what is IPv6-= only in the scope of this document/work ...<br> <br> Are we talking about a network that in the "customer" LANs doesn&= #39;t have ANY IPv4 and never connects to any "IPv4-only remote site&q= uot;.<br> <br> Are the access links IPv6-only ? Or the LANs are IPv6 only, but the access = links are dual-stack?<br> <br> Or the LAN's don't have IPv4, but apps, running IPv6 can connect to= remote "IPv4-only sites" (so the network or the access provider)= has a NAT64 or equivalent mechanism?<br> <br> I recall we tried to clarify this definition in a previous document, and I = still see everybody reading different things ...<br></blockquote><div><br><= /div><div><div>I don't think there is a single answer to this question,= it is context dependent.=C2=A0=C2=A0</div><div><br></div><div>In an ISP co= ntext, since CE routers are fairly typical. I think the IPv6-only designati= on means IPv6-only from the customer edge through the ISP's backbone, t= o the ISP's internet edge.=C2=A0 Allowing IPv4 on the customer LAN, pro= bably with something like 464XLAT/CLAT in the CE router. With NAT64 occurri= ng near the ISP Internet edge.</div><div><br></div><div>However, larger ent= erprises don't commonly have CE routers. Larger enterprise access LANs = frequently connect directly to enterprise backbone routers or layer 3 switc= hes that don't typically include features like 464XLAT/CLAT.=C2=A0 Agai= n with NAT64 occurring near the enterprise Internet edge. So at least in my= opinion in the context of these larger enterprises, the LAN is included in= the IPv6-only designation and if there is 464XLAT/CLAT function, it needs = to occur in the enterprise host itself or it needs a bump-in-the-host. Ther= e is another option, but at least in my enterprise environment it isn't= practical, all applications could be IPv6 enabled. Whereas very small ente= rprises or SOHO environments will have a CE router and the LAN may not matt= er in the IPv6-only designation.</div><div><br></div><div>Then again there = are ISP environments without CE routers, like an IPv6-only Public WiFi, in = this case, the LAN is probably included in the IPv6-only designation. And a= gain, if there is a the 464XLAT/CLAT function, it needs to occur in the hos= t itself or the host needs a bump-in-the-host, or all applications need to = be IPv6 enabled.</div><div><br></div><div>So, I guess the question I have, = as a network operator is, do most host OSes either implement a 464XLAT/CLAT= function or a bump-in-the-host or require all applications to be IPv6 enab= led? I'm not sure it is the IETF's job to provide this information,= but it will be useful if we expect IPv6-only deployments to proceed. I'= ;m not saying there can't be gaps, but as a network operator, I need to= understand what the gaps are before I can proceed with production IPv6-onl= y deployments.</div><div><br></div><div>Thanks.</div></div><div><br></div><= div><div style=3D"text-decoration-style:initial;text-decoration-color:initi= al;background-color:rgb(255,255,255)"><br></div></div></div>-- <br><div cla= ss=3D"gmail-m_2707869734280523939gmail_signature">=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<wbr>=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>David Farmer=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 <a href=3D"mailto:Email%3Afarm= er@umn.edu" target=3D"_blank">Email:farmer@umn.edu</a><br>Networking & = Telecommunication Services<br>Office of Information Technology<br>Universit= y of Minnesota=C2=A0=C2=A0 <br>2218 University Ave SE=C2=A0 =C2=A0 =C2=A0 = =C2=A0 Phone: 612-626-0815<br>Minneapolis, MN 55414-3029=C2=A0=C2=A0 Cell: = 612-812-9952<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<wbr>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D<br></div> </div></div></div> --00000000000081a9c60573f699a6-- From nobody Tue Aug 21 12:16:33 2018 Return-Path: <gert@space.net> 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 44A00130E4F for <v6ops@ietfa.amsl.com>; Tue, 21 Aug 2018 12:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 RE9cyXz3RrYx for <v6ops@ietfa.amsl.com>; Tue, 21 Aug 2018 12:16:30 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F10E2130DF7 for <v6ops@ietf.org>; Tue, 21 Aug 2018 12:16:29 -0700 (PDT) X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id F27F7438CC for <v6ops@ietf.org>; Tue, 21 Aug 2018 21:16:27 +0200 (CEST) X-SpaceNet-Relay: true X-SpaceNet-Relay: true X-SpaceNet-Relay: true Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id E1C7E40EDA; Tue, 21 Aug 2018 21:16:27 +0200 (CEST) Received: by moebius4.space.net (Postfix, from userid 1007) id D1DC19AA0B; Tue, 21 Aug 2018 21:16:27 +0200 (CEST) Date: Tue, 21 Aug 2018 21:16:27 +0200 From: Gert Doering <gert@space.net> To: Ted Lemon <mellon@fugue.com> Cc: Lee Howard <lee@asgard.org>, IPv6 Ops WG <v6ops@ietf.org> Message-ID: <20180821191627.GD11393@Space.Net> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> <CAD6AjGQ_OBFGJb_C+mP_87nu7q_oXPrTvxhaV_=RcubeHtMy2Q@mail.gmail.com> <E345387F-6C1D-49D4-8B03-52D04498DDA5@lists.zabbadoz.net> <a9eeba1b-76dc-a69f-aabe-04fa4ddc3a4f@gmail.com> <e560c82c-085e-60fe-2076-70e3624696c0@asgard.org> <CAPt1N1mAELodigHMdNGQEhr0bmHv0oruhAAHNZDjCA4BummBDw@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CAPt1N1mAELodigHMdNGQEhr0bmHv0oruhAAHNZDjCA4BummBDw@mail.gmail.com> X-NCC-RegID: de.space User-Agent: Mutt/1.10.0 (2018-05-17) Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/YfElPQ33iXCR0mL9UyWlbcmyidc> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 21 Aug 2018 19:16:32 -0000 Hi, On Tue, Aug 21, 2018 at 12:26:14PM -0400, Ted Lemon wrote: > What's the state of SIP over IPv6 these days? At least one german access providers uses this, and it seems to work. (Over here, an end user account is fairly often "native IPv6 and DS-Lite for IPv4" these days, and the providers' own SIP stuff is done via IPv6. AVM Fritz!Box, m-net.de) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Tue Aug 21 16:02:24 2018 Return-Path: <internet-drafts@ietf.org> 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 7FBEC130DE6; Tue, 21 Aug 2018 16:02:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: <i-d-announce@ietf.org> Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <153489253646.9387.9350845947461725637@ietfa.amsl.com> Date: Tue, 21 Aug 2018 16:02:16 -0700 Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/-fMAdl1aTXrWoTfZNCEAX2Pew64> Subject: [v6ops] I-D Action: draft-ietf-v6ops-conditional-ras-08.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 21 Aug 2018 23:02:17 -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-08.txt Pages : 21 Date : 2018-08-21 Abstract: This document discusses the most common scenarios of connecting an enterprise network to multiple ISPs using an address space assigned by an ISP and how the approach proposed in the "ietf-rtgwg- enterprise-pa-multihoming" draft could be applied in those scenarios. 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 adopts the approach proposed in the "ietf-rtgwg-enterprise-pa-multihoming" draft to provide a solution 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-conditional-ras-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-conditional-ras-08 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 Tue Aug 21 16:10:02 2018 Return-Path: <furry13@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721D0130DEE; Tue, 21 Aug 2018 16:09:52 -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 dMFTwX6iJrDt; Tue, 21 Aug 2018 16:09:51 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::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 D6C41130DCA; Tue, 21 Aug 2018 16:09:50 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id f8-v6so47582ljk.1; Tue, 21 Aug 2018 16:09:50 -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=xhKEQyy4ndcAv5DNmin2Mz1stmw9gDnORAkfBKVneuw=; b=CkHqnVCVpybvqzu7pzGKNGwrCpN9rmcECNt/t8LK9uHczIqiqmCZlbyCCazM3Th/42 xMQvdMr64pax0BRmTD0W9U6onPpKAiRhGTcw/A2DLfRB5S/hxWFjX5Vp9QD7PPRFhp83 JwEt6noYQm9E3zvfD+CDxBUIGN0L/hz8WRLHg+ebaT3Wul86gVP52uBG2GDY95CpXb4x t6y/kVPzZ353uEhPzrS5Ig4aUNvCkGkh2tBkqOcYh1ylo3yawGt5rCXSOkJbiHrKNytc XhLipIcO7r1GCeSXEcDm1FtU3UDy86PcYoVpM0JnYxqBGaI1GpAUFIn36zaZTooYlBPo lIMg== 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=xhKEQyy4ndcAv5DNmin2Mz1stmw9gDnORAkfBKVneuw=; b=FIz9+j4ELmceJYAYaCZ/KKm5FEdqZNEVJkO9VzTOZeKCzk6eb00NDyn2ZWWGOgo/gH VEtF4SGUL9nz21FiYhure3ZEc5oX2IjdlI4v5ynkKtiS9nhpWv8rdkoU+PrsW3erBleK X/9E43MeRr5PvsbHLbnsOP8Bgjwl1q+/qVmcJl0Cvm7eqcn/dYehKhoNtiM8QKTk5UxC 1HmpsWopvx8HkKsHRJxX12rmthlXkSOvedL15cnrICkM9dF5N+KQYDdmm1S3lPfL40se FYzcpuHmEbUarJm23NHyQ+/bjxVr1qIRxj2BmPhNfm6ecagYnl2ZTI+FNyvTKNK/dPJZ FK0Q== X-Gm-Message-State: AOUpUlFi9YrJO2IGyV5lK6hLt1YYcw+TOvkXvR2wPm3DzThQOUC5GiM7 YPZyfEpv7t68JX4vwUQikH5AOEPnzSRAxefZJRXpV+SH X-Google-Smtp-Source: ANB0VdbfE4qD7eRUNhp0U++KfcsVuRK/SYUwCe56KUQk7jEtWrTFsBAHCV04IvWcOVWWrkmfHSiS3ltla2q7/yYJD24= X-Received: by 2002:a2e:1b4a:: with SMTP id b71-v6mr4149757ljb.104.1534892988965; Tue, 21 Aug 2018 16:09:48 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:1d82:0:0:0:0:0 with HTTP; Tue, 21 Aug 2018 16:09:28 -0700 (PDT) In-Reply-To: <CAJE_bqeEUKWBA1St3du0aJ=KQJenj-j0XGXwiPQGk9CZJN24Gg@mail.gmail.com> References: <153321790308.2265.731201835682425291.idtracker@ietfa.amsl.com> <CAFU7BAQVqWajKtnsAZ4Ys52BZS7hkoD2E0vmB-Dg=+pYndxCMQ@mail.gmail.com> <CAJE_bqeEUKWBA1St3du0aJ=KQJenj-j0XGXwiPQGk9CZJN24Gg@mail.gmail.com> From: Jen Linkova <furry13@gmail.com> Date: Wed, 22 Aug 2018 09:09:28 +1000 Message-ID: <CAFU7BASV+gJmgoBRb6eTpAioUQN73LVc5BZvBKU-hEgk_mvUkQ@mail.gmail.com> To: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp> Cc: Suresh Krishnan <suresh@kaloom.com>, Russ White <russ@riw.us>, draft-ietf-v6ops-conditional-ras@ietf.org, V6 Ops List <v6ops@ietf.org>, v6ops-chairs@ietf.org, The IESG <iesg@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/XJhGA0z3guz_a3xGouWYf7Xapwk> Subject: Re: [v6ops] Suresh Krishnan's Yes on draft-ietf-v6ops-conditional-ras-06: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 21 Aug 2018 23:09:53 -0000 I've submitted -08 version https://datatracker.ietf.org/doc/draft-ietf-v6ops-conditional-ras/ where "Actually it would not even be possible as Section 5.5.3 of [RFC4862] prevents hosts from setting valid lifetime for addresses to zero." is replaced with "Actually it would not even be possible for unauthenticated RAs (which is the most common deployment scenario) as Section 5.5.3 of RFC4862] prevents hosts from setting valid lifetime for addresses to zero unless RAs are authenticated." On Sat, Aug 11, 2018 at 3:27 AM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 <jinm= ei@wide.ad.jp> wrote: > At Fri, 10 Aug 2018 22:25:50 +1000, > Jen Linkova <furry13@gmail.com> wrote: > >> I've added a paragraph clarifying that we only modify preferred >> lifetime and that RFC4862 does not >> allow an RA with both preferred and valid lifetime for the prefix set >> to 0 to invalidate the address completely: >> >> https://tools.ietf.org/html/draft-ietf-v6ops-conditional-ras-07 > > To be very accurate, it's still allowed if the RA is authenticated: > > Neighbor Discovery [RFC3971]). If the Router Advertisement > was authenticated, the valid lifetime of the corresponding > address should be set to the Valid Lifetime in the received > option. > > (whether v6ops-conditional-ras should be this accurate is a different > question, for which I don't have a strong opinion) > > -- > JINMEI, Tatuya --=20 SY, Jen Linkova aka Furry From nobody Tue Aug 21 16:14:52 2018 Return-Path: <furry13@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F63130DE6 for <v6ops@ietfa.amsl.com>; Tue, 21 Aug 2018 16:14:51 -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 HUebDbqkR62E for <v6ops@ietfa.amsl.com>; Tue, 21 Aug 2018 16:14:50 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 D76F4130DCA for <v6ops@ietf.org>; Tue, 21 Aug 2018 16:14:49 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id z11-v6so32098lff.9 for <v6ops@ietf.org>; Tue, 21 Aug 2018 16:14:49 -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=vctfQxLlk4UMnPck21wihixKCl8KJGQeEqFMna+oc1k=; b=AUjoa1bghB0fwCOlCV8tgAfEeyYjIMXjpE+M/Rqc3JTSreZa8RvveaWWYBCtGsup5V RB9HtLqf0TXPFL2U+YStwfFV5T8WyCzCGWoP7LozNGWOq14/VfPX6hWSeZ4gP0ENMiib df+v1rh89WpKfVzCZOnFhJw55MlrRdHvQO6QDnWfEQTTg6uigNyDHQnYhXWnrn9osNsJ ePNwpVHT4apg15QUS0JF7C5PopEyRHPPQumM+i/vnw/j/7RULzNkL4h6ms/M28rtV3/x +EkTu4tv0TUWgbwBJsncPoDEPzv5qEv0NRF9Km4DAOt6XfNUAVI1eqQDBntUOBMJeTrz pUMg== 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=vctfQxLlk4UMnPck21wihixKCl8KJGQeEqFMna+oc1k=; b=Nsb9OP0bKZ3pmm3NzjmzaWdn3CYPtilZufQjhv8QZHdq01hEl6x1bCIT9HqDgeW5Rp DsmCXKwfOJ34EYTI4EgICXvpzM2hcCGCFKLfhIPfX2H3YeR9b/FBy7MBf/OTzciZT+SC jf6NNRNR1Uj5iKwVBdLZYEQ0v9xPiKUyR0KCLThTsH6D2Y702B0IZ32OGjSWHBAIwemr dbADZ5Jq7xtqewn8n3A5ETOarOSmFp0OwfoR/1sVaNVYidiW14r10yqPULQjkA1OJOXv 55Ezm/+ar/veuVeqnM67tIGRO6npkYNgiw6BD9cttcbdGE0VmD2m/2TueKJ5hAOXxtEb MHCQ== X-Gm-Message-State: AOUpUlE8csy0ERkB/q0m7ZjtXMrh8C0GUSAXiANBUw8iqPjpYCtRC/el Wa1fiC0/XaZ9MMnUlbTPxVKLOacl0iLXJ8EFqZyVZQ== X-Google-Smtp-Source: AA+uWPy6U14ZCssiKQTLTy6XQMNAY2Mlb9Yzrc2Y2SLmha0PPD9UUMvMUzq+2HwMaDzqAksbGjEoKMwNrPsBvBdCpDI= X-Received: by 2002:a19:16d8:: with SMTP id 85-v6mr13016294lfw.142.1534893288047; Tue, 21 Aug 2018 16:14:48 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:1d82:0:0:0:0:0 with HTTP; Tue, 21 Aug 2018 16:14:27 -0700 (PDT) In-Reply-To: <e560c82c-085e-60fe-2076-70e3624696c0@asgard.org> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> <CAD6AjGQ_OBFGJb_C+mP_87nu7q_oXPrTvxhaV_=RcubeHtMy2Q@mail.gmail.com> <E345387F-6C1D-49D4-8B03-52D04498DDA5@lists.zabbadoz.net> <a9eeba1b-76dc-a69f-aabe-04fa4ddc3a4f@gmail.com> <e560c82c-085e-60fe-2076-70e3624696c0@asgard.org> From: Jen Linkova <furry13@gmail.com> Date: Wed, 22 Aug 2018 09:14:27 +1000 Message-ID: <CAFU7BASn9QT7tMdF-f7urAYUx3Uji4rf5jzN7owfmRwm0FM1jA@mail.gmail.com> To: Lee Howard <lee@asgard.org> Cc: V6 Ops List <v6ops@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/8HnhhXiUZxlwTywxifi3KnK-7sA> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 21 Aug 2018 23:14:51 -0000 On Wed, Aug 22, 2018 at 2:20 AM, Lee Howard <lee@asgard.org> wrote: > I will boldly assert that there are no RFCs requiring updates in order to > deploy IPv6-only. I'm afraid some RFCs might need clarifications (or one might call it 'guidance to vendors/implementors') to make sure IPv6-only works as well (from end-user perspective) as dual-stack networks. -- SY, Jen Linkova aka Furry who has spent significant amount of time recently troubleshooting IPv6-only networks.... From nobody Tue Aug 21 16:38:44 2018 Return-Path: <jinmei.tatuya@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97AF4129C6B; Tue, 21 Aug 2018 16:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.917 X-Spam-Level: X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 K-0nKsJLKDIl; Tue, 21 Aug 2018 16:38:35 -0700 (PDT) Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45]) (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 B4D10127148; Tue, 21 Aug 2018 16:38:34 -0700 (PDT) Received: by mail-lf1-f45.google.com with SMTP id e23-v6so51884lfc.13; Tue, 21 Aug 2018 16:38:34 -0700 (PDT) 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=G++osF0SMi1GQSzX87mCaN/xvvPtCv2TWPHDNK//fLM=; b=KXoGjsI4avFjfDtckWFnMCjpi4IE1E7ybVwoNbECC9eJciNrrk4ohqeyRNyUK0Kvni OH3binSkAS2XkEY9nvxSm5It8t84fS/WkEvXTDBFciS+B/TcLT9IvZuvE16MKM8p1nIi AoJtpCfrTDA3aUNfKi5woqdpd6zMnr0bmryFeA+qK4dv1DjoRhMsvTTjCCDPIjs1Xrec 8eRLmVfVBpWNvfH23oqT+oNWGW9jiYyhE1OiFiG2yNhzzYzAzU0IppmgmWv7Rll2zdID Fy8kRlwe05tirH1tGpiajeipVNI4lO0KfBeTvl3jPuWV1fnLwTf27lUSjYWvBS83nPgi rPRw== X-Gm-Message-State: AOUpUlHrk9eF1G+QoyNS6JPjFhoB4qpSnIQBzkqbcKwRlk8hpEkSDqpM Y/p7OLufVGhJ2tC8tXbx9pM0z9Y4l3p2U/M4zAk= X-Google-Smtp-Source: AA+uWPxqpx3ulOHbQqs5CQSxLjtNTSow9SBugXJWYrJaYTK7M3cVpDCjrfiPZPGciIzOv2G5KodFLvkMKSt7q0sSLcE= X-Received: by 2002:a19:c4c9:: with SMTP id u192-v6mr5004958lff.87.1534894712686; Tue, 21 Aug 2018 16:38:32 -0700 (PDT) MIME-Version: 1.0 References: <153321790308.2265.731201835682425291.idtracker@ietfa.amsl.com> <CAFU7BAQVqWajKtnsAZ4Ys52BZS7hkoD2E0vmB-Dg=+pYndxCMQ@mail.gmail.com> <CAJE_bqeEUKWBA1St3du0aJ=KQJenj-j0XGXwiPQGk9CZJN24Gg@mail.gmail.com> <CAFU7BASV+gJmgoBRb6eTpAioUQN73LVc5BZvBKU-hEgk_mvUkQ@mail.gmail.com> In-Reply-To: <CAFU7BASV+gJmgoBRb6eTpAioUQN73LVc5BZvBKU-hEgk_mvUkQ@mail.gmail.com> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp> Date: Tue, 21 Aug 2018 16:38:20 -0700 Message-ID: <CAJE_bqdNXvBqLGnaY=xwifbjFNczPkSFs0QUuPuWxuDE9_LY8A@mail.gmail.com> To: Jen Linkova <furry13@gmail.com> Cc: v6ops@ietf.org, Russ White <russ@riw.us>, v6ops-chairs@ietf.org, draft-ietf-v6ops-conditional-ras@ietf.org, The IESG <iesg@ietf.org>, suresh@kaloom.com Content-Type: multipart/alternative; boundary="0000000000001e0c030573fa8630" Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Vn7lZgSbXkHVUs5-Ovt9BVg-lW4> Subject: Re: [v6ops] Suresh Krishnan's Yes on draft-ietf-v6ops-conditional-ras-06: (with COMMENT) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 21 Aug 2018 23:38:37 -0000 --0000000000001e0c030573fa8630 Content-Type: text/plain; charset="UTF-8" At Wed, 22 Aug 2018 09:09:28 +1000, Jen Linkova <furry13@gmail.com> wrote: > I've submitted -08 version > https://datatracker.ietf.org/doc/draft-ietf-v6ops-conditional-ras/ > > where > > "Actually it would not even be possible as Section 5.5.3 of [RFC4862] > prevents hosts from setting valid lifetime for > addresses to zero." > > is replaced with > > "Actually it would not even be possible for unauthenticated RAs (which > is the most common deployment scenario) as Section 5.5.3 of RFC4862] > prevents hosts from setting valid lifetime for > addresses to zero unless RAs are authenticated." (I guess it's needless to say but) looks good to me. -- JINMEI, Tatuya --0000000000001e0c030573fa8630 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">At Wed, 22 Aug 2018 09:09:28 +1000,<br>Jen Linkova <<a = href=3D"mailto:furry13@gmail.com">furry13@gmail.com</a>> wrote:<br><br>&= gt; I've submitted -08 version<br>> <a href=3D"https://datatracker.i= etf.org/doc/draft-ietf-v6ops-conditional-ras/">https://datatracker.ietf.org= /doc/draft-ietf-v6ops-conditional-ras/</a><br>> <br>> where<br>> <= br>> "Actually it would not even be possible as Section 5.5.3 of [R= FC4862]<br>> prevents hosts from setting valid lifetime for<br>> addr= esses to zero."<br>> <br>> is replaced with<br>> <br>> &qu= ot;Actually it would not even be possible for unauthenticated RAs (which<br= >> is the most common deployment scenario) as Section 5.5.3 of RFC4862]<= br>> prevents hosts from setting valid lifetime for<br>> addresses to= zero unless RAs are authenticated."<br><br>(I guess it's needless= to say but) looks good to me.<br><br>--<br>JINMEI, Tatuya<br></div> --0000000000001e0c030573fa8630-- From nobody Wed Aug 22 09:34:16 2018 Return-Path: <ljsong@biigroup.cn> 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 9EA7F126CB6 for <v6ops@ietfa.amsl.com>; Wed, 22 Aug 2018 09:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.358 X-Spam-Level: ** X-Spam-Status: No, score=2.358 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, RCVD_IN_DNSWL_NONE=-0.0001, T_KAM_HTML_FONT_INVALID=0.01] 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 zJVx3cJo-QoG for <v6ops@ietfa.amsl.com>; Wed, 22 Aug 2018 09:34:09 -0700 (PDT) Received: from smtpbgau1.qq.com (smtpbgau1.qq.com [54.206.16.166]) (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 E381212872C for <v6ops@ietf.org>; Wed, 22 Aug 2018 09:34:08 -0700 (PDT) X-QQ-mid: bizesmtp22t1534955641t0ijasgb Received: from sljpc (unknown [106.39.68.184]) by esmtp6.qq.com (ESMTP) with SMTP id 0 for <v6ops@ietf.org>; Thu, 23 Aug 2018 00:34:00 +0800 (CST) X-QQ-SSF: 00400000002000F0FLF0B00A0000000 X-QQ-FEAT: i/xzikqTSPYtmQWlST1zexND8+FuiplMrjw4fCrAYznOaVafket2FXcGrIa9G yVsZ4FF8zDYfkHhGcfz8HsWVsWyZ+IlNhu3BMYhkxqfCgeoHRNFLFufXo5XojIMEZ5t4k+S 5s/tgKx1+JU60KGIDRRq7oafy+YgX21VyGXvzEbj2HA8RJRRrPc9MwwpemHCBb7gu5iAfXH xG/wXl4S8u4pDks4sTNImgL/btmAGn1pKyGhc/o8mCmmTBXNHP/D2iYRbmy4xotNmCZb0nA InIpkjcYPvGVRGg4ztYkoxKkXgk/XmZ2CXSLlMuUjvRVTbdj4poxOtN+Zx0E4zAVXrQw== X-QQ-GoodBg: 2 From: =?gb2312?B?RGF2ZXkgU29uZyjLzsHWvaEp?= <ljsong@biigroup.cn> To: <v6ops@ietf.org> Date: Thu, 23 Aug 2018 00:34:00 +0800 Message-ID: <003701d43a35$ef01fe70$cd05fb50$@cn>+9E1A52AA77BCE4F5 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0038_01D43A78.FD253E70" X-Mailer: Microsoft Office Outlook 12.0 Content-Language: zh-cn Thread-Index: AdQ6Ne5hASiYP/GuSSK1vKRGyaJEpA== X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:biigroup.cn:qybgforeign:qybgforeign4 X-QQ-Bgrelay: 1 Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/tx3_IvXuQBr00HljUWD3ld5KXDs> Subject: [v6ops] Happyeyeballs timer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 22 Aug 2018 16:34:15 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0038_01D43A78.FD253E70 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi folks,=20 =20 I=A1=AFm writing to ask the state-of-art or best-practice happyeyeballs = timer implementation. It=A1=AFs appreciated if anyone can give me some = pointers. =20 I do know that Google chrome used 300ms in 2011. And Apple in 2015 = updated the first timer of 25ms for waiting AAAA record and second timer based = on TCP RTT. But I=A1=AFm not sure they are still the hold the same? = What=A1=AFs the HE timer for <https://en.wikipedia.org/wiki/Opera_(web_browser)> Opera, <https://en.wikipedia.org/wiki/Firefox> Firefox and <https://en.wikipedia.org/wiki/CURL> cURL AFAIK from HE WIKI. =20 Best regards, Davey =20 ------=_NextPart_000_0038_01D43A78.FD253E70 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta = http-equiv=3DContent-Type content=3D"text/html; charset=3Dgb2312"><meta = name=3DGenerator content=3D"Microsoft Word 12 (filtered = medium)"><style><!-- /* Font Definitions */ @font-face {font-family:=CB=CE=CC=E5; panose-1:2 1 6 0 3 1 1 1 1 1;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:"\@=CB=CE=CC=E5"; panose-1:2 1 6 0 3 1 1 1 1 1;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; text-align:justify; text-justify:inter-ideograph; font-size:10.5pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Calibri","sans-serif"; color:windowtext;} .MsoChpDefault {mso-style-type:export-only;} /* Page Definitions */ @page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 90.0pt 72.0pt 90.0pt;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DZH-CN link=3Dblue = vlink=3Dpurple style=3D'text-justify-trim:punctuation'><div = class=3DWordSection1><p class=3DMsoNormal><span lang=3DEN-US>Hi folks, = <o:p></o:p></span></p><p class=3DMsoNormal><span = lang=3DEN-US><o:p> </o:p></span></p><p class=3DMsoNormal><span = lang=3DEN-US>I=A1=AFm writing to ask the state-of-art or best-practice = happyeyeballs timer implementation. It=A1=AFs appreciated if anyone can = give me some pointers.<o:p></o:p></span></p><p class=3DMsoNormal><span = lang=3DEN-US><o:p> </o:p></span></p><p class=3DMsoNormal><span = lang=3DEN-US>I do know that Google chrome used 300ms in 2011. And Apple = in 2015 updated the first timer of 25ms for waiting AAAA record and = second timer based on TCP RTT. But I=A1=AFm not sure they are still the = hold the same? </span><span lang=3DEN-US = style=3D'font-family:"Arial","sans-serif";color:#222222;background:white'= > What=A1=AFs the HE timer for </span><span lang=3DEN-US><a = href=3D"https://en.wikipedia.org/wiki/Opera_(web_browser)" = title=3D"Opera (web browser)"><span = style=3D'color:windowtext;text-decoration:none'>Opera</span></a>, <a= href=3D"https://en.wikipedia.org/wiki/Firefox" title=3DFirefox><span = style=3D'color:windowtext;text-decoration:none'>Firefox</span></a> a= nd <a href=3D"https://en.wikipedia.org/wiki/CURL" = title=3DCURL><span = style=3D'color:windowtext;text-decoration:none'>cURL</span></a> AFAIK = from HE WIKI.<o:p></o:p></span></p><p class=3DMsoNormal><span = lang=3DEN-US><o:p> </o:p></span></p><p class=3DMsoNormal><span = lang=3DEN-US>Best regards,<o:p></o:p></span></p><p = class=3DMsoNormal><span lang=3DEN-US>Davey =      <o:p></o:p></span></p></div></body></html> ------=_NextPart_000_0038_01D43A78.FD253E70-- From nobody Wed Aug 22 09:55:30 2018 Return-Path: <ljsong@biigroup.cn> 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 3E14F130DD5 for <v6ops@ietfa.amsl.com>; Wed, 22 Aug 2018 09:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.342 X-Spam-Level: X-Spam-Status: No, score=-0.342 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, RCVD_IN_DNSWL_NONE=-0.0001, T_KAM_HTML_FONT_INVALID=0.01] 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 zxVLFiMWByTf for <v6ops@ietfa.amsl.com>; Wed, 22 Aug 2018 09:55:24 -0700 (PDT) Received: from smtpbg202.qq.com (smtpbg202.qq.com [184.105.206.29]) (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 B7291127598 for <v6ops@ietf.org>; Wed, 22 Aug 2018 09:55:23 -0700 (PDT) X-QQ-mid: bizesmtp18t1534956919tdy4e9dn Received: from sljpc (unknown [106.39.68.184]) by esmtp6.qq.com (ESMTP) with SMTP id 0 for <v6ops@ietf.org>; Thu, 23 Aug 2018 00:55:19 +0800 (CST) X-QQ-SSF: 00400000002000F0FLF0B00A0000000 X-QQ-FEAT: Pc2HeLh3g/8/glTRGAJ2VQLlNisJoipH8NzO5Mw+Aq9ibAi/V/22k7kU7oL+d 1/ObdQ58Y0c2XYXF/hc1WBhOj82cLSuzVBpegUKeIg2x4kzm/z9amKxCd62GyIeurw/JGjG XS9Kj37j1JVwZh3vwaHY+7UfcoGNAZhPig3+SuYWQGNY4NcJv1YUmvf3tzLuIP6cvDdfKtV 6VpGLy8l0rMqyIDFfGVsCfh+PxXk7R8w21fmNvquJ7HvXGesgh4prm/botSse6uaXAUEtb8 z+RZvVVwe8VFMGZTrrKexjWL7gwRrAho9f38shcuWpKEssCv74AbUkxhTQH1PbEZdia34ID lM0vGCg X-QQ-GoodBg: 2 From: =?gb2312?B?RGF2ZXkgU29uZyjLzsHWvaEp?= <ljsong@biigroup.cn> To: <v6ops@ietf.org> References: In-Reply-To: Date: Thu, 23 Aug 2018 00:55:19 +0800 Message-ID: <003c01d43a38$e926a2f0$bb73e8d0$@cn>+3463CD15048DE491 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003D_01D43A7B.F749E2F0" X-Mailer: Microsoft Office Outlook 12.0 Content-Language: zh-cn Thread-Index: AdQ6Ne5hASiYP/GuSSK1vKRGyaJEpAAAtYuA X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:biigroup.cn:qybgforeign:qybgforeign4 X-QQ-Bgrelay: 1 Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/t6OS2xCgc-J-HzijJpcYr4vWQ20> Subject: Re: [v6ops] Happyeyeballs timer X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 22 Aug 2018 16:55:29 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_003D_01D43A7B.F749E2F0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable I found it is recommended a 50 ms for Resolution Delay and around 250 ms = for Connection Attempt Delay in new Happyeyeballs specification (RFC8305). = Is it widely accepted in most OS and web browsers?=20 =20 Thanks, Davey =20 =20 =B7=A2=BC=FE=C8=CB: Davey Song(=CB=CE=C1=D6=BD=A1) = [mailto:ljsong@biigroup.cn]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2018=C4=EA8=D4=C223=C8=D5 0:34 =CA=D5=BC=FE=C8=CB: 'v6ops@ietf.org' =D6=F7=CC=E2: Happyeyeballs timer =20 Hi folks,=20 =20 I=A1=AFm writing to ask the state-of-art or best-practice happyeyeballs = timer implementation. It=A1=AFs appreciated if anyone can give me some = pointers. =20 I do know that Google chrome used 300ms in 2011. And Apple in 2015 = updated the first timer of 25ms for waiting AAAA record and second timer based = on TCP RTT. But I=A1=AFm not sure they are still the hold the same? = What=A1=AFs the HE timer for <https://en.wikipedia.org/wiki/Opera_(web_browser)> Opera, <https://en.wikipedia.org/wiki/Firefox> Firefox and <https://en.wikipedia.org/wiki/CURL> cURL AFAIK from HE WIKI. =20 Best regards, Davey =20 ------=_NextPart_000_003D_01D43A7B.F749E2F0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta = http-equiv=3DContent-Type content=3D"text/html; charset=3Dgb2312"><meta = name=3DGenerator content=3D"Microsoft Word 12 (filtered = medium)"><style><!-- /* Font Definitions */ @font-face {font-family:=CB=CE=CC=E5; panose-1:2 1 6 0 3 1 1 1 1 1;} @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:"\@=CB=CE=CC=E5"; panose-1:2 1 6 0 3 1 1 1 1 1;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; text-align:justify; text-justify:inter-ideograph; font-size:10.5pt; font-family:"Calibri","sans-serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal; font-family:"Calibri","sans-serif"; color:windowtext;} span.EmailStyle18 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 90.0pt 72.0pt 90.0pt;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DZH-CN link=3Dblue = vlink=3Dpurple style=3D'text-justify-trim:punctuation'><div = class=3DWordSection1><p class=3DMsoNormal align=3Dleft = style=3D'text-align:left'><span lang=3DEN-US>I found it is recommended = a 50 ms for Resolution Delay and around 250 ms = for Connection Attempt Delay in new Happyeyeballs = specification (RFC8305).  Is it widely accepted in most OS and web = browsers? <o:p></o:p></span></p><p class=3DMsoNormal align=3Dleft = style=3D'text-align:left'><span = lang=3DEN-US><o:p> </o:p></span></p><p class=3DMsoNormal = align=3Dleft style=3D'text-align:left'><span = lang=3DEN-US>Thanks,<o:p></o:p></span></p><p class=3DMsoNormal = align=3Dleft style=3D'text-align:left'><span = lang=3DEN-US>Davey<o:p></o:p></span></p><p class=3DMsoNormal><span = lang=3DEN-US style=3D'color:#1F497D'><o:p> </o:p></span></p><p = class=3DMsoNormal><a name=3D"_MailEndCompose"><span lang=3DEN-US = style=3D'color:#1F497D'><o:p> </o:p></span></a></p><div = style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm = 4.0pt'><div><div style=3D'border:none;border-top:solid #B5C4DF = 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=3DMsoNormal align=3Dleft = style=3D'text-align:left'><b><span = style=3D'font-size:10.0pt;font-family:=CB=CE=CC=E5'>=B7=A2=BC=FE=C8=CB<sp= an lang=3DEN-US>:</span></span></b><span lang=3DEN-US = style=3D'font-size:10.0pt;font-family:=CB=CE=CC=E5'> Davey = Song(</span><span = style=3D'font-size:10.0pt;font-family:=CB=CE=CC=E5'>=CB=CE=C1=D6=BD=A1<sp= an lang=3DEN-US>) [mailto:ljsong@biigroup.cn] = <br></span><b>=B7=A2=CB=CD=CA=B1=BC=E4<span = lang=3DEN-US>:</span></b><span lang=3DEN-US> 2018</span>=C4=EA<span = lang=3DEN-US>8</span>=D4=C2<span lang=3DEN-US>23</span>=C8=D5<span = lang=3DEN-US> 0:34<br></span><b>=CA=D5=BC=FE=C8=CB<span = lang=3DEN-US>:</span></b><span lang=3DEN-US> = 'v6ops@ietf.org'<br></span><b>=D6=F7=CC=E2<span = lang=3DEN-US>:</span></b><span lang=3DEN-US> Happyeyeballs = timer<o:p></o:p></span></span></p></div></div><p class=3DMsoNormal = align=3Dleft style=3D'text-align:left'><span = lang=3DEN-US><o:p> </o:p></span></p><p class=3DMsoNormal><span = lang=3DEN-US>Hi folks, <o:p></o:p></span></p><p class=3DMsoNormal><span = lang=3DEN-US><o:p> </o:p></span></p><p class=3DMsoNormal><span = lang=3DEN-US>I=A1=AFm writing to ask the state-of-art or best-practice = happyeyeballs timer implementation. It=A1=AFs appreciated if anyone can = give me some pointers.<o:p></o:p></span></p><p class=3DMsoNormal><span = lang=3DEN-US><o:p> </o:p></span></p><p class=3DMsoNormal><span = lang=3DEN-US>I do know that Google chrome used 300ms in 2011. And Apple = in 2015 updated the first timer of 25ms for waiting AAAA record and = second timer based on TCP RTT. But I=A1=AFm not sure they are still the = hold the same? </span><span lang=3DEN-US = style=3D'font-family:"Arial","sans-serif";color:#222222;background:white'= > What=A1=AFs the HE timer for </span><span lang=3DEN-US><a = href=3D"https://en.wikipedia.org/wiki/Opera_(web_browser)" = title=3D"Opera (web browser)"><span = style=3D'color:windowtext;text-decoration:none'>Opera</span></a>, <a= href=3D"https://en.wikipedia.org/wiki/Firefox" title=3DFirefox><span = style=3D'color:windowtext;text-decoration:none'>Firefox</span></a> a= nd <a href=3D"https://en.wikipedia.org/wiki/CURL" = title=3DCURL><span = style=3D'color:windowtext;text-decoration:none'>cURL</span></a> AFAIK = from HE WIKI.<o:p></o:p></span></p><p class=3DMsoNormal><span = lang=3DEN-US><o:p> </o:p></span></p><p class=3DMsoNormal><span = lang=3DEN-US>Best regards,<o:p></o:p></span></p><p = class=3DMsoNormal><span lang=3DEN-US>Davey =      <o:p></o:p></span></p></div></div></body></= html> ------=_NextPart_000_003D_01D43A7B.F749E2F0-- From nobody Sun Aug 26 17:51:07 2018 Return-Path: <songlinjian@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B910130DE2 for <v6ops@ietfa.amsl.com>; Sun, 26 Aug 2018 17:51:06 -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, HTML_MESSAGE=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 uMhf6cTMnxPV for <v6ops@ietfa.amsl.com>; Sun, 26 Aug 2018 17:51:04 -0700 (PDT) Received: from mail-ua1-x92f.google.com (mail-ua1-x92f.google.com [IPv6:2607:f8b0:4864:20::92f]) (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 3AE0F1277C8 for <v6ops@ietf.org>; Sun, 26 Aug 2018 17:51:04 -0700 (PDT) Received: by mail-ua1-x92f.google.com with SMTP id w7-v6so8537398uan.9 for <v6ops@ietf.org>; Sun, 26 Aug 2018 17:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=VjWAUtiEuJkvJC7sFJvosRqPzNSRBJbGmGTQUgwoWeY=; b=RJcaGmN5G5O3So0HfqmE2d9Mm3GKPqJujqkLplt1u0oQ182/5XQOLhwLqjuM7uzrUz LleT5Qk3rPXD1DnhKGToZqAp5JDvpFY3qVVBUviI6oCoRhySQnBu43aH/sTxg+9k0nvW /+RCTzDQ+r/8/qj+mqSYDtb92GO2z40UrMXPEq+wry4nErW1OziixMeLobT6u990/zeH klJjN0U4xEJ8kaf+n6149jp8nzda28eGT67R+8H6KVYHM9fnG6S4wZf4VbutM+I0tMu8 Wyx6mAgskgSDSdpmf4hz4EfYkNqoq/K6HKAp1zfyHpS3qNQwyXGnvAgmS4L7w5rt5uCF gDqw== 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=VjWAUtiEuJkvJC7sFJvosRqPzNSRBJbGmGTQUgwoWeY=; b=k/r8r5mZnrM2ArrVkmHtVaav5QK9jfMBsyBAhkrPe1TYod+HQqBJha0GBs/K+m6ZuE yedwcG1ytHUtG18umQK3ip4l2hXMFFwvgAaedZDVrms658xRjcU3cgc+Fa9BjiTtygOe 2Q+EOu/MBFs6OWNQDQc+DZh8qEaV8PfJCyH/6RyCoUR527C5YhCP6+rAhp6aph+/IA3v bQRqlqU5wpynzZ8Bqudw/kyWMjLbgK22H0SOY0rPQfLj4b3FTwtb3bYlhn/iJXDx6hYw a3ipaFHjPhDmwsrf2vZY0kixcJYIXlv4Y5vbgTN1TZoFsophIgID+N/BeoxgXQ4wscEK QAvw== X-Gm-Message-State: APzg51A4UA+/ZNoQhktkF3Ma2NoUnfQ6ySn6paG5zhBrA4BO+q+JpkcF vAZRg/ZvbPQ/GjCy+bY4JPpuUBr1j1mKIDGWJKqnGa2z X-Google-Smtp-Source: ANB0VdbAKy1k7t2UwTXVz3qw07RMBgjyS/j9Qd99hZ3nGRFzGqOqvO95MGnFlsmEq2HgvRi3qY7qaER9wkB+9PH3W6Y= X-Received: by 2002:ab0:3242:: with SMTP id r2-v6mr7277623uan.92.1535331063041; Sun, 26 Aug 2018 17:51:03 -0700 (PDT) MIME-Version: 1.0 From: Davey Song <songlinjian@gmail.com> Date: Mon, 27 Aug 2018 08:50:55 +0800 Message-ID: <CAAObRXLe35KoONVsSO_oU+SRhMzMrKRE_SU-QNf2pGHYKpUrxA@mail.gmail.com> To: v6ops@ietf.org Content-Type: multipart/alternative; boundary="000000000000a015120574601e01" Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/D1E3dk54pgW_9B0egEXRtJAHQg4> Subject: [v6ops] How my Android phone got assigned with IPv6 address via 4G LTE? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 27 Aug 2018 00:51:06 -0000 --000000000000a015120574601e01 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi folks, Recently the IPv6 4G LTE of China moible and China Telecom is working. And I got the address information on my android phone, like : China Mobile : 2409:8900:8a10:6dof:4177:9599:de56:7092 China Telecom: 240e:ff:b10a:54a9:b5f7:5e4c:2f2d:9847 My question is : How these IPv6 addresses are assigned to my pohone and what type of address they are? They looks no EUI-64 address, without FFFE in the middle of low 64 bits. And it can not be done by DHCPv6 because I heard Android does not support DHCPv6, right? I'm not sure how my LTE provider provisioning IPv6 address. So The only possbile way is SLAAC+private address=EF=BC=9F Anyone who can help me out on this question? Or share your experience on how the mobile ISP commonly provison their users. Thanks. Best regards, Davey --000000000000a015120574601e01 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Hi folks,<div><br></div><div>Recently the IPv6 4G LTE of C= hina moible and China Telecom is working. And I got the address information= on my android phone, like :</div><div><br></div><div>China Mobile : 2409:8= 900:8a10:6dof:4177:9599:de56:7092</div><div>China Telecom: 240e:ff:b10a:54a= 9:b5f7:5e4c:2f2d:9847</div><div><br></div><div>My question is : How these I= Pv6 addresses are assigned to my pohone and what type of address they are?= =C2=A0 They looks no EUI-64 address, without FFFE in the middle of low 64 b= its.=C2=A0 And it can not be done by DHCPv6 because I heard Android does no= t support DHCPv6, right?=C2=A0 I'm not sure how my LTE provider provisi= oning IPv6 address. So The only possbile way is SLAAC+private address=EF=BC= =9F=C2=A0=C2=A0</div><div><br></div><div>Anyone who can help me out on this= question? Or share your experience on how the mobile ISP commonly provison= their users. Thanks.=C2=A0</div><div><br></div><div>Best regards,</div><di= v>Davey</div></div> --000000000000a015120574601e01-- From nobody Sun Aug 26 18:01:55 2018 Return-Path: <lorenzo@google.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE0C1277C8 for <v6ops@ietfa.amsl.com>; Sun, 26 Aug 2018 18:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.712 X-Spam-Level: X-Spam-Status: No, score=-16.712 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, HTML_MESSAGE=0.001, MIME_BOUND_DIGITS_15=0.798, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no 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 otqAxX6j8hUX for <v6ops@ietfa.amsl.com>; Sun, 26 Aug 2018 18:01:52 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 7966E130DEB for <v6ops@ietf.org>; Sun, 26 Aug 2018 18:01:52 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id u13-v6so379915iti.1 for <v6ops@ietf.org>; Sun, 26 Aug 2018 18:01:52 -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=8g6cDOLKAO3J6ww4T1EXGnhPoCRcUTkGg7wEaWq5Xv4=; b=oAwxg19QTrENRjT8OKqb5Psh9W3bxL9XZiEUElFC0iLcpVDIaopyECbV7MlML85mJh GQnylJpoTITUjBUxCSiJ1HlQtbZQRKqFLGruVDHEmZlY9mmhGQ+BORTCPDCzWLxAVf27 1tv9llSDuzHB52SEB9uNloDAoTK1pCRWmhTWqPrVaPcTph2Imj36TUJXClMQByYJAOmT DDYNBWWL8UDY7Gfed8VZLrC5Xre+Y9uwSpOmWoway8+pPMJ73N6zhTOHmTiK9bZ77xqI lswHchEL4h7ZzwV82NEOsBnm2viUp4h/kaRXmhNTDEPlZxdYVKJUZpbUGIKCnQnRTLFw Xo1Q== 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=8g6cDOLKAO3J6ww4T1EXGnhPoCRcUTkGg7wEaWq5Xv4=; b=IReKuiol5fouVQZRSvbKtpx/6sW9UwtJCjJ9yyHzjdM3CUkUo1Dj1XBmxrkBUu8urf mRH5bgPNKqPPkSfMsV2xNhIm+tnFT/x4aB8B+qSmuSul70N6VxP5XFenBLFizIKFR/yH p9ojTWpOzxlpm24Nt2kKrVYnwy3YRXrKsBnEGASya3Sc331tbQRiHN8/7frz8hnSrmXU ErSYGEsT0WcRXgpicnSP/fUPUcslHRKbsWCKEZbP36FoqT5qluKAe87HPbiHghvLwGlT 8AkNliRVrHFnMs+N4L7IZABY0JUXeGqBVGUL5UHjqaK46FPsnd3NdBRp1N5LnR1O6rVj Y30w== X-Gm-Message-State: APzg51AsY0qmhWevJR/HhS45YjFRO6Qk3ZpeBpSwmsh4O82swlnYJpwH TV6Anu4egFFheR9TTNEmkIbpfyxWOGYkFaC9so2CbA== X-Google-Smtp-Source: ANB0VdboVBLmnA3ro1Zz8Ms2d+h4My+E4lL7VkZM9UVJd6Y91gsR0mW+rgne2VAUNbIrtNrYsjfGR13oQjsGnERSFA4= X-Received: by 2002:a24:8282:: with SMTP id t124-v6mr5488747itd.57.1535331711180; Sun, 26 Aug 2018 18:01:51 -0700 (PDT) MIME-Version: 1.0 References: <CAAObRXLe35KoONVsSO_oU+SRhMzMrKRE_SU-QNf2pGHYKpUrxA@mail.gmail.com> In-Reply-To: <CAAObRXLe35KoONVsSO_oU+SRhMzMrKRE_SU-QNf2pGHYKpUrxA@mail.gmail.com> From: Lorenzo Colitti <lorenzo@google.com> Date: Mon, 27 Aug 2018 10:01:39 +0900 Message-ID: <CAKD1Yr1mzVu8B382z19RJPEEo1RcRTvy5YAH9cRVWgu6cn6h0w@mail.gmail.com> To: songlinjian@gmail.com Cc: "v6ops@ietf.org WG" <v6ops@ietf.org> Content-Type: multipart/alternative; boundary="0000000000004297060574604539" Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/vyE8Zl3RHsGtPQk28DSBRATzv2Y> Subject: Re: [v6ops] How my Android phone got assigned with IPv6 address via 4G LTE? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 27 Aug 2018 01:01:54 -0000 --0000000000004297060574604539 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable See RFC 6459, and if you want more detail, the various 3GPP documents listed in the references section of that RFC. On Mon, Aug 27, 2018 at 9:51 AM Davey Song <songlinjian@gmail.com> wrote: > Hi folks, > > Recently the IPv6 4G LTE of China moible and China Telecom is working. An= d > I got the address information on my android phone, like : > > China Mobile : 2409:8900:8a10:6dof:4177:9599:de56:7092 > China Telecom: 240e:ff:b10a:54a9:b5f7:5e4c:2f2d:9847 > > My question is : How these IPv6 addresses are assigned to my pohone and > what type of address they are? They looks no EUI-64 address, without FFF= E > in the middle of low 64 bits. And it can not be done by DHCPv6 because I > heard Android does not support DHCPv6, right? I'm not sure how my LTE > provider provisioning IPv6 address. So The only possbile way is > SLAAC+private address=EF=BC=9F > > Anyone who can help me out on this question? Or share your experience on > how the mobile ISP commonly provison their users. Thanks. > > Best regards, > Davey > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --0000000000004297060574604539 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">See RFC 6459, and if you want more detail, the various 3GP= P documents listed in the references section of that RFC.</div><br><div cla= ss=3D"gmail_quote"><div dir=3D"ltr">On Mon, Aug 27, 2018 at 9:51 AM Davey S= ong <<a href=3D"mailto:songlinjian@gmail.com">songlinjian@gmail.com</a>&= gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0= .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi folk= s,<div><br></div><div>Recently the IPv6 4G LTE of China moible and China Te= lecom is working. And I got the address information on my android phone, li= ke :</div><div><br></div><div>China Mobile : 2409:8900:8a10:6dof:4177:9599:= de56:7092</div><div>China Telecom: 240e:ff:b10a:54a9:b5f7:5e4c:2f2d:9847</d= iv><div><br></div><div>My question is : How these IPv6 addresses are assign= ed to my pohone and what type of address they are?=C2=A0 They looks no EUI-= 64 address, without FFFE in the middle of low 64 bits.=C2=A0 And it can not= be done by DHCPv6 because I heard Android does not support DHCPv6, right?= =C2=A0 I'm not sure how my LTE provider provisioning IPv6 address. So T= he only possbile way is SLAAC+private address=EF=BC=9F=C2=A0=C2=A0</div><di= v><br></div><div>Anyone who can help me out on this question? Or share your= experience on how the mobile ISP commonly provison their users. Thanks.=C2= =A0</div><div><br></div><div>Best regards,</div><div>Davey</div></div> _______________________________________________<br> v6ops mailing list<br> <a href=3D"mailto:v6ops@ietf.org" target=3D"_blank">v6ops@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/v6ops" rel=3D"noreferrer" = target=3D"_blank">https://www.ietf.org/mailman/listinfo/v6ops</a><br> </blockquote></div> --0000000000004297060574604539-- From nobody Sun Aug 26 18:13:44 2018 Return-Path: <xiechf.bri@chinatelecom.cn> 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 5DE0F130E2A for <v6ops@ietfa.amsl.com>; Sun, 26 Aug 2018 18:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 SvyiaEvqN8Tn for <v6ops@ietfa.amsl.com>; Sun, 26 Aug 2018 18:13:40 -0700 (PDT) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.228]) by ietfa.amsl.com (Postfix) with ESMTP id 125BC1277C8 for <v6ops@ietf.org>; Sun, 26 Aug 2018 18:13:39 -0700 (PDT) HMM_SOURCE_IP: 172.18.0.48:19657.1067248962 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-219.142.69.76 (unknown [172.18.0.48]) by chinatelecom.cn (HERMES) with SMTP id 6042728008F; Mon, 27 Aug 2018 09:13:19 +0800 (CST) Received: from DANGMM9A10 ([219.142.69.76]) by App0024 with ESMTP id 47a2de00-98c0-4255-9347-055e0792541c for songlinjian@gmail.com; Mon Aug 27 09:13:28 2018 X-filter-score: filter<0> X-Real-From: xiechf.bri@chinatelecom.cn X-Receive-IP: 219.142.69.76 X-MEDUSA-Status: 0 Date: Mon, 27 Aug 2018 09:13:23 +0800 From: "xiechf.bri@chinatelecom.cn" <xiechf.bri@chinatelecom.cn> To: "Davey Song" <songlinjian@gmail.com>, v6ops <v6ops@ietf.org> References: <CAAObRXLe35KoONVsSO_oU+SRhMzMrKRE_SU-QNf2pGHYKpUrxA@mail.gmail.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 8, 379[cn] Mime-Version: 1.0 Message-ID: <2018082709132233449033@chinatelecom.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart561222657654_=----" Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/0d7lSiP_78td3vWBlMnVvmp7UAo> Subject: Re: [v6ops] How my Android phone got assigned with IPv6 address via 4G LTE? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 27 Aug 2018 01:13:42 -0000 This is a multi-part message in MIME format. ------=_001_NextPart561222657654_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGnvvIwgRGF2ZXksDQoNCkkgdGhpbmsgeW91IGNhbiBjaGVjayAzR1BQIFRTIDIzLjQwMSB2ZXJz aW9uIDEwLjMuMCBSZWxlYXNlIDEwIC4gaW4gd2hpY2ggdGhlIElQdjYgYWxsb2NhdGlvbiB0byBV RSBpcyBkZXNjcmliZWQgYXMgYmVsb3csDQoNCiJJUHY2IFN0YXRlbGVzcyBBZGRyZXNzIGF1dG9j b25maWd1cmF0aW9uIHNwZWNpZmllZCBpbiBSRkMgNDg2MiBbMThdIGlzIHRoZSBiYXNpYyBtZWNo YW5pc20gdG8gYWxsb2NhdGUgLzY0IElQdjYgcHJlZml4DQp0byB0aGUgVUUuIER1cmluZyBkZWZh dWx0IGJlYXJlciBlc3RhYmxpc2htZW50LCB0aGUgUEROIEdXIHNlbmRzIHRoZSBJUHY2IHByZWZp eCBhbmQgSW50ZXJmYWNlIElkZW50aWZpZXIgdG8gdGhlIFMtR1csIGFuZCB0aGVuDQp0aGUgUy1H VyBmb3J3YXJkcyB0aGUgSVB2NiBwcmVmaXggYW5kIEludGVyZmFjZSBJZGVudGlmaWVyIHRvIHRo ZSBNTUUgb3IgdG8gdGhlIFNHU04uIFRoZSBNTUUgb3IgdGhlIFNHU04NCmZvcndhcmRzIHRoZSBJ UHY2IEludGVyZmFjZSBJZGVudGlmaWVyIHRvIHRoZSBVRS4gVGhlIE1NRSBkb2VzIG5vdCBmb3J3 YXJkIHRoZSBJUHY2IHByZWZpeCB0byB0aGUgVUUuIElmIHRoZSBVRQ0KcmVjZWl2ZXMgdGhlIElQ djYgcHJlZml4IGZyb20gdGhlIFNHU04gZHVyaW5nIFBEUCBDb250ZXh0IEFjdGl2YXRpb24gcHJv Y2VkdXJlLCBpdCBzaGFsbCBpZ25vcmUgaXQuIg0KDQpGcm9tIHRoZSBhYm92ZSB3ZSBjYW4gc2Vl IHRoYXQgdGhlIEludGVyZmFjZSBJZGVudGlmaWVyIG9mIFVFIGlzIGFsbG9jYXRlZCBieSBuZXR3 b3JrIHNpZGUuDQoNCkNob25nZmVuZw0KDQoNCg0KDQoNCnhpZWNoZi5icmlAY2hpbmF0ZWxlY29t LmNuDQogDQpGcm9tOiBEYXZleSBTb25nDQpEYXRlOiAyMDE4LTA4LTI3IDA4OjUwDQpUbzogdjZv cHMNClN1YmplY3Q6IFt2Nm9wc10gSG93IG15IEFuZHJvaWQgcGhvbmUgZ290IGFzc2lnbmVkIHdp dGggSVB2NiBhZGRyZXNzIHZpYSA0RyBMVEU/DQpIaSBmb2xrcywNCg0KUmVjZW50bHkgdGhlIElQ djYgNEcgTFRFIG9mIENoaW5hIG1vaWJsZSBhbmQgQ2hpbmEgVGVsZWNvbSBpcyB3b3JraW5nLiBB bmQgSSBnb3QgdGhlIGFkZHJlc3MgaW5mb3JtYXRpb24gb24gbXkgYW5kcm9pZCBwaG9uZSwgbGlr ZSA6DQoNCkNoaW5hIE1vYmlsZSA6IDI0MDk6ODkwMDo4YTEwOjZkb2Y6NDE3Nzo5NTk5OmRlNTY6 NzA5Mg0KQ2hpbmEgVGVsZWNvbTogMjQwZTpmZjpiMTBhOjU0YTk6YjVmNzo1ZTRjOjJmMmQ6OTg0 Nw0KDQpNeSBxdWVzdGlvbiBpcyA6IEhvdyB0aGVzZSBJUHY2IGFkZHJlc3NlcyBhcmUgYXNzaWdu ZWQgdG8gbXkgcG9ob25lIGFuZCB3aGF0IHR5cGUgb2YgYWRkcmVzcyB0aGV5IGFyZT8gIFRoZXkg bG9va3Mgbm8gRVVJLTY0IGFkZHJlc3MsIHdpdGhvdXQgRkZGRSBpbiB0aGUgbWlkZGxlIG9mIGxv dyA2NCBiaXRzLiAgQW5kIGl0IGNhbiBub3QgYmUgZG9uZSBieSBESENQdjYgYmVjYXVzZSBJIGhl YXJkIEFuZHJvaWQgZG9lcyBub3Qgc3VwcG9ydCBESENQdjYsIHJpZ2h0PyAgSSdtIG5vdCBzdXJl IGhvdyBteSBMVEUgcHJvdmlkZXIgcHJvdmlzaW9uaW5nIElQdjYgYWRkcmVzcy4gU28gVGhlIG9u bHkgcG9zc2JpbGUgd2F5IGlzIFNMQUFDK3ByaXZhdGUgYWRkcmVzc++8nyAgDQoNCkFueW9uZSB3 aG8gY2FuIGhlbHAgbWUgb3V0IG9uIHRoaXMgcXVlc3Rpb24/IE9yIHNoYXJlIHlvdXIgZXhwZXJp ZW5jZSBvbiBob3cgdGhlIG1vYmlsZSBJU1AgY29tbW9ubHkgcHJvdmlzb24gdGhlaXIgdXNlcnMu IFRoYW5rcy4gDQoNCkJlc3QgcmVnYXJkcywNCkRhdmV5DQo= ------=_001_NextPart561222657654_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charse= t=3DUTF-8"><style>body { line-height: 1.5; }blockquote { margin-top: 0px; = margin-bottom: 0px; margin-left: 0.5em; }div.foxdiv20180827090914910278 { = }body { font-size: 10.5pt; font-family: 'Microsoft YaHei UI'; color: rgb(0= , 0, 0); line-height: 1.5; }</style></head><body>=0A<div><span></span>Hi= =EF=BC=8C Davey,</div><div><br></div><div>I think you can check <span= style=3D"font-family: ''; font-size: 10.5pt; line-height: 1.5; background= -color: window;">3GPP TS 23.401 version 10.3.0 Re= lease 10</span><span style=3D"font-size: 10.5pt; line-height: 1.5; ba= ckground-color: window;"> . in which the IPv6 allocation to UE is des= cribed as below,</span></div><div><br></div><div>"<span style=3D"font-fami= ly: ''; font-size: 10.5pt; line-height: 1.5; background-color: window;">IP= v6 Stateless Address autoconfiguration specified = in RFC 4862 [18] is the basic mechanism=  to allocate /64 IPv6 prefix</span></div><div><sp= an style=3D"font-family: ''; font-size: 10.5pt; line-height: 1.5; backgrou= nd-color: window;">to the UE. </span><span style=3D"font-fa= mily: ''; font-size: 10.5pt; line-height: 1.5; background-color: window;">= During default bearer establishment, the PDN = ;GW sends the IPv6 prefix and Interface = ;Identifier to the S-GW, and then</span></div><sp= an style=3D"font-family: "" microsoft=3D"" yahei=3D"" ui'";=3D"" font= -size:=3D"" 14px;=3D"" color:=3D"" rgb(0,=3D"" 0,=3D"" 0);=3D"" background= -color:=3D"" rgba(0,=3D"" font-weight:=3D"" normal;=3D"" font-style:=3D"" = normal;text-decoration:=3D"" none;'=3D"">the S-GW forwards = the IPv6 prefix and Interface Identifier to&= nbsp;the MME or to the SGSN. The MME&nb= sp;or the SGSN<br>forwards the IPv6 Interface&nbs= p;Identifier to the UE. The MME does no= t forward the IPv6 prefix to the UE.&nb= sp;If the UE<br></span><div><span style=3D"font-family: ''; font= -size: 10.5pt; line-height: 1.5; background-color: window;">receives = the IPv6 prefix from the SGSN during PD= P Context Activation procedure, it shall ign= ore it.</span>"</div><div><br></div><div>From the above we can see th= at the <span style=3D"font-size: 10.5pt; line-height: 1.5; background= -color: window;">Interface Identifier of UE is allocated by network s= ide.</span></div><div><span style=3D"font-size: 10.5pt; line-height: 1.5; = background-color: window;"><br></span></div><div>Chongfeng</div><div><br><= /div><div><br></div>=0A<div><br></div><hr style=3D"width: 210px; height: 1= px;" color=3D"#b5c4df" size=3D"1" align=3D"left">=0A<div><span><div style= =3D"MARGIN: 10px; FONT-FAMILY: verdana; FONT-SIZE: 10pt"><div>xiechf.bri@c= hinatelecom.cn</div></div></span></div>=0A<blockquote style=3D"margin-top:= 0px; margin-bottom: 0px; margin-left: 0.5em;"><div> </div><div style= =3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">= <div style=3D"PADDING-RIGHT: 8px; PADDING-LEFT: 8px; FONT-SIZE: 12px;FONT-= FAMILY:tahoma;COLOR:#000000; BACKGROUND: #efefef; PADDING-BOTTOM: 8px; PAD= DING-TOP: 8px"><div><b>From:</b> <a href=3D"mailto:songlinjian@gmail.= com">Davey Song</a></div><div><b>Date:</b> 2018-08-27 08:50</div= ><div><b>To:</b> <a href=3D"mailto:v6ops@ietf.org">v6ops</a></div><di= v><b>Subject:</b> [v6ops] How my Android phone got assigned with IPv6= address via 4G LTE?</div></div></div><div><div class=3D"FoxDiv20180827090= 914910278"><div dir=3D"ltr">Hi folks,<div><br></div><div>Recently the IPv6= 4G LTE of China moible and China Telecom is working. And I got the addres= s information on my android phone, like :</div><div><br></div><div>China M= obile : 2409:8900:8a10:6dof:4177:9599:de56:7092</div><div>China Telecom: 2= 40e:ff:b10a:54a9:b5f7:5e4c:2f2d:9847</div><div><br></div><div>My question = is : How these IPv6 addresses are assigned to my pohone and what type of a= ddress they are?  They looks no EUI-64 address, without FFFE in the m= iddle of low 64 bits.  And it can not be done by DHCPv6 because I hea= rd Android does not support DHCPv6, right?  I'm not sure how my LTE p= rovider provisioning IPv6 address. So The only possbile way is SLAAC+priva= te address=EF=BC=9F  </div><div><br></div><div>Anyone who can he= lp me out on this question? Or share your experience on how the mobile ISP= commonly provison their users. Thanks. </div><div><br></div><div>Bes= t regards,</div><div>Davey</div></div>=0A</div></div></blockquote>=0A</bod= y></html> ------=_001_NextPart561222657654_=------ From nobody Sun Aug 26 18:19:53 2018 Return-Path: <songlinjian@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE0D3130E77 for <v6ops@ietfa.amsl.com>; Sun, 26 Aug 2018 18:19:42 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 hcupFPuRUMxj for <v6ops@ietfa.amsl.com>; Sun, 26 Aug 2018 18:19:37 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::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 F3BED130E69 for <v6ops@ietf.org>; Sun, 26 Aug 2018 18:19:36 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id b78-v6so6776064vka.12 for <v6ops@ietf.org>; Sun, 26 Aug 2018 18:19:36 -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=3+UtINU7aeQ5IXkXN4PfWbCIa1OCg9ogFoF7lPb2CNs=; b=cEZc3P+aA6LEhhsASNgMQYJg2GzTUIv3HEko1kYm7QX/SYO+l5I2y/5S2KqVWw4KK2 k86UhmwLCyEZA3BN555Eke8i6+A5UVkUpmdr68aTEyoJ/Q7fC+yfPfrk/1STbZQCquHv s2/d+ZTIL3BWhf7QSlz49vjfjZk61N5na9F/DFHZcZ1IbugxgGsbljtHJd/aR3j8gcAf oe7E5tPaBzVHA8fwEjWbDSl3u2Rq75iq6oB9IsXLhVNUbH1MYdrYxcmw3xAFUGrS+vO0 KEr1c8jzKKeA26T/28vu82DcaiSYyMGNyxFkc6YUf/Rrg0MgayzIF9OM3cU9pB7vBVfB T7kQ== 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=3+UtINU7aeQ5IXkXN4PfWbCIa1OCg9ogFoF7lPb2CNs=; b=p7vcq17772XoREHDlKBOucHjQfreV0seF63tMZov/HBOYw44LcHKi1snAoXWTaJI7c Psq3FMHrAgxofJV57mRZyT/kVLTBrQPrzFawNvcP+BGd3dkKW5jbUWWAkoA+Q8rN1TqS t2hEH4037sc8J5gVffUiruCb7cwhmJPkbJmWFyNnOOoVT4r1+ZFO6RIi6kMKtQaVgkIo gjJ3buT2QR+zizcvkKc7EuLldwm8tdgmVxjr92pRdgHHQyyFGKc1Mt2DYt3wnHOthXwL T0UWw97ZfyByYQ/hYYWnt7Z4ruJZf0K65DeoWsNuVftYSKBSy+86d8Pk7ZGs00Zh7MAx K36g== X-Gm-Message-State: APzg51D5aM0K+rQ5FAXYCIskz1tzdIxAMxonFd1l8OAr3uBelMudyHXw yr/17uBtuaE5Rgf2muTaCHN18Wf/IAc6jTS5rPc= X-Google-Smtp-Source: ANB0VdYvPZVF9cnWgZ1tT/HJmDFVnxmFD0DQUELSfS1CI3cq1JJwfPJYtyxC0zqtAKgfv5ZqF+YTJZqeXwv33E/UIco= X-Received: by 2002:a1f:d507:: with SMTP id m7-v6mr6597367vkg.40.1535332776032; Sun, 26 Aug 2018 18:19:36 -0700 (PDT) MIME-Version: 1.0 References: <CAAObRXLe35KoONVsSO_oU+SRhMzMrKRE_SU-QNf2pGHYKpUrxA@mail.gmail.com> <2018082709132233449033@chinatelecom.cn> In-Reply-To: <2018082709132233449033@chinatelecom.cn> From: Davey Song <songlinjian@gmail.com> Date: Mon, 27 Aug 2018 09:19:28 +0800 Message-ID: <CAAObRXJnZu=yjkoPcHP-Gh+P+LH2=43D_L=QFZ4j2+q1Ao+hrQ@mail.gmail.com> To: xiechf.bri@chinatelecom.cn, Lorenzo Colitti <lorenzo@google.com> Cc: v6ops@ietf.org Content-Type: multipart/alternative; boundary="000000000000ba3e1205746084bc" Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/j-rsfEqnvZhsggRPOVZKEKTS5hA> Subject: Re: [v6ops] How my Android phone got assigned with IPv6 address via 4G LTE? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 27 Aug 2018 01:19:51 -0000 --000000000000ba3e1205746084bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for your information, Lorenzo and Dr. Xie , I will check that. Davey On Mon, 27 Aug 2018 at 09:13, xiechf.bri@chinatelecom.cn < xiechf.bri@chinatelecom.cn> wrote: > Hi=EF=BC=8C Davey, > > I think you can check 3GPP TS 23.401 version 10.3.0 Release 10 . in which > the IPv6 allocation to UE is described as below, > > " > IPv6 Stateless Address autoconfiguration specified in RFC 4862 [18] is th= e basic mechanism to allocate /64 IPv6 prefix > to the UE. > During default bearer establishment, the PDN GW sends the IPv6 prefix and= Interface Identifier to the S-GW, and then > > the S-GW forwards the IPv6 prefix and Interface Identifier to the MME or = to the SGSN. The MME or the SGSN > > forwards the IPv6 Interface Identifier to the UE. The MME does not forwar= d the IPv6 prefix to the UE. If the UE > > receives the IPv6 prefix from the SGSN during PDP Context Activation proc= edure, it shall ignore it. > " > > From the above we can see that the Interface Identifier of UE is > allocated by network side. > > Chongfeng > > > > ------------------------------ > xiechf.bri@chinatelecom.cn > > > *From:* Davey Song <songlinjian@gmail.com> > *Date:* 2018-08-27 08:50 > *To:* v6ops <v6ops@ietf.org> > *Subject:* [v6ops] How my Android phone got assigned with IPv6 address > via 4G LTE? > Hi folks, > > Recently the IPv6 4G LTE of China moible and China Telecom is working. An= d > I got the address information on my android phone, like : > > China Mobile : 2409:8900:8a10:6dof:4177:9599:de56:7092 > China Telecom: 240e:ff:b10a:54a9:b5f7:5e4c:2f2d:9847 > > My question is : How these IPv6 addresses are assigned to my pohone and > what type of address they are? They looks no EUI-64 address, without FFF= E > in the middle of low 64 bits. And it can not be done by DHCPv6 because I > heard Android does not support DHCPv6, right? I'm not sure how my LTE > provider provisioning IPv6 address. So The only possbile way is > SLAAC+private address=EF=BC=9F > > Anyone who can help me out on this question? Or share your experience on > how the mobile ISP commonly provison their users. Thanks. > > Best regards, > Davey > > --000000000000ba3e1205746084bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Thanks for your information, Lorenzo and Dr. Xie , I will = check that.=C2=A0<div><br></div><div>Davey</div></div><br><div class=3D"gma= il_quote"><div dir=3D"ltr">On Mon, 27 Aug 2018 at 09:13, <a href=3D"mailto:= xiechf.bri@chinatelecom.cn">xiechf.bri@chinatelecom.cn</a> <<a href=3D"m= ailto:xiechf.bri@chinatelecom.cn">xiechf.bri@chinatelecom.cn</a>> wrote:= <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord= er-left:1px #ccc solid;padding-left:1ex"><div> <div><span></span>Hi=EF=BC=8C Davey,</div><div><br></div><div>I think you c= an check=C2=A0<span style=3D"font-family:'';font-size:10.5pt;line-h= eight:1.5;background-color:window">3GPP=C2=A0TS=C2=A023.401=C2=A0version=C2= =A010.3.0=C2=A0Release=C2=A010</span><span style=3D"font-size:10.5pt;line-h= eight:1.5;background-color:window">=C2=A0. in which the IPv6 allocation to = UE is described as below,</span></div><div><br></div><div>"<span style= =3D"font-family:'';font-size:10.5pt;line-height:1.5;background-colo= r:window">IPv6=C2=A0Stateless=C2=A0Address=C2=A0autoconfiguration=C2=A0spec= ified=C2=A0in=C2=A0RFC=C2=A04862=C2=A0[18]=C2=A0is=C2=A0the=C2=A0basic=C2= =A0mechanism=C2=A0to=C2=A0allocate=C2=A0/64=C2=A0IPv6=C2=A0prefix</span></d= iv><div><span style=3D"font-family:'';font-size:10.5pt;line-height:= 1.5;background-color:window">to=C2=A0the=C2=A0UE.=C2=A0</span><span style= =3D"font-family:'';font-size:10.5pt;line-height:1.5;background-colo= r:window">During=C2=A0default=C2=A0bearer=C2=A0establishment,=C2=A0the=C2= =A0PDN=C2=A0GW=C2=A0sends=C2=A0the=C2=A0IPv6=C2=A0prefix=C2=A0and=C2=A0Inte= rface=C2=A0Identifier=C2=A0to=C2=A0the=C2=A0S-GW,=C2=A0and=C2=A0then</span>= </div><span>the=C2=A0S-GW=C2=A0forwards=C2=A0the=C2=A0IPv6=C2=A0prefix=C2= =A0and=C2=A0Interface=C2=A0Identifier=C2=A0to=C2=A0the=C2=A0MME=C2=A0or=C2= =A0to=C2=A0the=C2=A0SGSN.=C2=A0The=C2=A0MME=C2=A0or=C2=A0the=C2=A0SGSN<br>f= orwards=C2=A0the=C2=A0IPv6=C2=A0Interface=C2=A0Identifier=C2=A0to=C2=A0the= =C2=A0UE.=C2=A0The=C2=A0MME=C2=A0does=C2=A0not=C2=A0forward=C2=A0the=C2=A0I= Pv6=C2=A0prefix=C2=A0to=C2=A0the=C2=A0UE.=C2=A0If=C2=A0the=C2=A0UE<br></spa= n><div><span style=3D"font-family:'';font-size:10.5pt;line-height:1= .5;background-color:window">receives=C2=A0the=C2=A0IPv6=C2=A0prefix=C2=A0fr= om=C2=A0the=C2=A0SGSN=C2=A0during=C2=A0PDP=C2=A0Context=C2=A0Activation=C2= =A0procedure,=C2=A0it=C2=A0shall=C2=A0ignore=C2=A0it.</span>"</div><di= v><br></div><div>From the above we can see that the=C2=A0<span style=3D"fon= t-size:10.5pt;line-height:1.5;background-color:window">Interface=C2=A0Ident= ifier of UE is allocated by network side.</span></div><div><span style=3D"f= ont-size:10.5pt;line-height:1.5;background-color:window"><br></span></div><= div>Chongfeng</div><div><br></div><div><br></div> <div><br></div><hr style=3D"width:210px;height:1px" color=3D"#b5c4df" size= =3D"1" align=3D"left"> <div><span><div style=3D"MARGIN:10px;FONT-FAMILY:verdana;FONT-SIZE:10pt"><d= iv><a href=3D"mailto:xiechf.bri@chinatelecom.cn" target=3D"_blank">xiechf.b= ri@chinatelecom.cn</a></div></div></span></div> <blockquote style=3D"margin-top:0px;margin-bottom:0px;margin-left:0.5em"><d= iv>=C2=A0</div><div style=3D"border:none;border-top:solid #b5c4df 1.0pt;pad= ding:3.0pt 0cm 0cm 0cm"><div style=3D"PADDING-RIGHT:8px;PADDING-LEFT:8px;FO= NT-SIZE:12px;FONT-FAMILY:tahoma;COLOR:#000000;BACKGROUND:#efefef;PADDING-BO= TTOM:8px;PADDING-TOP:8px"><div><b>From:</b>=C2=A0<a href=3D"mailto:songlinj= ian@gmail.com" target=3D"_blank">Davey Song</a></div><div><b>Date:</b>=C2= =A02018-08-27=C2=A008:50</div><div><b>To:</b>=C2=A0<a href=3D"mailto:v6ops@= ietf.org" target=3D"_blank">v6ops</a></div><div><b>Subject:</b>=C2=A0[v6ops= ] How my Android phone got assigned with IPv6 address via 4G LTE?</div></di= v></div><div><div class=3D"m_9079167007755996120FoxDiv20180827090914910278"= ><div dir=3D"ltr">Hi folks,<div><br></div><div>Recently the IPv6 4G LTE of = China moible and China Telecom is working. And I got the address informatio= n on my android phone, like :</div><div><br></div><div>China Mobile : 2409:= 8900:8a10:6dof:4177:9599:de56:7092</div><div>China Telecom: 240e:ff:b10a:54= a9:b5f7:5e4c:2f2d:9847</div><div><br></div><div>My question is : How these = IPv6 addresses are assigned to my pohone and what type of address they are?= =C2=A0 They looks no EUI-64 address, without FFFE in the middle of low 64 b= its.=C2=A0 And it can not be done by DHCPv6 because I heard Android does no= t support DHCPv6, right?=C2=A0 I'm not sure how my LTE provider provisi= oning IPv6 address. So The only possbile way is SLAAC+private address=EF=BC= =9F=C2=A0=C2=A0</div><div><br></div><div>Anyone who can help me out on this= question? Or share your experience on how the mobile ISP commonly provison= their users. Thanks.=C2=A0</div><div><br></div><div>Best regards,</div><di= v>Davey</div></div> </div></div></blockquote> </div></blockquote></div> --000000000000ba3e1205746084bc-- From nobody Sun Aug 26 18:21:39 2018 Return-Path: <lorenzo@google.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48FB8130E6D for <v6ops@ietfa.amsl.com>; Sun, 26 Aug 2018 18:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, T_KAM_HTML_FONT_INVALID=0.01, 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 aNZNad36IACu for <v6ops@ietfa.amsl.com>; Sun, 26 Aug 2018 18:21:26 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 CC2F2130E79 for <v6ops@ietf.org>; Sun, 26 Aug 2018 18:21:25 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id x79-v6so10318094ita.1 for <v6ops@ietf.org>; Sun, 26 Aug 2018 18:21:25 -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=eMXPEfgkXaIbgfyEQYprZjtATXcgRol7WAOHF3VnZRM=; b=bOT2lsuQnYGK9navF9YoIVmGqdBsPwHUb31HL/RN/0Rgjb30uxlVvBNzZ+IHFsnkhF pkvrr6CVAoAM/Am3oXPfAGB3IrntFGGwOZQWGuUcv5RHzvxjIomC6U5dToklFyIU1BLC K2IrsKB+pj4cB9X5/2qKt7GNHezX6nRlvznW3KFCkHvKMRpHs2CfUfCpgRa/+c+4+UzW a9G2jEe/SZ9bLfOp5uLHH++0Lq68OxIAPrWg/KgJj79cKnGVnVMeXZOqtrokUs2s/ZXz /H8+kt40iRwSMZ86lgoZMWtgpkV99Ys2eYUMBp2dROZPQu+4GdzcUFG4CR8cS33x8h7y v/aQ== 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=eMXPEfgkXaIbgfyEQYprZjtATXcgRol7WAOHF3VnZRM=; b=b7eYc6UXe7LlAQPl1S1e6ez/CLJCAXD3EMnwPkuA9LvpCXfrJaH90EGINOoCQJ0CzG g7u5fv3ub87FgsEpsgaSUf9P0Xxuevgq4lkr5dVLEBlnMaf/s3+1DaykgtL52LZsWm7Z k7+GplIzv1SW1LEceIgB2L0e+AWt37QjvPAh8YAOwXswhTISOMM1QSDJVdWk8b9X5Z3c o8Sno00wFHEgfJxZglpDsapEux5KpRmb3sjepMIlwuvAotGjIdiPSMoB6ICu97J7Hu6G yR6UI8KkCxPouC6+5TyEUZajFmMKfwVlBn6XlkcQaug5Z+WuylvmRfw799zZ2Ens82VH MMYg== X-Gm-Message-State: APzg51BjoVS+O+vD2iQUxqtkVi9JMQ/Qj5zDY8zJgO8yJKgRZGkCQ8bZ Cp9gLF4J7diPqEdq865jSVnqOrStM5KW5jRIehMptA== X-Google-Smtp-Source: ANB0Vdatvq91eST8gDcni2BfL7dmV6tjnavywYk1ToYDNHluoy0HwdUm316BBKhoUSzHlrP5KRC6Je+eToTZsnbG9VY= X-Received: by 2002:a24:4f52:: with SMTP id c79-v6mr5011993itb.36.1535332884669; Sun, 26 Aug 2018 18:21:24 -0700 (PDT) MIME-Version: 1.0 References: <CAAObRXLe35KoONVsSO_oU+SRhMzMrKRE_SU-QNf2pGHYKpUrxA@mail.gmail.com> <2018082709132233449033@chinatelecom.cn> In-Reply-To: <2018082709132233449033@chinatelecom.cn> From: Lorenzo Colitti <lorenzo@google.com> Date: Mon, 27 Aug 2018 10:21:13 +0900 Message-ID: <CAKD1Yr3PFKC06vwALL9Pjyd8Ji-RnqPR-HMvLA6CS6cyDadzVw@mail.gmail.com> To: xiechf.bri@chinatelecom.cn Cc: songlinjian@gmail.com, "v6ops@ietf.org WG" <v6ops@ietf.org> Content-Type: multipart/alternative; boundary="00000000000034583f0574608b75" Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/S5duDbXPjyFa5i6EhFWZPFKlc4Y> Subject: Re: [v6ops] How my Android phone got assigned with IPv6 address via 4G LTE? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 27 Aug 2018 01:21:38 -0000 --00000000000034583f0574608b75 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Actually I think per standards, the network only assigns the interface identifier for the link-local address. The interface identifier(s) for the global address(es) are assigned by the terminal in whatever way it wants to assign them. On Mon, Aug 27, 2018 at 10:14 AM xiechf.bri@chinatelecom.cn < xiechf.bri@chinatelecom.cn> wrote: > Hi=EF=BC=8C Davey, > > I think you can check 3GPP TS 23.401 version 10.3.0 Release 10 . in which > the IPv6 allocation to UE is described as below, > > " > IPv6 Stateless Address autoconfiguration specified in RFC 4862 [18] is th= e basic mechanism to allocate /64 IPv6 prefix > to the UE. > During default bearer establishment, the PDN GW sends the IPv6 prefix and= Interface Identifier to the S-GW, and then > > the S-GW forwards the IPv6 prefix and Interface Identifier to the MME or = to the SGSN. The MME or the SGSN > > forwards the IPv6 Interface Identifier to the UE. The MME does not forwar= d the IPv6 prefix to the UE. If the UE > > receives the IPv6 prefix from the SGSN during PDP Context Activation proc= edure, it shall ignore it. > " > > From the above we can see that the Interface Identifier of UE is > allocated by network side. > > Chongfeng > > > > ------------------------------ > xiechf.bri@chinatelecom.cn > > > *From:* Davey Song <songlinjian@gmail.com> > *Date:* 2018-08-27 08:50 > *To:* v6ops <v6ops@ietf.org> > *Subject:* [v6ops] How my Android phone got assigned with IPv6 address > via 4G LTE? > Hi folks, > > Recently the IPv6 4G LTE of China moible and China Telecom is working. An= d > I got the address information on my android phone, like : > > China Mobile : 2409:8900:8a10:6dof:4177:9599:de56:7092 > China Telecom: 240e:ff:b10a:54a9:b5f7:5e4c:2f2d:9847 > > My question is : How these IPv6 addresses are assigned to my pohone and > what type of address they are? They looks no EUI-64 address, without FFF= E > in the middle of low 64 bits. And it can not be done by DHCPv6 because I > heard Android does not support DHCPv6, right? I'm not sure how my LTE > provider provisioning IPv6 address. So The only possbile way is > SLAAC+private address=EF=BC=9F > > Anyone who can help me out on this question? Or share your experience on > how the mobile ISP commonly provison their users. Thanks. > > Best regards, > Davey > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --00000000000034583f0574608b75 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Actually I think per standards, the network only assigns t= he interface identifier for the link-local address. The interface identifie= r(s) for the global address(es) are assigned by the terminal in whatever wa= y it wants to assign them.</div><br><div class=3D"gmail_quote"><div dir=3D"= ltr">On Mon, Aug 27, 2018 at 10:14 AM <a href=3D"mailto:xiechf.bri@chinatel= ecom.cn">xiechf.bri@chinatelecom.cn</a> <<a href=3D"mailto:xiechf.bri@ch= inatelecom.cn">xiechf.bri@chinatelecom.cn</a>> wrote:<br></div><blockquo= te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so= lid;padding-left:1ex"><div> <div><span></span>Hi=EF=BC=8C Davey,</div><div><br></div><div>I think you c= an check=C2=A0<span style=3D"font-family:'';font-size:10.5pt;line-h= eight:1.5;background-color:window">3GPP=C2=A0TS=C2=A023.401=C2=A0version=C2= =A010.3.0=C2=A0Release=C2=A010</span><span style=3D"font-size:10.5pt;line-h= eight:1.5;background-color:window">=C2=A0. in which the IPv6 allocation to = UE is described as below,</span></div><div><br></div><div>"<span style= =3D"font-family:'';font-size:10.5pt;line-height:1.5;background-colo= r:window">IPv6=C2=A0Stateless=C2=A0Address=C2=A0autoconfiguration=C2=A0spec= ified=C2=A0in=C2=A0RFC=C2=A04862=C2=A0[18]=C2=A0is=C2=A0the=C2=A0basic=C2= =A0mechanism=C2=A0to=C2=A0allocate=C2=A0/64=C2=A0IPv6=C2=A0prefix</span></d= iv><div><span style=3D"font-family:'';font-size:10.5pt;line-height:= 1.5;background-color:window">to=C2=A0the=C2=A0UE.=C2=A0</span><span style= =3D"font-family:'';font-size:10.5pt;line-height:1.5;background-colo= r:window">During=C2=A0default=C2=A0bearer=C2=A0establishment,=C2=A0the=C2= =A0PDN=C2=A0GW=C2=A0sends=C2=A0the=C2=A0IPv6=C2=A0prefix=C2=A0and=C2=A0Inte= rface=C2=A0Identifier=C2=A0to=C2=A0the=C2=A0S-GW,=C2=A0and=C2=A0then</span>= </div><span>the=C2=A0S-GW=C2=A0forwards=C2=A0the=C2=A0IPv6=C2=A0prefix=C2= =A0and=C2=A0Interface=C2=A0Identifier=C2=A0to=C2=A0the=C2=A0MME=C2=A0or=C2= =A0to=C2=A0the=C2=A0SGSN.=C2=A0The=C2=A0MME=C2=A0or=C2=A0the=C2=A0SGSN<br>f= orwards=C2=A0the=C2=A0IPv6=C2=A0Interface=C2=A0Identifier=C2=A0to=C2=A0the= =C2=A0UE.=C2=A0The=C2=A0MME=C2=A0does=C2=A0not=C2=A0forward=C2=A0the=C2=A0I= Pv6=C2=A0prefix=C2=A0to=C2=A0the=C2=A0UE.=C2=A0If=C2=A0the=C2=A0UE<br></spa= n><div><span style=3D"font-family:'';font-size:10.5pt;line-height:1= .5;background-color:window">receives=C2=A0the=C2=A0IPv6=C2=A0prefix=C2=A0fr= om=C2=A0the=C2=A0SGSN=C2=A0during=C2=A0PDP=C2=A0Context=C2=A0Activation=C2= =A0procedure,=C2=A0it=C2=A0shall=C2=A0ignore=C2=A0it.</span>"</div><di= v><br></div><div>From the above we can see that the=C2=A0<span style=3D"fon= t-size:10.5pt;line-height:1.5;background-color:window">Interface=C2=A0Ident= ifier of UE is allocated by network side.</span></div><div><span style=3D"f= ont-size:10.5pt;line-height:1.5;background-color:window"><br></span></div><= div>Chongfeng</div><div><br></div><div><br></div> <div><br></div><hr style=3D"width:210px;height:1px" color=3D"#b5c4df" size= =3D"1" align=3D"left"> <div><span><div style=3D"MARGIN:10px;FONT-FAMILY:verdana;FONT-SIZE:10pt"><d= iv><a href=3D"mailto:xiechf.bri@chinatelecom.cn" target=3D"_blank">xiechf.b= ri@chinatelecom.cn</a></div></div></span></div> <blockquote style=3D"margin-top:0px;margin-bottom:0px;margin-left:0.5em"><d= iv>=C2=A0</div><div style=3D"border:none;border-top:solid #b5c4df 1.0pt;pad= ding:3.0pt 0cm 0cm 0cm"><div style=3D"PADDING-RIGHT:8px;PADDING-LEFT:8px;FO= NT-SIZE:12px;FONT-FAMILY:tahoma;COLOR:#000000;BACKGROUND:#efefef;PADDING-BO= TTOM:8px;PADDING-TOP:8px"><div><b>From:</b>=C2=A0<a href=3D"mailto:songlinj= ian@gmail.com" target=3D"_blank">Davey Song</a></div><div><b>Date:</b>=C2= =A02018-08-27=C2=A008:50</div><div><b>To:</b>=C2=A0<a href=3D"mailto:v6ops@= ietf.org" target=3D"_blank">v6ops</a></div><div><b>Subject:</b>=C2=A0[v6ops= ] How my Android phone got assigned with IPv6 address via 4G LTE?</div></di= v></div><div><div class=3D"m_3867402898991505251FoxDiv20180827090914910278"= ><div dir=3D"ltr">Hi folks,<div><br></div><div>Recently the IPv6 4G LTE of = China moible and China Telecom is working. And I got the address informatio= n on my android phone, like :</div><div><br></div><div>China Mobile : 2409:= 8900:8a10:6dof:4177:9599:de56:7092</div><div>China Telecom: 240e:ff:b10a:54= a9:b5f7:5e4c:2f2d:9847</div><div><br></div><div>My question is : How these = IPv6 addresses are assigned to my pohone and what type of address they are?= =C2=A0 They looks no EUI-64 address, without FFFE in the middle of low 64 b= its.=C2=A0 And it can not be done by DHCPv6 because I heard Android does no= t support DHCPv6, right?=C2=A0 I'm not sure how my LTE provider provisi= oning IPv6 address. So The only possbile way is SLAAC+private address=EF=BC= =9F=C2=A0=C2=A0</div><div><br></div><div>Anyone who can help me out on this= question? Or share your experience on how the mobile ISP commonly provison= their users. Thanks.=C2=A0</div><div><br></div><div>Best regards,</div><di= v>Davey</div></div> </div></div></blockquote> </div>_______________________________________________<br> v6ops mailing list<br> <a href=3D"mailto:v6ops@ietf.org" target=3D"_blank">v6ops@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/v6ops" rel=3D"noreferrer" = target=3D"_blank">https://www.ietf.org/mailman/listinfo/v6ops</a><br> </blockquote></div> --00000000000034583f0574608b75-- From nobody Sun Aug 26 18:29:37 2018 Return-Path: <songlinjian@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C58130DE2 for <v6ops@ietfa.amsl.com>; Sun, 26 Aug 2018 18:29:36 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 hwDfmuTGNUM9 for <v6ops@ietfa.amsl.com>; Sun, 26 Aug 2018 18:29:34 -0700 (PDT) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 53B631277C8 for <v6ops@ietf.org>; Sun, 26 Aug 2018 18:29:34 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id o11-v6so8576060uak.5 for <v6ops@ietf.org>; Sun, 26 Aug 2018 18:29:34 -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=GwWTPTk0m3gAqi3z294inpB7KMhrnOiy51Atj+/bno8=; b=sR3A2vhQEp8WipDhz8n0eyVBrB4Cr4LYVbyl3GRvIrrh8+4ZQ4QROLt/A5oiYDBbM7 64ICPjbRuZbQZyAcE1F5B3lpdkJQYsjwlFvs+UuAxT08+/xiDfiLN3b+4CyvTg7mecTj FeYXYgpJJhYuZ0MNLCcyLXi28OENOtySNFriHKMmat9Y2D+3ZMb+b/cblmu0NixtR9YJ cxwSnOxSuoDZiunuFCD2dOfQ6frZ2hBTC5N5YBOtpRhFj2vhUkzjstBGUh+qJnLH/KlM UJ9AQ02R8l9kveerjtvP1EYJ8obykRh/UQyKqWje1pGmCYPJXs9oXh1x6UOYqhuKcEsF HXtA== 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=GwWTPTk0m3gAqi3z294inpB7KMhrnOiy51Atj+/bno8=; b=OmC44qpEaAMTdVY+mpYMCgyk9hIEZDKyVJIjUiEGqEv1rrB4tDwmh4yQQn7DeNLpGG svPa/T27VrYG1ix770e1EP5Jom/2ua553fDGA1XAwczADWDZKb+sbYqOD64xSzHAt6mh mELbOYU17im3vP8g32cd90H7KMijt6JpZkzsG9TZaC8dtLQ5YUjxkUFlUa18cSwDqBQz eGglI4Fs/R9wvEd7f3RwytlqILe0ORLGafFkbF1oJGzNZn8k3S50EopnjngIb8dM7Iu8 MKdJpcpdjjRPMvGAMdtNLZRTIhL3Y8Jkj0ZuhGqvlVZikxTsQ+E4wWqm7RAyD31xBEjw j0uw== X-Gm-Message-State: APzg51BgkZMf5OdhK6AomT1gAr/id8+xyjYDkZVzSwVG/E9V1HwZX9Z2 VoPdhUjqA3qb2mZSSBaaMNM4HcGBKZZqZiqwSHA= X-Google-Smtp-Source: ANB0VdZ00l+JsVUsmSKdp7VnSbEItTKb+f2CxHhFO6fBQZk+GemyVWFybS/OSA0wCAXO1bq1KPrpvyqGsG/fs3Bs1Q4= X-Received: by 2002:ab0:30ea:: with SMTP id d10-v6mr7127679uam.58.1535333373313; Sun, 26 Aug 2018 18:29:33 -0700 (PDT) MIME-Version: 1.0 References: <CAAObRXLe35KoONVsSO_oU+SRhMzMrKRE_SU-QNf2pGHYKpUrxA@mail.gmail.com> <2018082709132233449033@chinatelecom.cn> <CAKD1Yr3PFKC06vwALL9Pjyd8Ji-RnqPR-HMvLA6CS6cyDadzVw@mail.gmail.com> In-Reply-To: <CAKD1Yr3PFKC06vwALL9Pjyd8Ji-RnqPR-HMvLA6CS6cyDadzVw@mail.gmail.com> From: Davey Song <songlinjian@gmail.com> Date: Mon, 27 Aug 2018 09:29:24 +0800 Message-ID: <CAAObRXJx-8cPYuU-5gSMCvoOX-m29Q5BZg1-GANXBV-2Zmjv0A@mail.gmail.com> To: Lorenzo Colitti <lorenzo@google.com> Cc: xiechf.bri@chinatelecom.cn, v6ops@ietf.org Content-Type: multipart/alternative; boundary="00000000000054074e057460a841" Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/RXxeI7Qr09qPBG87C2eF88ey0OA> Subject: Re: [v6ops] How my Android phone got assigned with IPv6 address via 4G LTE? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 27 Aug 2018 01:29:36 -0000 --00000000000054074e057460a841 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So it is not neccsarily rfc7217 address? Is it true that no one can 100% sure what type of address (or which std it is using) for a specific IPv6 address assigned due to privacy consideration, right? Davey On Mon, 27 Aug 2018 at 09:21, Lorenzo Colitti <lorenzo@google.com> wrote: > Actually I think per standards, the network only assigns the interface > identifier for the link-local address. The interface identifier(s) for th= e > global address(es) are assigned by the terminal in whatever way it wants = to > assign them. > > On Mon, Aug 27, 2018 at 10:14 AM xiechf.bri@chinatelecom.cn < > xiechf.bri@chinatelecom.cn> wrote: > >> Hi=EF=BC=8C Davey, >> >> I think you can check 3GPP TS 23.401 version 10.3.0 Release 10 . in >> which the IPv6 allocation to UE is described as below, >> >> " >> IPv6 Stateless Address autoconfiguration specified in RFC 4862 [18] is t= he basic mechanism to allocate /64 IPv6 prefix >> to the UE. >> During default bearer establishment, the PDN GW sends the IPv6 prefix an= d Interface Identifier to the S-GW, and then >> >> the S-GW forwards the IPv6 prefix and Interface Identifier to the MME or= to the SGSN. The MME or the SGSN >> >> forwards the IPv6 Interface Identifier to the UE. The MME does not forwa= rd the IPv6 prefix to the UE. If the UE >> >> receives the IPv6 prefix from the SGSN during PDP Context Activation pro= cedure, it shall ignore it. >> " >> >> From the above we can see that the Interface Identifier of UE is >> allocated by network side. >> >> Chongfeng >> >> >> >> ------------------------------ >> xiechf.bri@chinatelecom.cn >> >> >> *From:* Davey Song <songlinjian@gmail.com> >> *Date:* 2018-08-27 08:50 >> *To:* v6ops <v6ops@ietf.org> >> *Subject:* [v6ops] How my Android phone got assigned with IPv6 address >> via 4G LTE? >> Hi folks, >> >> Recently the IPv6 4G LTE of China moible and China Telecom is working. >> And I got the address information on my android phone, like : >> >> China Mobile : 2409:8900:8a10:6dof:4177:9599:de56:7092 >> China Telecom: 240e:ff:b10a:54a9:b5f7:5e4c:2f2d:9847 >> >> My question is : How these IPv6 addresses are assigned to my pohone and >> what type of address they are? They looks no EUI-64 address, without FF= FE >> in the middle of low 64 bits. And it can not be done by DHCPv6 because = I >> heard Android does not support DHCPv6, right? I'm not sure how my LTE >> provider provisioning IPv6 address. So The only possbile way is >> SLAAC+private address=EF=BC=9F >> >> Anyone who can help me out on this question? Or share your experience on >> how the mobile ISP commonly provison their users. Thanks. >> >> Best regards, >> Davey >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > --00000000000054074e057460a841 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">So it is not neccsarily rfc7217 address?=C2=A0 Is it true = that no one can 100% sure what type of address (or which std it is using) f= or a specific IPv6 address assigned due to privacy consideration, right?=C2= =A0<div><br></div><div>Davey<br><div class=3D"gmail_quote"><div dir=3D"ltr"= >On Mon, 27 Aug 2018 at 09:21, Lorenzo Colitti <<a href=3D"mailto:lorenz= o@google.com">lorenzo@google.com</a>> wrote:<br></div><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex"><div dir=3D"ltr">Actually I think per standards, the network = only assigns the interface identifier for the link-local address. The inter= face identifier(s) for the global address(es) are assigned by the terminal = in whatever way it wants to assign them.</div><br><div class=3D"gmail_quote= "><div dir=3D"ltr">On Mon, Aug 27, 2018 at 10:14 AM <a href=3D"mailto:xiech= f.bri@chinatelecom.cn" target=3D"_blank">xiechf.bri@chinatelecom.cn</a> <= ;<a href=3D"mailto:xiechf.bri@chinatelecom.cn" target=3D"_blank">xiechf.bri= @chinatelecom.cn</a>> wrote:<br></div><blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di= v> <div><span></span>Hi=EF=BC=8C Davey,</div><div><br></div><div>I think you c= an check=C2=A0<span style=3D"font-family:'';font-size:10.5pt;line-h= eight:1.5;background-color:window">3GPP=C2=A0TS=C2=A023.401=C2=A0version=C2= =A010.3.0=C2=A0Release=C2=A010</span><span style=3D"font-size:10.5pt;line-h= eight:1.5;background-color:window">=C2=A0. in which the IPv6 allocation to = UE is described as below,</span></div><div><br></div><div>"<span style= =3D"font-family:'';font-size:10.5pt;line-height:1.5;background-colo= r:window">IPv6=C2=A0Stateless=C2=A0Address=C2=A0autoconfiguration=C2=A0spec= ified=C2=A0in=C2=A0RFC=C2=A04862=C2=A0[18]=C2=A0is=C2=A0the=C2=A0basic=C2= =A0mechanism=C2=A0to=C2=A0allocate=C2=A0/64=C2=A0IPv6=C2=A0prefix</span></d= iv><div><span style=3D"font-family:'';font-size:10.5pt;line-height:= 1.5;background-color:window">to=C2=A0the=C2=A0UE.=C2=A0</span><span style= =3D"font-family:'';font-size:10.5pt;line-height:1.5;background-colo= r:window">During=C2=A0default=C2=A0bearer=C2=A0establishment,=C2=A0the=C2= =A0PDN=C2=A0GW=C2=A0sends=C2=A0the=C2=A0IPv6=C2=A0prefix=C2=A0and=C2=A0Inte= rface=C2=A0Identifier=C2=A0to=C2=A0the=C2=A0S-GW,=C2=A0and=C2=A0then</span>= </div><span>the=C2=A0S-GW=C2=A0forwards=C2=A0the=C2=A0IPv6=C2=A0prefix=C2= =A0and=C2=A0Interface=C2=A0Identifier=C2=A0to=C2=A0the=C2=A0MME=C2=A0or=C2= =A0to=C2=A0the=C2=A0SGSN.=C2=A0The=C2=A0MME=C2=A0or=C2=A0the=C2=A0SGSN<br>f= orwards=C2=A0the=C2=A0IPv6=C2=A0Interface=C2=A0Identifier=C2=A0to=C2=A0the= =C2=A0UE.=C2=A0The=C2=A0MME=C2=A0does=C2=A0not=C2=A0forward=C2=A0the=C2=A0I= Pv6=C2=A0prefix=C2=A0to=C2=A0the=C2=A0UE.=C2=A0If=C2=A0the=C2=A0UE<br></spa= n><div><span style=3D"font-family:'';font-size:10.5pt;line-height:1= .5;background-color:window">receives=C2=A0the=C2=A0IPv6=C2=A0prefix=C2=A0fr= om=C2=A0the=C2=A0SGSN=C2=A0during=C2=A0PDP=C2=A0Context=C2=A0Activation=C2= =A0procedure,=C2=A0it=C2=A0shall=C2=A0ignore=C2=A0it.</span>"</div><di= v><br></div><div>From the above we can see that the=C2=A0<span style=3D"fon= t-size:10.5pt;line-height:1.5;background-color:window">Interface=C2=A0Ident= ifier of UE is allocated by network side.</span></div><div><span style=3D"f= ont-size:10.5pt;line-height:1.5;background-color:window"><br></span></div><= div>Chongfeng</div><div><br></div><div><br></div> <div><br></div><hr style=3D"width:210px;height:1px" color=3D"#b5c4df" size= =3D"1" align=3D"left"> <div><span><div style=3D"MARGIN:10px;FONT-FAMILY:verdana;FONT-SIZE:10pt"><d= iv><a href=3D"mailto:xiechf.bri@chinatelecom.cn" target=3D"_blank">xiechf.b= ri@chinatelecom.cn</a></div></div></span></div> <blockquote style=3D"margin-top:0px;margin-bottom:0px;margin-left:0.5em"><d= iv>=C2=A0</div><div style=3D"border:none;border-top:solid #b5c4df 1.0pt;pad= ding:3.0pt 0cm 0cm 0cm"><div style=3D"PADDING-RIGHT:8px;PADDING-LEFT:8px;FO= NT-SIZE:12px;FONT-FAMILY:tahoma;COLOR:#000000;BACKGROUND:#efefef;PADDING-BO= TTOM:8px;PADDING-TOP:8px"><div><b>From:</b>=C2=A0<a href=3D"mailto:songlinj= ian@gmail.com" target=3D"_blank">Davey Song</a></div><div><b>Date:</b>=C2= =A02018-08-27=C2=A008:50</div><div><b>To:</b>=C2=A0<a href=3D"mailto:v6ops@= ietf.org" target=3D"_blank">v6ops</a></div><div><b>Subject:</b>=C2=A0[v6ops= ] How my Android phone got assigned with IPv6 address via 4G LTE?</div></di= v></div><div><div class=3D"m_-1498842969820883944m_3867402898991505251FoxDi= v20180827090914910278"><div dir=3D"ltr">Hi folks,<div><br></div><div>Recent= ly the IPv6 4G LTE of China moible and China Telecom is working. And I got = the address information on my android phone, like :</div><div><br></div><di= v>China Mobile : 2409:8900:8a10:6dof:4177:9599:de56:7092</div><div>China Te= lecom: 240e:ff:b10a:54a9:b5f7:5e4c:2f2d:9847</div><div><br></div><div>My qu= estion is : How these IPv6 addresses are assigned to my pohone and what typ= e of address they are?=C2=A0 They looks no EUI-64 address, without FFFE in = the middle of low 64 bits.=C2=A0 And it can not be done by DHCPv6 because I= heard Android does not support DHCPv6, right?=C2=A0 I'm not sure how m= y LTE provider provisioning IPv6 address. So The only possbile way is SLAAC= +private address=EF=BC=9F=C2=A0=C2=A0</div><div><br></div><div>Anyone who c= an help me out on this question? Or share your experience on how the mobile= ISP commonly provison their users. Thanks.=C2=A0</div><div><br></div><div>= Best regards,</div><div>Davey</div></div> </div></div></blockquote> </div>_______________________________________________<br> v6ops mailing list<br> <a href=3D"mailto:v6ops@ietf.org" target=3D"_blank">v6ops@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/v6ops" rel=3D"noreferrer" = target=3D"_blank">https://www.ietf.org/mailman/listinfo/v6ops</a><br> </blockquote></div> </blockquote></div></div></div> --00000000000054074e057460a841-- From nobody Sun Aug 26 18:37:16 2018 Return-Path: <cgaylord@vt.edu> 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 2B03A130DE2 for <v6ops@ietfa.amsl.com>; Sun, 26 Aug 2018 18:37:15 -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 82KmaQ8t9Hu7 for <v6ops@ietfa.amsl.com>; Sun, 26 Aug 2018 18:37:13 -0700 (PDT) Received: from omr1.cc.vt.edu (omr1.cc.ipv6.vt.edu [IPv6:2607:b400:92:8300:0:c6:2117:b0e]) (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 12DE21277C8 for <v6ops@ietf.org>; Sun, 26 Aug 2018 18:37:12 -0700 (PDT) Received: from mr3.cc.vt.edu (mr3.cc.vt.edu [IPv6:2607:b400:92:8500:0:7f:b804:6b0a]) by omr1.cc.vt.edu (8.14.4/8.14.4) with ESMTP id w7R1bCVZ003752 for <v6ops@ietf.org>; Sun, 26 Aug 2018 21:37:12 -0400 Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) by mr3.cc.vt.edu (8.14.7/8.14.7) with ESMTP id w7R1b666009236 for <v6ops@ietf.org>; Sun, 26 Aug 2018 21:37:11 -0400 Received: by mail-ed1-f70.google.com with SMTP id z30-v6so6026405edd.19 for <v6ops@ietf.org>; Sun, 26 Aug 2018 18:37:11 -0700 (PDT) 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=99sWU0HfT0OA62hinSqJOzQjuzK94ZphEWTsdLOhxpg=; b=cSvYctZbc/HC7+qXyWb16Uvwmlex2L2qmIYuAPD5+sC/pdA/RozKokiSPK7lkkMIme TNaokZpSC3mnRzuweqgGcow2px6f6G1vDL3zR4p5RMU+D36OhPj/g8z1B47da0kRf4Im xVt72/N2GECDEr41tEvAnHbPJl76pAiwBU6ylw2klQAKICf6QNX40w6Pj/+UyYczaY+3 UYfcCQ4x24OraItCOOcI4Yj3VCj5Lo1Xjd6rf3pR6uUxgMJ28lLnLGzi5wXxWz4lCgof vXjmqyyLDEX3LiElQ9c44mQtMGWZoU5Kp1ZvaH1NIqUsUmr/TZDiX+lKaDHyZmfD22aA e4rw== X-Gm-Message-State: APzg51BOb0ozIX89YdIUoACJCG5USbeE/hw5Kowq2gdkPRRbKhg3KHZj EftAD/tgInzfbebVpg79v8DsZpnEz5dL9nGVPOYW5qvaQWUeX+hWHGP+wc5+Fa4juBKx2fYAf3n i5bimB+OsP2ARsMhAMAv0qjhe6u3F8sZ9 X-Received: by 2002:a50:c8c3:: with SMTP id k3-v6mr14041230edh.193.1535333826253; Sun, 26 Aug 2018 18:37:06 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZWMbUy8A8jsTZjeZ5QOhGzxTUZi/4q7ap2FLoCEYdqWGgHef4sYlJOK7DB+Nf/RQUp15xylIM3EUR7SVR+56k= X-Received: by 2002:a50:c8c3:: with SMTP id k3-v6mr14041213edh.193.1535333825834; Sun, 26 Aug 2018 18:37:05 -0700 (PDT) MIME-Version: 1.0 References: <CAAObRXLe35KoONVsSO_oU+SRhMzMrKRE_SU-QNf2pGHYKpUrxA@mail.gmail.com> <CAKD1Yr1mzVu8B382z19RJPEEo1RcRTvy5YAH9cRVWgu6cn6h0w@mail.gmail.com> In-Reply-To: <CAKD1Yr1mzVu8B382z19RJPEEo1RcRTvy5YAH9cRVWgu6cn6h0w@mail.gmail.com> From: Clark Gaylord <cgaylord@vt.edu> Date: Sun, 26 Aug 2018 21:36:53 -0400 Message-ID: <CADzU5g6JdjM30OW4DD82ZecNNfD4g5XK++tb6qpygDSgnhhVog@mail.gmail.com> To: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org> Cc: songlinjian@gmail.com, "v6ops@ietf.org WG" <v6ops@ietf.org> Content-Type: multipart/alternative; boundary="0000000000004d085c057460c353" Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/bHjLxKGbWkaTB5NUPgoaRBq2T0E> Subject: Re: [v6ops] How my Android phone got assigned with IPv6 address via 4G LTE? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 27 Aug 2018 01:37:15 -0000 --0000000000004d085c057460c353 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >From RFC 6459: IPv6 Stateless Address Autoconfiguration (SLAAC), as specified in [RFC4861] and [RFC4862], is the only supported address configuration mechanism. Stateful DHCPv6-based address configuration [RFC3315] is not supported by 3GPP specifications. What you need to remember about SLAAC relative to the "FFFE" component is that this is part of how we convert 48 bit MAC addresses (EUI-48) to 64 bits (the other part being a bit flip). If you have 64 bits of interface address already, you don't need to stuff in 16 more bits. So don't let the lack of FFFE confuse you; this isn't Ethernet. :-) Enjoy Clark On Sun, Aug 26, 2018, 21:02 Lorenzo Colitti <lorenzo=3D 40google.com@dmarc.ietf.org> wrote: > See RFC 6459, and if you want more detail, the various 3GPP documents > listed in the references section of that RFC. > > On Mon, Aug 27, 2018 at 9:51 AM Davey Song <songlinjian@gmail.com> wrote: > >> Hi folks, >> >> Recently the IPv6 4G LTE of China moible and China Telecom is working. >> And I got the address information on my android phone, like : >> >> China Mobile : 2409:8900:8a10:6dof:4177:9599:de56:7092 >> China Telecom: 240e:ff:b10a:54a9:b5f7:5e4c:2f2d:9847 >> >> My question is : How these IPv6 addresses are assigned to my pohone and >> what type of address they are? They looks no EUI-64 address, without FF= FE >> in the middle of low 64 bits. And it can not be done by DHCPv6 because = I >> heard Android does not support DHCPv6, right? I'm not sure how my LTE >> provider provisioning IPv6 address. So The only possbile way is >> SLAAC+private address=EF=BC=9F >> >> Anyone who can help me out on this question? Or share your experience on >> how the mobile ISP commonly provison their users. Thanks. >> >> Best regards, >> Davey >> _______________________________________________ >> 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 > --=20 -- Clark Gaylord cgaylord@vt.edu ... Autocorrect may have improved this message ... --0000000000004d085c057460c353 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >From RFC 6459: IPv6 Stateless Address Autoconfiguration (SLAAC), as specifi= ed in [RFC4861] and [RFC4862], is the only supported address configuration = mechanism. Stateful DHCPv6-based address configuration [RFC3315] is not sup= ported by 3GPP specifications.<div><br></div><div>What you need to remember= about SLAAC relative to the "FFFE" component is that this is par= t of how we convert 48 bit MAC addresses (EUI-48) to 64 bits (the other par= t being a bit flip). If you have 64 bits of interface address already, you = don't need to stuff in 16 more bits. So don't let the lack of FFFE = confuse you; this isn't Ethernet. :-)</div><div><br></div><div>Enjoy</d= iv><div>Clark<br><div dir=3D"auto"><br><div class=3D"gmail_quote"><div dir= =3D"ltr">On Sun, Aug 26, 2018, 21:02 Lorenzo Colitti <lorenzo=3D<a href= =3D"mailto:40google.com@dmarc.ietf.org">40google.com@dmarc.ietf.org</a>>= wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8= ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">See RFC 64= 59, and if you want more detail, the various 3GPP documents listed in the r= eferences section of that RFC.</div><br><div class=3D"gmail_quote"><div dir= =3D"ltr">On Mon, Aug 27, 2018 at 9:51 AM Davey Song <<a href=3D"mailto:s= onglinjian@gmail.com" target=3D"_blank">songlinjian@gmail.com</a>> wrote= :<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor= der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi folks,<div><b= r></div><div>Recently the IPv6 4G LTE of China moible and China Telecom is = working. And I got the address information on my android phone, like :</div= ><div><br></div><div>China Mobile : 2409:8900:8a10:6dof:4177:9599:de56:7092= </div><div>China Telecom: 240e:ff:b10a:54a9:b5f7:5e4c:2f2d:9847</div><div><= br></div><div>My question is : How these IPv6 addresses are assigned to my = pohone and what type of address they are?=C2=A0 They looks no EUI-64 addres= s, without FFFE in the middle of low 64 bits.=C2=A0 And it can not be done = by DHCPv6 because I heard Android does not support DHCPv6, right?=C2=A0 I&#= 39;m not sure how my LTE provider provisioning IPv6 address. So The only po= ssbile way is SLAAC+private address=EF=BC=9F=C2=A0=C2=A0</div><div><br></di= v><div>Anyone who can help me out on this question? Or share your experienc= e on how the mobile ISP commonly provison their users. Thanks.=C2=A0</div><= div><br></div><div>Best regards,</div><div>Davey</div></div> _______________________________________________<br> v6ops mailing list<br> <a href=3D"mailto:v6ops@ietf.org" target=3D"_blank">v6ops@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/v6ops" rel=3D"noreferrer" = target=3D"_blank">https://www.ietf.org/mailman/listinfo/v6ops</a><br> </blockquote></div> _______________________________________________<br> v6ops mailing list<br> <a href=3D"mailto:v6ops@ietf.org" target=3D"_blank">v6ops@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/v6ops" rel=3D"noreferrer" = target=3D"_blank">https://www.ietf.org/mailman/listinfo/v6ops</a><br> </blockquote></div></div></div>-- <br><div dir=3D"ltr" class=3D"gmail_signa= ture" data-smartmail=3D"gmail_signature"><p dir=3D"ltr">--<br> Clark Gaylord<br> <a href=3D"mailto:cgaylord@vt.edu">cgaylord@vt.edu</a><br> ... Autocorrect may have improved this message ... </p> </div> --0000000000004d085c057460c353-- From nobody Sun Aug 26 19:04:40 2018 Return-Path: <lorenzo@google.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69DD9130E40 for <v6ops@ietfa.amsl.com>; Sun, 26 Aug 2018 19:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, T_KAM_HTML_FONT_INVALID=0.01, 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 HXTKNRQRbCDs for <v6ops@ietfa.amsl.com>; Sun, 26 Aug 2018 19:04:36 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (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 CC2CF1277C8 for <v6ops@ietf.org>; Sun, 26 Aug 2018 19:04:35 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id p79-v6so349966itp.3 for <v6ops@ietf.org>; Sun, 26 Aug 2018 19:04:35 -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=1tokfTo9f4+hTtV1OzUf7LvADlIPameG0IyD+B4/o84=; b=T8/vxse7n/ggoVfh9xE3rMwY9/FAyszfboAuPvuqszb5grjm88BfBkVPSmZKh8Av2F EVil2vvZps+7en/pvjcafkRD8k7KsYjfIo9kbvv6o3gSzxYGNg2ObwR+k1zkly8GMdZR lq+wQsCoUtdVlB7/lzO0SlzSjYmwiwxYjUSg+TL1pxyY3scvhauAwqyoJVUoCMq+Y90H XyYdJ0FhpD+AQJwWMoxuYCihfeyDvhGXQbvxi+zjf5fi+SaSI81BuNsAE/5nhzrSVNpO Zb0Bw7t18aI5hUHjfWkGkjsiPrNnPS8l3GhBbcuHjJNO6qMEMBOuriPyQFdWEYrTM7pb gscQ== 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=1tokfTo9f4+hTtV1OzUf7LvADlIPameG0IyD+B4/o84=; b=RoCETRBllGQ7s7Jjy1ToApp8DXnUE2cZtXfN3n5pVJoYQQ4IHS0NVi9LtACjj3sjpL 1ext3+078JvHJlKs+QckmnoZ2dHvW7NFbfTR7ZUXlIWKpZvWXgec1maE0vrzNsTSgZnc QnES1WLXH1i6KEANsoWZVFxQkIiGPQm1i/zwwlW3nkfvOwF4f5MLzr14eTVqlxpHOm2R kkAESKRlEwYjMOByMle6XsgBUklumpH74sFAjlTLs0T3FoyGL1pJPpA71OAbrgSSA3Kr Dp+SgMeJ+XG7cvbCQSZPNJyRBNMekMzPZD5QEBa6wCWtsD6yJZxxsH9vh4KJFjMDwaL4 ANGg== X-Gm-Message-State: APzg51AB8euz1a2/T5W6VktUsxopddZXd8nqTaydelsAyeCGXRNknFuo /wxr50GWp8vua3vOBQsyh7m3nClaBzZ9/t/CRX9gng== X-Google-Smtp-Source: ANB0VdaYURRRwhVnFzhKCptvlb8meaqRcNDV+dN8vOsLc7glNPMgx6qlAl4IbRcAzlhYSsFeENmby6j4uNP/Zl7oF0k= X-Received: by 2002:a24:41e9:: with SMTP id b102-v6mr5537656itd.19.1535335474507; Sun, 26 Aug 2018 19:04:34 -0700 (PDT) MIME-Version: 1.0 References: <CAAObRXLe35KoONVsSO_oU+SRhMzMrKRE_SU-QNf2pGHYKpUrxA@mail.gmail.com> <2018082709132233449033@chinatelecom.cn> <CAKD1Yr3PFKC06vwALL9Pjyd8Ji-RnqPR-HMvLA6CS6cyDadzVw@mail.gmail.com> <CAAObRXJx-8cPYuU-5gSMCvoOX-m29Q5BZg1-GANXBV-2Zmjv0A@mail.gmail.com> In-Reply-To: <CAAObRXJx-8cPYuU-5gSMCvoOX-m29Q5BZg1-GANXBV-2Zmjv0A@mail.gmail.com> From: Lorenzo Colitti <lorenzo@google.com> Date: Mon, 27 Aug 2018 11:04:23 +0900 Message-ID: <CAKD1Yr24fXHsRTwFErNGc+RYzXDfHFpF6zG5QFjfjS+xx5-9Mg@mail.gmail.com> To: songlinjian@gmail.com Cc: xiechf.bri@chinatelecom.cn, "v6ops@ietf.org WG" <v6ops@ietf.org> Content-Type: multipart/alternative; boundary="000000000000925d0b05746125e7" Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/0kHfHWfXKka-xexWZm9-Urta-U4> Subject: Re: [v6ops] How my Android phone got assigned with IPv6 address via 4G LTE? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 27 Aug 2018 02:04:39 -0000 --000000000000925d0b05746125e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The terminal can generate whatever addresses it wants. Per 23.060 section 9.2.1.1: =3D=3D=3D=3D=3D For stateless address autoconfiguration however, the MS can choose any interface identifier to generate addresses other than link-local, without involving the network. However, the UE shall not use any identifiers defined in TS 23.003 [4] as the basis for generating the interface identifier. For privacy, the UE may change the interface identifier used to generate full IPv6 address as defined in TS 23.221 [80], without involving the network. In particular, the SGSN and the GGSN are not updated with the actual address used by the MS, as the prefix alone identifies the PDP context. =3D=3D=3D=3D=3D On Mon, Aug 27, 2018 at 10:29 AM Davey Song <songlinjian@gmail.com> wrote: > So it is not neccsarily rfc7217 address? Is it true that no one can 100% > sure what type of address (or which std it is using) for a specific IPv6 > address assigned due to privacy consideration, right? > > Davey > On Mon, 27 Aug 2018 at 09:21, Lorenzo Colitti <lorenzo@google.com> wrote: > >> Actually I think per standards, the network only assigns the interface >> identifier for the link-local address. The interface identifier(s) for t= he >> global address(es) are assigned by the terminal in whatever way it wants= to >> assign them. >> >> On Mon, Aug 27, 2018 at 10:14 AM xiechf.bri@chinatelecom.cn < >> xiechf.bri@chinatelecom.cn> wrote: >> >>> Hi=EF=BC=8C Davey, >>> >>> I think you can check 3GPP TS 23.401 version 10.3.0 Release 10 . in >>> which the IPv6 allocation to UE is described as below, >>> >>> " >>> IPv6 Stateless Address autoconfiguration specified in RFC 4862 [18] is = the basic mechanism to allocate /64 IPv6 prefix >>> to the UE. >>> During default bearer establishment, the PDN GW sends the IPv6 prefix a= nd Interface Identifier to the S-GW, and then >>> >>> the S-GW forwards the IPv6 prefix and Interface Identifier to the MME o= r to the SGSN. The MME or the SGSN >>> >>> forwards the IPv6 Interface Identifier to the UE. The MME does not forw= ard the IPv6 prefix to the UE. If the UE >>> >>> receives the IPv6 prefix from the SGSN during PDP Context Activation pr= ocedure, it shall ignore it. >>> " >>> >>> From the above we can see that the Interface Identifier of UE is >>> allocated by network side. >>> >>> Chongfeng >>> >>> >>> >>> ------------------------------ >>> xiechf.bri@chinatelecom.cn >>> >>> >>> *From:* Davey Song <songlinjian@gmail.com> >>> *Date:* 2018-08-27 08:50 >>> *To:* v6ops <v6ops@ietf.org> >>> *Subject:* [v6ops] How my Android phone got assigned with IPv6 address >>> via 4G LTE? >>> Hi folks, >>> >>> Recently the IPv6 4G LTE of China moible and China Telecom is working. >>> And I got the address information on my android phone, like : >>> >>> China Mobile : 2409:8900:8a10:6dof:4177:9599:de56:7092 >>> China Telecom: 240e:ff:b10a:54a9:b5f7:5e4c:2f2d:9847 >>> >>> My question is : How these IPv6 addresses are assigned to my pohone and >>> what type of address they are? They looks no EUI-64 address, without F= FFE >>> in the middle of low 64 bits. And it can not be done by DHCPv6 because= I >>> heard Android does not support DHCPv6, right? I'm not sure how my LTE >>> provider provisioning IPv6 address. So The only possbile way is >>> SLAAC+private address=EF=BC=9F >>> >>> Anyone who can help me out on this question? Or share your experience o= n >>> how the mobile ISP commonly provison their users. Thanks. >>> >>> Best regards, >>> Davey >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> --000000000000925d0b05746125e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">The terminal can generate whatever addresses it wants. Per= 23.060 section <a href=3D"http://9.2.1.1">9.2.1.1</a>:<div><br></div><div>= =3D=3D=3D=3D=3D</div><div>For stateless address autoconfiguration however, = the MS can choose any interface identifier to generate addresses other than= link-local, without involving the network. However, the UE shall not use a= ny identifiers defined in TS 23.003 [4] as the basis for generating the int= erface identifier. For privacy, the UE may change the interface identifier = used to generate full IPv6 address as defined in TS 23.221 [80], without in= volving the network. In particular, the SGSN and the GGSN are not updated w= ith the actual address used by the MS, as the prefix alone identifies the P= DP context.</div><div><div>=3D=3D=3D=3D=3D</div></div></div><br><div class= =3D"gmail_quote"><div dir=3D"ltr">On Mon, Aug 27, 2018 at 10:29 AM Davey So= ng <<a href=3D"mailto:songlinjian@gmail.com">songlinjian@gmail.com</a>&g= t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">So it is= not neccsarily rfc7217 address?=C2=A0 Is it true that no one can 100% sure= what type of address (or which std it is using) for a specific IPv6 addres= s assigned due to privacy consideration, right?=C2=A0<div><br></div><div>Da= vey<br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, 27 Aug 2018 at 0= 9:21, Lorenzo Colitti <<a href=3D"mailto:lorenzo@google.com" target=3D"_= blank">lorenzo@google.com</a>> wrote:<br></div><blockquote class=3D"gmai= l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left= :1ex"><div dir=3D"ltr">Actually I think per standards, the network only ass= igns the interface identifier for the link-local address. The interface ide= ntifier(s) for the global address(es) are assigned by the terminal in whate= ver way it wants to assign them.</div><br><div class=3D"gmail_quote"><div d= ir=3D"ltr">On Mon, Aug 27, 2018 at 10:14 AM <a href=3D"mailto:xiechf.bri@ch= inatelecom.cn" target=3D"_blank">xiechf.bri@chinatelecom.cn</a> <<a href= =3D"mailto:xiechf.bri@chinatelecom.cn" target=3D"_blank">xiechf.bri@chinate= lecom.cn</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D= "margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div> <div><span></span>Hi=EF=BC=8C Davey,</div><div><br></div><div>I think you c= an check=C2=A0<span style=3D"font-family:'';font-size:10.5pt;line-h= eight:1.5;background-color:window">3GPP=C2=A0TS=C2=A023.401=C2=A0version=C2= =A010.3.0=C2=A0Release=C2=A010</span><span style=3D"font-size:10.5pt;line-h= eight:1.5;background-color:window">=C2=A0. in which the IPv6 allocation to = UE is described as below,</span></div><div><br></div><div>"<span style= =3D"font-family:'';font-size:10.5pt;line-height:1.5;background-colo= r:window">IPv6=C2=A0Stateless=C2=A0Address=C2=A0autoconfiguration=C2=A0spec= ified=C2=A0in=C2=A0RFC=C2=A04862=C2=A0[18]=C2=A0is=C2=A0the=C2=A0basic=C2= =A0mechanism=C2=A0to=C2=A0allocate=C2=A0/64=C2=A0IPv6=C2=A0prefix</span></d= iv><div><span style=3D"font-family:'';font-size:10.5pt;line-height:= 1.5;background-color:window">to=C2=A0the=C2=A0UE.=C2=A0</span><span style= =3D"font-family:'';font-size:10.5pt;line-height:1.5;background-colo= r:window">During=C2=A0default=C2=A0bearer=C2=A0establishment,=C2=A0the=C2= =A0PDN=C2=A0GW=C2=A0sends=C2=A0the=C2=A0IPv6=C2=A0prefix=C2=A0and=C2=A0Inte= rface=C2=A0Identifier=C2=A0to=C2=A0the=C2=A0S-GW,=C2=A0and=C2=A0then</span>= </div><span>the=C2=A0S-GW=C2=A0forwards=C2=A0the=C2=A0IPv6=C2=A0prefix=C2= =A0and=C2=A0Interface=C2=A0Identifier=C2=A0to=C2=A0the=C2=A0MME=C2=A0or=C2= =A0to=C2=A0the=C2=A0SGSN.=C2=A0The=C2=A0MME=C2=A0or=C2=A0the=C2=A0SGSN<br>f= orwards=C2=A0the=C2=A0IPv6=C2=A0Interface=C2=A0Identifier=C2=A0to=C2=A0the= =C2=A0UE.=C2=A0The=C2=A0MME=C2=A0does=C2=A0not=C2=A0forward=C2=A0the=C2=A0I= Pv6=C2=A0prefix=C2=A0to=C2=A0the=C2=A0UE.=C2=A0If=C2=A0the=C2=A0UE<br></spa= n><div><span style=3D"font-family:'';font-size:10.5pt;line-height:1= .5;background-color:window">receives=C2=A0the=C2=A0IPv6=C2=A0prefix=C2=A0fr= om=C2=A0the=C2=A0SGSN=C2=A0during=C2=A0PDP=C2=A0Context=C2=A0Activation=C2= =A0procedure,=C2=A0it=C2=A0shall=C2=A0ignore=C2=A0it.</span>"</div><di= v><br></div><div>From the above we can see that the=C2=A0<span style=3D"fon= t-size:10.5pt;line-height:1.5;background-color:window">Interface=C2=A0Ident= ifier of UE is allocated by network side.</span></div><div><span style=3D"f= ont-size:10.5pt;line-height:1.5;background-color:window"><br></span></div><= div>Chongfeng</div><div><br></div><div><br></div> <div><br></div><hr style=3D"width:210px;height:1px" color=3D"#b5c4df" size= =3D"1" align=3D"left"> <div><span><div style=3D"MARGIN:10px;FONT-FAMILY:verdana;FONT-SIZE:10pt"><d= iv><a href=3D"mailto:xiechf.bri@chinatelecom.cn" target=3D"_blank">xiechf.b= ri@chinatelecom.cn</a></div></div></span></div> <blockquote style=3D"margin-top:0px;margin-bottom:0px;margin-left:0.5em"><d= iv>=C2=A0</div><div style=3D"border:none;border-top:solid #b5c4df 1.0pt;pad= ding:3.0pt 0cm 0cm 0cm"><div style=3D"PADDING-RIGHT:8px;PADDING-LEFT:8px;FO= NT-SIZE:12px;FONT-FAMILY:tahoma;COLOR:#000000;BACKGROUND:#efefef;PADDING-BO= TTOM:8px;PADDING-TOP:8px"><div><b>From:</b>=C2=A0<a href=3D"mailto:songlinj= ian@gmail.com" target=3D"_blank">Davey Song</a></div><div><b>Date:</b>=C2= =A02018-08-27=C2=A008:50</div><div><b>To:</b>=C2=A0<a href=3D"mailto:v6ops@= ietf.org" target=3D"_blank">v6ops</a></div><div><b>Subject:</b>=C2=A0[v6ops= ] How my Android phone got assigned with IPv6 address via 4G LTE?</div></di= v></div><div><div class=3D"m_-7774863976398680665m_-1498842969820883944m_38= 67402898991505251FoxDiv20180827090914910278"><div dir=3D"ltr">Hi folks,<div= ><br></div><div>Recently the IPv6 4G LTE of China moible and China Telecom = is working. And I got the address information on my android phone, like :</= div><div><br></div><div>China Mobile : 2409:8900:8a10:6dof:4177:9599:de56:7= 092</div><div>China Telecom: 240e:ff:b10a:54a9:b5f7:5e4c:2f2d:9847</div><di= v><br></div><div>My question is : How these IPv6 addresses are assigned to = my pohone and what type of address they are?=C2=A0 They looks no EUI-64 add= ress, without FFFE in the middle of low 64 bits.=C2=A0 And it can not be do= ne by DHCPv6 because I heard Android does not support DHCPv6, right?=C2=A0 = I'm not sure how my LTE provider provisioning IPv6 address. So The only= possbile way is SLAAC+private address=EF=BC=9F=C2=A0=C2=A0</div><div><br><= /div><div>Anyone who can help me out on this question? Or share your experi= ence on how the mobile ISP commonly provison their users. Thanks.=C2=A0</di= v><div><br></div><div>Best regards,</div><div>Davey</div></div> </div></div></blockquote> </div>_______________________________________________<br> v6ops mailing list<br> <a href=3D"mailto:v6ops@ietf.org" target=3D"_blank">v6ops@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/v6ops" rel=3D"noreferrer" = target=3D"_blank">https://www.ietf.org/mailman/listinfo/v6ops</a><br> </blockquote></div> </blockquote></div></div></div> </blockquote></div> --000000000000925d0b05746125e7-- From nobody Sun Aug 26 20:46:52 2018 Return-Path: <songlinjian@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2011277BB for <v6ops@ietfa.amsl.com>; Sun, 26 Aug 2018 20:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 fucw5NShdbPc for <v6ops@ietfa.amsl.com>; Sun, 26 Aug 2018 20:46:47 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (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 60711126F72 for <v6ops@ietf.org>; Sun, 26 Aug 2018 20:46:47 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id b14-v6so6883790vke.13 for <v6ops@ietf.org>; Sun, 26 Aug 2018 20:46:47 -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=M8lkGwmL1iP5XgQJEOmCbLL8XPDXY6jki0X9YfX15sw=; b=Q5r/wdig+JO3AmOzW6zqiIc+FwdAM++2Lsh0BR1pVca/wUCc8OJz+1VDXa+UErIofD 3xjBXqQ8jJR5wAar3yiw4lMreA4TYuPTfukHdIzO3cxJiqnoIXQ7E4Ab78Fn89pc3Nz+ zA5MuqJUstUu3C+NSrnYhgKJ3wAFrOxBFB1cHBs05GSHa3CFb6p44B08dcKqXtEDtsZz x0USFtaYMI8ORqRRxvhRYUh4LIzfjKBycMV8I6ZPB0CgrVLLwjkDlw4BgSEnDdHS/0OS 77yh/5b8I4NuFAhkfY0ZCw5al92DayffhsoPry7ii+31lTn95WEZFN2RbeqmCjc+DDsZ wlYw== 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=M8lkGwmL1iP5XgQJEOmCbLL8XPDXY6jki0X9YfX15sw=; b=JrrgqRq2bYztrWaRczTIRqxH7LimjU9bac70MBVUW9zfBQcqnjL+Y94kUBxvKoVXve BKhPtCR+8cHOVbvsELUEPUHirYD1klelHZheMcPcBZ5lnNt2D5ws2ZpJufMK4WYx88qQ ernrZmPzvp1wg5bCOiqeJooMRSWI9kEqVbZoAM/SBg39HZxm1IN0WBXcwFHGWXz0wGcW bmvxv1464Jz072YDT/jnrONJSEIal8Fmzi5E+z8Cjoe+7WTHC8WXK0sNUjmYRa3IqEfm cSj/EajWjs/A78x7MgbRyEqga5675KFSQig3rsag5MLVYkljTw6xabkdJFPz61lLHN/0 6kIA== X-Gm-Message-State: APzg51DXSmdOsEcYkTFZK9xfqotSqAdP5QAT1iS1eE/ozmBDyQlRei6Q dqDjeKlL06RkS3ExfnN1R9VsMUPuSRXLrY8ZyVM= X-Google-Smtp-Source: ANB0VdYhodRGYf6aO75HEdllJ+hOijaK2gaZ9kKsFjDVFxiXTB8n1bBqZwSAPFeXdp9bEYt5xnjODEEqqzcvaorqD8M= X-Received: by 2002:a1f:d844:: with SMTP id p65-v6mr7171083vkg.54.1535341606332; Sun, 26 Aug 2018 20:46:46 -0700 (PDT) MIME-Version: 1.0 References: <CAAObRXLe35KoONVsSO_oU+SRhMzMrKRE_SU-QNf2pGHYKpUrxA@mail.gmail.com> <2018082709132233449033@chinatelecom.cn> <CAKD1Yr3PFKC06vwALL9Pjyd8Ji-RnqPR-HMvLA6CS6cyDadzVw@mail.gmail.com> <CAAObRXJx-8cPYuU-5gSMCvoOX-m29Q5BZg1-GANXBV-2Zmjv0A@mail.gmail.com> <CAKD1Yr24fXHsRTwFErNGc+RYzXDfHFpF6zG5QFjfjS+xx5-9Mg@mail.gmail.com> In-Reply-To: <CAKD1Yr24fXHsRTwFErNGc+RYzXDfHFpF6zG5QFjfjS+xx5-9Mg@mail.gmail.com> From: Davey Song <songlinjian@gmail.com> Date: Mon, 27 Aug 2018 11:46:37 +0800 Message-ID: <CAAObRXK3jx_FXi-Rt5W3iSkOrf8zmc2z0NC1hUoET=AMFj2sig@mail.gmail.com> To: Lorenzo Colitti <lorenzo@google.com> Cc: xiechf.bri@chinatelecom.cn, v6ops@ietf.org Content-Type: multipart/alternative; boundary="0000000000000dee9a05746293ed" Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/h6Cn2DSpHHtLeAZZNPWi3FAFdKw> Subject: Re: [v6ops] How my Android phone got assigned with IPv6 address via 4G LTE? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 27 Aug 2018 03:46:50 -0000 --0000000000000dee9a05746293ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Another question about the lifetime of the address. How long will the address persist? I mean the lifetime of a IPv6 address assigned. I test with my phone that every time I turn on the "Mobile data", or switch from WIF, the IPv6 address changed. I'm not sure How long it will persist. I check windows 10 on my laptop (netsh interface ipv6 show privacy), the Maximum Preferred Lifetime is one day. I ask the question because some application developer may build their app based on the persistence of the IPv6 address. Mycurrent suggestion to them is "DO NOT RELY on IPv6 PERSISTENCE" becuase it changes more frequently than IPv4. Is it right ? Davey On Mon, 27 Aug 2018 at 10:04, Lorenzo Colitti <lorenzo@google.com> wrote: > The terminal can generate whatever addresses it wants. Per 23.060 section > 9.2.1.1: > > =3D=3D=3D=3D=3D > For stateless address autoconfiguration however, the MS can choose any > interface identifier to generate addresses other than link-local, without > involving the network. However, the UE shall not use any identifiers > defined in TS 23.003 [4] as the basis for generating the interface > identifier. For privacy, the UE may change the interface identifier used = to > generate full IPv6 address as defined in TS 23.221 [80], without involvin= g > the network. In particular, the SGSN and the GGSN are not updated with th= e > actual address used by the MS, as the prefix alone identifies the PDP > context. > =3D=3D=3D=3D=3D > > On Mon, Aug 27, 2018 at 10:29 AM Davey Song <songlinjian@gmail.com> wrote= : > >> So it is not neccsarily rfc7217 address? Is it true that no one can 100= % >> sure what type of address (or which std it is using) for a specific IPv6 >> address assigned due to privacy consideration, right? >> >> Davey >> On Mon, 27 Aug 2018 at 09:21, Lorenzo Colitti <lorenzo@google.com> wrote= : >> >>> Actually I think per standards, the network only assigns the interface >>> identifier for the link-local address. The interface identifier(s) for = the >>> global address(es) are assigned by the terminal in whatever way it want= s to >>> assign them. >>> >>> On Mon, Aug 27, 2018 at 10:14 AM xiechf.bri@chinatelecom.cn < >>> xiechf.bri@chinatelecom.cn> wrote: >>> >>>> Hi=EF=BC=8C Davey, >>>> >>>> I think you can check 3GPP TS 23.401 version 10.3.0 Release 10 . in >>>> which the IPv6 allocation to UE is described as below, >>>> >>>> " >>>> IPv6 Stateless Address autoconfiguration specified in RFC 4862 [18] is= the basic mechanism to allocate /64 IPv6 prefix >>>> to the UE. >>>> During default bearer establishment, the PDN GW sends the IPv6 prefix = and Interface Identifier to the S-GW, and then >>>> >>>> the S-GW forwards the IPv6 prefix and Interface Identifier to the MME = or to the SGSN. The MME or the SGSN >>>> >>>> forwards the IPv6 Interface Identifier to the UE. The MME does not for= ward the IPv6 prefix to the UE. If the UE >>>> >>>> receives the IPv6 prefix from the SGSN during PDP Context Activation p= rocedure, it shall ignore it. >>>> " >>>> >>>> From the above we can see that the Interface Identifier of UE is >>>> allocated by network side. >>>> >>>> Chongfeng >>>> >>>> >>>> >>>> ------------------------------ >>>> xiechf.bri@chinatelecom.cn >>>> >>>> >>>> *From:* Davey Song <songlinjian@gmail.com> >>>> *Date:* 2018-08-27 08:50 >>>> *To:* v6ops <v6ops@ietf.org> >>>> *Subject:* [v6ops] How my Android phone got assigned with IPv6 address >>>> via 4G LTE? >>>> Hi folks, >>>> >>>> Recently the IPv6 4G LTE of China moible and China Telecom is working. >>>> And I got the address information on my android phone, like : >>>> >>>> China Mobile : 2409:8900:8a10:6dof:4177:9599:de56:7092 >>>> China Telecom: 240e:ff:b10a:54a9:b5f7:5e4c:2f2d:9847 >>>> >>>> My question is : How these IPv6 addresses are assigned to my pohone an= d >>>> what type of address they are? They looks no EUI-64 address, without = FFFE >>>> in the middle of low 64 bits. And it can not be done by DHCPv6 becaus= e I >>>> heard Android does not support DHCPv6, right? I'm not sure how my LTE >>>> provider provisioning IPv6 address. So The only possbile way is >>>> SLAAC+private address=EF=BC=9F >>>> >>>> Anyone who can help me out on this question? Or share your experience >>>> on how the mobile ISP commonly provison their users. Thanks. >>>> >>>> Best regards, >>>> Davey >>>> >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >>> --0000000000000dee9a05746293ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><br></div><div><br></div><div>Another question about = the lifetime of the address.</div><div><br></div><div>How long will the add= ress persist? I mean the lifetime of a IPv6 address assigned.=C2=A0 I test = with my phone that every time I turn on the=C2=A0 "Mobile data", = or switch from WIF, the IPv6 address changed. I'm not sure How long it = will persist. I check windows 10 on my laptop (netsh interface ipv6 show pr= ivacy), the Maximum Preferred Lifetime is one day.</div><div><br></div><div= >I ask the question because some application developer may build their app = based on the persistence of the IPv6 address. Mycurrent suggestion to them = is "DO NOT RELY on IPv6 PERSISTENCE" becuase it changes more freq= uently than IPv4.=C2=A0 Is it right ?</div><div><br></div><div>Davey</div><= /div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, 27 Aug 2018 at= 10:04, Lorenzo Colitti <<a href=3D"mailto:lorenzo@google.com">lorenzo@g= oogle.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir= =3D"ltr">The terminal can generate whatever addresses it wants. Per 23.060 = section <a href=3D"http://9.2.1.1" target=3D"_blank">9.2.1.1</a>:<div><br><= /div><div>=3D=3D=3D=3D=3D</div><div>For stateless address autoconfiguration= however, the MS can choose any interface identifier to generate addresses = other than link-local, without involving the network. However, the UE shall= not use any identifiers defined in TS 23.003 [4] as the basis for generati= ng the interface identifier. For privacy, the UE may change the interface i= dentifier used to generate full IPv6 address as defined in TS 23.221 [80], = without involving the network. In particular, the SGSN and the GGSN are not= updated with the actual address used by the MS, as the prefix alone identi= fies the PDP context.</div><div><div>=3D=3D=3D=3D=3D</div></div></div><br><= div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Aug 27, 2018 at 10:29 AM= Davey Song <<a href=3D"mailto:songlinjian@gmail.com" target=3D"_blank">= songlinjian@gmail.com</a>> wrote:<br></div><blockquote class=3D"gmail_qu= ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex= "><div dir=3D"ltr">So it is not neccsarily rfc7217 address?=C2=A0 Is it tru= e that no one can 100% sure what type of address (or which std it is using)= for a specific IPv6 address assigned due to privacy consideration, right?= =C2=A0<div><br></div><div>Davey<br><div class=3D"gmail_quote"><div dir=3D"l= tr">On Mon, 27 Aug 2018 at 09:21, Lorenzo Colitti <<a href=3D"mailto:lor= enzo@google.com" target=3D"_blank">lorenzo@google.com</a>> wrote:<br></d= iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left= :1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Actually I think per sta= ndards, the network only assigns the interface identifier for the link-loca= l address. The interface identifier(s) for the global address(es) are assig= ned by the terminal in whatever way it wants to assign them.</div><br><div = class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Aug 27, 2018 at 10:14 AM <a = href=3D"mailto:xiechf.bri@chinatelecom.cn" target=3D"_blank">xiechf.bri@chi= natelecom.cn</a> <<a href=3D"mailto:xiechf.bri@chinatelecom.cn" target= =3D"_blank">xiechf.bri@chinatelecom.cn</a>> wrote:<br></div><blockquote = class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid= ;padding-left:1ex"><div> <div><span></span>Hi=EF=BC=8C Davey,</div><div><br></div><div>I think you c= an check=C2=A0<span style=3D"font-family:'';font-size:10.5pt;line-h= eight:1.5;background-color:window">3GPP=C2=A0TS=C2=A023.401=C2=A0version=C2= =A010.3.0=C2=A0Release=C2=A010</span><span style=3D"font-size:10.5pt;line-h= eight:1.5;background-color:window">=C2=A0. in which the IPv6 allocation to = UE is described as below,</span></div><div><br></div><div>"<span style= =3D"font-family:'';font-size:10.5pt;line-height:1.5;background-colo= r:window">IPv6=C2=A0Stateless=C2=A0Address=C2=A0autoconfiguration=C2=A0spec= ified=C2=A0in=C2=A0RFC=C2=A04862=C2=A0[18]=C2=A0is=C2=A0the=C2=A0basic=C2= =A0mechanism=C2=A0to=C2=A0allocate=C2=A0/64=C2=A0IPv6=C2=A0prefix</span></d= iv><div><span style=3D"font-family:'';font-size:10.5pt;line-height:= 1.5;background-color:window">to=C2=A0the=C2=A0UE.=C2=A0</span><span style= =3D"font-family:'';font-size:10.5pt;line-height:1.5;background-colo= r:window">During=C2=A0default=C2=A0bearer=C2=A0establishment,=C2=A0the=C2= =A0PDN=C2=A0GW=C2=A0sends=C2=A0the=C2=A0IPv6=C2=A0prefix=C2=A0and=C2=A0Inte= rface=C2=A0Identifier=C2=A0to=C2=A0the=C2=A0S-GW,=C2=A0and=C2=A0then</span>= </div><span>the=C2=A0S-GW=C2=A0forwards=C2=A0the=C2=A0IPv6=C2=A0prefix=C2= =A0and=C2=A0Interface=C2=A0Identifier=C2=A0to=C2=A0the=C2=A0MME=C2=A0or=C2= =A0to=C2=A0the=C2=A0SGSN.=C2=A0The=C2=A0MME=C2=A0or=C2=A0the=C2=A0SGSN<br>f= orwards=C2=A0the=C2=A0IPv6=C2=A0Interface=C2=A0Identifier=C2=A0to=C2=A0the= =C2=A0UE.=C2=A0The=C2=A0MME=C2=A0does=C2=A0not=C2=A0forward=C2=A0the=C2=A0I= Pv6=C2=A0prefix=C2=A0to=C2=A0the=C2=A0UE.=C2=A0If=C2=A0the=C2=A0UE<br></spa= n><div><span style=3D"font-family:'';font-size:10.5pt;line-height:1= .5;background-color:window">receives=C2=A0the=C2=A0IPv6=C2=A0prefix=C2=A0fr= om=C2=A0the=C2=A0SGSN=C2=A0during=C2=A0PDP=C2=A0Context=C2=A0Activation=C2= =A0procedure,=C2=A0it=C2=A0shall=C2=A0ignore=C2=A0it.</span>"</div><di= v><br></div><div>From the above we can see that the=C2=A0<span style=3D"fon= t-size:10.5pt;line-height:1.5;background-color:window">Interface=C2=A0Ident= ifier of UE is allocated by network side.</span></div><div><span style=3D"f= ont-size:10.5pt;line-height:1.5;background-color:window"><br></span></div><= div>Chongfeng</div><div><br></div><div><br></div> <div><br></div><hr style=3D"width:210px;height:1px" color=3D"#b5c4df" size= =3D"1" align=3D"left"> <div><span><div style=3D"MARGIN:10px;FONT-FAMILY:verdana;FONT-SIZE:10pt"><d= iv><a href=3D"mailto:xiechf.bri@chinatelecom.cn" target=3D"_blank">xiechf.b= ri@chinatelecom.cn</a></div></div></span></div> <blockquote style=3D"margin-top:0px;margin-bottom:0px;margin-left:0.5em"><d= iv>=C2=A0</div><div style=3D"border:none;border-top:solid #b5c4df 1.0pt;pad= ding:3.0pt 0cm 0cm 0cm"><div style=3D"PADDING-RIGHT:8px;PADDING-LEFT:8px;FO= NT-SIZE:12px;FONT-FAMILY:tahoma;COLOR:#000000;BACKGROUND:#efefef;PADDING-BO= TTOM:8px;PADDING-TOP:8px"><div><b>From:</b>=C2=A0<a href=3D"mailto:songlinj= ian@gmail.com" target=3D"_blank">Davey Song</a></div><div><b>Date:</b>=C2= =A02018-08-27=C2=A008:50</div><div><b>To:</b>=C2=A0<a href=3D"mailto:v6ops@= ietf.org" target=3D"_blank">v6ops</a></div><div><b>Subject:</b>=C2=A0[v6ops= ] How my Android phone got assigned with IPv6 address via 4G LTE?</div></di= v></div><div><div class=3D"m_2322334285191149487m_-7774863976398680665m_-14= 98842969820883944m_3867402898991505251FoxDiv20180827090914910278"><div dir= =3D"ltr">Hi folks,<div><br></div><div>Recently the IPv6 4G LTE of China moi= ble and China Telecom is working. And I got the address information on my a= ndroid phone, like :</div><div><br></div><div>China Mobile : 2409:8900:8a10= :6dof:4177:9599:de56:7092</div><div>China Telecom: 240e:ff:b10a:54a9:b5f7:5= e4c:2f2d:9847</div><div><br></div><div>My question is : How these IPv6 addr= esses are assigned to my pohone and what type of address they are?=C2=A0 Th= ey looks no EUI-64 address, without FFFE in the middle of low 64 bits.=C2= =A0 And it can not be done by DHCPv6 because I heard Android does not suppo= rt DHCPv6, right?=C2=A0 I'm not sure how my LTE provider provisioning I= Pv6 address. So The only possbile way is SLAAC+private address=EF=BC=9F=C2= =A0=C2=A0</div><div><br></div><div>Anyone who can help me out on this quest= ion? Or share your experience on how the mobile ISP commonly provison their= users. Thanks.=C2=A0</div><div><br></div><div>Best regards,</div><div>Dave= y</div></div> </div></div></blockquote> </div>_______________________________________________<br> v6ops mailing list<br> <a href=3D"mailto:v6ops@ietf.org" target=3D"_blank">v6ops@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/v6ops" rel=3D"noreferrer" = target=3D"_blank">https://www.ietf.org/mailman/listinfo/v6ops</a><br> </blockquote></div> </blockquote></div></div></div> </blockquote></div> </blockquote></div> --0000000000000dee9a05746293ed-- From nobody Sun Aug 26 21:00:49 2018 Return-Path: <ek@google.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC8C126F72 for <v6ops@ietfa.amsl.com>; Sun, 26 Aug 2018 21:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.511 X-Spam-Level: X-Spam-Status: No, score=-17.511 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, 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 lEtxjNqF7iOZ for <v6ops@ietfa.amsl.com>; Sun, 26 Aug 2018 21:00:45 -0700 (PDT) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7F80128CF3 for <v6ops@ietf.org>; Sun, 26 Aug 2018 21:00:45 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id f145-v6so5565711ybg.4 for <v6ops@ietf.org>; Sun, 26 Aug 2018 21:00:45 -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=3UyOsh7JzfEGyvCSTSiojtHeksiFjMKtWR642n+aaiE=; b=nlo2bR5BqH9OPv8LoJhOh8elilfnsxe3HxXs617Qs+Tag8ZcHjAFKLmGzmalUsmgdS ciP8Avj+5d/qAHkj/43SGudm5Uct0tiBWlGYoZO0Yrxh8c19c3iJFFZs5cFmXlS83GFk SHf5BGlWbdJwYedT0rz8vrYK0b9UON7c0dOpgD4caC6kAZ1Tr/ULAPBQuACqcTHbNDpG EnR7O273P2aHXQyTMPyizWZY9a+zm+yQwXYRni83YVEMLcCO0EW3XLPXwbCna68mlMwC jZkpBNU+XFZvUq9fJgmhr7mnhCEZphq/NxlcDQyMdJAET4r8bOx/keaplk7Vd+PQdW+L cykg== 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=3UyOsh7JzfEGyvCSTSiojtHeksiFjMKtWR642n+aaiE=; b=ANGBhcln7jr8amV2GLFsoizMFOVHhNrSIt5YZ2NpTFn/6ySljCRzKncxDXEEkiJ4Ec XUApIQAH+EPzHWoCsY7sPTBV+tFcqgncs8ne0nF3FZIlyLULAHLiqjNGeF8BfigSPlEl 333TiW9dlZVFUQcok4GziSEBmNraULge03TK1dA5mVWrpwVFWAN97fk5oLSgbPjSjQR7 CRTb8486VupuNojSrWE6BNg295cCZYW5ph1ByY9GLTyyEEYA/a94ELHxqwmAZierD4NU 243C+68LWMl8xm5NayxHlIn3vcsOJGaIJRj2rdvC5m863o/Jj/X8LrPOfqXOCDgfcVBi MHUg== X-Gm-Message-State: APzg51DwiQHZFjHDEX/0CS+nl/ZMfD9G5znOKhdJAITo7l/XrCenSoRp z5ERmivsFeuITFdEZXqHRM6NYCKlAJx/sDag6jjvpQ== X-Google-Smtp-Source: ANB0VdYLYsnYW60T4vUpznKruzn1YRZEL+gXoBVIGvlyHHA7PK7fw473x9emKtBNZlyUQsD4Pnyr8LW0+WuTTDpY1G8= X-Received: by 2002:a25:c382:: with SMTP id t124-v6mr6194831ybf.130.1535342444362; Sun, 26 Aug 2018 21:00:44 -0700 (PDT) MIME-Version: 1.0 References: <CAAObRXLe35KoONVsSO_oU+SRhMzMrKRE_SU-QNf2pGHYKpUrxA@mail.gmail.com> <2018082709132233449033@chinatelecom.cn> <CAKD1Yr3PFKC06vwALL9Pjyd8Ji-RnqPR-HMvLA6CS6cyDadzVw@mail.gmail.com> <CAAObRXJx-8cPYuU-5gSMCvoOX-m29Q5BZg1-GANXBV-2Zmjv0A@mail.gmail.com> <CAKD1Yr24fXHsRTwFErNGc+RYzXDfHFpF6zG5QFjfjS+xx5-9Mg@mail.gmail.com> <CAAObRXK3jx_FXi-Rt5W3iSkOrf8zmc2z0NC1hUoET=AMFj2sig@mail.gmail.com> In-Reply-To: <CAAObRXK3jx_FXi-Rt5W3iSkOrf8zmc2z0NC1hUoET=AMFj2sig@mail.gmail.com> From: Erik Kline <ek@google.com> Date: Mon, 27 Aug 2018 13:00:30 +0900 Message-ID: <CAAedzxouJUY1-R2NQH8sMDA0vrkOSznOWUaykBtdMy5a5Cup4g@mail.gmail.com> To: songlinjian@gmail.com Cc: Lorenzo Colitti <lorenzo@google.com>, "v6ops@ietf.org WG" <v6ops@ietf.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000000bbb98057462c579" Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/OxLXQFsGvyTgKINRByvHZ6lZiYM> Subject: Re: [v6ops] How my Android phone got assigned with IPv6 address via 4G LTE? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 27 Aug 2018 04:00:48 -0000 --0000000000000bbb98057462c579 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 27 Aug 2018 at 12:47, Davey Song <songlinjian@gmail.com> wrote: > > > > Another question about the lifetime of the address. > > How long will the address persist? I mean the lifetime of a IPv6 address = assigned. I test with my phone that every time I turn on the "Mobile data= ", or switch from WIF, the IPv6 address changed. I'm not sure How long it w= ill persist. I check windows 10 on my laptop (netsh interface ipv6 show pri= vacy), the Maximum Preferred Lifetime is one day. > > I ask the question because some application developer may build their app= based on the persistence of the IPv6 address. Mycurrent suggestion to them= is "DO NOT RELY on IPv6 PERSISTENCE" becuase it changes more frequently th= an IPv4. Is it right ? There are no guarantees at the IP layer of address persistence beyond the lifetimes in the PIO/RA. In general, any number of circumstances can cause the device to disconnect from the network at any time. When it next reconnects it may be provisioned with an entirely different prefix, for example. Of course, there might be some contractual arrangement that a given device is routed a known prefix, but that has no IP-layer representation. > Davey --0000000000000bbb98057462c579 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMPipSifuL4Tx7dmsbMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MDcxNTA2MzcxOFoXDTE5MDEx MTA2MzcxOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALkHIP2fSFudoue2xAkNBouFm2EulKm/RKnsxmEw4dSbxQC2Mt72Ga/t ySyn6PMSAgsyjgP0bKJZf/NHBzDGuSKpY09UgBupEUEejwR4d5vrHk8IJNfIDTQ+Ygv4krlQmkO0 Qh/GB1y4PxtIn0tVfGfB7s3Z7wWyYbN1JrUrxAhKTpvkbJLRF1n/fKgv1nfUYyY9se4cZE3XQbJV 2biA0ATE8hw55TPa9FTv+QuWbAWXlTfsvz8SxdL8cs1HXVzBwi7kpzm2LbLictqUYotBdrCk2JQ9 ZkICHIpunwWnfTfNJ1Vt7MYL8worV+Y0TfBP0Uw1IG8qQ1Fdie3quVfdAoUCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBQw12fRZdlCj/XWgp08Ky/Ct82W7DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAsH2eOQwQDXJ145YZFyjaTxqiVS9t F3F65BSt739euYxmyoYFAFgBVwRLXBjD0eTRqz6W6O9FC3ZPzsIup/DXZZlPNPitbqGA391usTKN YHYsBchdjOocgO8gNokf3H4yvjUv6699ncUQXX+d0deUo38jOa4+OujSIQbz+PUicageFuFcraDO MV5VMHYtn/1Ngkrw4JSaf2nv1WTfUBQyRRorMCPXVJZLEm8K0apTK2RHaxnFvXHJjFPkLLsJSwmQ RCeC98jyQdFHPQank0x8KmEo+nlu2d0X0n/aLibqG7rRSVKINpvLv6C3j8P4b1t1Fu23J6OYkWUx Rz/Rs1hfPTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDD4qUon7i+E8e3ZrGzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgcwd5UdMmlQwymNCKj/HV0TmedgvlADVV 4G7p66enThIwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwODI3 MDQwMDQ1WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBADVsUTVrrb5kA0DNgBbYQ3jS2X9JsnFXuGATRFRglW9mE00W5ruW ackEm47uYZfbDUemoAeuzntXXp1/PxU5L9Qa2f2GwrdHiI/9rLA1s1lxHuS8d7pup6w2/tGyEtAL DcbNYhrwEEQKeYMpMN2/PBzWSbjixBpp5NKJw6VjiWfAElC1qrMM18cEVpf0vJreBrXh2hXUcH1S PKD/ejDL3Pj0G3OodfY2ojbJluVBiqWvUx5AusBUcAb6tJSHmwhnl/NA1u2OnCmtT/XKVDZAC/eq e5+1eYZZTrIsnghom/yKoBOu1VSvTaJC5tOTPxQChXbaZwkjE60sfCsp4mPMiS8= --0000000000000bbb98057462c579-- From nobody Sun Aug 26 21:27:09 2018 Return-Path: <brian.e.carpenter@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EACC2130E84 for <v6ops@ietfa.amsl.com>; Sun, 26 Aug 2018 21:26:59 -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=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 vgoNzE4KaYza for <v6ops@ietfa.amsl.com>; Sun, 26 Aug 2018 21:26:58 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 7E87B130E8C for <v6ops@ietf.org>; Sun, 26 Aug 2018 21:26:57 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id w14-v6so3556242plp.6 for <v6ops@ietf.org>; Sun, 26 Aug 2018 21:26:57 -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=j2KUBVbLJOXqc3jmiHIwUmnQRQXRQ532Ssk28fX4N8o=; b=fBOfZ++S2U77bj+bBNWRO5DLe+2jXY4k4OBQ452Maeg9iugMXNv3hbYT446ZIHdd0v YuVZ1OafpeRYzik/vTmcOI7cs2P4XCFoxL4xeUwjQzzvBPAnm2b0JojfnRjBKbvFBMiN LjwtCWTxP7vMwnaxWYe7LyUKsN0q4uq2TDQQngaWuXNDz1CTUvDU9Aw9nUTyBmgOvrRf IdgpDPUqWIdnLQy2yqgmH3EiYV1mPFZhwu1fhI0GVa5jpKZiB7NbJB8PAFvuuYfmmhG2 NKZtvpjfMFugv06Z/i/+CvtXu7quSkC8Rklp2y/x/wWyBaMe5qFHmF6LAbuV8kMc3EN1 pkpw== 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=j2KUBVbLJOXqc3jmiHIwUmnQRQXRQ532Ssk28fX4N8o=; b=NhDRyL2E8BwP/kQj3g6aA35IB/7kDt/3CTffwlflII2lhIeZFUGy3ElMalcN1MD9BX 2lqC6Hkc/OTppHf8PVYfbq8RyXYFa/slrth06C4g7idGifFzHiLSzoz1H6z6hl173mJV By9YqkAOUhZIRolGmey7+2Pzdza1RNOZxTkQWd9UGkUL8BNS7kTOvf+ic1nu4ZK7QPsV 7qEtXmB3Di5xU/OySIeXaciLln32iZanhwQsvPkgV8pGftqWhoMRzCN6mAKy+OTB0L/f Q9tKPIKKF9jZwqVSaNA9Ver1lFFzDqaYsu32Ng/5zQb7+rc+6lNJ3EXcA/E4bq+achKL aYMQ== X-Gm-Message-State: APzg51DzFuJ5HYMgucxtVUJRo6OYKqss/2OwksG34w6ZclHBe4WliRRz fgXMEara96ZHmz3JGzf0/hYF3YTt X-Google-Smtp-Source: ANB0VdYUYSKkPr0MbqG7nK1b9V+QjD3ouHTvsgiUnjtY5NGbgqqurr7URDBdc77qYdEMyclypi/Wpg== X-Received: by 2002:a17:902:48c8:: with SMTP id u8-v6mr11607205plh.152.1535344016844; Sun, 26 Aug 2018 21:26:56 -0700 (PDT) Received: from [192.168.178.30] ([118.148.68.33]) by smtp.gmail.com with ESMTPSA id w81-v6sm29044319pfk.92.2018.08.26.21.26.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Aug 2018 21:26:55 -0700 (PDT) To: Erik Kline <ek=40google.com@dmarc.ietf.org>, songlinjian@gmail.com Cc: "v6ops@ietf.org WG" <v6ops@ietf.org> References: <CAAObRXLe35KoONVsSO_oU+SRhMzMrKRE_SU-QNf2pGHYKpUrxA@mail.gmail.com> <2018082709132233449033@chinatelecom.cn> <CAKD1Yr3PFKC06vwALL9Pjyd8Ji-RnqPR-HMvLA6CS6cyDadzVw@mail.gmail.com> <CAAObRXJx-8cPYuU-5gSMCvoOX-m29Q5BZg1-GANXBV-2Zmjv0A@mail.gmail.com> <CAKD1Yr24fXHsRTwFErNGc+RYzXDfHFpF6zG5QFjfjS+xx5-9Mg@mail.gmail.com> <CAAObRXK3jx_FXi-Rt5W3iSkOrf8zmc2z0NC1hUoET=AMFj2sig@mail.gmail.com> <CAAedzxouJUY1-R2NQH8sMDA0vrkOSznOWUaykBtdMy5a5Cup4g@mail.gmail.com> From: Brian E Carpenter <brian.e.carpenter@gmail.com> Message-ID: <34329770-1e00-be97-8443-79448be367cb@gmail.com> Date: Mon, 27 Aug 2018 16:26:51 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <CAAedzxouJUY1-R2NQH8sMDA0vrkOSznOWUaykBtdMy5a5Cup4g@mail.gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/-5DaSE41dmqLVkOWEbUoUtRCS3A> Subject: Re: [v6ops] How my Android phone got assigned with IPv6 address via 4G LTE? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 27 Aug 2018 04:27:08 -0000 On 2018-08-27 16:00, Erik Kline wrote: > On Mon, 27 Aug 2018 at 12:47, Davey Song <songlinjian@gmail.com> wrote: >> >> >> >> Another question about the lifetime of the address. >> >> How long will the address persist? I mean the lifetime of a IPv6 address assigned. I test with my phone that every time I turn on the "Mobile data", or switch from WIF, the IPv6 address changed. I'm not sure How long it will persist. I check windows 10 on my laptop (netsh interface ipv6 show privacy), the Maximum Preferred Lifetime is one day. >> >> I ask the question because some application developer may build their app based on the persistence of the IPv6 address. Mycurrent suggestion to them is "DO NOT RELY on IPv6 PERSISTENCE" becuase it changes more frequently than IPv4. Is it right ? > > There are no guarantees at the IP layer of address persistence beyond > the lifetimes in the PIO/RA. > > In general, any number of circumstances can cause the device to > disconnect from the network at any time. When it next reconnects it > may be provisioned with an entirely different prefix, for example. Of > course, there might be some contractual arrangement that a given > device is routed a known prefix, but that has no IP-layer > representation. Not only that. Depending on the roaming situation, the device might be switched between IPv6 and IPv4 without warning. Or (like mine) it might have IPv6 connectivity sometimes on WiFi, even if the cell operator only supports IPv4. So apps also need complete dual stack agility at any time. No address is persistent. Brian From nobody Sun Aug 26 22:05:18 2018 Return-Path: <ggm@algebras.org> 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 255D9130E87 for <v6ops@ietfa.amsl.com>; Sun, 26 Aug 2018 22:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=algebras-org.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 y-5-_1J8l6jP for <v6ops@ietfa.amsl.com>; Sun, 26 Aug 2018 22:05:05 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 39382130E97 for <v6ops@ietf.org>; Sun, 26 Aug 2018 22:05:05 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id b19-v6so6797879wme.3 for <v6ops@ietf.org>; Sun, 26 Aug 2018 22:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SdhdqVpqorcrXIxKOuEHqAA9jJWdRbjPClJrvWHQKBU=; b=V+IBP8mi2PtqHIys8Xqwgajt6NAULaCU0FoGEXGEzzbpNJHQiqohEn7Qfmjx7AZeiI A9l+n1yKeYngCcA2YjazhBC9n+lFIksOyU5GGVX4vb2mAT4QFs8cWNjAivjsRzOUlZTb S6YPY5xbUd5x9lQTyfePJLTxMiRaOM8Dtd+e2aPJrfDEFzDAmgeSwS4SFJ3ogqowci54 JddpwXqrYUW4Bb3IAx97bq1C9OmfdnP1kQXN5DfOldhGYBiCqbQD8/blr+EtMuP3FS4p OgLMyRCKysTfp8izpX4XlCRGoISiS3GXfLkoZz0O4xwNGIqbGUZcW32eQpExxZa89KS9 pX4A== 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:content-transfer-encoding; bh=SdhdqVpqorcrXIxKOuEHqAA9jJWdRbjPClJrvWHQKBU=; b=ov7hjj0nxjJfcTTghs9AG94IM+oen3teQFXCanNz/6/ndENe7Y4EyzKiP10RWKLDTw 6N/wpMwS5/vl75qZ/8t8IEGp4QA0yZj3QZkWpIyo3vV/mX6OeK2/dpPOLsHSsoxzuaP/ pgSeJvnKVn5uI3/OWaEA3T2SW4abcQkU691uBz7UGsSgmA+tXcPo97oeMUzlmJ1Nm5/J I211qh9ixm4pziSIU4dI9k7IG356rYMHMORBJTtoB6D3turSvvl8q11FnoKW6cJGuluA wthxL6Zu3T40sAZc1Jlj89mi/jn4GSt6nhzzS7bIO7miS6MSgrj8x9CaojYUiUL9knnj wpiQ== X-Gm-Message-State: APzg51CudwXJDj6Fzzaid0QA9dHVf42u5I9/glxbvdN1sa/dqHPWVgzJ CWklnFDHxBUA0e4rR2EC44E0/68QoG+p56LcmefxCA== X-Google-Smtp-Source: ANB0VdYp3Ljd1LWpdqIe8SVV57yqwWjAuUOeqmV4FwyGc6ntBWKGv58q5p/9dLQmZPEAwcrnhweeUBdN0rIJf+kdiU0= X-Received: by 2002:a1c:ca17:: with SMTP id a23-v6mr4254022wmg.122.1535346303524; Sun, 26 Aug 2018 22:05:03 -0700 (PDT) MIME-Version: 1.0 References: <CAAObRXLe35KoONVsSO_oU+SRhMzMrKRE_SU-QNf2pGHYKpUrxA@mail.gmail.com> <2018082709132233449033@chinatelecom.cn> <CAKD1Yr3PFKC06vwALL9Pjyd8Ji-RnqPR-HMvLA6CS6cyDadzVw@mail.gmail.com> <CAAObRXJx-8cPYuU-5gSMCvoOX-m29Q5BZg1-GANXBV-2Zmjv0A@mail.gmail.com> <CAKD1Yr24fXHsRTwFErNGc+RYzXDfHFpF6zG5QFjfjS+xx5-9Mg@mail.gmail.com> <CAAObRXK3jx_FXi-Rt5W3iSkOrf8zmc2z0NC1hUoET=AMFj2sig@mail.gmail.com> <CAAedzxouJUY1-R2NQH8sMDA0vrkOSznOWUaykBtdMy5a5Cup4g@mail.gmail.com> <34329770-1e00-be97-8443-79448be367cb@gmail.com> In-Reply-To: <34329770-1e00-be97-8443-79448be367cb@gmail.com> From: George Michaelson <ggm@algebras.org> Date: Mon, 27 Aug 2018 15:04:51 +1000 Message-ID: <CAKr6gn0bpRnF5FSRW+Goxh7E7a53TtKcTWBEViQ1EBy2nd_GSw@mail.gmail.com> To: Brian E Carpenter <brian.e.carpenter@gmail.com> Cc: ek=40google.com@dmarc.ietf.org, songlinjian@gmail.com, "<v6ops@ietf.org>" <v6ops@ietf.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/EdNcfYlysj1BPsvd-_XjSAB8_-o> Subject: Re: [v6ops] How my Android phone got assigned with IPv6 address via 4G LTE? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 27 Aug 2018 05:05:17 -0000 I surprised people still treat an IP address in either 4 or 6 as an endpoint identifier. Its not an identifier. Its not a session identifier either. QUIC doesn't use IP addresses as session IDs, it does address agility. Multipath TCP likewise I would think by now, we understand, that if you want state, the IP address isn't the primary key to the state, something else has to be. a give five-tuple is keyed on IP and port because at the protocol level it has to be: I thats not something which should be taken out of context and used "above" the {TCP, UDP}/IP level to determine things. On Mon, Aug 27, 2018 at 2:27 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote: > > On 2018-08-27 16:00, Erik Kline wrote: > > On Mon, 27 Aug 2018 at 12:47, Davey Song <songlinjian@gmail.com> wrote: > >> > >> > >> > >> Another question about the lifetime of the address. > >> > >> How long will the address persist? I mean the lifetime of a IPv6 addre= ss assigned. I test with my phone that every time I turn on the "Mobile d= ata", or switch from WIF, the IPv6 address changed. I'm not sure How long i= t will persist. I check windows 10 on my laptop (netsh interface ipv6 show = privacy), the Maximum Preferred Lifetime is one day. > >> > >> I ask the question because some application developer may build their = app based on the persistence of the IPv6 address. Mycurrent suggestion to t= hem is "DO NOT RELY on IPv6 PERSISTENCE" becuase it changes more frequently= than IPv4. Is it right ? > > > > There are no guarantees at the IP layer of address persistence beyond > > the lifetimes in the PIO/RA. > > > > In general, any number of circumstances can cause the device to > > disconnect from the network at any time. When it next reconnects it > > may be provisioned with an entirely different prefix, for example. Of > > course, there might be some contractual arrangement that a given > > device is routed a known prefix, but that has no IP-layer > > representation. > > Not only that. Depending on the roaming situation, the device might > be switched between IPv6 and IPv4 without warning. Or (like mine) > it might have IPv6 connectivity sometimes on WiFi, even if the cell > operator only supports IPv4. > > So apps also need complete dual stack agility at any time. No address > is persistent. > > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sun Aug 26 22:39:30 2018 Return-Path: <xiechf.bri@chinatelecom.cn> 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 D8175130E6A for <v6ops@ietfa.amsl.com>; Sun, 26 Aug 2018 22:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Z9BXlAJMos-P for <v6ops@ietfa.amsl.com>; Sun, 26 Aug 2018 22:39:27 -0700 (PDT) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.221]) by ietfa.amsl.com (Postfix) with ESMTP id DF3F1130DD2 for <v6ops@ietf.org>; Sun, 26 Aug 2018 22:39:26 -0700 (PDT) HMM_SOURCE_IP: 172.18.0.80:51713.1161638150 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-219.142.69.76 (unknown [172.18.0.80]) by chinatelecom.cn (HERMES) with SMTP id B990728008C; Mon, 27 Aug 2018 13:39:12 +0800 (CST) Received: from DANGMM9A10 ([219.142.69.76]) by App0022 with ESMTP id 53cc0e56-cf55-4078-b798-634a2f194047 for brian.e.carpenter@gmail.com; Mon Aug 27 13:39:18 2018 X-filter-score: filter<0> X-Real-From: xiechf.bri@chinatelecom.cn X-Receive-IP: 219.142.69.76 X-MEDUSA-Status: 0 Date: Mon, 27 Aug 2018 13:39:14 +0800 From: "xiechf.bri@chinatelecom.cn" <xiechf.bri@chinatelecom.cn> To: "Brian E Carpenter" <brian.e.carpenter@gmail.com>, "Erik Kline" <ek=40google.com@dmarc.ietf.org>, "Davey Song" <songlinjian@gmail.com> Cc: v6ops <v6ops@ietf.org> References: <CAAObRXLe35KoONVsSO_oU+SRhMzMrKRE_SU-QNf2pGHYKpUrxA@mail.gmail.com>, <2018082709132233449033@chinatelecom.cn>, <CAKD1Yr3PFKC06vwALL9Pjyd8Ji-RnqPR-HMvLA6CS6cyDadzVw@mail.gmail.com>, <CAAObRXJx-8cPYuU-5gSMCvoOX-m29Q5BZg1-GANXBV-2Zmjv0A@mail.gmail.com>, <CAKD1Yr24fXHsRTwFErNGc+RYzXDfHFpF6zG5QFjfjS+xx5-9Mg@mail.gmail.com>, <CAAObRXK3jx_FXi-Rt5W3iSkOrf8zmc2z0NC1hUoET=AMFj2sig@mail.gmail.com>, <CAAedzxouJUY1-R2NQH8sMDA0vrkOSznOWUaykBtdMy5a5Cup4g@mail.gmail.com>, <34329770-1e00-be97-8443-79448be367cb@gmail.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 8, 379[cn] Mime-Version: 1.0 Message-ID: <201808271339136864338@chinatelecom.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart636546157448_=----" Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/cPu_jtrOShDB0QnVuaEwlnu80kM> Subject: Re: [v6ops] How my Android phone got assigned with IPv6 address via 4G LTE? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 27 Aug 2018 05:39:30 -0000 This is a multi-part message in MIME format. ------=_001_NextPart636546157448_=---- Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 DQpJZiBhcHBsaWNhdGlvbnMgaGF2ZSB0aGUgcmVxdWlyZW1lbnQgb2YgZml4ZWQgSVB2NiBhZGRy ZXNzIGZvciB1c2VycyBpbiBtb2JpbGUgbmV0d29yaywgdGhlIElQdjYgYWRkcmVzcyBmb3IgZWFj aCB1c2VyIGNhbiBiZSBwcmUtY29uZmlndXJlZCBpbiBIU1MgZGF0YWJhc2UsIHdoaWNoIGhhcyBi ZWVuIHN1cHBvcnRlZCBpbiBjdXJyZW50IDRHIExURSBhcmNoaXRlY3R1cmUuICBJbiBhZGRpdGlv biwgdGhlIEJTUyBzeXN0ZW0gc2hvdWxkIGFsc28gYmUgdXBncmFkZWQgdG8gc3VwcG9ydCB0aGUg Y2FwYWJpbGl0eSBvZiBmaXhlZCBJUHY2IGFkZHJlc3MgZm9yIFVFLg0KDQpDaG9uZ2ZlbmcgDQoN Cg0KDQp4aWVjaGYuYnJpQGNoaW5hdGVsZWNvbS5jbg0KIA0KRnJvbTogQnJpYW4gRSBDYXJwZW50 ZXINCkRhdGU6IDIwMTgtMDgtMjcgMTI6MjYNClRvOiBFcmlrIEtsaW5lOyBzb25nbGluamlhbg0K Q0M6IHY2b3BzQGlldGYub3JnIFdHDQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBIb3cgbXkgQW5kcm9p ZCBwaG9uZSBnb3QgYXNzaWduZWQgd2l0aCBJUHY2IGFkZHJlc3MgdmlhIDRHIExURT8NCk9uIDIw MTgtMDgtMjcgMTY6MDAsIEVyaWsgS2xpbmUgd3JvdGU6DQo+IE9uIE1vbiwgMjcgQXVnIDIwMTgg YXQgMTI6NDcsIERhdmV5IFNvbmcgPHNvbmdsaW5qaWFuQGdtYWlsLmNvbT4gd3JvdGU6DQo+Pg0K Pj4NCj4+DQo+PiBBbm90aGVyIHF1ZXN0aW9uIGFib3V0IHRoZSBsaWZldGltZSBvZiB0aGUgYWRk cmVzcy4NCj4+DQo+PiBIb3cgbG9uZyB3aWxsIHRoZSBhZGRyZXNzIHBlcnNpc3Q/IEkgbWVhbiB0 aGUgbGlmZXRpbWUgb2YgYSBJUHY2IGFkZHJlc3MgYXNzaWduZWQuICBJIHRlc3Qgd2l0aCBteSBw aG9uZSB0aGF0IGV2ZXJ5IHRpbWUgSSB0dXJuIG9uIHRoZSAgIk1vYmlsZSBkYXRhIiwgb3Igc3dp dGNoIGZyb20gV0lGLCB0aGUgSVB2NiBhZGRyZXNzIGNoYW5nZWQuIEknbSBub3Qgc3VyZSBIb3cg bG9uZyBpdCB3aWxsIHBlcnNpc3QuIEkgY2hlY2sgd2luZG93cyAxMCBvbiBteSBsYXB0b3AgKG5l dHNoIGludGVyZmFjZSBpcHY2IHNob3cgcHJpdmFjeSksIHRoZSBNYXhpbXVtIFByZWZlcnJlZCBM aWZldGltZSBpcyBvbmUgZGF5Lg0KPj4NCj4+IEkgYXNrIHRoZSBxdWVzdGlvbiBiZWNhdXNlIHNv bWUgYXBwbGljYXRpb24gZGV2ZWxvcGVyIG1heSBidWlsZCB0aGVpciBhcHAgYmFzZWQgb24gdGhl IHBlcnNpc3RlbmNlIG9mIHRoZSBJUHY2IGFkZHJlc3MuIE15Y3VycmVudCBzdWdnZXN0aW9uIHRv IHRoZW0gaXMgIkRPIE5PVCBSRUxZIG9uIElQdjYgUEVSU0lTVEVOQ0UiIGJlY3Vhc2UgaXQgY2hh bmdlcyBtb3JlIGZyZXF1ZW50bHkgdGhhbiBJUHY0LiAgSXMgaXQgcmlnaHQgPw0KPiANCj4gVGhl cmUgYXJlIG5vIGd1YXJhbnRlZXMgYXQgdGhlIElQIGxheWVyIG9mIGFkZHJlc3MgcGVyc2lzdGVu Y2UgYmV5b25kDQo+IHRoZSBsaWZldGltZXMgaW4gdGhlIFBJTy9SQS4NCj4gDQo+IEluIGdlbmVy YWwsIGFueSBudW1iZXIgb2YgY2lyY3Vtc3RhbmNlcyBjYW4gY2F1c2UgdGhlIGRldmljZSB0bw0K PiBkaXNjb25uZWN0IGZyb20gdGhlIG5ldHdvcmsgYXQgYW55IHRpbWUuICBXaGVuIGl0IG5leHQg cmVjb25uZWN0cyBpdA0KPiBtYXkgYmUgcHJvdmlzaW9uZWQgd2l0aCBhbiBlbnRpcmVseSBkaWZm ZXJlbnQgcHJlZml4LCBmb3IgZXhhbXBsZS4gIE9mDQo+IGNvdXJzZSwgdGhlcmUgbWlnaHQgYmUg c29tZSBjb250cmFjdHVhbCBhcnJhbmdlbWVudCB0aGF0IGEgZ2l2ZW4NCj4gZGV2aWNlIGlzIHJv dXRlZCBhIGtub3duIHByZWZpeCwgYnV0IHRoYXQgaGFzIG5vIElQLWxheWVyDQo+IHJlcHJlc2Vu dGF0aW9uLg0KIA0KTm90IG9ubHkgdGhhdC4gRGVwZW5kaW5nIG9uIHRoZSByb2FtaW5nIHNpdHVh dGlvbiwgdGhlIGRldmljZSBtaWdodA0KYmUgc3dpdGNoZWQgYmV0d2VlbiBJUHY2IGFuZCBJUHY0 IHdpdGhvdXQgd2FybmluZy4gT3IgKGxpa2UgbWluZSkNCml0IG1pZ2h0IGhhdmUgSVB2NiBjb25u ZWN0aXZpdHkgc29tZXRpbWVzIG9uIFdpRmksIGV2ZW4gaWYgdGhlIGNlbGwNCm9wZXJhdG9yIG9u bHkgc3VwcG9ydHMgSVB2NC4NCiANClNvIGFwcHMgYWxzbyBuZWVkIGNvbXBsZXRlIGR1YWwgc3Rh Y2sgYWdpbGl0eSBhdCBhbnkgdGltZS4gTm8gYWRkcmVzcw0KaXMgcGVyc2lzdGVudC4NCiANCiAg ICBCcmlhbg0KIA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnY2b3BzIG1haWxpbmcgbGlzdA0KdjZvcHNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCiANCg== ------=_001_NextPart636546157448_=---- Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charse= t=3DISO-8859-1"><style>body { line-height: 1.5; }blockquote { margin-top: = 0px; margin-bottom: 0px; margin-left: 0.5em; }body { font-size: 10.5pt; fo= nt-family: 'Microsoft YaHei UI'; color: rgb(0, 0, 0); line-height: 1.5; }<= /style></head><body>=0A<div><span></span><br></div><div>If applications ha= ve the requirement of fixed IPv6 address for users in mobile network, the = IPv6 address for each user can be pre-configured in HSS database, which ha= s been supported in current 4G LTE architecture.  In addition, the BS= S system should also be upgraded <span style=3D"font-size: 10.5pt; line-he= ight: 1.5; background-color: window;">to support the capability of fixed I= Pv6 address for UE.</span></div><div><br></div><div>Chongfeng </div>= =0A<div><br></div><hr style=3D"width: 210px; height: 1px;" color=3D"#b5c4d= f" size=3D"1" align=3D"left">=0A<div><span><div style=3D"MARGIN: 10px; FON= T-FAMILY: verdana; FONT-SIZE: 10pt"><div>xiechf.bri@chinatelecom.cn</div><= /div></span></div>=0A<blockquote style=3D"margin-top: 0px; margin-bottom: = 0px; margin-left: 0.5em;"><div> </div><div style=3D"border:none;borde= r-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm"><div style=3D"PADDING= -RIGHT: 8px; PADDING-LEFT: 8px; FONT-SIZE: 12px;FONT-FAMILY:tahoma;COLOR:#= 000000; BACKGROUND: #efefef; PADDING-BOTTOM: 8px; PADDING-TOP: 8px"><div><= b>From:</b> <a href=3D"mailto:brian.e.carpenter@gmail.com">Brian E Ca= rpenter</a></div><div><b>Date:</b> 2018-08-27 12:26</div><div><b= >To:</b> <a href=3D"mailto:ek=3D40google.com@dmarc.ietf.org">Erik Kli= ne</a>; <a href=3D"mailto:songlinjian@gmail.com">songlinjian</a></div><div= ><b>CC:</b> <a href=3D"mailto:v6ops@ietf.org">v6ops@ietf.org WG</a></= div><div><b>Subject:</b> Re: [v6ops] How my Android phone got assigne= d with IPv6 address via 4G LTE?</div></div></div><div><div>On 2018-08-27 1= 6:00, Erik Kline wrote:</div>=0A<div>> On Mon, 27 Aug 2018 at 12:47, Da= vey Song <songlinjian@gmail.com> wrote:</div>=0A<div>>></div>= =0A<div>>></div>=0A<div>>></div>=0A<div>>> Another quest= ion about the lifetime of the address.</div>=0A<div>>></div>=0A<div>= >> How long will the address persist? I mean the lifetime of a IPv6 = address assigned.  I test with my phone that every time I turn on the=   "Mobile data", or switch from WIF, the IPv6 address changed. I'm no= t sure How long it will persist. I check windows 10 on my laptop (netsh in= terface ipv6 show privacy), the Maximum Preferred Lifetime is one day.</di= v>=0A<div>>></div>=0A<div>>> I ask the question because some a= pplication developer may build their app based on the persistence of the I= Pv6 address. Mycurrent suggestion to them is "DO NOT RELY on IPv6 PERSISTE= NCE" becuase it changes more frequently than IPv4.  Is it right ?</di= v>=0A<div>> </div>=0A<div>> There are no guarantees at the IP layer = of address persistence beyond</div>=0A<div>> the lifetimes in the PIO/R= A.</div>=0A<div>> </div>=0A<div>> In general, any number of circumst= ances can cause the device to</div>=0A<div>> disconnect from the networ= k at any time.  When it next reconnects it</div>=0A<div>> may be p= rovisioned with an entirely different prefix, for example.  Of</div>= =0A<div>> course, there might be some contractual arrangement that a gi= ven</div>=0A<div>> device is routed a known prefix, but that has no IP-= layer</div>=0A<div>> representation.</div>=0A<div> </div>=0A<div>N= ot only that. Depending on the roaming situation, the device might</div>= =0A<div>be switched between IPv6 and IPv4 without warning. Or (like mine)<= /div>=0A<div>it might have IPv6 connectivity sometimes on WiFi, even if th= e cell</div>=0A<div>operator only supports IPv4.</div>=0A<div> </div>= =0A<div>So apps also need complete dual stack agility at any time. No addr= ess</div>=0A<div>is persistent.</div>=0A<div> </div>=0A<div> &nb= sp;  Brian</div>=0A<div> </div>=0A<div>_________________________= ______________________</div>=0A<div>v6ops mailing list</div>=0A<div>v6ops@= ietf.org</div>=0A<div>https://www.ietf.org/mailman/listinfo/v6ops</div>=0A= <div> </div>=0A</div></blockquote>=0A</body></html> ------=_001_NextPart636546157448_=------ From nobody Sun Aug 26 23:07:13 2018 Return-Path: <songlinjian@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B61130E73 for <v6ops@ietfa.amsl.com>; Sun, 26 Aug 2018 23:07:12 -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, HTML_MESSAGE=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 47NjYSqGcmbL for <v6ops@ietfa.amsl.com>; Sun, 26 Aug 2018 23:07:10 -0700 (PDT) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 7B1BE130E72 for <v6ops@ietf.org>; Sun, 26 Aug 2018 23:07:10 -0700 (PDT) Received: by mail-ua1-x92e.google.com with SMTP id c12-v6so8827972uan.3 for <v6ops@ietf.org>; Sun, 26 Aug 2018 23:07:10 -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=Ubiv/BOrnskhzHZU23fVJ114VOeTl4IR7mop8MSbCB4=; b=kNVZzS0g/QfHNhl9b7iX+kQOWk0W3UY8xAm3VVOUexJ31QFlvu5hFLwE54EV2Cv8LB oBlKefEOq81TEFbYtLw0qsl/CKtniKQdeqTbLA7kjMTdFnTOKLovtASHv8zcqQNlpUrH Ldm+APA7ERCzNmj20ojIXhak4uDt5B0WIRxa0lQ+R5rcu1TaV1Uv/GDwqeANUTB8PkXx nF5/kAXfxIJNUwdFSrAso6ZFoRgaE5qSdWLmPG9TqqcYFyKpV5kSFtp2ZRU5stwVpauh C5JmBHd/1NpE/ZecWGFOdHLbstYpFTrkDNj0N1ttBC3wf7xAFLsbag9f0MhR9vxeEKSs 6F+A== 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=Ubiv/BOrnskhzHZU23fVJ114VOeTl4IR7mop8MSbCB4=; b=Xt20hccrCdCWnwazg1B3uad5vvazy+2RAdkWonoN8Mav2tvBIYU9GIG6fG8vQo2Rui depcP9SRF8vW5l43/H/BFqC3UIh74AHmFUfPSzvgWxuX6Si39dMlVbGVEmgRrqsMe+Cx Lh9s1SPNBfFDEGDVEk40YJ4YT9YQcW/wCppafc2ValGXV9fXFQ9JFFw4m0TnaYjjhgI5 o3CF/WQcZreu33yU1cdht9DMhu/E+BS2IUgGShtqEJEef/IGbWFUBYpDT8H6kah6Pgnh wbml6i7vXMLs0uoKaKwvRDH3QPiGq1efzhzMPke2RZSygfYvYruYZj68HCDMKN4YePpD t4oQ== X-Gm-Message-State: APzg51DsQ0j3B+5D3d3DyxM+J9N1gv7KSBuJ4FKSCyK6ytLjideqBcED Ihq9b6RonptwoErkkv9iMk8dbPVBprVM145a+0U= X-Google-Smtp-Source: ANB0VdZxH0e5AzPlZXCh3zOUyHfh4lFcOgt/zundulbovp2IoQfIieoRB+rLOZTf1hMuH8+B2jzwkjQ0XozXRwbNQHo= X-Received: by 2002:ab0:6a6:: with SMTP id g35-v6mr7564132uag.16.1535350029506; Sun, 26 Aug 2018 23:07:09 -0700 (PDT) MIME-Version: 1.0 References: <CAAObRXLe35KoONVsSO_oU+SRhMzMrKRE_SU-QNf2pGHYKpUrxA@mail.gmail.com> <2018082709132233449033@chinatelecom.cn> <CAKD1Yr3PFKC06vwALL9Pjyd8Ji-RnqPR-HMvLA6CS6cyDadzVw@mail.gmail.com> <CAAObRXJx-8cPYuU-5gSMCvoOX-m29Q5BZg1-GANXBV-2Zmjv0A@mail.gmail.com> <CAKD1Yr24fXHsRTwFErNGc+RYzXDfHFpF6zG5QFjfjS+xx5-9Mg@mail.gmail.com> <CAAObRXK3jx_FXi-Rt5W3iSkOrf8zmc2z0NC1hUoET=AMFj2sig@mail.gmail.com> <CAAedzxouJUY1-R2NQH8sMDA0vrkOSznOWUaykBtdMy5a5Cup4g@mail.gmail.com> <34329770-1e00-be97-8443-79448be367cb@gmail.com> <CAKr6gn0bpRnF5FSRW+Goxh7E7a53TtKcTWBEViQ1EBy2nd_GSw@mail.gmail.com> In-Reply-To: <CAKr6gn0bpRnF5FSRW+Goxh7E7a53TtKcTWBEViQ1EBy2nd_GSw@mail.gmail.com> From: Davey Song <songlinjian@gmail.com> Date: Mon, 27 Aug 2018 14:07:01 +0800 Message-ID: <CAAObRXKiT3ugL_t4j3WzThx8nNrXYZs=F55CZjNpAMRJFUwG0w@mail.gmail.com> To: ggm@algebras.org Cc: brian.e.carpenter@gmail.com, ek=40google.com@dmarc.ietf.org, v6ops@ietf.org Content-Type: multipart/alternative; boundary="0000000000001d5ec505746489a7" Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/DDP2usGcxDQUzUdlSNcNpnV2rP8> Subject: Re: [v6ops] How my Android phone got assigned with IPv6 address via 4G LTE? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 27 Aug 2018 06:07:12 -0000 --0000000000001d5ec505746489a7 Content-Type: text/plain; charset="UTF-8" On Mon, 27 Aug 2018 at 13:05, George Michaelson <ggm@algebras.org> wrote: > I surprised people still treat an IP address in either 4 or 6 as an > endpoint identifier. > It is ture for many application develop who still live in IPv4 world, in which IP address is viewed persistent and treated as an important user profile such as geo-location info. That's why it is hard for them to migrate their app back-end services to IPv6. Davey --0000000000001d5ec505746489a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, 27= Aug 2018 at 13:05, George Michaelson <<a href=3D"mailto:ggm@algebras.or= g">ggm@algebras.org</a>> wrote:<br></div><blockquote class=3D"gmail_quot= e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">= I surprised people still treat an IP address in either 4 or 6 as an<br> endpoint identifier.<br></blockquote><div><br></div><div>It is ture for man= y application develop who still live in IPv4 world, in which IP address is = viewed persistent and treated as an important user profile such as geo-loca= tion info. That's why it is hard for them to migrate their app back-end= services to IPv6.</div><div><br></div><div>Davey</div></div></div> --0000000000001d5ec505746489a7-- From nobody Sun Aug 26 23:18:53 2018 Return-Path: <marka@isc.org> 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 4503E130E72 for <v6ops@ietfa.amsl.com>; Sun, 26 Aug 2018 23:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 NoN49XOJa6CP for <v6ops@ietfa.amsl.com>; Sun, 26 Aug 2018 23:18:46 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 5FA5D130E6F for <v6ops@ietf.org>; Sun, 26 Aug 2018 23:18:46 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 273163AB03F; Mon, 27 Aug 2018 06:18:44 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id E26E8160067; Mon, 27 Aug 2018 06:18:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id CFF40160044; Mon, 27 Aug 2018 06:18:43 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id H_ZKNJvhDppp; Mon, 27 Aug 2018 06:18:43 +0000 (UTC) Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id D8CE516003D; Mon, 27 Aug 2018 06:18:42 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mark Andrews <marka@isc.org> In-Reply-To: <CAAObRXKiT3ugL_t4j3WzThx8nNrXYZs=F55CZjNpAMRJFUwG0w@mail.gmail.com> Date: Mon, 27 Aug 2018 16:18:40 +1000 Cc: ggm@algebras.org, v6ops@ietf.org, ek=40google.com@dmarc.ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <62BF9292-B37E-46C2-A885-221319D95C16@isc.org> References: <CAAObRXLe35KoONVsSO_oU+SRhMzMrKRE_SU-QNf2pGHYKpUrxA@mail.gmail.com> <2018082709132233449033@chinatelecom.cn> <CAKD1Yr3PFKC06vwALL9Pjyd8Ji-RnqPR-HMvLA6CS6cyDadzVw@mail.gmail.com> <CAAObRXJx-8cPYuU-5gSMCvoOX-m29Q5BZg1-GANXBV-2Zmjv0A@mail.gmail.com> <CAKD1Yr24fXHsRTwFErNGc+RYzXDfHFpF6zG5QFjfjS+xx5-9Mg@mail.gmail.com> <CAAObRXK3jx_FXi-Rt5W3iSkOrf8zmc2z0NC1hUoET=AMFj2sig@mail.gmail.com> <CAAedzxouJUY1-R2NQH8sMDA0vrkOSznOWUaykBtdMy5a5Cup4g@mail.gmail.com> <34329770-1e00-be97-8443-79448be367cb@gmail.com> <CAKr6gn0bpRnF5FSRW+Goxh7E7a53TtKcTWBEViQ1EBy2nd_GSw@mail.gmail.com> <CAAObRXKiT3ugL_t4j3WzThx8nNrXYZs=F55CZjNpAMRJFUwG0w@mail.gmail.com> To: Davey Song <songlinjian@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/4q6vtOy_JEL3q_oEE36sfVyI0wM> Subject: Re: [v6ops] How my Android phone got assigned with IPv6 address via 4G LTE? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 27 Aug 2018 06:18:52 -0000 > On 27 Aug 2018, at 4:07 pm, Davey Song <songlinjian@gmail.com> wrote: >=20 >=20 > On Mon, 27 Aug 2018 at 13:05, George Michaelson <ggm@algebras.org> = wrote: > I surprised people still treat an IP address in either 4 or 6 as an > endpoint identifier. >=20 > It is ture for many application develop who still live in IPv4 world, = in which IP address is viewed persistent and treated as an important = user profile such as geo-location info. That's why it is hard for them = to migrate their app back-end services to IPv6. There is zero difference between IPv4 and IPv6 here. IPv4 addresses are = no more stable than IPv6 addresses. Geo location from IP is essentially = the same. The IPv6 geoip databases may not be as complete but the data is just or more stable as there isn=E2=80=99t a IPv6 address resale market. Thats a excuse they give which doesn=E2=80=99t bear up to scrutiny. Mark > Davey > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Aug 27 01:19:24 2018 Return-Path: <lists@quux.de> 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 C6D76130E7B for <v6ops@ietfa.amsl.com>; Mon, 27 Aug 2018 01:19:23 -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] 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 YpVoQZCk2Im3 for <v6ops@ietfa.amsl.com>; Mon, 27 Aug 2018 01:19:21 -0700 (PDT) Received: from mail.quux.de (mail.quux.de [IPv6:2001:678:340::71]) (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 7B55F128C65 for <v6ops@ietf.org>; Mon, 27 Aug 2018 01:19:21 -0700 (PDT) Received: by mail.quux.de (Postfix, from userid 110) id F138526828; Mon, 27 Aug 2018 10:10:25 +0200 (CEST) Received: from pc8.quux.de (ip5b404e26.dynamic.kabel-deutschland.de [91.64.78.38]) by mail.quux.de (Postfix) with ESMTPA id 93C3A25C63 for <v6ops@ietf.org>; Mon, 27 Aug 2018 10:10:23 +0200 (CEST) Received: from pc8.berlin.quux.de (localhost [127.0.0.1]) by pc8.quux.de (Postfix) with ESMTPS id 25E6744817D for <v6ops@ietf.org>; Mon, 27 Aug 2018 10:19:17 +0200 (CEST) From: Jens Link <lists@quux.de> To: v6ops@ietf.org Organization: - References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> X-URL: http://www.quux.de X-message-flag: HTML Mails will not be read! Send plain text! X-Clacks-Overhead: GNU Terry Pratchett Date: Mon, 27 Aug 2018 10:19:16 +0200 In-Reply-To: <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> (Lee Howard's message of "Fri, 17 Aug 2018 14:23:02 -0400") Message-ID: <87woscfchn.fsf@pc8.berlin.quux.de> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/qpcjPb8FqCJuw7RrzUE7hL2uXQw> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 27 Aug 2018 08:19:24 -0000 Lee Howard <lee@asgard.org> writes: > * Software repos that are IPv4-only I did a prensentation at the last RIPE Meeting about that[1]. I tried to build Linux from Scratch on an IPv6 only host and then asked the people not having IPv6 why. After that I checked the homepage variable in the rpm spec files of a current CentOS mirror. About 3/4 (out of ~1.000 hosts) was not reachable via IPv6. BTW: I've given up asking, using https://ipv6excuses.com/ takes way less time and has the same results. Jens [1] https://ripe76.ripe.net/wp-content/uploads/presentations/146-we_dont_need_ipv6.pdf -- ---------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@quux.de | --------------- | ---------------------------------------------------------------------------- From jenslink@quux.de Mon Aug 27 01:11:26 2018 Return-Path: <jenslink@quux.de> 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 CB051130E7B for <v6ops@ietfa.amsl.com>; Mon, 27 Aug 2018 01:11:26 -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] 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 7f1xyp9Q_hUw for <v6ops@ietfa.amsl.com>; Mon, 27 Aug 2018 01:11:24 -0700 (PDT) Received: from mail.quux.de (mail.quux.de [109.235.43.71]) (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 BD482128C65 for <v6ops@ietf.org>; Mon, 27 Aug 2018 01:11:24 -0700 (PDT) Received: by mail.quux.de (Postfix, from userid 110) id BBA1D25C63; Mon, 27 Aug 2018 10:02:27 +0200 (CEST) Received: from pc8.quux.de (ip5b404e26.dynamic.kabel-deutschland.de [91.64.78.38]) by mail.quux.de (Postfix) with ESMTPA id 4C2F025C63 for <v6ops@ietf.org>; Mon, 27 Aug 2018 10:02:26 +0200 (CEST) Received: from pc8.berlin.quux.de (localhost [127.0.0.1]) by pc8.quux.de (Postfix) with ESMTPS id E26AE44817C for <v6ops@ietf.org>; Mon, 27 Aug 2018 10:10:49 +0200 (CEST) From: Jens Link <jenslink@quux.de> To: IPv6 Ops WG <v6ops@ietf.org> Organization: - References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> <CAD6AjGQ_OBFGJb_C+mP_87nu7q_oXPrTvxhaV_=RcubeHtMy2Q@mail.gmail.com> <E345387F-6C1D-49D4-8B03-52D04498DDA5@lists.zabbadoz.net> <a9eeba1b-76dc-a69f-aabe-04fa4ddc3a4f@gmail.com> <e560c82c-085e-60fe-2076-70e3624696c0@asgard.org> <CAPt1N1mAELodigHMdNGQEhr0bmHv0oruhAAHNZDjCA4BummBDw@mail.gmail.com> <20180821191627.GD11393@Space.Net> X-URL: http://www.quux.de X-message-flag: HTML Mails will not be read! Send plain text! X-Clacks-Overhead: GNU Terry Pratchett Date: Mon, 27 Aug 2018 10:10:49 +0200 In-Reply-To: <20180821191627.GD11393@Space.Net> (Gert Doering's message of "Tue, 21 Aug 2018 21:16:27 +0200") Message-ID: <871sakgrg6.fsf@pc8.berlin.quux.de> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/QTJE8cdpGY3ruVPJQxyHMvYWgvA> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 27 Aug 2018 08:20:35 -0000 Gert Doering <gert@space.net> writes: > Hi, > > On Tue, Aug 21, 2018 at 12:26:14PM -0400, Ted Lemon wrote: >> What's the state of SIP over IPv6 these days? > > At least one german access providers uses this, and it seems to work. In Germany I'm aware of sipgate running SIP over IPv6. After complaing in their blog that all the (cable) providers are evil and doing some NAT for IPv4. They got about 50 comments that they should run IPv6. Jens -- ---------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink@quux.de | --------------- | ---------------------------------------------------------------------------- From nobody Mon Aug 27 07:20:50 2018 Return-Path: <rbonica@juniper.net> 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 BCD95130DED for <v6ops@ietfa.amsl.com>; Mon, 27 Aug 2018 07:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] 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 WCDJD5M-7hGx for <v6ops@ietfa.amsl.com>; Mon, 27 Aug 2018 07:20:47 -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 5D08A130E71 for <v6ops@ietf.org>; Mon, 27 Aug 2018 07:20:47 -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 w7REIwiA007113 for <v6ops@ietf.org>; Mon, 27 Aug 2018 07:20:47 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=asqm7F5vGJEUJE5pqjCfu+/7JxfndVMYuevJOTS/hgk=; b=1OnJO1Rxd2fu/haf9pYMwC29RQcgpCvGkn49rdN6bd+O197DEAstOgARorJPzxFnv72K rUE/PHEeqLnV14LL5Xzo7MwtCw1d1hEarcbJHHndKmhs0sqGp7HREpEWhVMEJIMPIfMN mfWelLV5PfAb87XH54ZWIg7ScOB9Zmew5NdUVRiQFgSjEFVEFMobvRuJqYNW7Aro2mUV 0FYe8Ked2ZdXVkvBsFmzTJi1HwtW6xbzLznZRI9xdPwdcDCuMHOJoS9lnbBVi7HGZ7aX TSMlWezXliQRLV2EeVYj4b5ISL7tdePMvZER500fmTmnVvScpejOL1Rk12JbFJAmIt3z nQ== Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0017.outbound.protection.outlook.com [216.32.180.17]) by mx0a-00273201.pphosted.com with ESMTP id 2m4j8tr2yu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for <v6ops@ietf.org>; Mon, 27 Aug 2018 07:20:46 -0700 Received: from CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) by CO1PR05MB394.namprd05.prod.outlook.com (10.141.75.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.1101.10; Mon, 27 Aug 2018 14:20:44 +0000 Received: from CO1PR05MB443.namprd05.prod.outlook.com ([fe80::990e:3cb2:ad57:cd42]) by CO1PR05MB443.namprd05.prod.outlook.com ([fe80::990e:3cb2:ad57:cd42%18]) with mapi id 15.20.1101.007; Mon, 27 Aug 2018 14:20:44 +0000 From: Ron Bonica <rbonica@juniper.net> To: "v6ops@ietf.org" <v6ops@ietf.org> Thread-Topic: draft-palet-v6ops-rfc6177-bis Thread-Index: AdQ+ERSkgrY6L5QoTzWBeUJlAjTblQ== Date: Mon, 27 Aug 2018 14:20:44 +0000 Message-ID: <CO1PR05MB443BFFA74AAEB374E38BD8FAE0B0@CO1PR05MB443.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [66.129.241.10] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CO1PR05MB394; 6:xC1oKwAS7Rq4OAliTFmsZwoZtXJY5g66knIYkaR2KPLefeTnvE76+TexsC5j+pgjFRrQs2z4dVwE9/FKjs5gzwFE4CZExe/mINiiSnV6llZWkYCFchsrB3vEKz2iYpM2dW2JGD2UnBQYUKBW2z789qEHImxtuCuRT15wsepk7Y3LNU7vi2hAhoRp+TTrPUqOSX05mtVCRI3h66IU5BHeroFBAZmA5y/a2yhMPtVuyJ4+Mvu0jNooFgaCNvC++tqfpQRfloxuhRH/WdZ2Fo1Xggo/sGd0JlmZPAoBbRMgjKURuOu663Wsh1WFlE+hk9Fbm+BrtbAFXkdojLew4jvWNhU76AEsvr7wUsl7450+z8SMLQRKJqyRV5BxMcIvCfk8hAXH1OBGydR++ZmoPqYj6zxltfKg5/A0jF0m1cMGkuvNULXPz1sL04gsmqghYvlhRCeIoVPUJhsm5jwIQTIgvg==; 5:/vTTFDBNr9wIMfe8SR2R9dxYNtDDJCKcAvWhk4JBP89N6ST5Hqv1X/EmiBu8+HyrwLtcvddWCkCIkbJaJ6s5UZEkL8ln12JKAFsmNcqaf74TD9UThyW5CAuOEInlO7CSAtDtn06CoIbhUMhPgsh6UPI9qT5PJfE6vEImeHKis0E=; 7:UC76WMTAmNktpmLF1kQr2A8mKQSMd4YHEXBky5ewxH7x7DDFh95syezNLDx19ooYtXkoVk5MwW+93Z9Yo1fWTwcicfHFqEbpL9mqL/tcWswF6hLpj4FqYqgvP3wT/9vk9D8FuEGbKzl2u6jpf+ZnoLJtpQk1GKz4P6lbI3+2kOZRM9nGA4gUR7pzeEyTIb4VgQkb53uZeI9KflVzEF1cSKm3+drwviSZk0gg9PjQnQKIqfjknQA+lvfg8U8i6ARu x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: bb67bb5b-4a56-4183-1628-08d60c2846c9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(4618075)(2017052603328)(7153060)(7193020); SRVR:CO1PR05MB394; x-ms-traffictypediagnostic: CO1PR05MB394: x-microsoft-antispam-prvs: <CO1PR05MB3943A5EC379F16530BEBE11AE0B0@CO1PR05MB394.namprd05.prod.outlook.com> 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)(93006095)(93001095)(3231311)(944501410)(52105095)(3002001)(10201501046)(6055026)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(201708071742011)(7699016); SRVR:CO1PR05MB394; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB394; x-forefront-prvs: 07778E4001 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(396003)(376002)(136003)(346002)(189003)(199004)(81166006)(25786009)(53936002)(86362001)(74316002)(8936002)(305945005)(81156014)(5640700003)(476003)(486006)(186003)(6436002)(5250100002)(9686003)(2501003)(256004)(3846002)(6116002)(55016002)(33656002)(14454004)(106356001)(558084003)(7696005)(6506007)(26005)(97736004)(2900100001)(99286004)(316002)(66066001)(102836004)(5660300001)(7736002)(8676002)(105586002)(478600001)(6916009)(2351001)(2906002)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB394; H:CO1PR05MB443.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-microsoft-antispam-message-info: Etp2IIt2MmkKlw/YDWDdA4Q8JRfZvncMLQbbQEDDEi3V21tLbzgkHWhcVHW7iLl4gHeRnolVS3Tis/SIjqysZskERZ58R3AZiTJSrEhj4pOfejaU1feI8JPOIaufBRkd9gbtvWyS9B7Siu5wSR9G8JNGdEJTdh6bNtDoOMGFsWg32fH4EV1JpEi/pP3VG1vIRFvjAMuMWDDGlY1JI6nLjDAoHRp7awvioIqOgWXeWcxVDSOrqpIvJehz513PelVu1wZt1hXL2bXTMSPQD5yHgQ8SD4INXahnAkVxB64qTwvUTiAbcZobp386WhNosijOJ5jzII/E3+/6iJHQxg/SQeL0yd/kvvyS2SZklRJ+Dy0= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: bb67bb5b-4a56-4183-1628-08d60c2846c9 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2018 14:20:44.4375 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB394 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-27_06:, , 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=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=415 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808270152 Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/vomJ_hcC9Gn4HMrkKZMCHyngDEE> Subject: [v6ops] draft-palet-v6ops-rfc6177-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 27 Aug 2018 14:20:49 -0000 Folks, Each week between now and IETF 103, we will review and discuss one draft wi= th an eye towards progressing it. This week, please review and comment on draft-palet-v6ops-rfc6177-bis. Fred and Ron From nobody Mon Aug 27 08:49:30 2018 Return-Path: <cb.list6@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64C7E130E07 for <v6ops@ietfa.amsl.com>; Mon, 27 Aug 2018 08:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 FA5skt3Zs1zE for <v6ops@ietfa.amsl.com>; Mon, 27 Aug 2018 08:49:25 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (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 D64CD130E06 for <v6ops@ietf.org>; Mon, 27 Aug 2018 08:49:24 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id f145-v6so6195616ybg.4 for <v6ops@ietf.org>; Mon, 27 Aug 2018 08:49:24 -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=WSqu220N8XXqhQz+W1MRQN1w5+QxDBkUbGs6qJkDT0I=; b=qsiCmByym3SPC5RznknbbVF2Xjp7iyeqjlHQQbaKxFSTBVtKJeyuOJMaW5D/7QnP5S 3BeNXHYv0yCPuQZFpRhB3j8EQbEVMtbA5GaCkw81fjb71+UYnNw82z9U9KDMUvFx7dMO ZPFv1gtdZ7haFMM1qbyYvRanxAJSIFUPL+rrIZlEp0+CyleLUVAFOUH6NNdCoSXeCeUz ARcc89LJWlEXUx5i+85FEbto63jP8CFNGMOXLfLgEu7R+CaHLX5oLiT0l1f5hFfvdgSa sYWk5AGtMPn8L+ZJxeEGpRBvB5EvRss+t7CREe+XKKnwbFsrkK67Td/h9X8kZ6J5BbQZ 8wUg== 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=WSqu220N8XXqhQz+W1MRQN1w5+QxDBkUbGs6qJkDT0I=; b=X7Tu4j/9AylZLaoicFFvHs0TWE/X4nzUONjh4lCGccaYrVcsk1u+qxNtbpOr37zpTz A08sEcHDMqatrDuU0svDM1cFG7eOgy8trJSSDCrT6hHHXKvbvumeE+Ulh7rMt08tngmv erUBNC6LAcLm/3kzgt7S5ufq8ngup+RSBtgJrxxmVFXyFdLKk1pKKdnkYO5R4mnWS7Vv 4udZCptsQtSQx/46MGN57VPSLQKF15SsbFv3vWYXYmAuXlkxiKa+A9daaLPTIL+6vsa/ nLxSf0QL4y5+dmoAtE5SY4LQ1xGc8HboboOP84U3qOFpvd+36g6DFIIfefr4zkZ5lAdI pjlQ== X-Gm-Message-State: APzg51AdHFxnVBvndWD0dYo/aqaUe7jhLRFWrHKLQoN8guuCF6rHcUUg AlMJ2mhzJS6z9CdT75hzzSyxV/kTUdqxue5UgIsq7A== X-Google-Smtp-Source: ANB0VdYEalnCuX3oqj5H5DSfxcuFheDLHikVwmINcTFHdsvOgIhusyrGEworfDofTDP5d1UloM/xlcoo0oY6WnSvlWs= X-Received: by 2002:a25:5444:: with SMTP id i65-v6mr7057780ybb.207.1535384963871; Mon, 27 Aug 2018 08:49:23 -0700 (PDT) MIME-Version: 1.0 References: <CAAObRXLe35KoONVsSO_oU+SRhMzMrKRE_SU-QNf2pGHYKpUrxA@mail.gmail.com> <2018082709132233449033@chinatelecom.cn> <CAKD1Yr3PFKC06vwALL9Pjyd8Ji-RnqPR-HMvLA6CS6cyDadzVw@mail.gmail.com> <CAAObRXJx-8cPYuU-5gSMCvoOX-m29Q5BZg1-GANXBV-2Zmjv0A@mail.gmail.com> <CAKD1Yr24fXHsRTwFErNGc+RYzXDfHFpF6zG5QFjfjS+xx5-9Mg@mail.gmail.com> <CAAObRXK3jx_FXi-Rt5W3iSkOrf8zmc2z0NC1hUoET=AMFj2sig@mail.gmail.com> <CAAedzxouJUY1-R2NQH8sMDA0vrkOSznOWUaykBtdMy5a5Cup4g@mail.gmail.com> <34329770-1e00-be97-8443-79448be367cb@gmail.com> <201808271339136864338@chinatelecom.cn> In-Reply-To: <201808271339136864338@chinatelecom.cn> From: Ca By <cb.list6@gmail.com> Date: Mon, 27 Aug 2018 08:49:12 -0700 Message-ID: <CAD6AjGReSzm0GHwFO74KL8R0F5Ahwd6c0s3bn2PtCyDTo-MPCw@mail.gmail.com> To: "xiechf.bri@chinatelecom.cn" <xiechf.bri@chinatelecom.cn> Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Davey Song <songlinjian@gmail.com>, Erik Kline <ek=40google.com@dmarc.ietf.org>, v6ops <v6ops@ietf.org> Content-Type: multipart/alternative; boundary="0000000000005d79a305746cab4c" Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/iie-h3F0Sng1Z9ArXL2M9KRx9V0> Subject: Re: [v6ops] How my Android phone got assigned with IPv6 address via 4G LTE? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 27 Aug 2018 15:49:27 -0000 --0000000000005d79a305746cab4c Content-Type: text/plain; charset="UTF-8" On Sun, Aug 26, 2018 at 10:39 PM xiechf.bri@chinatelecom.cn < xiechf.bri@chinatelecom.cn> wrote: > > If applications have the requirement of fixed IPv6 address for users in > mobile network, the IPv6 address for each user can be pre-configured in HSS > database, which has been supported in current 4G LTE architecture. In > addition, the BSS system should also be upgraded to support the > capability of fixed IPv6 address for UE. > > Chongfeng > The IID is still independently assigned by the UE. Only the first 64 bits can be reliably assigned by the network. This has caused some pain for enterprise applications, and they have had to use ipv4 instead of ipv6. I know of a case regarding busines applications getting static ipv4 because the admins could not initiate connections from the internet since the full UE address is unknown > ------------------------------ > xiechf.bri@chinatelecom.cn > > > *From:* Brian E Carpenter <brian.e.carpenter@gmail.com> > *Date:* 2018-08-27 12:26 > *To:* Erik Kline <ek=40google.com@dmarc.ietf.org>; songlinjian > <songlinjian@gmail.com> > *CC:* v6ops@ietf.org WG <v6ops@ietf.org> > *Subject:* Re: [v6ops] How my Android phone got assigned with IPv6 > address via 4G LTE? > > On 2018-08-27 16:00, Erik Kline wrote: > > On Mon, 27 Aug 2018 at 12:47, Davey Song <songlinjian@gmail.com> wrote: > >> > >> > >> > >> Another question about the lifetime of the address. > >> > >> How long will the address persist? I mean the lifetime of a IPv6 > address assigned. I test with my phone that every time I turn on the > "Mobile data", or switch from WIF, the IPv6 address changed. I'm not sure > How long it will persist. I check windows 10 on my laptop (netsh interface > ipv6 show privacy), the Maximum Preferred Lifetime is one day. > >> > >> I ask the question because some application developer may build their > app based on the persistence of the IPv6 address. Mycurrent suggestion to > them is "DO NOT RELY on IPv6 PERSISTENCE" becuase it changes more > frequently than IPv4. Is it right ? > > > > There are no guarantees at the IP layer of address persistence beyond > > the lifetimes in the PIO/RA. > > > > In general, any number of circumstances can cause the device to > > disconnect from the network at any time. When it next reconnects it > > may be provisioned with an entirely different prefix, for example. Of > > course, there might be some contractual arrangement that a given > > device is routed a known prefix, but that has no IP-layer > > representation. > > Not only that. Depending on the roaming situation, the device might > be switched between IPv6 and IPv4 without warning. Or (like mine) > it might have IPv6 connectivity sometimes on WiFi, even if the cell > operator only supports IPv4. > > So apps also need complete dual stack agility at any time. No address > is persistent. > > 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 > --0000000000005d79a305746cab4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div><br></div><div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sun,= Aug 26, 2018 at 10:39 PM <a href=3D"mailto:xiechf.bri@chinatelecom.cn">xie= chf.bri@chinatelecom.cn</a> <<a href=3D"mailto:xiechf.bri@chinatelecom.c= n">xiechf.bri@chinatelecom.cn</a>> wrote:<br></div><blockquote class=3D"= gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-= left:1ex"><div> <div><span></span><br></div><div>If applications have the requirement of fi= xed IPv6 address for users in mobile network, the IPv6 address for each use= r can be pre-configured in HSS database, which has been supported in curren= t 4G LTE architecture.=C2=A0 In addition, the BSS system should also be upg= raded <span style=3D"font-size:10.5pt;line-height:1.5;background-color:wind= ow">to support the capability of fixed IPv6 address for UE.</span></div><di= v><br></div><div>Chongfeng=C2=A0</div> <div></div></div></blockquote><div dir=3D"auto"><br></div><div dir=3D"auto"= >The IID is still independently assigned by the UE. =C2=A0</div><div dir=3D= "auto">=C2=A0</div><div dir=3D"auto">Only the first 64 bits can be reliably= assigned by the network.=C2=A0</div><div dir=3D"auto"><br></div><div dir= =3D"auto">This has caused some pain for enterprise applications, and they h= ave had to use ipv4 instead of ipv6.=C2=A0</div><div dir=3D"auto"><br></div= ><div dir=3D"auto">I know of a case regarding busines applications getting = static ipv4 because the admins could not initiate connections from the inte= rnet since the full UE address is unknown</div><div dir=3D"auto"><br></div>= <div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex"><div><div><br></div><hr style=3D"width:210px;height:1px" colo= r=3D"#b5c4df" size=3D"1" align=3D"left"> <div><span><div style=3D"MARGIN:10px;FONT-FAMILY:verdana;FONT-SIZE:10pt"><d= iv><a href=3D"mailto:xiechf.bri@chinatelecom.cn" target=3D"_blank">xiechf.b= ri@chinatelecom.cn</a></div></div></span></div> <blockquote style=3D"margin-top:0px;margin-bottom:0px;margin-left:0.5em"><d= iv>=C2=A0</div><div style=3D"border:none;border-top:solid #b5c4df 1.0pt;pad= ding:3.0pt 0cm 0cm 0cm"><div style=3D"PADDING-RIGHT:8px;PADDING-LEFT:8px;FO= NT-SIZE:12px;FONT-FAMILY:tahoma;COLOR:#000000;BACKGROUND:#efefef;PADDING-BO= TTOM:8px;PADDING-TOP:8px"><div><b>From:</b>=C2=A0<a href=3D"mailto:brian.e.= carpenter@gmail.com" target=3D"_blank">Brian E Carpenter</a></div><div><b>D= ate:</b>=C2=A02018-08-27=C2=A012:26</div><div><b>To:</b>=C2=A0<a href=3D"ma= ilto:ek=3D40google.com@dmarc.ietf.org" target=3D"_blank">Erik Kline</a>; <a= href=3D"mailto:songlinjian@gmail.com" target=3D"_blank">songlinjian</a></d= iv><div><b>CC:</b>=C2=A0<a href=3D"mailto:v6ops@ietf.org" target=3D"_blank"= >v6ops@ietf.org WG</a></div><div><b>Subject:</b>=C2=A0Re: [v6ops] How my An= droid phone got assigned with IPv6 address via 4G LTE?</div></div></div></b= lockquote></div><div><blockquote style=3D"margin-top:0px;margin-bottom:0px;= margin-left:0.5em"><div><div>On 2018-08-27 16:00, Erik Kline wrote:</div> <div>> On Mon, 27 Aug 2018 at 12:47, Davey Song <<a href=3D"mailto:so= nglinjian@gmail.com" target=3D"_blank">songlinjian@gmail.com</a>> wrote:= </div> <div>>></div> <div>>></div> <div>>></div> <div>>> Another question about the lifetime of the address.</div> <div>>></div> <div>>> How long will the address persist? I mean the lifetime of a I= Pv6 address assigned.=C2=A0 I test with my phone that every time I turn on = the=C2=A0 "Mobile data", or switch from WIF, the IPv6 address cha= nged. I'm not sure How long it will persist. I check windows 10 on my l= aptop (netsh interface ipv6 show privacy), the Maximum Preferred Lifetime i= s one day.</div> <div>>></div> <div>>> I ask the question because some application developer may bui= ld their app based on the persistence of the IPv6 address. Mycurrent sugges= tion to them is "DO NOT RELY on IPv6 PERSISTENCE" becuase it chan= ges more frequently than IPv4.=C2=A0 Is it right ?</div> <div>> </div> <div>> There are no guarantees at the IP layer of address persistence be= yond</div> <div>> the lifetimes in the PIO/RA.</div> <div>> </div> <div>> In general, any number of circumstances can cause the device to</= div> <div>> disconnect from the network at any time.=C2=A0 When it next recon= nects it</div> <div>> may be provisioned with an entirely different prefix, for example= .=C2=A0 Of</div> <div>> course, there might be some contractual arrangement that a given<= /div> <div>> device is routed a known prefix, but that has no IP-layer</div> <div>> representation.</div> <div>=C2=A0</div> <div>Not only that. Depending on the roaming situation, the device might</d= iv> <div>be switched between IPv6 and IPv4 without warning. Or (like mine)</div= > <div>it might have IPv6 connectivity sometimes on WiFi, even if the cell</d= iv> <div>operator only supports IPv4.</div> <div>=C2=A0</div> <div>So apps also need complete dual stack agility at any time. No address<= /div> <div>is persistent.</div> <div>=C2=A0</div> <div>=C2=A0=C2=A0=C2=A0 Brian</div> <div>=C2=A0</div> <div>_______________________________________________</div> <div>v6ops mailing list</div> <div><a href=3D"mailto:v6ops@ietf.org" target=3D"_blank">v6ops@ietf.org</a>= </div> <div><a href=3D"https://www.ietf.org/mailman/listinfo/v6ops" target=3D"_bla= nk">https://www.ietf.org/mailman/listinfo/v6ops</a></div> <div>=C2=A0</div> </div></blockquote> </div>_______________________________________________<br> v6ops mailing list<br> <a href=3D"mailto:v6ops@ietf.org" target=3D"_blank">v6ops@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/v6ops" rel=3D"noreferrer" = target=3D"_blank">https://www.ietf.org/mailman/listinfo/v6ops</a><br> </blockquote></div></div> --0000000000005d79a305746cab4c-- From nobody Mon Aug 27 11:23:39 2018 Return-Path: <dmudric@avaya.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B2A12785F; Mon, 27 Aug 2018 11:23: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=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 8VMEAa5x2Yiz; Mon, 27 Aug 2018 11:23:36 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.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 0E7DA12426A; Mon, 27 Aug 2018 11:23:31 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GSAgACQYRb/yYyC4daDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCeiYvZW0SKAqDaJQ4gg2DPYUXjWaBKzsLIwkChD4CF4MTITc?= =?us-ascii?q?VAQIBAQEBAQECAgJpHAyCaC8BAQQHAwwvCQIDAQEBAQEBAU8CD0cBARgBAQEBA?= =?us-ascii?q?gESEREzBwYFBQcEAgEIDQQEAQEBAgIGIAICAh8RFQgIAgQBDQUIEweDAIFpAw0?= =?us-ascii?q?IAQ6aJYlvgS4aAocTDYMsBYELhzCBGxeBQj4mbEaCTIJWRQQYgQs+gn8xgiYCh?= =?us-ascii?q?20IAZMLKwkChjF3hTVygjWBP4cbAw+FXYsdY4dJgVcjgVJwFTuCaYYBihg6bwE?= =?us-ascii?q?BgRSKLwGBEAsBAQ?= X-IPAS-Result: =?us-ascii?q?A2GSAgACQYRb/yYyC4daDgsBAQEBAQEBAQEBAQEHAQEBAQG?= =?us-ascii?q?CeiYvZW0SKAqDaJQ4gg2DPYUXjWaBKzsLIwkChD4CF4MTITcVAQIBAQEBAQECA?= =?us-ascii?q?gJpHAyCaC8BAQQHAwwvCQIDAQEBAQEBAU8CD0cBARgBAQEBAgESEREzBwYFBQc?= =?us-ascii?q?EAgEIDQQEAQEBAgIGIAICAh8RFQgIAgQBDQUIEweDAIFpAw0IAQ6aJYlvgS4aA?= =?us-ascii?q?ocTDYMsBYELhzCBGxeBQj4mbEaCTIJWRQQYgQs+gn8xgiYCh20IAZMLKwkChjF?= =?us-ascii?q?3hTVygjWBP4cbAw+FXYsdY4dJgVcjgVJwFTuCaYYBihg6bwEBgRSKLwGBEAsBA?= =?us-ascii?q?Q?= X-IronPort-AV: E=Sophos;i="5.53,296,1531800000"; d="scan'208";a="301435038" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 27 Aug 2018 14:23:29 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Aug 2018 14:23:29 -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; Mon, 27 Aug 2018 14:23:29 -0400 From: "Mudric, Dusan (Dusan)" <dmudric@avaya.com> To: Lea Roberts <lea.roberts@stanford.edu>, Brian E Carpenter <brian.e.carpenter@gmail.com>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org> CC: "draft-palet-v6ops-rfc6177-bis@ietf.org" <draft-palet-v6ops-rfc6177-bis@ietf.org>, IPv6 Operations <v6ops@ietf.org> Thread-Topic: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt Thread-Index: AQHUFwS5hR0dlGIaRECFIUzwEPML5KSW+0GAgAAwrwCAPQk0kA== Date: Mon, 27 Aug 2018 18:23:28 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E459CB44344@AZ-US1EXMB03.global.avaya.com> References: <153017691583.14743.17000446834856511528@ietfa.amsl.com> <78a36a81-3bb3-9d47-aa06-8da8f7594677@gmail.com> <C040E02F-7BEC-4FF9-8585-BE380B6859DE@consulintel.es> <alpine.DEB.2.02.1807191054090.7979@networking.stanford.edu> In-Reply-To: <alpine.DEB.2.02.1807191054090.7979@networking.stanford.edu> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/EYS61I0ie6-DccUe4qZiYO2x7wQ> Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 27 Aug 2018 18:23:38 -0000 U2VjdGlvbiA0Lg0KIiAgIGIuICBBbiBlbmQtdXNlciBzaG91bGQgYmUgYWJsZSB0byByZWNlaXZl IGFueSBwcmVmaXggbGVuZ3RoIHVwIHRvIC80OA0KICAgICAgIHNpbXBseSBieSBhc2tpbmcuIg0K DQpDYW4gIHRoaXMgYmUgZGVmaW5lZCBpbiBhIHdheSB0byBtYWtlIHN1cmUgdGhhdCBuZXcgYXBw bGljYXRpb25zIGFuZCBkZXZpY2VzIHdpbGwgYWx3YXlzIHdvcmsgYXQgZW5kIHNpdGVzIHdpdGhv dXQgYSBuZWVkIGZvciBhc2tpbmcgSVNQcyBmb3IgZXh0cmEgYWRkcmVzcyBzcGFjZT8gT3RoZXJ3 aXNlLCB0aGUgZW5kLXVzZXIgbWlnaHQgbm90IGdldCB3aGF0IGhlL3NoZSBhc2tzIGZvciwgd2l0 aG91dCBwYXlpbmcgZm9yIHRoZSAiaGlnaGVyIGdyYWRlIiBzZXJ2aWNlLiBDYW4gdGhlIGRlZmlu aXRpb24gaW1wb3NlIHVwIHRvIC80OCBMQVAgd2hlbiBuZWVkZWQgYXQgZW5kIHNpdGVzPyBGb3Ig ZXhhbXBsZSwgY2FuIGFuIGFwcGxpY2F0aW9uIHJlcXVlc3QgYSBob21lIHJvdXRlciB0byByZXF1 ZXN0IGFuIElTUCBmb3IgLzQ4IHByZWZpeCBhbmQsIHdoZW4gcmVxdWVzdGVkLCBJU1AgbXVzdCBn cmFudCBpdD8NCg0KUmVnYXJkcywNCkR1c2FuIE11ZHJpYy4NCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiB2Nm9wcyA8djZvcHMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVo YWxmIE9mIExlYSBSb2JlcnRzDQo+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDE5LCAyMDE4IDI6MDgg UE0NCj4gVG86IEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+ OyBKT1JESSBQQUxFVA0KPiBNQVJUSU5FWiA8am9yZGkucGFsZXQ9NDBjb25zdWxpbnRlbC5lc0Bk bWFyYy5pZXRmLm9yZz4NCj4gQ2M6IGRyYWZ0LXBhbGV0LXY2b3BzLXJmYzYxNzctYmlzQGlldGYu b3JnOyBJUHY2IE9wZXJhdGlvbnMNCj4gPHY2b3BzQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTog W3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1wYWxldC12Nm9wcy1yZmM2MTc3LWJpcy0wMC50eHQN Cj4gDQo+IGhpIEJyaWFuIGFuZCBKb3JkaSAtDQo+IA0KPiBleGNlbGxlbnQgY29tbWVudHMgYW5k IEkgYWdyZWUgYWxzby4NCj4gDQo+IHRoYW5rIHlvdSEhDQo+IC9MZWENCj4gDQo+IE9uIFRodSwg MTkgSnVsIDIwMTgsIEpPUkRJIFBBTEVUIE1BUlRJTkVaIHdyb3RlOg0KPiANCj4gPiBIaSBCcmlh biwNCj4gPg0KPiA+DQo+ID4NCj4gPiBUaGFua3MgYSBsb3QgZm9yIGNvbW1lbnRpbmcgYW5kIHNv cnJ5IHRoZSBsYXRlIGFuc3dlciAuLi4gdG9vIGJ1c3kgbGFzdA0KPiB3ZWVrcy4NCj4gPg0KPiA+ DQo+ID4NCj4gPiBDb21tZW50cyBpbi1saW5lIGJlbG93IChzdWJqZWN0ZWQgdG8gbXkgY28tYXV0 aG9yIGFncmVlbWVudCksIGJhc2ljYWxseSwNCj4gYWdyZWUgd2l0aCBhbGwgeW91ciBpbnB1dHMs IGV4Y2VwdCBhIGNvdXBsZSBvZiBwb2ludHMuDQo+ID4NCj4gPg0KPiA+DQo+ID4gVGhhbmtzIQ0K PiA+DQo+ID4NCj4gPg0KPiA+IFJlZ2FyZHMsDQo+ID4NCj4gPiBKb3JkaQ0KPiA+DQo+ID4NCj4g Pg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4g77u/LS0tLS1NZW5zYWplIG9yaWdpbmFsLS0tLS0N Cj4gPg0KPiA+IERlOiB2Nm9wcyA8djZvcHMtYm91bmNlc0BpZXRmLm9yZz4gZW4gbm9tYnJlIGRl IEJyaWFuIEUgQ2FycGVudGVyDQo+IDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+DQo+ID4N Cj4gPiBPcmdhbml6YWNpP246IFVuaXZlcnNpdHkgb2YgQXVja2xhbmQNCj4gPg0KPiA+IEZlY2hh OiBkb21pbmdvLCA4IGRlIGp1bGlvIGRlIDIwMTgsIDE3OjQzDQo+ID4NCj4gPiBQYXJhOiA8ZHJh ZnQtcGFsZXQtdjZvcHMtcmZjNjE3Ny1iaXNAaWV0Zi5vcmc+LCBJUHY2IE9wZXJhdGlvbnMNCj4g PHY2b3BzQGlldGYub3JnPg0KPiA+DQo+ID4gQXN1bnRvOiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9u OiBkcmFmdC1wYWxldC12Nm9wcy1yZmM2MTc3LWJpcy0wMC50eHQNCj4gPg0KPiA+DQo+ID4NCj4g PiAgICBIaSwNCj4gPg0KPiA+DQo+ID4NCj4gPiAgICBUaGFua3MgZm9yIHRoaXMgZHJhZnQuDQo+ ID4NCj4gPg0KPiA+DQo+ID4gICAgPiBBYnN0cmFjdA0KPiA+DQo+ID4NCj4gPg0KPiA+ICAgIFRo aXMgbmVlZHMgdG8gYmUgc2hvcnRlci4gVGhyZWUgcGFyYWdyYXBocyBpcyB0b28gbXVjaC4NCj4g Pg0KPiA+DQo+ID4NCj4gPiBGb3IgdGhlIG5leHQgdmVyc2lvbiwgSSd2ZSByZWR1Y2VkIDUwJSB0 aGUgbGVuZ3RoIG9mIHRoZSAxc3QgcGFyYWdyYXBoLiAzcmQNCj4gcGFyYWdyYXBoLCBJIHJlY2Fs bCBpcyBtYW5kYXRvcnkgKElETml0cykuDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+ICAg ID4gLi4uIHBvbGljeSBzaG91bGQgcmVmbGVjdCB0aGF0IGFzc2lnbm1lbnQgb2YgYSBzaW5nbGUg c3VibmV0IGlzDQo+ID4NCj4gPiAgICA+IG5vIGxvbmdlciBhcHByb3ByaWF0ZSB1bmxlc3MgdGhl IHJlY2lwaWVudCBleHBsaWNpdGx5IGFncmVlcyB0byB0aGUNCj4gPg0KPiA+ICAgID4gbGltaXRh dGlvbnMgaW1wbGllZCBieSBzdWNoIGFuIGFzc2lnbm1lbnQuDQo+ID4NCj4gPg0KPiA+DQo+ID4g ICAgSSAqc3Ryb25nbHkqIHN1Z2dlc3QgZGVsZXRpbmcgdGhlICJ1bmxlc3MiIGNsYXVzZS4gSXQg bGVhdmVzIGENCj4gPg0KPiA+ICAgIGxvb3Bob2xlLCBhbmQgaXQgY291bGQgZWFzaWx5IGJlIGhp ZGRlbiBpbiBzaHJpbmstd3JhcCB0ZXJtcw0KPiA+DQo+ID4gICAgYW5kIGNvbmRpdGlvbnMgc28g dGhhdCBhIHN1YnNjcmliZXIgd291bGQgYWdyZWUgd2l0aG91dCBldmVuDQo+ID4NCj4gPiAgICBr bm93aW5nIGFib3V0IGl0LiBSZWR1Y2UgdGhpcyBzaW1wbHkgdG86DQo+ID4NCj4gPg0KPiA+DQo+ ID4gICAgICAgLi4uIHBvbGljeSBzaG91bGQgcmVmbGVjdCB0aGF0IGFzc2lnbm1lbnQgb2YgYSBz aW5nbGUgc3VibmV0IGlzDQo+ID4NCj4gPiAgICAgICBuZXZlciBhcHByb3ByaWF0ZS4NCj4gPg0K PiA+DQo+ID4NCj4gPiBBZ3JlZWQgYW5kIGRvbmUuDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0K PiA+ICAgID4gMS4gIEludHJvZHVjdGlvbg0KPiA+DQo+ID4gICAgLi4uLg0KPiA+DQo+ID4gICAg PiAgICAxLiAgSXQgaXMgZXh0cmVtZWx5IGRpc2NvdXJhZ2VkIHRoYXQgLzEyOHMgYmUgZ2l2ZW4g b3V0LiAgV2hpbGUgdGhlcmUNCj4gPg0KPiA+ICAgID4gICAgICAgIG1heSBiZSBzb21lIGNhc2Vz IHdoZXJlIGFzc2lnbmluZyBvbmx5IGEgc2luZ2xlIGFkZHJlc3MgbWF5IGJlDQo+ID4NCj4gPiAg ICA+ICAgICAgICBqdXN0aWZpZWQsIGEgc2l0ZSwgYnkgZGVmaW5pdGlvbiwgaW1wbGllcyBtdWx0 aXBsZSBzdWJuZXRzIGFuZA0KPiA+DQo+ID4gICAgPiAgICAgICAgbXVsdGlwbGUgZGV2aWNlcy4N Cj4gPg0KPiA+DQo+ID4NCj4gPiAgICBJIGZpbmQgdGhpcyBhIGJpdCB3ZWFrLiBUcnk6DQo+ID4N Cj4gPg0KPiA+DQo+ID4gICAgICAgMS4gIEl0IGlzIGV4dHJlbWVseSBkaXNjb3VyYWdlZCB0aGF0 IC8xMjhzIGJlIGdpdmVuIG91dC4gIFdoaWxlIHRoZXJlDQo+ID4NCj4gPiAgICAgICAgICAgbWF5 IGJlIHNvbWUgYXBwbGljYXRpb25zIHdoZXJlIGFzc2lnbmluZyBvbmx5IGEgc2luZ2xlIGFkZHJl c3MgbWF5DQo+IGJlDQo+ID4NCj4gPiAgICAgICAgICAgdG9sZXJhdGVkLCBhIHNpdGUsIGJ5IGRl ZmluaXRpb24sIGltcGxpZXMgbXVsdGlwbGUgc3VibmV0cyBhbmQNCj4gPg0KPiA+ICAgICAgICAg ICBtdWx0aXBsZSBkZXZpY2VzLiBBbHNvLCBhIC8xMjggcHJldmVudHMgYW55IGZvcm0gb2YgcHJp dmFjeS1iYXNlZA0KPiA+DQo+ID4gICAgICAgICAgIGFkZHJlc3NpbmcuDQo+ID4NCj4gPg0KPiA+ DQo+ID4gQWdyZWVkIQ0KPiA+DQo+ID4NCj4gPg0KPiA+ICAgID4gICAgNC4gIFRoaXMgcmV2aXNp b24gaGFzIGJlZW4gY3JlYXRlZCB0byBtb3JlIGNsZWFybHkgYXNzZXJ0IHRoZQ0KPiA+DQo+ID4g ICAgPiAgICAgICAgcmVxdWlyZW1lbnQgdG8gZW5zdXJlIHRoYXQgYWRkcmVzcyBhc3NpZ25tZW50 cyB0byBlbmQtc2l0ZXMNCj4gPg0KPiA+ICAgID4gICAgICAgIHByb3ZpZGUgYSBzdWZmaWNpZW50 bHkgYmlnIG51bWJlciBvZiBzdWJuZXRzICgvNjQgb24gY2xhc3NpYw0KPiA+DQo+ID4gICAgPiAg ICAgICAgbmV0d29ya3MpIHRvIGVhY2ggZW5kLXNpdGUsIHRha2luZyB1bmRlciBjb25zaWRlcmF0 aW9uIHRoZSBlbmQtDQo+ID4NCj4gPiAgICA+ICAgICAgICBzaXRlJ3MgZnV0dXJlIGV4cGVjdGVk IG5lZWRzLCBuZXcgZGVwbG95bWVudCBleHBlY3RhdGlvbnMgYW5kDQo+IG5ldw0KPiA+DQo+ID4g ICAgPiAgICAgICAgcHJvdG9jb2wgcmVxdWlyZW1lbnRzLCBhbW9uZyBvdGhlcnMuICBPbmNlIGFs bCB0aGVzZSBhcmUNCj4gPg0KPiA+ICAgID4gICAgICAgIGNvbnNpZGVyZWQsIGl0IHNlZW1zIHVu bGlrZWx5IHRoYXQgYSBzaW5nbGUgc3VibmV0ICgvNjQpIG9yIGV2ZW4NCj4gPg0KPiA+ICAgID4g ICAgICAgIGEgc21hbGwgbnVtYmVyIG9mIHRoZW0gc2hvdWxkIGJlIGFzc2lnbmVkLCB1bmxlc3Mg dmVyeSBjbGVhcmx5DQo+ID4NCj4gPiAgICA+ICAgICAgICBqdXN0aWZpZWQgYW5kIGFncmVlZCB0 byBieSB0aGUgZW5kLXNpdGUuDQo+ID4NCj4gPg0KPiA+DQo+ID4gICAgVGhlICJ1bmxlc3MiIGNs YXVzZSBpcyBkYW5nZXJvdXMgYmVjYXVzZSBvZiBzaHJpbmstd3JhcCB0ZXJtcyBhbmQNCj4gPg0K PiA+ICAgIGNvbmRpdGlvbnMuIEkgc3VnZ2VzdCBkZWxldGluZyBpdC4NCj4gPg0KPiA+DQo+ID4N Cj4gPiBBZ3JlZWQhDQo+ID4NCj4gPg0KPiA+DQo+ID4gICAgPiAyLiAgQ29uc2lkZXJhdGlvbnMg UmVnYXJkaW5nIHRoZSBQcmVmaXggTGVuZ3RoDQo+ID4NCj4gPiAgICAuLi4uDQo+ID4NCj4gPiAg ICA+ICAgIFRoaXMgY29uc2lkZXJhdGlvbiBzaG91bGQgYmUgbm90aWNlZCwgYWNyb3NzIHRoaXMg ZG9jdW1lbnQsIGluIHRoZQ0KPiA+DQo+ID4gICAgPiAgICBzZW5zZSB0aGF0IGVuZC1zaXRlcyB1 c3VhbGx5IGhhdmUgc3VibmV0cyB0aGF0IHVzZSwgYnkgZGVmYXVsdCwNCj4gPg0KPiA+ICAgID4g ICAgU0xBQUMsIGFuZCBjb25zZXF1ZW50bHksIHRoZSBMQVAgaXMgbWFuZGF0b3JpbHkgYSAvNjQu ICBPdGhlcg0KPiA+DQo+ID4gICAgPiAgICB0ZWNobm9sb2dpZXMsIG1heSBoYXZlIGEgZGlmZmVy ZW50IExBUCwgd2hpY2ggbXVzdCBiZSB1c2VkDQo+ID4NCj4gPiAgICA+ICAgIGFjY29yZGluZ2x5 Lg0KPiA+DQo+ID4NCj4gPg0KPiA+ICAgIEkgc3VnZ2VzdCBzL090aGVyL0Z1dHVyZS8gc2luY2Ug LzY0IHByZXZhaWxzIGV2ZXJ5d2hlcmUgdG9kYXkuDQo+ID4NCj4gPg0KPiA+DQo+ID4gQWdyZWVk IQ0KPiA+DQo+ID4NCj4gPg0KPiA+ICAgID4gMy4gIE9uIC80OCBBc3NpZ25tZW50cyB0byBFbmQt U2l0ZXMNCj4gPg0KPiA+ICAgIC4uLi4NCj4gPg0KPiA+ICAgID4gICAgQW4gaW1wb3J0YW50DQo+ ID4NCj4gPiAgICA+ICAgIGdvYWwgaW4gSVB2NiBpcyB0byBzaWduaWZpY2FudGx5IGNoYW5nZSB0 aGUgZGVmYXVsdCBhbmQgbWluaW1hbCBlbmQNCj4gPg0KPiA+ICAgID4gICAgc2l0ZSBhc3NpZ25t ZW50LCBmcm9tICJhIHNpbmdsZSBhZGRyZXNzIiB0byAibXVsdGlwbGUgbmV0d29ya3MiIGFuZA0K PiA+DQo+ID4gICAgPiAgICB0byBlbnN1cmUgdGhhdCBlbmQtc2l0ZXMgY2FuIGVhc2lseSBvYnRh aW4gYWRkcmVzcyBzcGFjZS4NCj4gPg0KPiA+DQo+ID4NCj4gPiAgICBJIHN1Z2dlc3QgYWRkaW5n IHNvbWV0aGluZyBsaWtlIHRoaXM6DQo+ID4NCj4gPg0KPiA+DQo+ID4gICAgQXMgdGhlIG9wZXJh dGlvbmFsIGNvc3RzIG9mIGNhcnJpZXItZ3JhZGUgTkFUIGFuZCBhZGRyZXNzK3BvcnQgc2hhcmlu Zw0KPiA+DQo+ID4gICAgaGF2ZSBzaG93biwgYXZhaWxhYmlsaXR5IG9mIG11bHRpcGxlIGFkZHJl c3NlcyBhbmQgcHJlZml4ZXMgdG8gZW5kIHNpdGVzDQo+ID4NCj4gPiAgICB0aGF0IG5lZWQgdGhl bSB3aWxsIGJlIGEgY29uc2lkZXJhYmxlIHNhdmluZyB0byB0aGVpciBJU1BzLg0KPiA+DQo+ID4N Cj4gPg0KPiA+IEFncmVlZCENCj4gPg0KPiA+DQo+ID4NCj4gPiAgICA+ICAgIEl0IG1pZ2h0IGJl IHRlbXB0aW5nIHRvIGdpdmUgaG9tZSBzaXRlcyBhIHNpbmdsZSAvNjQsIHNpbmNlIHRoYXQgaXMN Cj4gPg0KPiA+ICAgID4gICAgYWxyZWFkeSBzaWduaWZpY2FudGx5IG1vcmUgYWRkcmVzcyBzcGFj ZSBjb21wYXJlZCB3aXRoIHRvZGF5J3MgSVB2NA0KPiA+DQo+ID4gICAgPiAgICBwcmFjdGljZS4g IEhvd2V2ZXIsIHRoaXMgcHJlY2x1ZGVzIHRoZSBleHBlY3RhdGlvbiB0aGF0IGV2ZW4gaG9tZQ0K PiA+DQo+ID4gICAgPiAgICBzaXRlcyB3aWxsIGdyb3cgdG8gc3VwcG9ydCBtdWx0aXBsZSBzdWJu ZXRzIGdvaW5nIGZvcndhcmQuICBIZW5jZSwgaXQNCj4gPg0KPiA+DQo+ID4NCj4gPiAgICBzL2V4 cGVjdGF0aW9uL2NlcnRhaW50eS8NCj4gPg0KPiA+DQo+ID4NCj4gPiBBZ3JlZWQhDQo+ID4NCj4g Pg0KPiA+DQo+ID4gICAgLi4uLg0KPiA+DQo+ID4gICAgPiAgICBBIGtleSBnb2FsIG9mIHRoZSBy ZWNvbW1lbmRhdGlvbnMgaW4gW1JGQzMxNzddIGlzIHRvDQo+ID4NCj4gPiAgICA+ICAgIGVuc3Vy ZSB0aGF0IHVwb24gcmVudW1iZXJpbmcsIG9uZSBkb2VzIG5vdCBoYXZlIHRvIGRlYWwgd2l0aA0K PiA+DQo+ID4gICAgPiAgICByZW51bWJlcmluZyBpbnRvIGEgc21hbGxlciBzdWJuZXQgc2l6ZS4N Cj4gPg0KPiA+DQo+ID4NCj4gPiAgICBQZXJoYXBzIGFkZDoNCj4gPg0KPiA+DQo+ID4NCj4gPiAg ICBJbiBwYXJ0aWN1bGFyIHRoaXMgd291bGQgYXBwbHkgdG8gYW55IHNpdGUgdGhhdCBzd2l0Y2hl cyB0bw0KPiA+DQo+ID4gICAgYW4gSVNQIHRoYXQgcHJvdmlkZXMgYSBsb25nZXIgcHJlZml4Lg0K PiA+DQo+ID4NCj4gPg0KPiA+IEFncmVlZCENCj4gPg0KPiA+DQo+ID4NCj4gPiAgICA+ICAgIEl0 IHNob3VsZCBiZSBub3RlZCB0aGF0IHNpbWlsYXIgYXJndW1lbnRzIGFwcGx5IHRvIHRoZSBtYW5h Z2VtZW50IG9mDQo+ID4NCj4gPiAgICA+ICAgIHpvbmUgZmlsZXMgaW4gdGhlIEROUy4gIEluIHBh cnRpY3VsYXIsIG1hbmFnaW5nIHRoZSByZXZlcnNlDQo+ID4NCj4gPiAgICA+ICAgIChpcDYuYXJw YSkgdHJlZSBpcyBzaW1wbGlmaWVkIHdoZW4gYWxsIGxpbmtzIGFyZSBudW1iZXJlZCB1c2luZyB0 aGUNCj4gPg0KPiA+ICAgID4gICAgc2FtZSBzdWJuZXQgaWRzDQo+ID4NCj4gPg0KPiA+DQo+ID4g ICAgcy9udW1iZXJlZC9yZW51bWJlcmVkLw0KPiA+DQo+ID4NCj4gPg0KPiA+IEFncmVlZCENCj4g Pg0KPiA+DQo+ID4NCj4gPiAgICAuLi4uDQo+ID4NCj4gPiAgICA+ICAgIHllYXJzLCBhbmQgd2Ug ZG9uJ3QgcmVjb3ZlciBiYWNrIHRoZSAvNDgncywgd2Ugd2lsbCBiZSBhYmxlIHRvIHVzZQ0KPiA+ DQo+ID4gICAgPiAgICBJUHY2IGFkZHJlc3Npbmcgc3BhY2UgZm9yIG92ZXIgMTAwLjAwMCB5ZWFy cy4NCj4gPg0KPiA+DQo+ID4NCj4gPiAgICBQZXJoYXBzIGFkZDoNCj4gPg0KPiA+DQo+ID4NCj4g PiAgICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IGFkdm9jYXRlIGNhcmVsZXNzIHVzZSBvZiBhZGRy ZXNzIHNwYWNlLCBidXQNCj4gPg0KPiA+ICAgIHRoZXJlIGlzIG9iamVjdGl2ZWx5IG5vIHJlYXNv biB0byBiZSByZXN0cmljdHZlLg0KPiA+DQo+ID4NCj4gPg0KPiA+IEFncmVlZCENCj4gPg0KPiA+ DQo+ID4NCj4gPiAgICAuLi4uDQo+ID4NCj4gPiAgICA+ICAgIFRvZGF5IHR5cGljYWxseSwgYSBo b21lIGhhcyBhbHJlYWR5IGEgY29uc2lkZXJhYmxlIG51bWJlciBvZiBwb3NzaWJsZQ0KPiA+DQo+ ID4gICAgPiAgICBzdWJuZXRzIChhIGNvbW1vbiBDRSBoYXMgNCBMQU4gcG9ydHMsIDIgV2lGaSBy YWRpb3Mgd2hpY2ggc3VwcG9ydA0KPiA+DQo+ID4gICAgPiAgICBzZXZlcmFsIFNTSURzIGVhY2gg b25lLCBWb0lQIHN1Ym5ldCwgSVBUViBzdWJuZXQsIGFkZGl0aW9uYWwgVkxBTnMpDQo+ID4NCj4g PiAgICA+ICAgIGFuZCBpZiBkb3duc3RyZWFtIHJvdXRlcnMgYXJlIHVzZWQsIHRoZXJlIGlzIGEg bmVlZCBmb3IgZnVydGhlcg0KPiA+DQo+ID4gICAgPiAgICBzdWJuZXRzLiAgVGhpcyBtZWFucyB0 aGF0IGluIGEgc2hvcnQgdGVybSwgYXNzaWduaW5nIGEgLzYwICgxNg0KPiA+DQo+ID4gICAgPiAg ICBzdWJuZXRzKSwgaXQgaXMgYWxyZWFkeSBhIHJlYWxseSBiYWQgZGVjaXNpb24sIGFzIGl0IG1h eSBlbmZvcmNlIElQdjYNCj4gPg0KPiA+ICAgID4gICAgTkFUIGJldHdlZW4gdGhlIG1haW4gQ0Ug YW5kIGRvd25zdHJlYW0gcm91dGVycy4NCj4gPg0KPiA+DQo+ID4NCj4gPiAgICBJIHN1Z2dlc3Qg ZGVsZXRpbmcgImFzIGl0IG1heSBlbmZvcmNlIElQdjYgTkFUIGJldHdlZW4gdGhlIG1haW4gQ0Ug YW5kDQo+ID4NCj4gPiAgICBkb3duc3RyZWFtIHJvdXRlcnMiLiBGaXJzdGx5IGl0IHB1dHMgTkFU IGludG8gdGhlIHJlYWRlcidzIG1pbmQuIFNlY29uZGx5LA0KPiA+DQo+ID4gICAgaXQgaXNuJ3Qg dGhlIG9ubHkgc29sdXRpb24gLSBJSURzIHNob3J0ZXIgdGhhbiA2NCBjb3VsZCBhbHNvIGJlIGlt cGxlbWVudGVkLg0KPiA+DQo+ID4NCj4gPg0KPiA+IEFncmVlZCENCj4gPg0KPiA+DQo+ID4NCj4g PiAgICA+IDQuICBJbXBhY3Qgb24gSVB2NiBTdGFuZGFyZHMNCj4gPg0KPiA+DQo+ID4NCj4gPiAg ICBJIHByb3Bvc2UgdG8gc2ltcGx5IGRlbGV0ZSB0aGlzIHNlY3Rpb24uDQo+ID4NCj4gPg0KPiA+ DQo+ID4gICAgRmlyc3RseSwgUkZDMzA1NiBpcyBkZXByZWNhdGVkIHNvIGl0J3MgaXJyZWxldmFu dCB0b2RheS4NCj4gPg0KPiA+ICAgIFNlY29uZGx5LCB0aGUgYXJndW1lbnQgYWJvdXQgVUxBcyAo UkZDNDE5MykgZG9lc24ndCBob2xkIHVwLg0KPiA+DQo+ID4gICAgVUxBcyBhcmUgbGlrZSBhbnkg b3RoZXIgLzQ4IHByZWZpeCAtIGlmIHlvdSBhcmUgZm9yY2VkIHRvDQo+ID4NCj4gPiAgICByZW51 bWJlciBpbnRvIGEgbG9uZ2VyIHByZWZpeCwgeW91IGxvc2Ugc29tZSBzdWJuZXQgYml0cy4NCj4g Pg0KPiA+ICAgIFRoYXQgaXMgYWxyZWFkeSBjb3ZlcmVkIGluIHRoZSBtaWRkbGUgb2Ygc2VjdGlv biAzICh0aGUNCj4gPg0KPiA+ICAgICJrZXkgZ29hbCIgc2VudGVuY2UgcXVvdGVkIGFib3ZlKS4N Cj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gSSByZWNhbGwgd2UgZGVwcmVjYXRlZCB0aGUg NnRvNCBhbnljYXN0LCBidXQgbm90IDZ0bzQsIGluIGZhY3QgNnRvNCB0byA2dG80DQo+IHRyYWZm aWMgaXMgc3RpbGwgdXNlZnVsIGZvciBwZWVyIHRvIHBlZXIuDQo+ID4NCj4gPg0KPiA+DQo+ID4g ICAgPiA2LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCj4gPg0KPiA+ICAgID4NCj4gPg0KPiA+ ICAgID4gICAgVGhpcyBkb2N1bWVudCBoYXMgbm8ga25vd24gc2VjdXJpdHkgaW1wbGljYXRpb25z Lg0KPiA+DQo+ID4NCj4gPg0KPiA+ICAgIFJlYWxseT8gTW9yZSBwcmVmaXggc3BhY2Ugb2ZmZXJz IG1vcmUgcG90ZW50aWFsIGZvciBzY2FubmluZw0KPiA+DQo+ID4gICAgYXR0YWNrcy4gTW9yZSBw cmVmaXggc3BhY2UgYWxzbyBhbGxvd3MgdGhlIHVzZSBvZiBzbGlnaHRseQ0KPiA+DQo+ID4gICAg cmFuZG9taXplZCBwcmVmaXhlcyBhbmQvb3IgcHJlZml4LXBlciBob3N0Lg0KPiA+DQo+ID4NCj4g Pg0KPiA+ICAgIEFsc28gb2YgY291cnNlLCBhIC8xMjggd291bGQgcHJldmVudCBhbnkgZm9ybSBv ZiBwcml2YWN5LWJhc2VkDQo+ID4NCj4gPiAgICBhZGRyZXNzaW5nLg0KPiA+DQo+ID4NCj4gPg0K PiA+IEkndmUgaW50cm9kdWNlZCBuZXcgdGV4dCBvbiB0aG9zZSBwb2ludHMuDQo+ID4NCj4gPg0K PiA+DQo+ID4gICAgPiA4LiAgQWNrbm93bGVkZ2VtZW50cw0KPiA+DQo+ID4gICAgPg0KPiA+DQo+ ID4gICAgPiAgICBUaGUgYXV0aG9ycyBvZiB0aGlzIGRvY3VtZW50IHdpbGwgbGlrZSB0byBhY2tu b3dsZWRnZSB0aGUgYXV0aG9ycyBvZg0KPiA+DQo+ID4gICAgPiAgICBwcmV2aW91cyB2ZXJzaW9u cyAoVGhvbWFzIE5hcnRlbiBhbmQgR2VvZmYgSHVzdG9uKQ0KPiA+DQo+ID4NCj4gPg0KPiA+ICAg IFJGQzMxNzcgd2FzIHNpZ25lZCBieSB0aGUgd2hvbGUgSUFCIGFuZCBJRVNHIHNlYXRlZCBpbiAy MDAxLCBhbmQgaXRzDQo+ID4NCj4gPiAgICBBY2tub3dsZWRnZW1lbnRzIHJlYWQ6DQo+ID4NCj4g Pg0KPiA+DQo+ID4gICAgPj4gICAgVGhpcyBkb2N1bWVudCBvcmlnaW5hdGVkIGZyb20gdGhlIElF VEYgSVB2NiBkaXJlY3RvcmF0ZSwgd2l0aCBtdWNoDQo+ID4NCj4gPiAgICA+PiAgICBpbnB1dCBm cm9tIHRoZSBJQUIgYW5kIElFU0cuICBUaGUgb3JpZ2luYWwgdGV4dCBmb3JtaW5nIHRoZSBiYXNp cyBvZg0KPiA+DQo+ID4gICAgPj4gICAgdGhpcyBkb2N1bWVudCB3YXMgY29udHJpYnV0ZWQgYnkg RnJlZCBCYWtlciBhbmQgQnJpYW4gQ2FycGVudGVyLg0KPiA+DQo+ID4gICAgPj4gICAgQWxsaXNv biBNYW5raW4gYW5kIFRob21hcyBOYXJ0ZW4gbWVyZ2VkIHRoZSBvcmlnaW5hbCBjb250cmlidXRp b25zDQo+ID4NCj4gPiAgICA+PiAgICBpbnRvIGEgc2luZ2xlIGRvY3VtZW50LCBhbmQgQWxhaW4g RHVyYW5kIGVkaXRlZCB0aGUgZG9jdW1lbnQNCj4gdGhyb3VnaA0KPiA+DQo+ID4gICAgPj4gICAg aXRzIGZpbmFsIHN0YWdlcy4NCj4gPg0KPiA+DQo+ID4NCj4gPiBBZ3JlZWQhDQo+ID4NCj4gPg0K PiA+DQo+ID4gICAgUmVnYXJkcw0KPiA+DQo+ID4gICAgICAgIEJyaWFuDQo+ID4NCj4gPg0KPiA+ DQo+ID4gICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPg0KPiA+ICAgIHY2b3BzIG1haWxpbmcgbGlzdA0KPiA+DQo+ID4gICAgdjZvcHNAaWV0Zi5v cmcNCj4gPg0KPiA+ICAgIGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwcy0NCj4gM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3Y2b3BzJmQ9RHdJ RGFRJmM9QkZwV1F3OGJzdUtwDQo+IGwxU2dpWkg2NFEmcj1VVDNCazljYkxlYUp4aGYzaUNyaElv VVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09LQ0KPiA1cmdZcV9uWU1iU0gySFhIbkhGQ0ZpMktEWXpP Q2xoU2lMbjBhdThXdTAmcz1pRXExdFVEYmVRTDRmM1NMTQ0KPiBmMS14aWhqSllUMEtBQU5fQldU bDktNzc5YyZlPQ0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+ICoqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCj4gPiBJUHY0IGlzIG92ZXINCj4g PiBBcmUgeW91IHJlYWR5IGZvciB0aGUgbmV3IEludGVybmV0ID8NCj4gPiBodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0NCj4gM0FfX3d3dy5jb25zdWxpbnRl bC5lcyZkPUR3SURhUSZjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmcj1VVDMNCj4gQms5Y2JMZWFK eGhmM2lDcmhJb1VXQjhZTFpVMjMwMjlzTVFHUTJrWSZtPS0NCj4gNXJnWXFfbllNYlNIMkhYSG5I RkNGaTJLRFl6T0NsaFNpTG4wYXU4V3UwJnM9R01STGRJdEY4eUtiVWRFOQ0KPiBOdVhFLVU0OHVr N09ITnVFaWp5bTlqaEUtLXMmZT0NCj4gPiBUaGUgSVB2NiBDb21wYW55DQo+ID4NCj4gPiBUaGlz IGVsZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBtYXkgYmUgcHJp dmlsZWdlZCBvcg0KPiBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBpcyBpbnRlbmRlZCB0 byBiZSBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlDQo+IGluZGl2aWR1YWwocykgbmFtZWQg YWJvdmUgYW5kIGZ1cnRoZXIgbm9uLWV4cGxpY2lsdHkgYXV0aG9yaXplZCBkaXNjbG9zdXJlLA0K PiBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIHRoZSBjb250ZW50cyBvZiB0aGlzIGlu Zm9ybWF0aW9uLCBldmVuIGlmDQo+IHBhcnRpYWxseSwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVz LCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCB3aWxsIGJlIGNvbnNpZGVyZWQgYQ0KPiBjcmlt aW5hbCBvZmZlbnNlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGJlIGF3 YXJlIHRoYXQgYW55DQo+IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ug b2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24sDQo+IGV2ZW4gaWYgcGFydGlhbGx5 LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQsIHdpbGwg YmUNCj4gY29uc2lkZXJlZCBhIGNyaW1pbmFsIG9mZmVuc2UsIHNvIHlvdSBtdXN0IHJlcGx5IHRv IHRoZSBvcmlnaW5hbCBzZW5kZXIgdG8NCj4gaW5mb3JtIGFib3V0IHRoaXMgY29tbXVuaWNhdGlv biBhbmQgZGVsZXRlIGl0Lg0KPiA+DQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gdjZvcHMgbWFpbGluZyBsaXN0DQo+ID4g djZvcHNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtDQo+IDNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb192Nm9wcyZk PUR3SURhUSZjPUJGcFdRdzhic3VLcA0KPiBsMVNnaVpINjRRJnI9VVQzQms5Y2JMZWFKeGhmM2lD cmhJb1VXQjhZTFpVMjMwMjlzTVFHUTJrWSZtPS0NCj4gNXJnWXFfbllNYlNIMkhYSG5IRkNGaTJL RFl6T0NsaFNpTG4wYXU4V3UwJnM9aUVxMXRVRGJlUUw0ZjNTTE0NCj4gZjEteGloakpZVDBLQUFO X0JXVGw5LTc3OWMmZT0NCg== From nobody Mon Aug 27 14:28:15 2018 Return-Path: <brian.e.carpenter@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D6C130DD3 for <v6ops@ietfa.amsl.com>; Mon, 27 Aug 2018 14:28:12 -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=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 ycnCEE_5yXBI for <v6ops@ietfa.amsl.com>; Mon, 27 Aug 2018 14:28:08 -0700 (PDT) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 719D3130E37 for <v6ops@ietf.org>; Mon, 27 Aug 2018 14:28:00 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id h69-v6so175791pfd.4 for <v6ops@ietf.org>; Mon, 27 Aug 2018 14:28:00 -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=CJJCaz9DUXwi3aKqFBFXkWh/I+YPGFnQOe/s/tcL5aU=; b=ldGJJ9On3SjNqkBZnFSbxR0ROhpeapOaN46O6H9Lq96TBhH8lRCXWGyBBUM/Dtl5NC u7VVT/Na6oSwlm2P+pMH1cX6l1l+dujC4mUpRK3grEsHuHwzQQOMNbGuc/2CLgOcbhFP BJTK88+N+BEZRGJ3PElQldB0jYduZud/MEGTb2sUBI77ZMBiD+dwM0kb37ocvi56SoJ8 FYMS2b5N/ygISjlihOHFbJyz6doqx/p2aaeMSOsqYcDrakACgaDWGJgq5RvIWK/MviCY cUnKrbiuSEshpgP8ni8UrtH37WIQ8/GM42sl1o742WMqQ3xbUtWXuU0Vci/r0RiSSILw vcEw== 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=CJJCaz9DUXwi3aKqFBFXkWh/I+YPGFnQOe/s/tcL5aU=; b=RW/VbscjYBQRFms48y2wDc88kf8LTDXzSkF30/rEQcH67ZDot0U5rzaU9Vz0FPRRBW n2RlMhZydGacC2/YM2kY1FSJwIFAP/A0j4WE/HK+N3kYloLo9lce4T7+EwkvPdqDwGUG JchvpsDON1MHd+9I9He1aghyMLRvepSoOPu8mivg01wmS/kBTuwzxVAp4W9CdfWiFaUO NrfaORYR5Ng/+UkAac02raT6jNfvQU2SJpPyHbVhdkkvpwP6fWk5Bwq6wbO0rP4hKtfI utD9RjUztlUrBkxU191JNeiCmEd5hN+FyGYq6tO9NF1wTsawaSpwLe3l06kVcGAgDViD T3UA== X-Gm-Message-State: APzg51DeCGi+Uke/ugfhKvrsnrpbLdlhKxze+I0SAzVsvzS+6CPvD1cI Y1EKkuxuyhTBZH214er9xL2+xBIT X-Google-Smtp-Source: ANB0VdZV64TpECU4FUUluVAQvngKOepZ5CsyjIq4sSB2fSgo0En6YcB061iasveXBGXbvPkF4rur6w== X-Received: by 2002:a62:6a01:: with SMTP id f1-v6mr15907911pfc.156.1535405279720; Mon, 27 Aug 2018 14:27:59 -0700 (PDT) Received: from [192.168.178.30] ([118.148.68.33]) by smtp.gmail.com with ESMTPSA id o34-v6sm228943pgm.44.2018.08.27.14.27.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Aug 2018 14:27:58 -0700 (PDT) To: "xiechf.bri@chinatelecom.cn" <xiechf.bri@chinatelecom.cn>, Erik Kline <ek=40google.com@dmarc.ietf.org>, Davey Song <songlinjian@gmail.com> Cc: v6ops <v6ops@ietf.org> References: <CAAObRXLe35KoONVsSO_oU+SRhMzMrKRE_SU-QNf2pGHYKpUrxA@mail.gmail.com> <2018082709132233449033@chinatelecom.cn> <CAKD1Yr3PFKC06vwALL9Pjyd8Ji-RnqPR-HMvLA6CS6cyDadzVw@mail.gmail.com> <CAAObRXJx-8cPYuU-5gSMCvoOX-m29Q5BZg1-GANXBV-2Zmjv0A@mail.gmail.com> <CAKD1Yr24fXHsRTwFErNGc+RYzXDfHFpF6zG5QFjfjS+xx5-9Mg@mail.gmail.com> <CAAObRXK3jx_FXi-Rt5W3iSkOrf8zmc2z0NC1hUoET=AMFj2sig@mail.gmail.com> <CAAedzxouJUY1-R2NQH8sMDA0vrkOSznOWUaykBtdMy5a5Cup4g@mail.gmail.com> <34329770-1e00-be97-8443-79448be367cb@gmail.com> <201808271339136864338@chinatelecom.cn> From: Brian E Carpenter <brian.e.carpenter@gmail.com> Message-ID: <7c2448ad-9143-5b6d-7a62-9fa53129e81e@gmail.com> Date: Tue, 28 Aug 2018 09:27:52 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <201808271339136864338@chinatelecom.cn> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/9nTka40p3aWemmShK7XkTzfoJpw> Subject: Re: [v6ops] How my Android phone got assigned with IPv6 address via 4G LTE? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 27 Aug 2018 21:28:12 -0000 On 2018-08-27 17:39, xiechf.bri@chinatelecom.cn wrote: > > If applications have the requirement of fixed IPv6 address for users in mobile network, the IPv6 address for each user can be pre-configured in HSS database, which has been supported in current 4G LTE architecture. In addition, the BSS system should also be upgraded to support the capability of fixed IPv6 address for UE. Sorry, that can't possibly work for devices that frequently roam between providers or switch technologies dynamically. My cell phone switches between dual stack WiFi, 4G, and v4-only WiFi when I travel from home to my office. That's at least 3 different addresses per trip. Any app that cannot deal with that is useless. Brian > > Chongfeng > > > > xiechf.bri@chinatelecom.cn > > From: Brian E Carpenter > Date: 2018-08-27 12:26 > To: Erik Kline; songlinjian > CC: v6ops@ietf.org WG > Subject: Re: [v6ops] How my Android phone got assigned with IPv6 address via 4G LTE? > On 2018-08-27 16:00, Erik Kline wrote: >> On Mon, 27 Aug 2018 at 12:47, Davey Song <songlinjian@gmail.com> wrote: >>> >>> >>> >>> Another question about the lifetime of the address. >>> >>> How long will the address persist? I mean the lifetime of a IPv6 address assigned. I test with my phone that every time I turn on the "Mobile data", or switch from WIF, the IPv6 address changed. I'm not sure How long it will persist. I check windows 10 on my laptop (netsh interface ipv6 show privacy), the Maximum Preferred Lifetime is one day. >>> >>> I ask the question because some application developer may build their app based on the persistence of the IPv6 address. Mycurrent suggestion to them is "DO NOT RELY on IPv6 PERSISTENCE" becuase it changes more frequently than IPv4. Is it right ? >> >> There are no guarantees at the IP layer of address persistence beyond >> the lifetimes in the PIO/RA. >> >> In general, any number of circumstances can cause the device to >> disconnect from the network at any time. When it next reconnects it >> may be provisioned with an entirely different prefix, for example. Of >> course, there might be some contractual arrangement that a given >> device is routed a known prefix, but that has no IP-layer >> representation. > > Not only that. Depending on the roaming situation, the device might > be switched between IPv6 and IPv4 without warning. Or (like mine) > it might have IPv6 connectivity sometimes on WiFi, even if the cell > operator only supports IPv4. > > So apps also need complete dual stack agility at any time. No address > is persistent. > > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From nobody Mon Aug 27 20:39:17 2018 Return-Path: <ek@google.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96549130E32 for <v6ops@ietfa.amsl.com>; Mon, 27 Aug 2018 20:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.511 X-Spam-Level: X-Spam-Status: No, score=-17.511 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, 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 ntEOGYQaKZ0F for <v6ops@ietfa.amsl.com>; Mon, 27 Aug 2018 20:39:12 -0700 (PDT) Received: from mail-yw1-xc36.google.com (mail-yw1-xc36.google.com [IPv6:2607:f8b0:4864:20::c36]) (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 9BD5812008A for <v6ops@ietf.org>; Mon, 27 Aug 2018 20:39:12 -0700 (PDT) Received: by mail-yw1-xc36.google.com with SMTP id w202-v6so77710yww.3 for <v6ops@ietf.org>; Mon, 27 Aug 2018 20:39:12 -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=uSZzccxR1UN50fOITe+MzVLxSTylOulSu/wzpUP7430=; b=rkbg8qkMnAb6viWpAHpLpqjc3Qs/Su2OaTjIA4591HMo5FjXrQHghmKF5aU158GVeC GBIiu7swJLwIOcJTnWsRN9r7oPzkRI1Vz5wUjMAYw41wQrikkOfr0d3bs9j3UDDZAmIQ cc/wDsXsi4RcyEURYlofwDLNNsokiIuH0ycrzSoBwMQyWLAjyjHSKDhiVKoOMOZ0dRAC 4Z29ecI21ZRUY0/7gjuLPACAqrMJaqkgCquYZE+XB9O6dAQpSIhobXcd9RLqx1KeeblR 8HaokLOVtxehv1NkWKmsz0qTNA46QDYze9UQO3neTloRARvWiTC9YqYAKNBnm2+N9ios /SZA== 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=uSZzccxR1UN50fOITe+MzVLxSTylOulSu/wzpUP7430=; b=GxK2+BfyFlOoaxeawKvw//CwZQipGs/zioZwau3K4eK8imRP32iFeQNqTMPQMd0kqp ULTyVDYrv8caGD36Nr+W4J/NJMJXkv28VSYcaMpv9gju7xMO1RYNgjVDf5MpzJr1vQdv xLTpED7WCBB0fvlzd3C08N6k70aMc2if7wq1Vzlfc8M30frp825Cwry3asDTZ/fVKebc t1pStkW6sO6IRqRKl+b6MdfSNM+SG4vPNGvSUqPCcTBpJ1Q+kuzN8Sd9wQB9pWCAXzp6 GHfFkrX25VMeLkr60Fx+1cp+kFDMVha0DJ2hqO8WRNk5CpGetN5YhsFBdOwfs7/sFhsT yXlQ== X-Gm-Message-State: APzg51AiwYnuHmVaWZiVR2AuEK0ixa4lzF2PX7m8KD/gf7uErxvvXH5K VdBUTipCAg5uaImiAAqFWDNAF++yBrZoBhdPkN2K2A== X-Google-Smtp-Source: ANB0VdbAtr/OSA5rOsjo49kE21WpPTkFQ3sQdG2nZy+e9afEpT15fudOPiPdvUGTqqtVwcv2dRau+kDUSYYUZrmxTWg= X-Received: by 2002:a81:7a92:: with SMTP id v140-v6mr8653779ywc.173.1535427551267; Mon, 27 Aug 2018 20:39:11 -0700 (PDT) MIME-Version: 1.0 References: <CAAObRXLe35KoONVsSO_oU+SRhMzMrKRE_SU-QNf2pGHYKpUrxA@mail.gmail.com> <2018082709132233449033@chinatelecom.cn> <CAKD1Yr3PFKC06vwALL9Pjyd8Ji-RnqPR-HMvLA6CS6cyDadzVw@mail.gmail.com> <CAAObRXJx-8cPYuU-5gSMCvoOX-m29Q5BZg1-GANXBV-2Zmjv0A@mail.gmail.com> <CAKD1Yr24fXHsRTwFErNGc+RYzXDfHFpF6zG5QFjfjS+xx5-9Mg@mail.gmail.com> <CAAObRXK3jx_FXi-Rt5W3iSkOrf8zmc2z0NC1hUoET=AMFj2sig@mail.gmail.com> <CAAedzxouJUY1-R2NQH8sMDA0vrkOSznOWUaykBtdMy5a5Cup4g@mail.gmail.com> <34329770-1e00-be97-8443-79448be367cb@gmail.com> <201808271339136864338@chinatelecom.cn> <CAD6AjGReSzm0GHwFO74KL8R0F5Ahwd6c0s3bn2PtCyDTo-MPCw@mail.gmail.com> In-Reply-To: <CAD6AjGReSzm0GHwFO74KL8R0F5Ahwd6c0s3bn2PtCyDTo-MPCw@mail.gmail.com> From: Erik Kline <ek@google.com> Date: Tue, 28 Aug 2018 12:38:55 +0900 Message-ID: <CAAedzxrDjTO=BSsBGdgbaDRmhCUuB6frtV_oRE-+vNu5tsA5+Q@mail.gmail.com> To: Cameron Byrne <cb.list6@gmail.com> Cc: xiechf.bri@chinatelecom.cn, Brian E Carpenter <brian.e.carpenter@gmail.com>, songlinjian@gmail.com, "v6ops@ietf.org WG" <v6ops@ietf.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000cedf360574769538" Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/mu4EWI8JXcagMFAxfu9DFD-zg04> Subject: Re: [v6ops] How my Android phone got assigned with IPv6 address via 4G LTE? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 28 Aug 2018 03:39:15 -0000 --000000000000cedf360574769538 Content-Type: text/plain; charset="UTF-8" > I know of a case regarding busines applications getting static ipv4 because the admins could not initiate connections from the internet since the full UE address is unknown The solution here is not fixing the address but using a rendezvous protocol (probably with some authentication) so the host can advertise its addresses and update them continuously as they change. --000000000000cedf360574769538 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMPipSifuL4Tx7dmsbMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MDcxNTA2MzcxOFoXDTE5MDEx MTA2MzcxOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALkHIP2fSFudoue2xAkNBouFm2EulKm/RKnsxmEw4dSbxQC2Mt72Ga/t ySyn6PMSAgsyjgP0bKJZf/NHBzDGuSKpY09UgBupEUEejwR4d5vrHk8IJNfIDTQ+Ygv4krlQmkO0 Qh/GB1y4PxtIn0tVfGfB7s3Z7wWyYbN1JrUrxAhKTpvkbJLRF1n/fKgv1nfUYyY9se4cZE3XQbJV 2biA0ATE8hw55TPa9FTv+QuWbAWXlTfsvz8SxdL8cs1HXVzBwi7kpzm2LbLictqUYotBdrCk2JQ9 ZkICHIpunwWnfTfNJ1Vt7MYL8worV+Y0TfBP0Uw1IG8qQ1Fdie3quVfdAoUCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBQw12fRZdlCj/XWgp08Ky/Ct82W7DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAsH2eOQwQDXJ145YZFyjaTxqiVS9t F3F65BSt739euYxmyoYFAFgBVwRLXBjD0eTRqz6W6O9FC3ZPzsIup/DXZZlPNPitbqGA391usTKN YHYsBchdjOocgO8gNokf3H4yvjUv6699ncUQXX+d0deUo38jOa4+OujSIQbz+PUicageFuFcraDO MV5VMHYtn/1Ngkrw4JSaf2nv1WTfUBQyRRorMCPXVJZLEm8K0apTK2RHaxnFvXHJjFPkLLsJSwmQ RCeC98jyQdFHPQank0x8KmEo+nlu2d0X0n/aLibqG7rRSVKINpvLv6C3j8P4b1t1Fu23J6OYkWUx Rz/Rs1hfPTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDD4qUon7i+E8e3ZrGzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgdfAMfShijMCQlk9s6uLSO3UwVqFF04ID jgVfkzplis4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwODI4 MDMzOTExWjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAGotNyYBMYX6uslC0ANUC0u/cr/1P8pZ2vfdU7JFFjqUDuVGPe0b Nzrq1W3d9R/sOrx094/f52ncdGDWgnMxeMv6nlCBvI6bPotRTcsLq5NNyM3U06A9mIesOav/K3A1 l0ATh9Kgpl7GL9bg/JlkSAg7TGHEgvQHBrthGQFfpQFXLLkO/8/M7ouWwtvlaRFEdlA700paCc/y 3uhvEE0KDqnWqBeP4UdZrVwhFBQruangIGqAktUw+/xH41h6ZHqVGnawPrYXEnAEUT2zDLb9NrfW OXahU3p/ABpP1h+39tyXRz3X9zimoF1qbKH8B5nHAAchlmMIoDHM+KCaU8nQ45A= --000000000000cedf360574769538-- From nobody Mon Aug 27 20:53:07 2018 Return-Path: <marka@isc.org> 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 BCD77130E45 for <v6ops@ietfa.amsl.com>; Mon, 27 Aug 2018 20:53:04 -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, 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 HC-8CQtNwzGY for <v6ops@ietfa.amsl.com>; Mon, 27 Aug 2018 20:53:03 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 175E7130E32 for <v6ops@ietf.org>; Mon, 27 Aug 2018 20:53:03 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id D79FC3AB040; Tue, 28 Aug 2018 03:53:02 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id B8A32160042; Tue, 28 Aug 2018 03:53:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A94D516006C; Tue, 28 Aug 2018 03:53:02 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id PeTQXiPg_6iJ; Tue, 28 Aug 2018 03:53:02 +0000 (UTC) Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id C0D7F160042; Tue, 28 Aug 2018 03:53:01 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mark Andrews <marka@isc.org> In-Reply-To: <CAAedzxrDjTO=BSsBGdgbaDRmhCUuB6frtV_oRE-+vNu5tsA5+Q@mail.gmail.com> Date: Tue, 28 Aug 2018 13:52:59 +1000 Cc: Cameron Byrne <cb.list6@gmail.com>, "v6ops@ietf.org WG" <v6ops@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <48B470F2-3F62-4D3F-90ED-C80A752AB61F@isc.org> References: <CAAObRXLe35KoONVsSO_oU+SRhMzMrKRE_SU-QNf2pGHYKpUrxA@mail.gmail.com> <2018082709132233449033@chinatelecom.cn> <CAKD1Yr3PFKC06vwALL9Pjyd8Ji-RnqPR-HMvLA6CS6cyDadzVw@mail.gmail.com> <CAAObRXJx-8cPYuU-5gSMCvoOX-m29Q5BZg1-GANXBV-2Zmjv0A@mail.gmail.com> <CAKD1Yr24fXHsRTwFErNGc+RYzXDfHFpF6zG5QFjfjS+xx5-9Mg@mail.gmail.com> <CAAObRXK3jx_FXi-Rt5W3iSkOrf8zmc2z0NC1hUoET=AMFj2sig@mail.gmail.com> <CAAedzxouJUY1-R2NQH8sMDA0vrkOSznOWUaykBtdMy5a5Cup4g@mail.gmail.com> <34329770-1e00-be97-8443-79448be367cb@gmail.com> <201808271339136864338@chinatelecom.cn> <CAD6AjGReSzm0GHwFO74KL8R0F5Ahwd6c0s3bn2PtCyDTo-MPCw@mail.gmail.com> <CAAedzxrDjTO=BSsBGdgbaDRmhCUuB6frtV_oRE-+vNu5tsA5+Q@mail.gmail.com> To: Erik Kline <ek=40google.com@dmarc.ietf.org> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/WJMi_Azc25-x-ptjd5HxuMJpuX0> Subject: Re: [v6ops] How my Android phone got assigned with IPv6 address via 4G LTE? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 28 Aug 2018 03:53:05 -0000 We have one. It is called DNS (STD13). We have DNS UPDATE (RFC 2136) = which can be authenticated with TSIG (RFC 2845) or SIG(0) (RFC 2931). There are name servers that have implemented this for over 2 decades now and allow access control down to the <name,tuple,class> tuple level. zone example.com { type master; update-policy { grant * self .; }; }; Add a KEY record for host.example.com to the zone then you can use DNS = UPDATE authenticated using SIG(0) to update records at host.example.com. zone example.com { type master; update-policy { grant * selfsub .; }; }; Or if you want to also allow _prefix records use policy =E2=80=9Cselfsub=E2= =80=9D. For TSIG you would use a HMAC key called host.example.com.=20 Mark > On 28 Aug 2018, at 1:38 pm, Erik Kline = <ek=3D40google.com@dmarc.ietf.org> wrote: >=20 >> I know of a case regarding busines applications getting static ipv4 = because the admins could not initiate connections from the internet = since the full UE address is unknown >=20 > The solution here is not fixing the address but using a rendezvous > protocol (probably with some authentication) so the host can advertise > its addresses and update them continuously as they change. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Aug 27 21:07:42 2018 Return-Path: <ek@google.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD39130E40 for <v6ops@ietfa.amsl.com>; Mon, 27 Aug 2018 21:07:41 -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=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 G7CYcjatvn_F for <v6ops@ietfa.amsl.com>; Mon, 27 Aug 2018 21:07:40 -0700 (PDT) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 A70FD130E32 for <v6ops@ietf.org>; Mon, 27 Aug 2018 21:07:39 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id w11-v6so186637wrc.5 for <v6ops@ietf.org>; Mon, 27 Aug 2018 21:07:39 -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=N/W2tZn1FWLIQ9EybSG0t9tdFUzvjf7RclwhsbQYaCg=; b=n5v7hnhIDMbyxbAx/QJ7oylw+wcx/ZEo989xhGxNn/4wCC6PTFJoJ5D5IPc+21JzJr qrpjlpgNhWNC9E5+oj3hOF/t4vB+YDojUBpghZ+VQXAUFL118olj1WsKCT0UEkUv/bNV vuRkH6CMGGZuKxLDgo3CNwrFS/mxI6mdlCqbp12AlcYn7Jp3RAMVyksKcviZMzllP4uV /FdQAZjbd3sMYPsFq6N6coFDR7Ph15qLXcsgRAtQKzGoWBCoHtw6THzehfLu4wDXuwzo RZ1/109RA8u2Yw2i+sG6JIICIHn7FLkZAZzDzdEsxcfT8ap5eo9EebOmBQdOa2I9+DR3 IAGg== 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=N/W2tZn1FWLIQ9EybSG0t9tdFUzvjf7RclwhsbQYaCg=; b=PtneItxS4mFkOBgZKG1e68vg3yuQZduiAOyE/lUI8pttlw/mVf6ET7E7ppz1bpgyuA ryreu884z6ZxhtwaMUbbKcdWlpi313lNA6cf9tcqYPt5M97N8eJZAqKvRmCGYutf9u03 0o2qPcVCL2HOSOfyRlQItWotPzdL/hTqdJAnM646FqBTLeouzFiTbdB2IXQdVsawWB6P Yn6JoT0cOPNulHS9AATJYd0pRVug1BAfFx+HhNuFDkqioVUACT6lpbwPsdiGhb8//rm3 59aHpKd/s1mN1B5NV9AJhp56ZhfZcjrtpQ2OpHKqegAdylORxJGTyHvoVEVDdcq5IOgr zJVA== X-Gm-Message-State: APzg51CCwDdyzcP26jrUexo9s7xQteayUyEpeLkj+wI2LgkS2tXnIvZs SJbjKauPDI0LdLt5yWqedMKaT99HxWI2Fe2hLP/GbQ== X-Google-Smtp-Source: ANB0VdYvUCqFUX6NRESDnDVV91wnV9Xwe5S+QQYY+TvVatTErPNDfT/MnIZXH6o5A8uYEUltL2hdzCQeOLNZofA98CA= X-Received: by 2002:adf:9d81:: with SMTP id p1-v6mr10000234wre.12.1535429257751; Mon, 27 Aug 2018 21:07:37 -0700 (PDT) MIME-Version: 1.0 References: <CAAObRXLe35KoONVsSO_oU+SRhMzMrKRE_SU-QNf2pGHYKpUrxA@mail.gmail.com> <2018082709132233449033@chinatelecom.cn> <CAKD1Yr3PFKC06vwALL9Pjyd8Ji-RnqPR-HMvLA6CS6cyDadzVw@mail.gmail.com> <CAAObRXJx-8cPYuU-5gSMCvoOX-m29Q5BZg1-GANXBV-2Zmjv0A@mail.gmail.com> <CAKD1Yr24fXHsRTwFErNGc+RYzXDfHFpF6zG5QFjfjS+xx5-9Mg@mail.gmail.com> <CAAObRXK3jx_FXi-Rt5W3iSkOrf8zmc2z0NC1hUoET=AMFj2sig@mail.gmail.com> <CAAedzxouJUY1-R2NQH8sMDA0vrkOSznOWUaykBtdMy5a5Cup4g@mail.gmail.com> <34329770-1e00-be97-8443-79448be367cb@gmail.com> <201808271339136864338@chinatelecom.cn> <CAD6AjGReSzm0GHwFO74KL8R0F5Ahwd6c0s3bn2PtCyDTo-MPCw@mail.gmail.com> <CAAedzxrDjTO=BSsBGdgbaDRmhCUuB6frtV_oRE-+vNu5tsA5+Q@mail.gmail.com> <48B470F2-3F62-4D3F-90ED-C80A752AB61F@isc.org> In-Reply-To: <48B470F2-3F62-4D3F-90ED-C80A752AB61F@isc.org> From: Erik Kline <ek@google.com> Date: Tue, 28 Aug 2018 13:07:25 +0900 Message-ID: <CAAedzxqfmODSBbnzSEg0hH+W+ovoDXcgmUjo+XUySiZFrxVcUg@mail.gmail.com> To: Mark Andrews <marka@isc.org> Cc: Cameron Byrne <cb.list6@gmail.com>, "v6ops@ietf.org WG" <v6ops@ietf.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000084d369057476fb14" Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/tufEZnMFPzhl99MjmKRocKUjTxA> Subject: Re: [v6ops] How my Android phone got assigned with IPv6 address via 4G LTE? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 28 Aug 2018 04:07:41 -0000 --00000000000084d369057476fb14 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yup, agreed. I wasn't implying a protocol didn't exist, only that it wasn't being used. To be honest, I've never try to use DNS UPDATE as a client/in an application, so I don't know if there are any unaddressed aspects to its use *other* than simply trying in the first place. On Tue, 28 Aug 2018 at 12:53, Mark Andrews <marka@isc.org> wrote: > > We have one. It is called DNS (STD13). We have DNS UPDATE (RFC 2136) wh= ich > can be authenticated with TSIG (RFC 2845) or SIG(0) (RFC 2931). > > There are name servers that have implemented this for over 2 decades now > and allow access control down to the <name,tuple,class> tuple level. > > zone example.com { > type master; > update-policy { > grant * self .; > }; > }; > > Add a KEY record for host.example.com to the zone then you can use DNS UP= DATE > authenticated using SIG(0) to update records at host.example.com. > > zone example.com { > type master; > update-policy { > grant * selfsub .; > }; > }; > > Or if you want to also allow _prefix records use policy =E2=80=9Cselfsub= =E2=80=9D. > > For TSIG you would use a HMAC key called host.example.com. > > Mark > > > On 28 Aug 2018, at 1:38 pm, Erik Kline <ek=3D40google.com@dmarc.ietf.or= g> wrote: > > > >> I know of a case regarding busines applications getting static ipv4 be= cause the admins could not initiate connections from the internet since the= full UE address is unknown > > > > The solution here is not fixing the address but using a rendezvous > > protocol (probably with some authentication) so the host can advertise > > its addresses and update them continuously as they change. > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > --00000000000084d369057476fb14 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMPipSifuL4Tx7dmsbMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MDcxNTA2MzcxOFoXDTE5MDEx MTA2MzcxOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALkHIP2fSFudoue2xAkNBouFm2EulKm/RKnsxmEw4dSbxQC2Mt72Ga/t ySyn6PMSAgsyjgP0bKJZf/NHBzDGuSKpY09UgBupEUEejwR4d5vrHk8IJNfIDTQ+Ygv4krlQmkO0 Qh/GB1y4PxtIn0tVfGfB7s3Z7wWyYbN1JrUrxAhKTpvkbJLRF1n/fKgv1nfUYyY9se4cZE3XQbJV 2biA0ATE8hw55TPa9FTv+QuWbAWXlTfsvz8SxdL8cs1HXVzBwi7kpzm2LbLictqUYotBdrCk2JQ9 ZkICHIpunwWnfTfNJ1Vt7MYL8worV+Y0TfBP0Uw1IG8qQ1Fdie3quVfdAoUCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBQw12fRZdlCj/XWgp08Ky/Ct82W7DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAsH2eOQwQDXJ145YZFyjaTxqiVS9t F3F65BSt739euYxmyoYFAFgBVwRLXBjD0eTRqz6W6O9FC3ZPzsIup/DXZZlPNPitbqGA391usTKN YHYsBchdjOocgO8gNokf3H4yvjUv6699ncUQXX+d0deUo38jOa4+OujSIQbz+PUicageFuFcraDO MV5VMHYtn/1Ngkrw4JSaf2nv1WTfUBQyRRorMCPXVJZLEm8K0apTK2RHaxnFvXHJjFPkLLsJSwmQ RCeC98jyQdFHPQank0x8KmEo+nlu2d0X0n/aLibqG7rRSVKINpvLv6C3j8P4b1t1Fu23J6OYkWUx Rz/Rs1hfPTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDD4qUon7i+E8e3ZrGzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgHd0OCyxxm/Yiu9//RUbH6+YtK9N9FSdu AYJmLzyN5UEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwODI4 MDQwNzM4WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBACEHIdi2s5CVeflp54hucOvBRmw+YICIOKSIum7G7n5RPAwF1iaG 6+Oy9VoXKjbAI2nQny9Ca1hUDy1prfXTmYWPtSK2rSAGhtVeUuVSGhThizBEHe64uT7PzLyijNwT 0hRwWPZ1TUhZm8h5hNDEcxS+UqoZqc//VlNFe9OT18AnxKlqhHDifg9dDNPberSRJX3DmDxUNpp1 Nfr/4rVZdULAeE33n+iUGJjbUFrQVKv2UVZTEPyCJeqgJPepEDDCmG4b0PtOSEIjR06mMMBTSQo1 9iYL2l43sgWS++8g1bQX3ercC8Yq26aFrIEKScW9B50aLFOi2O218CTUBV08KoU= --00000000000084d369057476fb14-- From nobody Mon Aug 27 21:27:10 2018 Return-Path: <brian.e.carpenter@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E49112D949; Mon, 27 Aug 2018 21:27:08 -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 o9x5gzS18Sld; Mon, 27 Aug 2018 21:27:05 -0700 (PDT) Received: from mail-pg1-x541.google.com (mail-pg1-x541.google.com [IPv6:2607:f8b0:4864:20::541]) (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 095431274D0; Mon, 27 Aug 2018 21:27:05 -0700 (PDT) Received: by mail-pg1-x541.google.com with SMTP id t14-v6so190455pgf.0; Mon, 27 Aug 2018 21:27:05 -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=Fjr/SiLPiNdI+bWgSXS70Z9rfqgx8PtFSkN5BTh0qyY=; b=nRiKHiu4IHL+BOw3aGaApxMqvTrE0slS17UpndiaQLOJOzsjQ7XfU4y/1uJad0PrzT jxLnoQX5BK9lGZcM0bujCyczrxNKxH+RwvCz+oRc+K2LGLBaRAZPZDcyoA/Wm3iNQCij pLUhqpfRyyQzmTEbzvsKph+j/G71h+sUI2XGkipnMTaU691whCKzs+bSG1Lvvy1OzxJo 6zG9YKilbuPTqxu+nIyBqeHW9Hn//oCEsgR8fTRmBrb+lKjt3yUb+/DKxEnySkdyv1Fa l9wRS2PaH5zzOCr9+3KMDeQTFd8r6n+xn0eSRR83KzwyoO291kkCjVAHEVwdklfnbbhr IzOQ== 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=Fjr/SiLPiNdI+bWgSXS70Z9rfqgx8PtFSkN5BTh0qyY=; b=VHfAdeJOwx2SzxbWUUCdLinWcA7DeKmWEX1nzShyqGv4cayOCzaV1jMw1QpjObDcdk z3HrhZBLSLEfTCt/DKPtNLIB1MhQWtmhr/FA9Nx44K/axnh2oBvkCerlGRn13WV3vOoh Ltitv9n/Tq8NG/qGGybdzAKwU++C5FY0er5mbbYBVfKM/APdbnrpLwUcLaKVn+qOCXqN 3KTvgwic3I+r/DjfozPE0CSYPC6oeyhPTYGsdrxheQt9yoBDVZFq5L/RbvgmPucXohDV MwPh87NUcsAW+zp6/4eTHJKU3yphCCiv8TceuyzpGDI3LYoIFBPvPKj6wwoMa2Mi3kwZ U/pw== X-Gm-Message-State: APzg51DHYOeQ2JumoYtHld5p7eGB24Rx5Hopx2ipK/P9QoDLrYiLX8w3 ZnVS+Ol3Y9nBuTNlJaiOpix71O0i X-Google-Smtp-Source: ANB0VdbeCuq69AXvhSj3LIMVOpKPHeRrph/fV71+4Q4YCptiMGvFNu/dQ5aliivMjDTKWlxwNrZUjg== X-Received: by 2002:a62:5ec3:: with SMTP id s186-v6mr17232810pfb.146.1535430424158; Mon, 27 Aug 2018 21:27:04 -0700 (PDT) Received: from [192.168.178.30] ([118.148.68.33]) by smtp.gmail.com with ESMTPSA id t86-v6sm1134795pfe.109.2018.08.27.21.27.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Aug 2018 21:27:03 -0700 (PDT) To: "Mudric, Dusan (Dusan)" <dmudric@avaya.com>, Lea Roberts <lea.roberts@stanford.edu>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org> Cc: "draft-palet-v6ops-rfc6177-bis@ietf.org" <draft-palet-v6ops-rfc6177-bis@ietf.org>, IPv6 Operations <v6ops@ietf.org> References: <153017691583.14743.17000446834856511528@ietfa.amsl.com> <78a36a81-3bb3-9d47-aa06-8da8f7594677@gmail.com> <C040E02F-7BEC-4FF9-8585-BE380B6859DE@consulintel.es> <alpine.DEB.2.02.1807191054090.7979@networking.stanford.edu> <9142206A0C5BF24CB22755C8EC422E459CB44344@AZ-US1EXMB03.global.avaya.com> From: Brian E Carpenter <brian.e.carpenter@gmail.com> Message-ID: <f1bc1848-abe0-553e-0fdf-623eb0d1a871@gmail.com> Date: Tue, 28 Aug 2018 16:26:58 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <9142206A0C5BF24CB22755C8EC422E459CB44344@AZ-US1EXMB03.global.avaya.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/TGO1k8cWOfhUjZiywzcrewuFvh0> Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 28 Aug 2018 04:27:08 -0000 On 2018-08-28 06:23, Mudric, Dusan (Dusan) wrote: > Section 4. > " b. An end-user should be able to receive any prefix length up to /= 48 > simply by asking." >=20 > Can this be defined in a way to make sure that new applications and de= vices will always work at end sites without a need for asking ISPs for ex= tra address space? Otherwise, the end-user might not get what he/she asks= for, without paying for the "higher grade" service. Can the definition i= mpose up to /48 LAP when needed at end sites? For example, can an applica= tion request a home router to request an ISP for /48 prefix and, when req= uested, ISP must grant it? Unfortunately we can never say "must" in this context. What ISPs will pro= vide for what fee is well outside the IETF's competence. As observed on anothe= r thread, applications need to be agile, even if they work better if such a= request was granted. I'd say that once this update is done, it may be time to revisit RFC4084. Regards Brian >=20 > Regards, > Dusan Mudric. >=20 >> -----Original Message----- >> From: v6ops <v6ops-bounces@ietf.org> On Behalf Of Lea Roberts >> Sent: Thursday, July 19, 2018 2:08 PM >> To: Brian E Carpenter <brian.e.carpenter@gmail.com>; JORDI PALET >> MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> >> Cc: draft-palet-v6ops-rfc6177-bis@ietf.org; IPv6 Operations >> <v6ops@ietf.org> >> Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt >> >> hi Brian and Jordi - >> >> excellent comments and I agree also. >> >> thank you!! >> /Lea >> >> On Thu, 19 Jul 2018, JORDI PALET MARTINEZ wrote: >> >>> Hi Brian, >>> >>> >>> >>> Thanks a lot for commenting and sorry the late answer ... too busy la= st >> weeks. >>> >>> >>> >>> Comments in-line below (subjected to my co-author agreement), basical= ly, >> agree with all your inputs, except a couple of points. >>> >>> >>> >>> Thanks! >>> >>> >>> >>> Regards, >>> >>> Jordi >>> >>> >>> >>> >>> >>> >>> >>> =EF=BB=BF-----Mensaje original----- >>> >>> De: v6ops <v6ops-bounces@ietf.org> en nombre de Brian E Carpenter >> <brian.e.carpenter@gmail.com> >>> >>> Organizaci?n: University of Auckland >>> >>> Fecha: domingo, 8 de julio de 2018, 17:43 >>> >>> Para: <draft-palet-v6ops-rfc6177-bis@ietf.org>, IPv6 Operations >> <v6ops@ietf.org> >>> >>> Asunto: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt >>> >>> >>> >>> Hi, >>> >>> >>> >>> Thanks for this draft. >>> >>> >>> >>> > Abstract >>> >>> >>> >>> This needs to be shorter. Three paragraphs is too much. >>> >>> >>> >>> For the next version, I've reduced 50% the length of the 1st paragrap= h. 3rd >> paragraph, I recall is mandatory (IDNits). >>> >>> >>> >>> >>> >>> > ... policy should reflect that assignment of a single subnet is >>> >>> > no longer appropriate unless the recipient explicitly agrees to = the >>> >>> > limitations implied by such an assignment. >>> >>> >>> >>> I *strongly* suggest deleting the "unless" clause. It leaves a >>> >>> loophole, and it could easily be hidden in shrink-wrap terms >>> >>> and conditions so that a subscriber would agree without even >>> >>> knowing about it. Reduce this simply to: >>> >>> >>> >>> ... policy should reflect that assignment of a single subnet is= >>> >>> never appropriate. >>> >>> >>> >>> Agreed and done. >>> >>> >>> >>> >>> >>> > 1. Introduction >>> >>> .... >>> >>> > 1. It is extremely discouraged that /128s be given out. Whi= le there >>> >>> > may be some cases where assigning only a single address m= ay be >>> >>> > justified, a site, by definition, implies multiple subnet= s and >>> >>> > multiple devices. >>> >>> >>> >>> I find this a bit weak. Try: >>> >>> >>> >>> 1. It is extremely discouraged that /128s be given out. While= there >>> >>> may be some applications where assigning only a single addr= ess may >> be >>> >>> tolerated, a site, by definition, implies multiple subnets = and >>> >>> multiple devices. Also, a /128 prevents any form of privacy= -based >>> >>> addressing. >>> >>> >>> >>> Agreed! >>> >>> >>> >>> > 4. This revision has been created to more clearly assert the= >>> >>> > requirement to ensure that address assignments to end-sit= es >>> >>> > provide a sufficiently big number of subnets (/64 on clas= sic >>> >>> > networks) to each end-site, taking under consideration th= e end- >>> >>> > site's future expected needs, new deployment expectations= and >> new >>> >>> > protocol requirements, among others. Once all these are >>> >>> > considered, it seems unlikely that a single subnet (/64) = or even >>> >>> > a small number of them should be assigned, unless very cl= early >>> >>> > justified and agreed to by the end-site. >>> >>> >>> >>> The "unless" clause is dangerous because of shrink-wrap terms and >>> >>> conditions. I suggest deleting it. >>> >>> >>> >>> Agreed! >>> >>> >>> >>> > 2. Considerations Regarding the Prefix Length >>> >>> .... >>> >>> > This consideration should be noticed, across this document, i= n the >>> >>> > sense that end-sites usually have subnets that use, by defaul= t, >>> >>> > SLAAC, and consequently, the LAP is mandatorily a /64. Other= >>> >>> > technologies, may have a different LAP, which must be used >>> >>> > accordingly. >>> >>> >>> >>> I suggest s/Other/Future/ since /64 prevails everywhere today. >>> >>> >>> >>> Agreed! >>> >>> >>> >>> > 3. On /48 Assignments to End-Sites >>> >>> .... >>> >>> > An important >>> >>> > goal in IPv6 is to significantly change the default and minim= al end >>> >>> > site assignment, from "a single address" to "multiple network= s" and >>> >>> > to ensure that end-sites can easily obtain address space. >>> >>> >>> >>> I suggest adding something like this: >>> >>> >>> >>> As the operational costs of carrier-grade NAT and address+port sha= ring >>> >>> have shown, availability of multiple addresses and prefixes to end= sites >>> >>> that need them will be a considerable saving to their ISPs. >>> >>> >>> >>> Agreed! >>> >>> >>> >>> > It might be tempting to give home sites a single /64, since t= hat is >>> >>> > already significantly more address space compared with today'= s IPv4 >>> >>> > practice. However, this precludes the expectation that even = home >>> >>> > sites will grow to support multiple subnets going forward. H= ence, it >>> >>> >>> >>> s/expectation/certainty/ >>> >>> >>> >>> Agreed! >>> >>> >>> >>> .... >>> >>> > A key goal of the recommendations in [RFC3177] is to >>> >>> > ensure that upon renumbering, one does not have to deal with >>> >>> > renumbering into a smaller subnet size. >>> >>> >>> >>> Perhaps add: >>> >>> >>> >>> In particular this would apply to any site that switches to >>> >>> an ISP that provides a longer prefix. >>> >>> >>> >>> Agreed! >>> >>> >>> >>> > It should be noted that similar arguments apply to the manage= ment of >>> >>> > zone files in the DNS. In particular, managing the reverse >>> >>> > (ip6.arpa) tree is simplified when all links are numbered usi= ng the >>> >>> > same subnet ids >>> >>> >>> >>> s/numbered/renumbered/ >>> >>> >>> >>> Agreed! >>> >>> >>> >>> .... >>> >>> > years, and we don't recover back the /48's, we will be able t= o use >>> >>> > IPv6 addressing space for over 100.000 years. >>> >>> >>> >>> Perhaps add: >>> >>> >>> >>> This document does not advocate careless use of address space, but= >>> >>> there is objectively no reason to be restrictve. >>> >>> >>> >>> Agreed! >>> >>> >>> >>> .... >>> >>> > Today typically, a home has already a considerable number of = possible >>> >>> > subnets (a common CE has 4 LAN ports, 2 WiFi radios which sup= port >>> >>> > several SSIDs each one, VoIP subnet, IPTV subnet, additional = VLANs) >>> >>> > and if downstream routers are used, there is a need for furth= er >>> >>> > subnets. This means that in a short term, assigning a /60 (1= 6 >>> >>> > subnets), it is already a really bad decision, as it may enfo= rce IPv6 >>> >>> > NAT between the main CE and downstream routers. >>> >>> >>> >>> I suggest deleting "as it may enforce IPv6 NAT between the main CE= and >>> >>> downstream routers". Firstly it puts NAT into the reader's mind. S= econdly, >>> >>> it isn't the only solution - IIDs shorter than 64 could also be im= plemented. >>> >>> >>> >>> Agreed! >>> >>> >>> >>> > 4. Impact on IPv6 Standards >>> >>> >>> >>> I propose to simply delete this section. >>> >>> >>> >>> Firstly, RFC3056 is deprecated so it's irrelevant today. >>> >>> Secondly, the argument about ULAs (RFC4193) doesn't hold up. >>> >>> ULAs are like any other /48 prefix - if you are forced to >>> >>> renumber into a longer prefix, you lose some subnet bits. >>> >>> That is already covered in the middle of section 3 (the >>> >>> "key goal" sentence quoted above). >>> >>> >>> >>> >>> >>> I recall we deprecated the 6to4 anycast, but not 6to4, in fact 6to4 t= o 6to4 >> traffic is still useful for peer to peer. >>> >>> >>> >>> > 6. Security Considerations >>> >>> > >>> >>> > This document has no known security implications. >>> >>> >>> >>> Really? More prefix space offers more potential for scanning >>> >>> attacks. More prefix space also allows the use of slightly >>> >>> randomized prefixes and/or prefix-per host. >>> >>> >>> >>> Also of course, a /128 would prevent any form of privacy-based >>> >>> addressing. >>> >>> >>> >>> I've introduced new text on those points. >>> >>> >>> >>> > 8. Acknowledgements >>> >>> > >>> >>> > The authors of this document will like to acknowledge the aut= hors of >>> >>> > previous versions (Thomas Narten and Geoff Huston) >>> >>> >>> >>> RFC3177 was signed by the whole IAB and IESG seated in 2001, and i= ts >>> >>> Acknowledgements read: >>> >>> >>> >>> >> This document originated from the IETF IPv6 directorate, wit= h much >>> >>> >> input from the IAB and IESG. The original text forming the = basis of >>> >>> >> this document was contributed by Fred Baker and Brian Carpen= ter. >>> >>> >> Allison Mankin and Thomas Narten merged the original contrib= utions >>> >>> >> into a single document, and Alain Durand edited the document= >> through >>> >>> >> its final stages. >>> >>> >>> >>> Agreed! >>> >>> >>> >>> Regards >>> >>> Brian >>> >>> >>> >>> _______________________________________________ >>> >>> v6ops mailing list >>> >>> v6ops@ietf.org >>> >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwIDaQ&c=3DBFpWQw8bsuKp >> l1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3D- >> 5rgYq_nYMbSH2HXHnHFCFi2KDYzOClhSiLn0au8Wu0&s=3DiEq1tUDbeQL4f3SLM >> f1-xihjJYT0KAAN_BWTl9-779c&e=3D >>> >>> >>> >>> >>> >>> >>> ********************************************** >>> IPv4 is over >>> Are you ready for the new Internet ? >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp- >> 3A__www.consulintel.es&d=3DDwIDaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3 >> Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3D- >> 5rgYq_nYMbSH2HXHnHFCFi2KDYzOClhSiLn0au8Wu0&s=3DGMRLdItF8yKbUdE9 >> NuXE-U48uk7OHNuEijym9jhE--s&e=3D >>> 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, even= if >> partially, including attached files, is strictly prohibited and will b= e 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 infor= mation, >> even if partially, including attached files, is strictly prohibited, w= ill be >> considered a criminal offense, so you must reply to the original sende= r to >> inform about this communication and delete it. >>> >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwIDaQ&c=3DBFpWQw8bsuKp >> l1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3D- >> 5rgYq_nYMbSH2HXHnHFCFi2KDYzOClhSiLn0au8Wu0&s=3DiEq1tUDbeQL4f3SLM >> f1-xihjJYT0KAAN_BWTl9-779c&e=3D From nobody Mon Aug 27 21:37:56 2018 Return-Path: <marka@isc.org> 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 13DD212D949 for <v6ops@ietfa.amsl.com>; Mon, 27 Aug 2018 21:37:54 -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, 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 EYE4TsC3b3rA for <v6ops@ietfa.amsl.com>; Mon, 27 Aug 2018 21:37:52 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 B467F12008A for <v6ops@ietf.org>; Mon, 27 Aug 2018 21:37:52 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 795B03AB001; Tue, 28 Aug 2018 04:37:51 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 31DC1160042; Tue, 28 Aug 2018 04:37:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id DE78616006C; Tue, 28 Aug 2018 04:37:50 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ynzuHJYrHs43; Tue, 28 Aug 2018 04:37:50 +0000 (UTC) Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id BEC44160042; Tue, 28 Aug 2018 04:37:49 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mark Andrews <marka@isc.org> In-Reply-To: <CAAedzxqfmODSBbnzSEg0hH+W+ovoDXcgmUjo+XUySiZFrxVcUg@mail.gmail.com> Date: Tue, 28 Aug 2018 14:37:47 +1000 Cc: Cameron Byrne <cb.list6@gmail.com>, "v6ops@ietf.org WG" <v6ops@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <D02DED65-CFDB-4ABE-A2C1-AA75440F19A8@isc.org> References: <CAAObRXLe35KoONVsSO_oU+SRhMzMrKRE_SU-QNf2pGHYKpUrxA@mail.gmail.com> <2018082709132233449033@chinatelecom.cn> <CAKD1Yr3PFKC06vwALL9Pjyd8Ji-RnqPR-HMvLA6CS6cyDadzVw@mail.gmail.com> <CAAObRXJx-8cPYuU-5gSMCvoOX-m29Q5BZg1-GANXBV-2Zmjv0A@mail.gmail.com> <CAKD1Yr24fXHsRTwFErNGc+RYzXDfHFpF6zG5QFjfjS+xx5-9Mg@mail.gmail.com> <CAAObRXK3jx_FXi-Rt5W3iSkOrf8zmc2z0NC1hUoET=AMFj2sig@mail.gmail.com> <CAAedzxouJUY1-R2NQH8sMDA0vrkOSznOWUaykBtdMy5a5Cup4g@mail.gmail.com> <34329770-1e00-be97-8443-79448be367cb@gmail.com> <201808271339136864338@chinatelecom.cn> <CAD6AjGReSzm0GHwFO74KL8R0F5Ahwd6c0s3bn2PtCyDTo-MPCw@mail.gmail.com> <CAAedzxrDjTO=BSsBGdgbaDRmhCUuB6frtV_oRE-+vNu5tsA5+Q@mail.gmail.com> <48B470F2-3F62-4D3F-90ED-C80A752AB61F@isc.org> <CAAedzxqfmODSBbnzSEg0hH+W+ovoDXcgmUjo+XUySiZFrxVcUg@mail.gmail.com> To: Erik Kline <ek@google.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/QVTMHOSOSSFRSyJWWUnB4aNf6z4> Subject: Re: [v6ops] How my Android phone got assigned with IPv6 address via 4G LTE? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 28 Aug 2018 04:37:54 -0000 > On 28 Aug 2018, at 2:07 pm, Erik Kline <ek@google.com> wrote: >=20 > Yup, agreed. I wasn't implying a protocol didn't exist, only that it > wasn't being used. >=20 > To be honest, I've never try to use DNS UPDATE as a client/in an > application, so I don't know if there are any unaddressed aspects to > its use *other* than simply trying in the first place. * DNS UPDATE is used by Active Directory (using GSS-TSIG to = authenticate). * DNS UPDATE is used by DHCP servers with TSIG in enterprises to update forward and reverse zones. * DNS UPDATE is/was used by DynDNS with TSIG and SRV to update forward = zones from CPE routers usually. * MacOS uses DNS UPDATE with TSIG and SRV to update forward zones. (System Preferences -> Sharing -> Edit -> Use Dynamic Global Hostname) There is actually a good chance that it was used behind the scenes with equipment that you have used. It=E2=80=99s just not used ubiquitously = and it should be. Mark --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Aug 27 22:11:32 2018 Return-Path: <brian.e.carpenter@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006B6130DC6 for <v6ops@ietfa.amsl.com>; Mon, 27 Aug 2018 22:11:31 -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 UEe3YI3B6rJS for <v6ops@ietfa.amsl.com>; Mon, 27 Aug 2018 22:11:29 -0700 (PDT) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (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 0032F124D68 for <v6ops@ietf.org>; Mon, 27 Aug 2018 22:11:28 -0700 (PDT) Received: by mail-pf1-x431.google.com with SMTP id d4-v6so210465pfn.0 for <v6ops@ietf.org>; Mon, 27 Aug 2018 22:11:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ld9VXxtW0l5Ce22HOXnlI5L23knDMW2POsNeANsTpUE=; b=Jl4O7dURMHAD5e10C48lZcS0tpbH08RbZhY+D2s0yAUoFJxI5/iIqPJok7vwBcpdtm 1HrgDnsvH+cL5RkUbPEzgZwOzwvd/IQ0JcU+gcwZRmXvskwxJU0r7CEBoUK6iAZBlu59 pQNnlohEC56cFEPxtcF+t20xDnpcilvuopSMqbge8BcUqyUx5pWXlFbTWUyGMPcURaM5 /XJ//ta2q0T8tD0vFH90fPKT+pRRuCIUluYikh5IOhkllrBuk/dMW5AS2djGyknZrQ7B siw/BtVR0IHV1VSfj+LBH3H1oBiQ1BK9bVaDRn8TNiXwO6dBp7wFm87kYZ8Dlo0y8nK2 5xqA== 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:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=ld9VXxtW0l5Ce22HOXnlI5L23knDMW2POsNeANsTpUE=; b=B9hXLjWY2kBk9C5x16GmdssYBs/U9gwlNjFfI2itxa6+zBLGoO7QIGQ3ZRVulGL382 x04IrCNpOl58Z9FKZUJRCoP4q+RRKFo5+tMDTtwgtY3jBALapnDS38b5d8xpF1VXrGNb 49Q9MinvDhIp4b7+EGzsFRcjfyNmTDD9QjuDSLI76DZq4YC+R4fs9Staw68WnHXkNouS k2bfQffxdmQLKwwrjizG5Ku7yZ49E/h+DJ8o5FW4ExqkiffAYmuIfCt7uVM9RDjMAmd6 Cv3iL3+yhCq2XLqmPeIoqELGqr3wsPfremOy87uPfEw6BQ0Kcd97bt0YzpZ3827uVtoS wzRw== X-Gm-Message-State: APzg51CR2zH0xtlcPo0zzfgDRTPAxrSoitstDvSOjtSoxy2c7+mQtJw/ LRZpTn+gVSMVE0p9cHi8uXGX8z8u X-Google-Smtp-Source: ANB0Vdbu+o3qfJdv5XPsP4+r1urC4gWySA1NbeEpBnIpA9eFDgUh51ugZ1nEhcsN2CBnH7U7TgOERg== X-Received: by 2002:a62:5d89:: with SMTP id n9-v6mr17276487pfj.102.1535433088147; Mon, 27 Aug 2018 22:11:28 -0700 (PDT) Received: from [192.168.178.30] ([118.148.68.33]) by smtp.gmail.com with ESMTPSA id u83-v6sm476559pfj.37.2018.08.27.22.11.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Aug 2018 22:11:27 -0700 (PDT) To: Ron Bonica <rbonica@juniper.net>, "v6ops@ietf.org" <v6ops@ietf.org> References: <CO1PR05MB443BFFA74AAEB374E38BD8FAE0B0@CO1PR05MB443.namprd05.prod.outlook.com> From: Brian E Carpenter <brian.e.carpenter@gmail.com> Organization: University of Auckland Message-ID: <80ec965c-4a6c-3cc8-b92f-ad03603f9223@gmail.com> Date: Tue, 28 Aug 2018 17:11:23 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <CO1PR05MB443BFFA74AAEB374E38BD8FAE0B0@CO1PR05MB443.namprd05.prod.outlook.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/-bVEIe_irUT1k_ryKC0QV_8oURY> Subject: Re: [v6ops] draft-palet-v6ops-rfc6177-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 28 Aug 2018 05:11:31 -0000 Hi, I fully support this draft. Here are a few (minor) wording issues and some nits. Issues: ------- > [RFC3177] called for a default end-site IPv6 assignment size of /48. > Subsequently, the Regional Internet Registries (RIRs) developed and > adopted IPv6 address assignment and allocation policies consistent > with those recommendations, and it triggered the development of > [RFC6177]. However, some of the RIRs, have later on updated those > policies, which still allow using /48, but leave the decision in the > hands of the ISP, or even, in some cases, encourage the assignment of > smaller (e.g., /56) blocks to residential end-sites, while keeping > /48 for business. I don't think that is accurate. Actually there was push-back *from* the RIRs against the wording of 3177, because some ISPs did not wish to be consistent with it. Here's another version: [RFC3177] called for a default end-site IPv6 assignment size of /48. Subsequently, the Regional Internet Registries (RIRs) developed and adopted IPv6 address assignment and allocation policies consistent with ISP practices, and this triggered the development of [RFC6177]. Current RIR policies still allow using /48, but leave the decision in the hands of the ISP, or even, in some cases, endorse the assignment of smaller (e.g., /56) blocks to residential end-sites, while keeping /48 for business. > This raises the question of a possible misinterpretation of [RFC6177] > by at least 1/3rd of the operational community and consequently, the > need to revisit it. No, I don't think there's any misinterpretation. I think it's quite clear (as in my previous comment) that this is exactly why the ISP community pushed for RFC6177. I think we should phrase this a bit differently. This raises the question of over-zealous interpretation of [RFC6177] by at least one third of the ISP community and consequently, the need to revisit it. > It might be tempting to give home sites a single /64, since that is > already significantly more address space compared with today's IPv4 > practice. However, this precludes the certainty that even home sites > will grow to support multiple subnets going forward. Hence, it is > strongly intended that even home sites be given a big number of > subnets worth of space, by default. Hence, this document still > recommends giving home sites significantly many more than a single > /64. I think a reference to RFC7368 and RFC7788 would be useful here, to make it clear that this is not guesswork. (Note that HNCP is mentioned later, so there is a little repetition in the argument.) Nits: ----- > Abstract > > The Regional Internet Registries (RIRs) policies, have different Delete the comma > requires an ever-increasing availability of subnets at the end-site > and so, policy should reflect that assignment of a single subnet is NEW requires an ever-increasing availability of subnets at the end-site, so policy should reflect that the assignment of a single subnet is I see a number of other minor syntax and punctuation nits in the text, but I'm afraid I'm going to leave those for the copy-editor. Regards, Brian From nobody Tue Aug 28 01:02:15 2018 Return-Path: <tim.chown@jisc.ac.uk> 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 224A4130DC1 for <v6ops@ietfa.amsl.com>; Tue, 28 Aug 2018 01:02: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=ham 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 AvdycIbU2Gag for <v6ops@ietfa.amsl.com>; Tue, 28 Aug 2018 01:02:11 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.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 5C7ED12F1A5 for <v6ops@ietf.org>; Tue, 28 Aug 2018 01:02:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1535443329; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uXuzoA/tAyagiLA3PNEoVzsWqF9z+IvDEFczSdshc4s=; b=h515EBm1Rcqd220ZyIPOrh3QFad5uTfWnh1cjm1/NlVPj32UmEGxb/FwN5lwgGzOVaz9Nquyf0kZoT3LfHJOQPTJZ1wXcZfqIagJIoQ4sO++Sp21pIli0YoqvEL5uupssMNjVcpwlE8+/p1/djYgbvfw1ymwghJ6D1EbS3B1zzY= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0241.outbound.protection.outlook.com [213.199.154.241]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-147-bSPRb8OhNNiZflc7C-zqRQ-1; Tue, 28 Aug 2018 09:02:07 +0100 Received: from AM0PR07MB4177.eurprd07.prod.outlook.com (52.133.59.156) by AM0PR07MB4753.eurprd07.prod.outlook.com (52.135.152.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1101.9; Tue, 28 Aug 2018 08:02:02 +0000 Received: from AM0PR07MB4177.eurprd07.prod.outlook.com ([fe80::6c7c:fd30:f5e4:cd76]) by AM0PR07MB4177.eurprd07.prod.outlook.com ([fe80::6c7c:fd30:f5e4:cd76%4]) with mapi id 15.20.1101.007; Tue, 28 Aug 2018 08:02:02 +0000 From: Tim Chown <Tim.Chown@jisc.ac.uk> To: Jens Link <jenslink@quux.de> CC: IPv6 Ops WG <v6ops@ietf.org> Thread-Topic: [v6ops] Thinking about problems in IPv6-only networks Thread-Index: AQHUNlUd9kDhUbu/SkeByQcX9N/lgqTEQgAAgAFeugCAAYKYgIACN7yAgAEN/ICAAAGnAIAAL4+AgAi27y+AAYzzgA== Date: Tue, 28 Aug 2018 08:02:01 +0000 Message-ID: <8B658D33-31FB-4530-A692-9A11E1A79523@jisc.ac.uk> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> <CAD6AjGQ_OBFGJb_C+mP_87nu7q_oXPrTvxhaV_=RcubeHtMy2Q@mail.gmail.com> <E345387F-6C1D-49D4-8B03-52D04498DDA5@lists.zabbadoz.net> <a9eeba1b-76dc-a69f-aabe-04fa4ddc3a4f@gmail.com> <e560c82c-085e-60fe-2076-70e3624696c0@asgard.org> <CAPt1N1mAELodigHMdNGQEhr0bmHv0oruhAAHNZDjCA4BummBDw@mail.gmail.com> <20180821191627.GD11393@Space.Net> <871sakgrg6.fsf@pc8.berlin.quux.de> In-Reply-To: <871sakgrg6.fsf@pc8.berlin.quux.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.9.1) x-originating-ip: [194.82.140.195] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM0PR07MB4753; 20:3AOV2qvmCS+5m1Qadx9UUtNuhydsr7WrD9oXXKVu9FkvswByyzUQUbNI/2OA8TwJy/ufMtUj0gNrZu5pp0SN0rYCuoY6NTlpvRAkWOAlqXgob0QBiedyJJS4DNSapeBFf82rGZ1NWglgvLv6J85Y/3SCZG7TLaxLPyerDZ+tQQU= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: bb5cf131-cb71-4582-a5d1-08d60cbc8988 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989137)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:AM0PR07MB4753; x-ms-traffictypediagnostic: AM0PR07MB4753: x-microsoft-antispam-prvs: <AM0PR07MB475327226C02DA0915632981D60A0@AM0PR07MB4753.eurprd07.prod.outlook.com> x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(3231311)(944501410)(52105095)(93006095)(93001095)(10201501046)(149027)(150027)(6041310)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(201708071742011)(7699016); SRVR:AM0PR07MB4753; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB4753; x-forefront-prvs: 077884B8B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(366004)(346002)(376002)(396003)(136003)(39850400004)(199004)(189003)(105586002)(8676002)(2900100001)(446003)(81166006)(81156014)(966005)(50226002)(6246003)(83716003)(4326008)(74482002)(72206003)(25786009)(86362001)(478600001)(8936002)(786003)(99286004)(82746002)(97736004)(316002)(93886005)(5250100002)(14454004)(14444005)(256004)(76176011)(57306001)(53936002)(36756003)(305945005)(2616005)(476003)(486006)(102836004)(6436002)(33656002)(7736002)(66066001)(3846002)(6116002)(5660300001)(68736007)(6916009)(186003)(26005)(6506007)(106356001)(11346002)(6512007)(53546011)(6306002)(229853002)(6486002)(2906002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB4753; H:AM0PR07MB4177.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-microsoft-antispam-message-info: vlTPTJpqKctFOJvSPs42msmuMhryC+RwIcwYy9E3m6BrqOB5HTIIuwzj42iYRJcx3wwWw/4OCVvHG9IylK29gfbZrgAmwdTFjlT0JzLlKSeByE2Tf8PQLWCGKW5hL5kXESzdivyOm22/dMnWNATi64YbFrRO0K1IxgZpI4u1PvCGz7k5EqBObPilJHG1aYc8iL4zkslBZAG0J9AbkvtrSxTw64B9vXVnQX8wy3yDofVmL+CzUL/N8dOyRe/blLAJ1JO6ZDiE7Jmh07lInc9T9I5BE0t7436bh0vsx0L4dK9vrBgHn/K9u7wMbvLnb/tHeo5aYMar4yTkYcctsa+nbNldDS5iWVGTu651Ys984YE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <A8934F6C66D3824DA997CC01A201A1FA@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: bb5cf131-cb71-4582-a5d1-08d60cbc8988 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2018 08:02:01.9854 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4753 X-MC-Unique: bSPRb8OhNNiZflc7C-zqRQ-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/YKMXqGAU-w1-cx00TEZecX7UoxQ> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 28 Aug 2018 08:02:14 -0000 > On 27 Aug 2018, at 09:10, Jens Link <jenslink@quux.de> wrote: >=20 > Gert Doering <gert@space.net> writes: >=20 >> Hi, >>=20 >> On Tue, Aug 21, 2018 at 12:26:14PM -0400, Ted Lemon wrote: >>> What's the state of SIP over IPv6 these days? >>=20 >> At least one german access providers uses this, and it seems to work. >=20 > In Germany I'm aware of sipgate running SIP over IPv6. After complaing > in their blog that all the (cable) providers are evil and doing some NAT > for IPv4. They got about 50 comments that they should run IPv6. I can remember running IPv6 SIP well over ten years ago, but that was with = open source not commercial platforms. In the UK, the first ISP that supported IPv6 has IPv6 SIP - https://aa.net.= uk/kb-telecoms-voip.html Tim From nobody Tue Aug 28 05:15:26 2018 Return-Path: <rajiva@cisco.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706D1130EA4 for <v6ops@ietfa.amsl.com>; Tue, 28 Aug 2018 05:15:25 -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_MED=-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 5iRo1DQBkve0 for <v6ops@ietfa.amsl.com>; Tue, 28 Aug 2018 05:15:23 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4502130DCC for <v6ops@ietf.org>; Tue, 28 Aug 2018 05:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2378; q=dns/txt; s=iport; t=1535458523; x=1536668123; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/8MWIEbGgijwDAGbPxnrKBLLSHnNojatZXRLc2n12zY=; b=LEmtj5ht9Ys9aTT73ozQIiOjjPEy78sin5n0y6U2toJNqOvOIOXC2wmO 9dAs8nAKZSTJr4oXfh5uQSOjEibt2SCJwaBWqm1XKEnfH4q9r5Y5Uossm X3Z734wo2NUeoExpVAOP8QAfyLdYvCJH+IoIHFkq5OL1ozbiIcYk5tBX2 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A1AwAhPIVb/5NdJa1aGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNPZX8og3GUOoFoJYM9lA0DUwsYC4RJAheDLSE3FQECAQE?= =?us-ascii?q?CAQECbRwMhTcBAQEBAgEBASEEDToLBQkCAgEIGAICJgICAhkMCxUQAgQOBYM?= =?us-ascii?q?hAYF5CA+jB3szhC0BhjAFBYEGiEsXgUE/gRInDBOCHi6DGwEBgXiCajGCJgK?= =?us-ascii?q?NHI4QCQKPbReBP40KiDaKbAIRFIEkMyIzgR9wFTsqAYI+ixWFPm+NHQEB?= X-IronPort-AV: E=Sophos;i="5.53,299,1531785600"; d="scan'208";a="444144335" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Aug 2018 12:15:22 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id w7SCFM8j023894 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Aug 2018 12:15:22 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 28 Aug 2018 07:15:21 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1367.000; Tue, 28 Aug 2018 07:15:21 -0500 From: "Rajiv Asati (rajiva)" <rajiva@cisco.com> To: Mark Andrews <marka@isc.org> CC: Erik Kline <ek@google.com>, "v6ops@ietf.org WG" <v6ops@ietf.org> Thread-Topic: [v6ops] How my Android phone got assigned with IPv6 address via 4G LTE? Thread-Index: AQHUPaAhXfa+N1TBsUuyyhgO2s7rHaTSy0g0gABVxoCAAAJJAIAACcaAgAAckICAAAPhAIAAB12A///ArR6AAP35AIAAxkqAgAAD74CAAAQIgIAACHyAgAAsB/0= Date: Tue, 28 Aug 2018 12:15:21 +0000 Message-ID: <7BC525AA-90F2-4477-BF1A-FB1FC80B8AF5@cisco.com> References: <CAAObRXLe35KoONVsSO_oU+SRhMzMrKRE_SU-QNf2pGHYKpUrxA@mail.gmail.com> <2018082709132233449033@chinatelecom.cn> <CAKD1Yr3PFKC06vwALL9Pjyd8Ji-RnqPR-HMvLA6CS6cyDadzVw@mail.gmail.com> <CAAObRXJx-8cPYuU-5gSMCvoOX-m29Q5BZg1-GANXBV-2Zmjv0A@mail.gmail.com> <CAKD1Yr24fXHsRTwFErNGc+RYzXDfHFpF6zG5QFjfjS+xx5-9Mg@mail.gmail.com> <CAAObRXK3jx_FXi-Rt5W3iSkOrf8zmc2z0NC1hUoET=AMFj2sig@mail.gmail.com> <CAAedzxouJUY1-R2NQH8sMDA0vrkOSznOWUaykBtdMy5a5Cup4g@mail.gmail.com> <34329770-1e00-be97-8443-79448be367cb@gmail.com> <201808271339136864338@chinatelecom.cn> <CAD6AjGReSzm0GHwFO74KL8R0F5Ahwd6c0s3bn2PtCyDTo-MPCw@mail.gmail.com> <CAAedzxrDjTO=BSsBGdgbaDRmhCUuB6frtV_oRE-+vNu5tsA5+Q@mail.gmail.com> <48B470F2-3F62-4D3F-90ED-C80A752AB61F@isc.org> <CAAedzxqfmODSBbnzSEg0hH+W+ovoDXcgmUjo+XUySiZFrxVcUg@mail.gmail.com>, <D02DED65-CFDB-4ABE-A2C1-AA75440F19A8@isc.org> In-Reply-To: <D02DED65-CFDB-4ABE-A2C1-AA75440F19A8@isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/DP-PUF6uqU6i70AS_OBfj2ktu7Q> Subject: Re: [v6ops] How my Android phone got assigned with IPv6 address via 4G LTE? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 28 Aug 2018 12:15:26 -0000 DQpXaXRoIElQdjYsIHVzYWdlIG9mIERETlMgc2hvdWxkIGJlIHJlY29tbWVuZGVkIGFzIGEgZ29v ZCBwcmFjdGljZSB0byBnZXQgaG9zdG5hbWUgLSBJUCBtYXBwaW5nLiBBbHNvIGltcG9ydGFudCBp cyB0byBmb3JtdWxhdGUgdGhlIGhvc3QgbmFtZXMgdGhhdCBjb21wbHkgd2l0aCBzYW5pdHkuIA0K DQpPZiBjb3Vyc2UsIHRoZSB0eXBpY2FsIHY0IHByYWN0aWNlIG9mIGZvcm11bGF0aW5nIGhvc3Ru YW1lcyBieSBlbmNvZGluZyB0aGUgZW50aXJlIHY0IGFkZHJlc3MgaW4gdGhlIGhvc3QgbmFtZSBt dXN0IG5vdCBiZSBmb2xsb3dlZC4gDQoNClBlcmhhcHMsIGEgdG9waWMgZm9yIGEgZGlmZmVyZW50 IHRocmVhZC4gDQpDaGVlcnMsDQpSYWppdiANCg0KDQo+IE9uIEF1ZyAyOCwgMjAxOCwgYXQgMTI6 MzggQU0sIE1hcmsgQW5kcmV3cyA8bWFya2FAaXNjLm9yZz4gd3JvdGU6DQo+IA0KPiANCj4gDQo+ PiBPbiAyOCBBdWcgMjAxOCwgYXQgMjowNyBwbSwgRXJpayBLbGluZSA8ZWtAZ29vZ2xlLmNvbT4g d3JvdGU6DQo+PiANCj4+IFl1cCwgYWdyZWVkLiAgSSB3YXNuJ3QgaW1wbHlpbmcgYSBwcm90b2Nv bCBkaWRuJ3QgZXhpc3QsIG9ubHkgdGhhdCBpdA0KPj4gd2Fzbid0IGJlaW5nIHVzZWQuDQo+PiAN Cj4+IFRvIGJlIGhvbmVzdCwgSSd2ZSBuZXZlciB0cnkgdG8gdXNlIEROUyBVUERBVEUgYXMgYSBj bGllbnQvaW4gYW4NCj4+IGFwcGxpY2F0aW9uLCBzbyBJIGRvbid0IGtub3cgaWYgdGhlcmUgYXJl IGFueSB1bmFkZHJlc3NlZCBhc3BlY3RzIHRvDQo+PiBpdHMgdXNlICpvdGhlciogdGhhbiBzaW1w bHkgdHJ5aW5nIGluIHRoZSBmaXJzdCBwbGFjZS4NCj4gDQo+ICogRE5TIFVQREFURSBpcyB1c2Vk IGJ5IEFjdGl2ZSBEaXJlY3RvcnkgKHVzaW5nIEdTUy1UU0lHIHRvIGF1dGhlbnRpY2F0ZSkuDQo+ ICogRE5TIFVQREFURSBpcyB1c2VkIGJ5IERIQ1Agc2VydmVycyB3aXRoIFRTSUcgaW4gZW50ZXJw cmlzZXMgdG8gdXBkYXRlDQo+ICBmb3J3YXJkIGFuZCByZXZlcnNlIHpvbmVzLg0KPiAqIEROUyBV UERBVEUgaXMvd2FzIHVzZWQgYnkgRHluRE5TIHdpdGggVFNJRyBhbmQgU1JWIHRvIHVwZGF0ZSBm b3J3YXJkIHpvbmVzDQo+ICBmcm9tIENQRSByb3V0ZXJzIHVzdWFsbHkuDQo+ICogTWFjT1MgdXNl cyBETlMgVVBEQVRFIHdpdGggVFNJRyBhbmQgU1JWIHRvIHVwZGF0ZSBmb3J3YXJkIHpvbmVzLg0K PiAgKFN5c3RlbSBQcmVmZXJlbmNlcyAtPiBTaGFyaW5nIC0+IEVkaXQgLT4gVXNlIER5bmFtaWMg R2xvYmFsIEhvc3RuYW1lKQ0KPiANCj4gVGhlcmUgaXMgYWN0dWFsbHkgYSBnb29kIGNoYW5jZSB0 aGF0IGl0IHdhcyB1c2VkIGJlaGluZCB0aGUgc2NlbmVzIHdpdGgNCj4gZXF1aXBtZW50IHRoYXQg eW91IGhhdmUgdXNlZC4gSXTigJlzIGp1c3Qgbm90IHVzZWQgdWJpcXVpdG91c2x5IGFuZCBpdCBz aG91bGQNCj4gYmUuDQo+IA0KPiBNYXJrDQo+IC0tIA0KPiBNYXJrIEFuZHJld3MsIElTQw0KPiAx IFNleW1vdXIgU3QuLCBEdW5kYXMgVmFsbGV5LCBOU1cgMjExNywgQXVzdHJhbGlhDQo+IFBIT05F OiArNjEgMiA5ODcxIDQ3NDIgICAgICAgICAgICAgIElOVEVSTkVUOiBtYXJrYUBpc2Mub3JnDQo+ IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2 Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K From nobody Tue Aug 28 07:34:34 2018 Return-Path: <lee@asgard.org> 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 CA7ED130DC2 for <v6ops@ietfa.amsl.com>; Tue, 28 Aug 2018 07:34:31 -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 ld1Z1LYiH05K for <v6ops@ietfa.amsl.com>; Tue, 28 Aug 2018 07:34:30 -0700 (PDT) Received: from atl4mhob05.registeredsite.com (atl4mhob05.registeredsite.com [209.17.115.43]) (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 EE5871294D0 for <v6ops@ietf.org>; Tue, 28 Aug 2018 07:34:29 -0700 (PDT) Received: from mailpod.hostingplatform.com (atl4qobmail02pod6.registeredsite.com [10.30.71.210]) by atl4mhob05.registeredsite.com (8.14.4/8.14.4) with ESMTP id w7SEYPW2026172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <v6ops@ietf.org>; Tue, 28 Aug 2018 10:34:25 -0400 Received: (qmail 23579 invoked by uid 0); 28 Aug 2018 14:34:25 -0000 X-TCPREMOTEIP: 174.64.33.182 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.2.103?) (lee@asgard.org@174.64.33.182) by 0 with ESMTPA; 28 Aug 2018 14:34:25 -0000 To: v6ops@ietf.org References: <CAAObRXLe35KoONVsSO_oU+SRhMzMrKRE_SU-QNf2pGHYKpUrxA@mail.gmail.com> <2018082709132233449033@chinatelecom.cn> <CAKD1Yr3PFKC06vwALL9Pjyd8Ji-RnqPR-HMvLA6CS6cyDadzVw@mail.gmail.com> <CAAObRXJx-8cPYuU-5gSMCvoOX-m29Q5BZg1-GANXBV-2Zmjv0A@mail.gmail.com> <CAKD1Yr24fXHsRTwFErNGc+RYzXDfHFpF6zG5QFjfjS+xx5-9Mg@mail.gmail.com> <CAAObRXK3jx_FXi-Rt5W3iSkOrf8zmc2z0NC1hUoET=AMFj2sig@mail.gmail.com> <CAAedzxouJUY1-R2NQH8sMDA0vrkOSznOWUaykBtdMy5a5Cup4g@mail.gmail.com> <34329770-1e00-be97-8443-79448be367cb@gmail.com> <201808271339136864338@chinatelecom.cn> <CAD6AjGReSzm0GHwFO74KL8R0F5Ahwd6c0s3bn2PtCyDTo-MPCw@mail.gmail.com> <CAAedzxrDjTO=BSsBGdgbaDRmhCUuB6frtV_oRE-+vNu5tsA5+Q@mail.gmail.com> <48B470F2-3F62-4D3F-90ED-C80A752AB61F@isc.org> <CAAedzxqfmODSBbnzSEg0hH+W+ovoDXcgmUjo+XUySiZFrxVcUg@mail.gmail.com> <D02DED65-CFDB-4ABE-A2C1-AA75440F19A8@isc.org> <7BC525AA-90F2-4477-BF1A-FB1FC80B8AF5@cisco.com> From: Lee Howard <lee@asgard.org> Message-ID: <c3df5aa5-4070-d16f-9c0d-684adb5f40e8@asgard.org> Date: Tue, 28 Aug 2018 10:34:25 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <7BC525AA-90F2-4477-BF1A-FB1FC80B8AF5@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/-VnxZ-jA4fgSZfSgrVwLaHrN3yc> Subject: Re: [v6ops] How my Android phone got assigned with IPv6 address via 4G LTE? X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 28 Aug 2018 14:34:32 -0000 On 08/28/2018 08:15 AM, Rajiv Asati (rajiva) wrote: > With IPv6, usage of DDNS should be recommended as a good practice to get hostname - IP mapping. Also important is to formulate the host names that comply with sanity. Only if you care about hostname - IP mapping. It matters for some kinds of servers, and is handy for traceroutes. Hosts that are clients don't generally get looked up by name. > > Of course, the typical v4 practice of formulating hostnames by encoding the entire v4 address in the host name must not be followed. It could be. "Sanity" (as you said above) is hard to define, especially when you don't want to give away private user information. > > Perhaps, a topic for a different thread. This draft is very close to publication: https://datatracker.ietf.org/doc/draft-ietf-dnsop-isp-ip6rdns/ The AD has for a very few minor changes, which I hope to make in the next 48 hours. It still needs IETF Last Call. Lee > Cheers, > Rajiv > > >> On Aug 28, 2018, at 12:38 AM, Mark Andrews <marka@isc.org> wrote: >> >> >> >>> On 28 Aug 2018, at 2:07 pm, Erik Kline <ek@google.com> wrote: >>> >>> Yup, agreed. I wasn't implying a protocol didn't exist, only that it >>> wasn't being used. >>> >>> To be honest, I've never try to use DNS UPDATE as a client/in an >>> application, so I don't know if there are any unaddressed aspects to >>> its use *other* than simply trying in the first place. >> * DNS UPDATE is used by Active Directory (using GSS-TSIG to authenticate). >> * DNS UPDATE is used by DHCP servers with TSIG in enterprises to update >> forward and reverse zones. >> * DNS UPDATE is/was used by DynDNS with TSIG and SRV to update forward zones >> from CPE routers usually. >> * MacOS uses DNS UPDATE with TSIG and SRV to update forward zones. >> (System Preferences -> Sharing -> Edit -> Use Dynamic Global Hostname) >> >> There is actually a good chance that it was used behind the scenes with >> equipment that you have used. It’s just not used ubiquitously and it should >> be. >> >> Mark >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >> >> _______________________________________________ >> 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 Tue Aug 28 08:07:02 2018 Return-Path: <dmudric@avaya.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97901130ED8; Tue, 28 Aug 2018 08:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=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 dqBivkS_HBcr; Tue, 28 Aug 2018 08:06:56 -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 D482C130F5E; Tue, 28 Aug 2018 08:06:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FoAgBrZIVb/wUHmMZaDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCelVlfygKg2iUOoINgz2FF41SFIErOwsjCQKEPgIXgl4hNRc?= =?us-ascii?q?BAgEBAQEBAQICAmkcDIJoLwEBBAcDDC8JAgMBAQEBAQEBTwIPRwEBGAEBAQEDE?= =?us-ascii?q?hERMwcGBQwEAgEIDQQEAQEBAgIGIAICAh8RFQgIAgQBDQUIEweDAIFpAxUBDpl?= =?us-ascii?q?IiW+BLhoChwgNgywFgQuHMIEbF4FCPiZsRoJMglZFBBiBCz4VFYJVMYImAodtC?= =?us-ascii?q?AGTCysJAoYxd4U1coI1gT+HGwMPhV2INoJnY4dJgUMCNYFScBU7gmmGAYoYOm8?= =?us-ascii?q?BAYEUimsBgRALAQE?= X-IPAS-Result: =?us-ascii?q?A2FoAgBrZIVb/wUHmMZaDgsBAQEBAQEBAQEBAQEHAQEBAQG?= =?us-ascii?q?CelVlfygKg2iUOoINgz2FF41SFIErOwsjCQKEPgIXgl4hNRcBAgEBAQEBAQICA?= =?us-ascii?q?mkcDIJoLwEBBAcDDC8JAgMBAQEBAQEBTwIPRwEBGAEBAQEDEhERMwcGBQwEAgE?= =?us-ascii?q?IDQQEAQEBAgIGIAICAh8RFQgIAgQBDQUIEweDAIFpAxUBDplIiW+BLhoChwgNg?= =?us-ascii?q?ywFgQuHMIEbF4FCPiZsRoJMglZFBBiBCz4VFYJVMYImAodtCAGTCysJAoYxd4U?= =?us-ascii?q?1coI1gT+HGwMPhV2INoJnY4dJgUMCNYFScBU7gmmGAYoYOm8BAYEUimsBgRALA?= =?us-ascii?q?QE?= X-IronPort-AV: E=Sophos;i="5.53,299,1531800000"; d="scan'208";a="253433247" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 28 Aug 2018 11:06:51 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC04.global.avaya.com) ([135.11.85.15]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Aug 2018 11:06:50 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC04.global.avaya.com ([135.11.85.15]) with mapi id 14.03.0382.000; Tue, 28 Aug 2018 11:06:50 -0400 From: "Mudric, Dusan (Dusan)" <dmudric@avaya.com> To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Lea Roberts <lea.roberts@stanford.edu>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org> CC: "draft-palet-v6ops-rfc6177-bis@ietf.org" <draft-palet-v6ops-rfc6177-bis@ietf.org>, IPv6 Operations <v6ops@ietf.org> Thread-Topic: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt Thread-Index: AQHUPoeW/ny7JdCSBEyCwIsFLEGznKTVQo4g Date: Tue, 28 Aug 2018 15:06:49 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E459CB44E7E@AZ-US1EXMB03.global.avaya.com> References: <153017691583.14743.17000446834856511528@ietfa.amsl.com> <78a36a81-3bb3-9d47-aa06-8da8f7594677@gmail.com> <C040E02F-7BEC-4FF9-8585-BE380B6859DE@consulintel.es> <alpine.DEB.2.02.1807191054090.7979@networking.stanford.edu> <9142206A0C5BF24CB22755C8EC422E459CB44344@AZ-US1EXMB03.global.avaya.com> <f1bc1848-abe0-553e-0fdf-623eb0d1a871@gmail.com> In-Reply-To: <f1bc1848-abe0-553e-0fdf-623eb0d1a871@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/xdhXwrcXVcIsgXGFcj3RTthX2gA> Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 28 Aug 2018 15:07:00 -0000 SGkgQnJpYW4sDQoNClRoZXJlIG11c3QgYSB3YXkgdG8gZGVmaW5lIGhvdyBwcmVmaXhlcyBhcmUg YXNzaWduZWQgdG8gYWx3YXlzIGFsbG93IC80OCwgaWYgbmVlZGVkLiBJZiBub3QgaW4gcmZjNjE3 Ny1iaXMgdGhhbiBpbiBhbm90aGVyIFJGQy4gV2UgaGF2ZSBhbHJlYWR5IG9uZSBsaW1pdGF0aW9u IGZvciBTTEFBQyB0aGF0IG1ha2VzIHN1cmUgZXZlcnkgaG9tZSBnZXRzIGF0IGxlYXN0IG9uZSAv NjQuIFdlIGNhbiBhZGQgYW5vdGhlciBvbmUsIGluIGFub3RoZXIgUkZDLCB0byBtYWtlIHN1cmUg LzQ4IGlzIGdpdmVuIG9uIGEgZGVtYW5kLiBUaGF0IHdpbGwgaW5zdXJlIGZ1dHVyZSBmbGV4aWJp bGl0eSBpbiBhbnkgbmV0d29yayBhbmQgbWFrZSB0aGUgcHJlZml4IGFzc2lnbm1lbnQgbm9uLXBv bGl0aWNhbCBwcm9jZXNzLiANCg0KUmVnYXJkcywNCkR1c2FuLg0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRl ckBnbWFpbC5jb20+DQo+IFNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAyOCwgMjAxOCAxMjoyNyBBTQ0K PiBUbzogTXVkcmljLCBEdXNhbiAoRHVzYW4pIDxkbXVkcmljQGF2YXlhLmNvbT47IExlYSBSb2Jl cnRzDQo+IDxsZWEucm9iZXJ0c0BzdGFuZm9yZC5lZHU+OyBKT1JESSBQQUxFVCBNQVJUSU5FWg0K PiA8am9yZGkucGFsZXQ9NDBjb25zdWxpbnRlbC5lc0BkbWFyYy5pZXRmLm9yZz4NCj4gQ2M6IGRy YWZ0LXBhbGV0LXY2b3BzLXJmYzYxNzctYmlzQGlldGYub3JnOyBJUHY2IE9wZXJhdGlvbnMNCj4g PHY2b3BzQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFm dC1wYWxldC12Nm9wcy1yZmM2MTc3LWJpcy0wMC50eHQNCj4gDQo+IE9uIDIwMTgtMDgtMjggMDY6 MjMsIE11ZHJpYywgRHVzYW4gKER1c2FuKSB3cm90ZToNCj4gPiBTZWN0aW9uIDQuDQo+ID4gIiAg IGIuICBBbiBlbmQtdXNlciBzaG91bGQgYmUgYWJsZSB0byByZWNlaXZlIGFueSBwcmVmaXggbGVu Z3RoIHVwIHRvIC80OA0KPiA+ICAgICAgICBzaW1wbHkgYnkgYXNraW5nLiINCj4gPg0KPiA+IENh biAgdGhpcyBiZSBkZWZpbmVkIGluIGEgd2F5IHRvIG1ha2Ugc3VyZSB0aGF0IG5ldyBhcHBsaWNh dGlvbnMgYW5kDQo+IGRldmljZXMgd2lsbCBhbHdheXMgd29yayBhdCBlbmQgc2l0ZXMgd2l0aG91 dCBhIG5lZWQgZm9yIGFza2luZyBJU1BzIGZvciBleHRyYQ0KPiBhZGRyZXNzIHNwYWNlPyBPdGhl cndpc2UsIHRoZSBlbmQtdXNlciBtaWdodCBub3QgZ2V0IHdoYXQgaGUvc2hlIGFza3MgZm9yLA0K PiB3aXRob3V0IHBheWluZyBmb3IgdGhlICJoaWdoZXIgZ3JhZGUiIHNlcnZpY2UuIENhbiB0aGUg ZGVmaW5pdGlvbiBpbXBvc2UgdXANCj4gdG8gLzQ4IExBUCB3aGVuIG5lZWRlZCBhdCBlbmQgc2l0 ZXM/IEZvciBleGFtcGxlLCBjYW4gYW4gYXBwbGljYXRpb24NCj4gcmVxdWVzdCBhIGhvbWUgcm91 dGVyIHRvIHJlcXVlc3QgYW4gSVNQIGZvciAvNDggcHJlZml4IGFuZCwgd2hlbiByZXF1ZXN0ZWQs DQo+IElTUCBtdXN0IGdyYW50IGl0Pw0KPiANCj4gVW5mb3J0dW5hdGVseSB3ZSBjYW4gbmV2ZXIg c2F5ICJtdXN0IiBpbiB0aGlzIGNvbnRleHQuIFdoYXQgSVNQcyB3aWxsDQo+IHByb3ZpZGUNCj4g Zm9yIHdoYXQgZmVlIGlzIHdlbGwgb3V0c2lkZSB0aGUgSUVURidzIGNvbXBldGVuY2UuIEFzIG9i c2VydmVkIG9uIGFub3RoZXINCj4gdGhyZWFkLCBhcHBsaWNhdGlvbnMgbmVlZCB0byBiZSBhZ2ls ZSwgZXZlbiBpZiB0aGV5IHdvcmsgYmV0dGVyIGlmIHN1Y2ggYQ0KPiByZXF1ZXN0IHdhcyBncmFu dGVkLg0KPiANCj4gSSdkIHNheSB0aGF0IG9uY2UgdGhpcyB1cGRhdGUgaXMgZG9uZSwgaXQgbWF5 IGJlIHRpbWUgdG8gcmV2aXNpdA0KPiBSRkM0MDg0Lg0KPiANCj4gUmVnYXJkcw0KPiAgICAgQnJp YW4NCj4gDQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+IER1c2FuIE11ZHJpYy4NCj4gPg0KPiA+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiB2Nm9wcyA8djZvcHMtYm91bmNl c0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIExlYSBSb2JlcnRzDQo+ID4+IFNlbnQ6IFRodXJzZGF5 LCBKdWx5IDE5LCAyMDE4IDI6MDggUE0NCj4gPj4gVG86IEJyaWFuIEUgQ2FycGVudGVyIDxicmlh bi5lLmNhcnBlbnRlckBnbWFpbC5jb20+OyBKT1JESSBQQUxFVA0KPiA+PiBNQVJUSU5FWiA8am9y ZGkucGFsZXQ9NDBjb25zdWxpbnRlbC5lc0BkbWFyYy5pZXRmLm9yZz4NCj4gPj4gQ2M6IGRyYWZ0 LXBhbGV0LXY2b3BzLXJmYzYxNzctYmlzQGlldGYub3JnOyBJUHY2IE9wZXJhdGlvbnMNCj4gPj4g PHY2b3BzQGlldGYub3JnPg0KPiA+PiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBk cmFmdC1wYWxldC12Nm9wcy1yZmM2MTc3LWJpcy0wMC50eHQNCj4gPj4NCj4gPj4gaGkgQnJpYW4g YW5kIEpvcmRpIC0NCj4gPj4NCj4gPj4gZXhjZWxsZW50IGNvbW1lbnRzIGFuZCBJIGFncmVlIGFs c28uDQo+ID4+DQo+ID4+IHRoYW5rIHlvdSEhDQo+ID4+IC9MZWENCj4gPj4NCj4gPj4gT24gVGh1 LCAxOSBKdWwgMjAxOCwgSk9SREkgUEFMRVQgTUFSVElORVogd3JvdGU6DQo+ID4+DQo+ID4+PiBI aSBCcmlhbiwNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IFRoYW5rcyBhIGxvdCBmb3IgY29t bWVudGluZyBhbmQgc29ycnkgdGhlIGxhdGUgYW5zd2VyIC4uLiB0b28gYnVzeSBsYXN0DQo+ID4+ IHdlZWtzLg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gQ29tbWVudHMgaW4tbGluZSBiZWxv dyAoc3ViamVjdGVkIHRvIG15IGNvLWF1dGhvciBhZ3JlZW1lbnQpLA0KPiBiYXNpY2FsbHksDQo+ ID4+IGFncmVlIHdpdGggYWxsIHlvdXIgaW5wdXRzLCBleGNlcHQgYSBjb3VwbGUgb2YgcG9pbnRz Lg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gVGhhbmtzIQ0KPiA+Pj4NCj4gPj4+DQo+ID4+ Pg0KPiA+Pj4gUmVnYXJkcywNCj4gPj4+DQo+ID4+PiBKb3JkaQ0KPiA+Pj4NCj4gPj4+DQo+ID4+ Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IO+7vy0tLS0tTWVuc2FqZSBvcmln aW5hbC0tLS0tDQo+ID4+Pg0KPiA+Pj4gRGU6IHY2b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3Jn PiBlbiBub21icmUgZGUgQnJpYW4gRSBDYXJwZW50ZXINCj4gPj4gPGJyaWFuLmUuY2FycGVudGVy QGdtYWlsLmNvbT4NCj4gPj4+DQo+ID4+PiBPcmdhbml6YWNpP246IFVuaXZlcnNpdHkgb2YgQXVj a2xhbmQNCj4gPj4+DQo+ID4+PiBGZWNoYTogZG9taW5nbywgOCBkZSBqdWxpbyBkZSAyMDE4LCAx Nzo0Mw0KPiA+Pj4NCj4gPj4+IFBhcmE6IDxkcmFmdC1wYWxldC12Nm9wcy1yZmM2MTc3LWJpc0Bp ZXRmLm9yZz4sIElQdjYgT3BlcmF0aW9ucw0KPiA+PiA8djZvcHNAaWV0Zi5vcmc+DQo+ID4+Pg0K PiA+Pj4gQXN1bnRvOiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1wYWxldC12Nm9wcy1y ZmM2MTc3LWJpcy0wMC50eHQNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ICAgIEhpLA0KPiA+ Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gICAgVGhhbmtzIGZvciB0aGlzIGRyYWZ0Lg0KPiA+Pj4N Cj4gPj4+DQo+ID4+Pg0KPiA+Pj4gICAgPiBBYnN0cmFjdA0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0K PiA+Pj4gICAgVGhpcyBuZWVkcyB0byBiZSBzaG9ydGVyLiBUaHJlZSBwYXJhZ3JhcGhzIGlzIHRv byBtdWNoLg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gRm9yIHRoZSBuZXh0IHZlcnNpb24s IEkndmUgcmVkdWNlZCA1MCUgdGhlIGxlbmd0aCBvZiB0aGUgMXN0IHBhcmFncmFwaC4NCj4gM3Jk DQo+ID4+IHBhcmFncmFwaCwgSSByZWNhbGwgaXMgbWFuZGF0b3J5IChJRE5pdHMpLg0KPiA+Pj4N Cj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAgICA+IC4uLiBwb2xpY3kgc2hvdWxk IHJlZmxlY3QgdGhhdCBhc3NpZ25tZW50IG9mIGEgc2luZ2xlIHN1Ym5ldCBpcw0KPiA+Pj4NCj4g Pj4+ICAgID4gbm8gbG9uZ2VyIGFwcHJvcHJpYXRlIHVubGVzcyB0aGUgcmVjaXBpZW50IGV4cGxp Y2l0bHkgYWdyZWVzIHRvIHRoZQ0KPiA+Pj4NCj4gPj4+ICAgID4gbGltaXRhdGlvbnMgaW1wbGll ZCBieSBzdWNoIGFuIGFzc2lnbm1lbnQuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAgICBJ ICpzdHJvbmdseSogc3VnZ2VzdCBkZWxldGluZyB0aGUgInVubGVzcyIgY2xhdXNlLiBJdCBsZWF2 ZXMgYQ0KPiA+Pj4NCj4gPj4+ICAgIGxvb3Bob2xlLCBhbmQgaXQgY291bGQgZWFzaWx5IGJlIGhp ZGRlbiBpbiBzaHJpbmstd3JhcCB0ZXJtcw0KPiA+Pj4NCj4gPj4+ICAgIGFuZCBjb25kaXRpb25z IHNvIHRoYXQgYSBzdWJzY3JpYmVyIHdvdWxkIGFncmVlIHdpdGhvdXQgZXZlbg0KPiA+Pj4NCj4g Pj4+ICAgIGtub3dpbmcgYWJvdXQgaXQuIFJlZHVjZSB0aGlzIHNpbXBseSB0bzoNCj4gPj4+DQo+ ID4+Pg0KPiA+Pj4NCj4gPj4+ICAgICAgIC4uLiBwb2xpY3kgc2hvdWxkIHJlZmxlY3QgdGhhdCBh c3NpZ25tZW50IG9mIGEgc2luZ2xlIHN1Ym5ldCBpcw0KPiA+Pj4NCj4gPj4+ICAgICAgIG5ldmVy IGFwcHJvcHJpYXRlLg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gQWdyZWVkIGFuZCBkb25l Lg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAgICA+IDEuICBJbnRy b2R1Y3Rpb24NCj4gPj4+DQo+ID4+PiAgICAuLi4uDQo+ID4+Pg0KPiA+Pj4gICAgPiAgICAxLiAg SXQgaXMgZXh0cmVtZWx5IGRpc2NvdXJhZ2VkIHRoYXQgLzEyOHMgYmUgZ2l2ZW4gb3V0LiAgV2hp bGUgdGhlcmUNCj4gPj4+DQo+ID4+PiAgICA+ICAgICAgICBtYXkgYmUgc29tZSBjYXNlcyB3aGVy ZSBhc3NpZ25pbmcgb25seSBhIHNpbmdsZSBhZGRyZXNzIG1heSBiZQ0KPiA+Pj4NCj4gPj4+ICAg ID4gICAgICAgIGp1c3RpZmllZCwgYSBzaXRlLCBieSBkZWZpbml0aW9uLCBpbXBsaWVzIG11bHRp cGxlIHN1Ym5ldHMgYW5kDQo+ID4+Pg0KPiA+Pj4gICAgPiAgICAgICAgbXVsdGlwbGUgZGV2aWNl cy4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ICAgIEkgZmluZCB0aGlzIGEgYml0IHdlYWsu IFRyeToNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ICAgICAgIDEuICBJdCBpcyBleHRyZW1l bHkgZGlzY291cmFnZWQgdGhhdCAvMTI4cyBiZSBnaXZlbiBvdXQuICBXaGlsZSB0aGVyZQ0KPiA+ Pj4NCj4gPj4+ICAgICAgICAgICBtYXkgYmUgc29tZSBhcHBsaWNhdGlvbnMgd2hlcmUgYXNzaWdu aW5nIG9ubHkgYSBzaW5nbGUgYWRkcmVzcw0KPiBtYXkNCj4gPj4gYmUNCj4gPj4+DQo+ID4+PiAg ICAgICAgICAgdG9sZXJhdGVkLCBhIHNpdGUsIGJ5IGRlZmluaXRpb24sIGltcGxpZXMgbXVsdGlw bGUgc3VibmV0cyBhbmQNCj4gPj4+DQo+ID4+PiAgICAgICAgICAgbXVsdGlwbGUgZGV2aWNlcy4g QWxzbywgYSAvMTI4IHByZXZlbnRzIGFueSBmb3JtIG9mIHByaXZhY3ktYmFzZWQNCj4gPj4+DQo+ ID4+PiAgICAgICAgICAgYWRkcmVzc2luZy4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IEFn cmVlZCENCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ICAgID4gICAgNC4gIFRoaXMgcmV2aXNp b24gaGFzIGJlZW4gY3JlYXRlZCB0byBtb3JlIGNsZWFybHkgYXNzZXJ0IHRoZQ0KPiA+Pj4NCj4g Pj4+ICAgID4gICAgICAgIHJlcXVpcmVtZW50IHRvIGVuc3VyZSB0aGF0IGFkZHJlc3MgYXNzaWdu bWVudHMgdG8gZW5kLXNpdGVzDQo+ID4+Pg0KPiA+Pj4gICAgPiAgICAgICAgcHJvdmlkZSBhIHN1 ZmZpY2llbnRseSBiaWcgbnVtYmVyIG9mIHN1Ym5ldHMgKC82NCBvbiBjbGFzc2ljDQo+ID4+Pg0K PiA+Pj4gICAgPiAgICAgICAgbmV0d29ya3MpIHRvIGVhY2ggZW5kLXNpdGUsIHRha2luZyB1bmRl ciBjb25zaWRlcmF0aW9uIHRoZSBlbmQtDQo+ID4+Pg0KPiA+Pj4gICAgPiAgICAgICAgc2l0ZSdz IGZ1dHVyZSBleHBlY3RlZCBuZWVkcywgbmV3IGRlcGxveW1lbnQgZXhwZWN0YXRpb25zIGFuZA0K PiA+PiBuZXcNCj4gPj4+DQo+ID4+PiAgICA+ICAgICAgICBwcm90b2NvbCByZXF1aXJlbWVudHMs IGFtb25nIG90aGVycy4gIE9uY2UgYWxsIHRoZXNlIGFyZQ0KPiA+Pj4NCj4gPj4+ICAgID4gICAg ICAgIGNvbnNpZGVyZWQsIGl0IHNlZW1zIHVubGlrZWx5IHRoYXQgYSBzaW5nbGUgc3VibmV0ICgv NjQpIG9yIGV2ZW4NCj4gPj4+DQo+ID4+PiAgICA+ICAgICAgICBhIHNtYWxsIG51bWJlciBvZiB0 aGVtIHNob3VsZCBiZSBhc3NpZ25lZCwgdW5sZXNzIHZlcnkgY2xlYXJseQ0KPiA+Pj4NCj4gPj4+ ICAgID4gICAgICAgIGp1c3RpZmllZCBhbmQgYWdyZWVkIHRvIGJ5IHRoZSBlbmQtc2l0ZS4NCj4g Pj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ICAgIFRoZSAidW5sZXNzIiBjbGF1c2UgaXMgZGFuZ2Vy b3VzIGJlY2F1c2Ugb2Ygc2hyaW5rLXdyYXAgdGVybXMgYW5kDQo+ID4+Pg0KPiA+Pj4gICAgY29u ZGl0aW9ucy4gSSBzdWdnZXN0IGRlbGV0aW5nIGl0Lg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+ Pj4gQWdyZWVkIQ0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gICAgPiAyLiAgQ29uc2lkZXJh dGlvbnMgUmVnYXJkaW5nIHRoZSBQcmVmaXggTGVuZ3RoDQo+ID4+Pg0KPiA+Pj4gICAgLi4uLg0K PiA+Pj4NCj4gPj4+ICAgID4gICAgVGhpcyBjb25zaWRlcmF0aW9uIHNob3VsZCBiZSBub3RpY2Vk LCBhY3Jvc3MgdGhpcyBkb2N1bWVudCwgaW4gdGhlDQo+ID4+Pg0KPiA+Pj4gICAgPiAgICBzZW5z ZSB0aGF0IGVuZC1zaXRlcyB1c3VhbGx5IGhhdmUgc3VibmV0cyB0aGF0IHVzZSwgYnkgZGVmYXVs dCwNCj4gPj4+DQo+ID4+PiAgICA+ICAgIFNMQUFDLCBhbmQgY29uc2VxdWVudGx5LCB0aGUgTEFQ IGlzIG1hbmRhdG9yaWx5IGEgLzY0LiAgT3RoZXINCj4gPj4+DQo+ID4+PiAgICA+ICAgIHRlY2hu b2xvZ2llcywgbWF5IGhhdmUgYSBkaWZmZXJlbnQgTEFQLCB3aGljaCBtdXN0IGJlIHVzZWQNCj4g Pj4+DQo+ID4+PiAgICA+ICAgIGFjY29yZGluZ2x5Lg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+ Pj4gICAgSSBzdWdnZXN0IHMvT3RoZXIvRnV0dXJlLyBzaW5jZSAvNjQgcHJldmFpbHMgZXZlcnl3 aGVyZSB0b2RheS4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IEFncmVlZCENCj4gPj4+DQo+ ID4+Pg0KPiA+Pj4NCj4gPj4+ICAgID4gMy4gIE9uIC80OCBBc3NpZ25tZW50cyB0byBFbmQtU2l0 ZXMNCj4gPj4+DQo+ID4+PiAgICAuLi4uDQo+ID4+Pg0KPiA+Pj4gICAgPiAgICBBbiBpbXBvcnRh bnQNCj4gPj4+DQo+ID4+PiAgICA+ICAgIGdvYWwgaW4gSVB2NiBpcyB0byBzaWduaWZpY2FudGx5 IGNoYW5nZSB0aGUgZGVmYXVsdCBhbmQgbWluaW1hbCBlbmQNCj4gPj4+DQo+ID4+PiAgICA+ICAg IHNpdGUgYXNzaWdubWVudCwgZnJvbSAiYSBzaW5nbGUgYWRkcmVzcyIgdG8gIm11bHRpcGxlIG5l dHdvcmtzIiBhbmQNCj4gPj4+DQo+ID4+PiAgICA+ICAgIHRvIGVuc3VyZSB0aGF0IGVuZC1zaXRl cyBjYW4gZWFzaWx5IG9idGFpbiBhZGRyZXNzIHNwYWNlLg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0K PiA+Pj4gICAgSSBzdWdnZXN0IGFkZGluZyBzb21ldGhpbmcgbGlrZSB0aGlzOg0KPiA+Pj4NCj4g Pj4+DQo+ID4+Pg0KPiA+Pj4gICAgQXMgdGhlIG9wZXJhdGlvbmFsIGNvc3RzIG9mIGNhcnJpZXIt Z3JhZGUgTkFUIGFuZCBhZGRyZXNzK3BvcnQgc2hhcmluZw0KPiA+Pj4NCj4gPj4+ICAgIGhhdmUg c2hvd24sIGF2YWlsYWJpbGl0eSBvZiBtdWx0aXBsZSBhZGRyZXNzZXMgYW5kIHByZWZpeGVzIHRv IGVuZCBzaXRlcw0KPiA+Pj4NCj4gPj4+ICAgIHRoYXQgbmVlZCB0aGVtIHdpbGwgYmUgYSBjb25z aWRlcmFibGUgc2F2aW5nIHRvIHRoZWlyIElTUHMuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+ PiBBZ3JlZWQhDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAgICA+ICAgIEl0IG1pZ2h0IGJl IHRlbXB0aW5nIHRvIGdpdmUgaG9tZSBzaXRlcyBhIHNpbmdsZSAvNjQsIHNpbmNlIHRoYXQgaXMN Cj4gPj4+DQo+ID4+PiAgICA+ICAgIGFscmVhZHkgc2lnbmlmaWNhbnRseSBtb3JlIGFkZHJlc3Mg c3BhY2UgY29tcGFyZWQgd2l0aCB0b2RheSdzDQo+IElQdjQNCj4gPj4+DQo+ID4+PiAgICA+ICAg IHByYWN0aWNlLiAgSG93ZXZlciwgdGhpcyBwcmVjbHVkZXMgdGhlIGV4cGVjdGF0aW9uIHRoYXQg ZXZlbiBob21lDQo+ID4+Pg0KPiA+Pj4gICAgPiAgICBzaXRlcyB3aWxsIGdyb3cgdG8gc3VwcG9y dCBtdWx0aXBsZSBzdWJuZXRzIGdvaW5nIGZvcndhcmQuICBIZW5jZSwgaXQNCj4gPj4+DQo+ID4+ Pg0KPiA+Pj4NCj4gPj4+ICAgIHMvZXhwZWN0YXRpb24vY2VydGFpbnR5Lw0KPiA+Pj4NCj4gPj4+ DQo+ID4+Pg0KPiA+Pj4gQWdyZWVkIQ0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gICAgLi4u Lg0KPiA+Pj4NCj4gPj4+ICAgID4gICAgQSBrZXkgZ29hbCBvZiB0aGUgcmVjb21tZW5kYXRpb25z IGluIFtSRkMzMTc3XSBpcyB0bw0KPiA+Pj4NCj4gPj4+ICAgID4gICAgZW5zdXJlIHRoYXQgdXBv biByZW51bWJlcmluZywgb25lIGRvZXMgbm90IGhhdmUgdG8gZGVhbCB3aXRoDQo+ID4+Pg0KPiA+ Pj4gICAgPiAgICByZW51bWJlcmluZyBpbnRvIGEgc21hbGxlciBzdWJuZXQgc2l6ZS4NCj4gPj4+ DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ICAgIFBlcmhhcHMgYWRkOg0KPiA+Pj4NCj4gPj4+DQo+ID4+ Pg0KPiA+Pj4gICAgSW4gcGFydGljdWxhciB0aGlzIHdvdWxkIGFwcGx5IHRvIGFueSBzaXRlIHRo YXQgc3dpdGNoZXMgdG8NCj4gPj4+DQo+ID4+PiAgICBhbiBJU1AgdGhhdCBwcm92aWRlcyBhIGxv bmdlciBwcmVmaXguDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBBZ3JlZWQhDQo+ID4+Pg0K PiA+Pj4NCj4gPj4+DQo+ID4+PiAgICA+ICAgIEl0IHNob3VsZCBiZSBub3RlZCB0aGF0IHNpbWls YXIgYXJndW1lbnRzIGFwcGx5IHRvIHRoZSBtYW5hZ2VtZW50DQo+IG9mDQo+ID4+Pg0KPiA+Pj4g ICAgPiAgICB6b25lIGZpbGVzIGluIHRoZSBETlMuICBJbiBwYXJ0aWN1bGFyLCBtYW5hZ2luZyB0 aGUgcmV2ZXJzZQ0KPiA+Pj4NCj4gPj4+ICAgID4gICAgKGlwNi5hcnBhKSB0cmVlIGlzIHNpbXBs aWZpZWQgd2hlbiBhbGwgbGlua3MgYXJlIG51bWJlcmVkIHVzaW5nIHRoZQ0KPiA+Pj4NCj4gPj4+ ICAgID4gICAgc2FtZSBzdWJuZXQgaWRzDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAgICBz L251bWJlcmVkL3JlbnVtYmVyZWQvDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBBZ3JlZWQh DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAgICAuLi4uDQo+ID4+Pg0KPiA+Pj4gICAgPiAg ICB5ZWFycywgYW5kIHdlIGRvbid0IHJlY292ZXIgYmFjayB0aGUgLzQ4J3MsIHdlIHdpbGwgYmUg YWJsZSB0byB1c2UNCj4gPj4+DQo+ID4+PiAgICA+ICAgIElQdjYgYWRkcmVzc2luZyBzcGFjZSBm b3Igb3ZlciAxMDAuMDAwIHllYXJzLg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gICAgUGVy aGFwcyBhZGQ6DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAgICBUaGlzIGRvY3VtZW50IGRv ZXMgbm90IGFkdm9jYXRlIGNhcmVsZXNzIHVzZSBvZiBhZGRyZXNzIHNwYWNlLCBidXQNCj4gPj4+ DQo+ID4+PiAgICB0aGVyZSBpcyBvYmplY3RpdmVseSBubyByZWFzb24gdG8gYmUgcmVzdHJpY3R2 ZS4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IEFncmVlZCENCj4gPj4+DQo+ID4+Pg0KPiA+ Pj4NCj4gPj4+ICAgIC4uLi4NCj4gPj4+DQo+ID4+PiAgICA+ICAgIFRvZGF5IHR5cGljYWxseSwg YSBob21lIGhhcyBhbHJlYWR5IGEgY29uc2lkZXJhYmxlIG51bWJlciBvZg0KPiBwb3NzaWJsZQ0K PiA+Pj4NCj4gPj4+ICAgID4gICAgc3VibmV0cyAoYSBjb21tb24gQ0UgaGFzIDQgTEFOIHBvcnRz LCAyIFdpRmkgcmFkaW9zIHdoaWNoIHN1cHBvcnQNCj4gPj4+DQo+ID4+PiAgICA+ICAgIHNldmVy YWwgU1NJRHMgZWFjaCBvbmUsIFZvSVAgc3VibmV0LCBJUFRWIHN1Ym5ldCwgYWRkaXRpb25hbA0K PiBWTEFOcykNCj4gPj4+DQo+ID4+PiAgICA+ICAgIGFuZCBpZiBkb3duc3RyZWFtIHJvdXRlcnMg YXJlIHVzZWQsIHRoZXJlIGlzIGEgbmVlZCBmb3IgZnVydGhlcg0KPiA+Pj4NCj4gPj4+ICAgID4g ICAgc3VibmV0cy4gIFRoaXMgbWVhbnMgdGhhdCBpbiBhIHNob3J0IHRlcm0sIGFzc2lnbmluZyBh IC82MCAoMTYNCj4gPj4+DQo+ID4+PiAgICA+ICAgIHN1Ym5ldHMpLCBpdCBpcyBhbHJlYWR5IGEg cmVhbGx5IGJhZCBkZWNpc2lvbiwgYXMgaXQgbWF5IGVuZm9yY2UgSVB2Ng0KPiA+Pj4NCj4gPj4+ ICAgID4gICAgTkFUIGJldHdlZW4gdGhlIG1haW4gQ0UgYW5kIGRvd25zdHJlYW0gcm91dGVycy4N Cj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ICAgIEkgc3VnZ2VzdCBkZWxldGluZyAiYXMgaXQg bWF5IGVuZm9yY2UgSVB2NiBOQVQgYmV0d2VlbiB0aGUgbWFpbiBDRQ0KPiBhbmQNCj4gPj4+DQo+ ID4+PiAgICBkb3duc3RyZWFtIHJvdXRlcnMiLiBGaXJzdGx5IGl0IHB1dHMgTkFUIGludG8gdGhl IHJlYWRlcidzIG1pbmQuDQo+IFNlY29uZGx5LA0KPiA+Pj4NCj4gPj4+ICAgIGl0IGlzbid0IHRo ZSBvbmx5IHNvbHV0aW9uIC0gSUlEcyBzaG9ydGVyIHRoYW4gNjQgY291bGQgYWxzbyBiZQ0KPiBp bXBsZW1lbnRlZC4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IEFncmVlZCENCj4gPj4+DQo+ ID4+Pg0KPiA+Pj4NCj4gPj4+ICAgID4gNC4gIEltcGFjdCBvbiBJUHY2IFN0YW5kYXJkcw0KPiA+ Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gICAgSSBwcm9wb3NlIHRvIHNpbXBseSBkZWxldGUgdGhp cyBzZWN0aW9uLg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gICAgRmlyc3RseSwgUkZDMzA1 NiBpcyBkZXByZWNhdGVkIHNvIGl0J3MgaXJyZWxldmFudCB0b2RheS4NCj4gPj4+DQo+ID4+PiAg ICBTZWNvbmRseSwgdGhlIGFyZ3VtZW50IGFib3V0IFVMQXMgKFJGQzQxOTMpIGRvZXNuJ3QgaG9s ZCB1cC4NCj4gPj4+DQo+ID4+PiAgICBVTEFzIGFyZSBsaWtlIGFueSBvdGhlciAvNDggcHJlZml4 IC0gaWYgeW91IGFyZSBmb3JjZWQgdG8NCj4gPj4+DQo+ID4+PiAgICByZW51bWJlciBpbnRvIGEg bG9uZ2VyIHByZWZpeCwgeW91IGxvc2Ugc29tZSBzdWJuZXQgYml0cy4NCj4gPj4+DQo+ID4+PiAg ICBUaGF0IGlzIGFscmVhZHkgY292ZXJlZCBpbiB0aGUgbWlkZGxlIG9mIHNlY3Rpb24gMyAodGhl DQo+ID4+Pg0KPiA+Pj4gICAgImtleSBnb2FsIiBzZW50ZW5jZSBxdW90ZWQgYWJvdmUpLg0KPiA+ Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBJIHJlY2FsbCB3ZSBkZXByZWNh dGVkIHRoZSA2dG80IGFueWNhc3QsIGJ1dCBub3QgNnRvNCwgaW4gZmFjdCA2dG80IHRvIDZ0bzQN Cj4gPj4gdHJhZmZpYyBpcyBzdGlsbCB1c2VmdWwgZm9yIHBlZXIgdG8gcGVlci4NCj4gPj4+DQo+ ID4+Pg0KPiA+Pj4NCj4gPj4+ICAgID4gNi4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQo+ID4+ Pg0KPiA+Pj4gICAgPg0KPiA+Pj4NCj4gPj4+ICAgID4gICAgVGhpcyBkb2N1bWVudCBoYXMgbm8g a25vd24gc2VjdXJpdHkgaW1wbGljYXRpb25zLg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4g ICAgUmVhbGx5PyBNb3JlIHByZWZpeCBzcGFjZSBvZmZlcnMgbW9yZSBwb3RlbnRpYWwgZm9yIHNj YW5uaW5nDQo+ID4+Pg0KPiA+Pj4gICAgYXR0YWNrcy4gTW9yZSBwcmVmaXggc3BhY2UgYWxzbyBh bGxvd3MgdGhlIHVzZSBvZiBzbGlnaHRseQ0KPiA+Pj4NCj4gPj4+ICAgIHJhbmRvbWl6ZWQgcHJl Zml4ZXMgYW5kL29yIHByZWZpeC1wZXIgaG9zdC4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ ICAgIEFsc28gb2YgY291cnNlLCBhIC8xMjggd291bGQgcHJldmVudCBhbnkgZm9ybSBvZiBwcml2 YWN5LWJhc2VkDQo+ID4+Pg0KPiA+Pj4gICAgYWRkcmVzc2luZy4NCj4gPj4+DQo+ID4+Pg0KPiA+ Pj4NCj4gPj4+IEkndmUgaW50cm9kdWNlZCBuZXcgdGV4dCBvbiB0aG9zZSBwb2ludHMuDQo+ID4+ Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAgICA+IDguICBBY2tub3dsZWRnZW1lbnRzDQo+ID4+Pg0K PiA+Pj4gICAgPg0KPiA+Pj4NCj4gPj4+ICAgID4gICAgVGhlIGF1dGhvcnMgb2YgdGhpcyBkb2N1 bWVudCB3aWxsIGxpa2UgdG8gYWNrbm93bGVkZ2UgdGhlIGF1dGhvcnMNCj4gb2YNCj4gPj4+DQo+ ID4+PiAgICA+ICAgIHByZXZpb3VzIHZlcnNpb25zIChUaG9tYXMgTmFydGVuIGFuZCBHZW9mZiBI dXN0b24pDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAgICBSRkMzMTc3IHdhcyBzaWduZWQg YnkgdGhlIHdob2xlIElBQiBhbmQgSUVTRyBzZWF0ZWQgaW4gMjAwMSwgYW5kIGl0cw0KPiA+Pj4N Cj4gPj4+ICAgIEFja25vd2xlZGdlbWVudHMgcmVhZDoNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4g Pj4+ICAgID4+ICAgIFRoaXMgZG9jdW1lbnQgb3JpZ2luYXRlZCBmcm9tIHRoZSBJRVRGIElQdjYg ZGlyZWN0b3JhdGUsIHdpdGgNCj4gbXVjaA0KPiA+Pj4NCj4gPj4+ICAgID4+ICAgIGlucHV0IGZy b20gdGhlIElBQiBhbmQgSUVTRy4gIFRoZSBvcmlnaW5hbCB0ZXh0IGZvcm1pbmcgdGhlIGJhc2lz IG9mDQo+ID4+Pg0KPiA+Pj4gICAgPj4gICAgdGhpcyBkb2N1bWVudCB3YXMgY29udHJpYnV0ZWQg YnkgRnJlZCBCYWtlciBhbmQgQnJpYW4gQ2FycGVudGVyLg0KPiA+Pj4NCj4gPj4+ICAgID4+ICAg IEFsbGlzb24gTWFua2luIGFuZCBUaG9tYXMgTmFydGVuIG1lcmdlZCB0aGUgb3JpZ2luYWwNCj4g Y29udHJpYnV0aW9ucw0KPiA+Pj4NCj4gPj4+ICAgID4+ICAgIGludG8gYSBzaW5nbGUgZG9jdW1l bnQsIGFuZCBBbGFpbiBEdXJhbmQgZWRpdGVkIHRoZSBkb2N1bWVudA0KPiA+PiB0aHJvdWdoDQo+ ID4+Pg0KPiA+Pj4gICAgPj4gICAgaXRzIGZpbmFsIHN0YWdlcy4NCj4gPj4+DQo+ID4+Pg0KPiA+ Pj4NCj4gPj4+IEFncmVlZCENCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ICAgIFJlZ2FyZHMN Cj4gPj4+DQo+ID4+PiAgICAgICAgQnJpYW4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ICAg IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pg0K PiA+Pj4gICAgdjZvcHMgbWFpbGluZyBsaXN0DQo+ID4+Pg0KPiA+Pj4gICAgdjZvcHNAaWV0Zi5v cmcNCj4gPj4+DQo+ID4+PiAgICBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtDQo+ID4+DQo+IDNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb192 Nm9wcyZkPUR3SURhUSZjPUJGcFdRdzhic3VLcA0KPiA+PiBsMVNnaVpINjRRJnI9VVQzQms5Y2JM ZWFKeGhmM2lDcmhJb1VXQjhZTFpVMjMwMjlzTVFHUTJrWSZtPS0NCj4gPj4NCj4gNXJnWXFfbllN YlNIMkhYSG5IRkNGaTJLRFl6T0NsaFNpTG4wYXU4V3UwJnM9aUVxMXRVRGJlUUw0ZjNTTE0NCj4g Pj4gZjEteGloakpZVDBLQUFOX0JXVGw5LTc3OWMmZT0NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4g Pj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioNCj4gPj4+IElQdjQgaXMgb3Zlcg0KPiA+Pj4gQXJlIHlvdSByZWFkeSBm b3IgdGhlIG5ldyBJbnRlcm5ldCA/DQo+ID4+PiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cC0NCj4gPj4NCj4gM0FfX3d3dy5jb25zdWxpbnRlbC5lcyZkPUR3 SURhUSZjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmcj1VVDMNCj4gPj4gQms5Y2JMZWFKeGhmM2lD cmhJb1VXQjhZTFpVMjMwMjlzTVFHUTJrWSZtPS0NCj4gPj4NCj4gNXJnWXFfbllNYlNIMkhYSG5I RkNGaTJLRFl6T0NsaFNpTG4wYXU4V3UwJnM9R01STGRJdEY4eUtiVWRFOQ0KPiA+PiBOdVhFLVU0 OHVrN09ITnVFaWp5bTlqaEUtLXMmZT0NCj4gPj4+IFRoZSBJUHY2IENvbXBhbnkNCj4gPj4+DQo+ ID4+PiBUaGlzIGVsZWN0cm9uaWMgbWVzc2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBt YXkgYmUgcHJpdmlsZWdlZCBvcg0KPiA+PiBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1hdGlvbiBp cyBpbnRlbmRlZCB0byBiZSBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YNCj4gdGhlDQo+ID4+IGlu ZGl2aWR1YWwocykgbmFtZWQgYWJvdmUgYW5kIGZ1cnRoZXIgbm9uLWV4cGxpY2lsdHkgYXV0aG9y aXplZA0KPiBkaXNjbG9zdXJlLA0KPiA+PiBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9m IHRoZSBjb250ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uLCBldmVuIGlmDQo+ID4+IHBhcnRpYWxs eSwgaW5jbHVkaW5nIGF0dGFjaGVkIGZpbGVzLCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCB3 aWxsIGJlDQo+IGNvbnNpZGVyZWQgYQ0KPiA+PiBjcmltaW5hbCBvZmZlbnNlLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGJlIGF3YXJlIHRoYXQgYW55DQo+ID4+IGRpc2Ns b3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRo aXMgaW5mb3JtYXRpb24sDQo+ID4+IGV2ZW4gaWYgcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNo ZWQgZmlsZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQsIHdpbGwgYmUNCj4gPj4gY29uc2lkZXJl ZCBhIGNyaW1pbmFsIG9mZmVuc2UsIHNvIHlvdSBtdXN0IHJlcGx5IHRvIHRoZSBvcmlnaW5hbCBz ZW5kZXIgdG8NCj4gPj4gaW5mb3JtIGFib3V0IHRoaXMgY29tbXVuaWNhdGlvbiBhbmQgZGVsZXRl IGl0Lg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiA+Pj4g djZvcHNAaWV0Zi5vcmcNCj4gPj4+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0NCj4gPj4NCj4gM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZv X3Y2b3BzJmQ9RHdJRGFRJmM9QkZwV1F3OGJzdUtwDQo+ID4+IGwxU2dpWkg2NFEmcj1VVDNCazlj YkxlYUp4aGYzaUNyaElvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09LQ0KPiA+Pg0KPiA1cmdZcV9u WU1iU0gySFhIbkhGQ0ZpMktEWXpPQ2xoU2lMbjBhdThXdTAmcz1pRXExdFVEYmVRTDRmM1NMTQ0K PiA+PiBmMS14aWhqSllUMEtBQU5fQldUbDktNzc5YyZlPQ0KDQo= From nobody Tue Aug 28 08:12:54 2018 Return-Path: <dmudric@avaya.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D175130DE5 for <v6ops@ietfa.amsl.com>; Tue, 28 Aug 2018 08:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 dWVpGtQQWzbS for <v6ops@ietfa.amsl.com>; Tue, 28 Aug 2018 08:12:51 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.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 3F6A4130DD9 for <v6ops@ietf.org>; Tue, 28 Aug 2018 08:12:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2HwAADTZYVb/wUHmMZaGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJ6VWV/KAqYIoINl2U7CyMJAoQ+AoJ1ITgUAQIBAQEBAQECAgJ?= =?us-ascii?q?pHAyCaC8BAQQHAwwvCQIDAQEBAQEBAU8CD0cBARgBAQEBAgESKDQQBwQCAQgNB?= =?us-ascii?q?AQBAQsUEDIdCAEBBAESCAwOgwCBeQgBDplFix0aAopBBYlWF4FCPoESRoJMgxs?= =?us-ascii?q?EGIFJgzCCJgKbLAkChjGJU4haA4Vsix2ILIFYIoFScBU7gmmCJReDRYpSb4EWi?= =?us-ascii?q?msBgRsBAQ?= X-IPAS-Result: =?us-ascii?q?A2HwAADTZYVb/wUHmMZaGQEBAQEBAQEBAQEBAQcBAQEBAYJ?= =?us-ascii?q?6VWV/KAqYIoINl2U7CyMJAoQ+AoJ1ITgUAQIBAQEBAQECAgJpHAyCaC8BAQQHA?= =?us-ascii?q?wwvCQIDAQEBAQEBAU8CD0cBARgBAQEBAgESKDQQBwQCAQgNBAQBAQsUEDIdCAE?= =?us-ascii?q?BBAESCAwOgwCBeQgBDplFix0aAopBBYlWF4FCPoESRoJMgxsEGIFJgzCCJgKbL?= =?us-ascii?q?AkChjGJU4haA4Vsix2ILIFYIoFScBU7gmmCJReDRYpSb4EWimsBgRsBAQ?= X-IronPort-AV: E=Sophos;i="5.53,299,1531800000"; d="scan'208";a="295459632" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 28 Aug 2018 11:12:49 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC04.global.avaya.com) ([135.11.85.15]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Aug 2018 11:12:48 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC04.global.avaya.com ([135.11.85.15]) with mapi id 14.03.0382.000; Tue, 28 Aug 2018 11:12:47 -0400 From: "Mudric, Dusan (Dusan)" <dmudric@avaya.com> To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Ron Bonica <rbonica@juniper.net>, "v6ops@ietf.org" <v6ops@ietf.org> Thread-Topic: [v6ops] draft-palet-v6ops-rfc6177-bis Thread-Index: AdQ+ERSkgrY6L5QoTzWBeUJlAjTblQAngKOAAAyJdZA= Date: Tue, 28 Aug 2018 15:12:46 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E459CB44EA3@AZ-US1EXMB03.global.avaya.com> References: <CO1PR05MB443BFFA74AAEB374E38BD8FAE0B0@CO1PR05MB443.namprd05.prod.outlook.com> <80ec965c-4a6c-3cc8-b92f-ad03603f9223@gmail.com> In-Reply-To: <80ec965c-4a6c-3cc8-b92f-ad03603f9223@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/KXwLRdQR95xgAodhwiT1mrtQres> Subject: Re: [v6ops] draft-palet-v6ops-rfc6177-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 28 Aug 2018 15:12:53 -0000 > Current RIR policies still allow using /48, but leave the decision in = the > hands of the ISP Decision like this should not be in anybody's hands. /48 should be given au= tomatically, when needed. Dusan > -----Original Message----- > From: v6ops <v6ops-bounces@ietf.org> On Behalf Of Brian E Carpenter > Sent: Tuesday, August 28, 2018 1:11 AM > To: Ron Bonica <rbonica@juniper.net>; v6ops@ietf.org > Subject: Re: [v6ops] draft-palet-v6ops-rfc6177-bis >=20 > Hi, >=20 > I fully support this draft. Here are a few (minor) wording issues > and some nits. >=20 > Issues: > ------- > > [RFC3177] called for a default end-site IPv6 assignment size of /48. > > Subsequently, the Regional Internet Registries (RIRs) developed and > > adopted IPv6 address assignment and allocation policies consistent > > with those recommendations, and it triggered the development of > > [RFC6177]. However, some of the RIRs, have later on updated those > > policies, which still allow using /48, but leave the decision in the > > hands of the ISP, or even, in some cases, encourage the assignment o= f > > smaller (e.g., /56) blocks to residential end-sites, while keeping > > /48 for business. >=20 > I don't think that is accurate. Actually there was push-back *from* > the RIRs against the wording of 3177, because some ISPs did not wish > to be consistent with it. Here's another version: >=20 > [RFC3177] called for a default end-site IPv6 assignment size of /48. > Subsequently, the Regional Internet Registries (RIRs) developed and > adopted IPv6 address assignment and allocation policies consistent > with ISP practices, and this triggered the development of [RFC6177]. > Current RIR policies still allow using /48, but leave the decision in = the > hands of the ISP, or even, in some cases, endorse the assignment of > smaller (e.g., /56) blocks to residential end-sites, while keeping > /48 for business. >=20 > > This raises the question of a possible misinterpretation of [RFC6177= ] > > by at least 1/3rd of the operational community and consequently, the > > need to revisit it. >=20 > No, I don't think there's any misinterpretation. I think it's quite > clear (as in my previous comment) that this is exactly why the ISP > community pushed for RFC6177. I think we should phrase this a bit > differently. >=20 > This raises the question of over-zealous interpretation of [RFC6177] > by at least one third of the ISP community and consequently, the > need to revisit it. >=20 > > It might be tempting to give home sites a single /64, since that is > > already significantly more address space compared with today's IPv4 > > practice. However, this precludes the certainty that even home site= s > > will grow to support multiple subnets going forward. Hence, it is > > strongly intended that even home sites be given a big number of > > subnets worth of space, by default. Hence, this document still > > recommends giving home sites significantly many more than a single > > /64. >=20 > I think a reference to RFC7368 and RFC7788 would be useful here, to make > it clear that this is not guesswork. (Note that HNCP is mentioned later, > so there is a little repetition in the argument.) >=20 > Nits: > ----- >=20 > > Abstract > > > > The Regional Internet Registries (RIRs) policies, have different > Delete the comma >=20 > > requires an ever-increasing availability of subnets at the end-site > > and so, policy should reflect that assignment of a single subnet is >=20 > NEW > requires an ever-increasing availability of subnets at the end-site, > so policy should reflect that the assignment of a single subnet is >=20 > I see a number of other minor syntax and punctuation nits in the > text, but I'm afraid I'm going to leave those for the copy-editor. >=20 > Regards, > Brian >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwICAg&c=3DBFpWQw8bsuKpl > 1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3DYd3D > j3oVG2HTAJSudmciO1QwxdBm5v8tty3i7nRVEE8&s=3DMyBUglnUbBkNpooKN- > YKnbJrsKVzg92HOWY-ZK_4RMU&e=3D From nobody Tue Aug 28 10:56:49 2018 Return-Path: <farmer@umn.edu> 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 443E9128CB7 for <v6ops@ietfa.amsl.com>; Tue, 28 Aug 2018 10:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_MED=-2.3, 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=umn.edu 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 4kgOXJCoPR9n for <v6ops@ietfa.amsl.com>; Tue, 28 Aug 2018 10:56:43 -0700 (PDT) Received: from mta-p7.oit.umn.edu (mta-p7.oit.umn.edu [134.84.196.207]) (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 489BA12872C for <v6ops@ietf.org>; Tue, 28 Aug 2018 10:56:43 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p7.oit.umn.edu (Postfix) with ESMTP id 8CC8B981 for <v6ops@ietf.org>; Tue, 28 Aug 2018 17:56:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p7.oit.umn.edu ([127.0.0.1]) by localhost (mta-p7.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRwTlXPh8-5q for <v6ops@ietf.org>; Tue, 28 Aug 2018 12:56:42 -0500 (CDT) Received: from mail-ua1-f72.google.com (mail-ua1-f72.google.com [209.85.222.72]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p7.oit.umn.edu (Postfix) with ESMTPS id 02C5CE47 for <v6ops@ietf.org>; Tue, 28 Aug 2018 12:56:41 -0500 (CDT) Received: by mail-ua1-f72.google.com with SMTP id g19-v6so926701uan.14 for <v6ops@ietf.org>; Tue, 28 Aug 2018 10:56:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YrY6UzzhaRCg/V0g3OaCZ7R/bhPSy2uMnG6HQV8h0aw=; b=bCDuJwdgbgSy5Cdod1kIu8ZnI80GrLNW4wzRO3Igq3hty1KFnLGXn3IJhBHeHmPGpW 17V4jfAIGdbI4HOZXramfgrD8rzFtRnLZrJD7k37nwCpvQwTHQ3cz4u8pCCes1UrkRKo CMHZh6YjVerHTHShkHY0zC/GHHmOMN0KRFOA8aC3ORpmHTVC267a9Y3HF4VzKqFxTCPX wSQkHfp0nwY1PRLLC5GNzcgBYirNJ2E5yvpNowJYjvuG47fjhAL2ARD28l87hn4HAP5A hA1ZlplyB0QK3orWdKwzg3FnZOwFd6xvOAthPuy+xGGxIw/PFGvwkKfaq67FWs8WeO3H 1/lg== 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=YrY6UzzhaRCg/V0g3OaCZ7R/bhPSy2uMnG6HQV8h0aw=; b=FTxUo42ZVTmXIJGVuPHsY3uRguVqQ9ahu1EoV47hKgmiD/KrbD/sOCLdDhosWjYhXx 5Xs4jVOQIhQdVGEmsRmw1sT08xIlRS/twvoQ3f0IyVi42gSQBItMai/VAxyX/CKDqEQc cxZdyBDjQwTPnAusJWLQBZU0YV4uTE0+PR1nZEDQyJSwG53Ir0DMt3yH1WFvAVjfrkwW 8CWaEmGBLWblY3HRzUXRyDeX/vwAWqm/6KlI2OTnntVvr6uPqRXiEygvhGzEZWX/5izf EXNvKB6ZJhW86mrTwx3PCkICuegf+V3bBVx1jl4QcdoPtMt/ek/wHv+88Z8Vv1PcBBJE VOxA== X-Gm-Message-State: APzg51C8VLxAzJqwqu6MeVFUr3TiD4ZtQ0evtPGSdokZcBcjZcQnBKE/ IECcqdYsmRh1KZA2Y8VndTCaXs7srnkLOvl0GQGkERc6gYk+HGBG3QkQoaqpd/mODpRkC6CTyFX yjKExXomvWUtkpZmziCVPDnRV0A== X-Received: by 2002:a1f:8c8c:: with SMTP id o134-v6mr1660009vkd.79.1535478999771; Tue, 28 Aug 2018 10:56:39 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYMDyMEyrpSKsgsvjBKKbDp6mU2rCI3wXwQmvVHuVBaKpLuTV79cSDCVq+ulXlAK6Fvy8uZgQQOtKyl7TiToFU= X-Received: by 2002:a1f:8c8c:: with SMTP id o134-v6mr1659983vkd.79.1535478999244; Tue, 28 Aug 2018 10:56:39 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a67:3bc7:0:0:0:0:0 with HTTP; Tue, 28 Aug 2018 10:56:38 -0700 (PDT) In-Reply-To: <9142206A0C5BF24CB22755C8EC422E459CB44E7E@AZ-US1EXMB03.global.avaya.com> References: <153017691583.14743.17000446834856511528@ietfa.amsl.com> <78a36a81-3bb3-9d47-aa06-8da8f7594677@gmail.com> <C040E02F-7BEC-4FF9-8585-BE380B6859DE@consulintel.es> <alpine.DEB.2.02.1807191054090.7979@networking.stanford.edu> <9142206A0C5BF24CB22755C8EC422E459CB44344@AZ-US1EXMB03.global.avaya.com> <f1bc1848-abe0-553e-0fdf-623eb0d1a871@gmail.com> <9142206A0C5BF24CB22755C8EC422E459CB44E7E@AZ-US1EXMB03.global.avaya.com> From: David Farmer <farmer@umn.edu> Date: Tue, 28 Aug 2018 12:56:38 -0500 Message-ID: <CAN-Dau2AcL-UvE94tndCfe1aQQ77SEPQ=SxawoJZDUK+bta8vg@mail.gmail.com> To: "Mudric, Dusan (Dusan)" <dmudric@avaya.com> Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Lea Roberts <lea.roberts@stanford.edu>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>, "draft-palet-v6ops-rfc6177-bis@ietf.org" <draft-palet-v6ops-rfc6177-bis@ietf.org>, IPv6 Operations <v6ops@ietf.org> Content-Type: multipart/alternative; boundary="0000000000004f79b705748290d8" Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/1a19AeX9CNtB24UVFxGoIoKS8Ng> Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 28 Aug 2018 17:56:47 -0000 --0000000000004f79b705748290d8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable We had such an RFC it was RFC3177, it wasn't very effective, many disagreed with it and it was ignored. We can say that /48s MUST be given out on request, but there is nothing to enforce that. You have to remember RFCs are voluntary, there is no Internet police. If you think that the IETF can force any network to do anything you misunderstand the system we have. Networks comply because they agree and see an advantage. However, you can always get IPv6 addresses, even a /48, you might have to go to a different ISP, or an RIR yourself and you may have to route them yourself, which most people are either incapable or unwilling to do. You might be able to get government regulators to enforce something like that, but be very careful what you ask for. And at least the US that doesn't seem to be going in that kind of regulatory direction. I agree with Brian's suggestions in a different email, we need to make the case why /48 makes sense and is in an ISP's and their customer's interest. Not dictate a magic number to them. Homenet is a big part of that, but I'm not sure by itself it's enough. In most cases, especially when Homenet is not in use /56 seems like plenty of address space for the typical home, even /60 will work in many cases. The message we need to make clear is a single /64 is not good enough. Thanks. On Tue, Aug 28, 2018 at 10:06 AM, Mudric, Dusan (Dusan) <dmudric@avaya.com> wrote: > Hi Brian, > > There must a way to define how prefixes are assigned to always allow /48, > if needed. If not in rfc6177-bis than in another RFC. We have already one > limitation for SLAAC that makes sure every home gets at least one /64. We > can add another one, in another RFC, to make sure /48 is given on a deman= d. > That will insure future flexibility in any network and make the prefix > assignment non-political process. > > Regards, > Dusan. > > > -----Original Message----- > > From: Brian E Carpenter <brian.e.carpenter@gmail.com> > > Sent: Tuesday, August 28, 2018 12:27 AM > > To: Mudric, Dusan (Dusan) <dmudric@avaya.com>; Lea Roberts > > <lea.roberts@stanford.edu>; JORDI PALET MARTINEZ > > <jordi.palet=3D40consulintel.es@dmarc.ietf.org> > > Cc: draft-palet-v6ops-rfc6177-bis@ietf.org; IPv6 Operations > > <v6ops@ietf.org> > > Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt > > > > On 2018-08-28 06:23, Mudric, Dusan (Dusan) wrote: > > > Section 4. > > > " b. An end-user should be able to receive any prefix length up to > /48 > > > simply by asking." > > > > > > Can this be defined in a way to make sure that new applications and > > devices will always work at end sites without a need for asking ISPs fo= r > extra > > address space? Otherwise, the end-user might not get what he/she asks > for, > > without paying for the "higher grade" service. Can the definition impos= e > up > > to /48 LAP when needed at end sites? For example, can an application > > request a home router to request an ISP for /48 prefix and, when > requested, > > ISP must grant it? > > > > Unfortunately we can never say "must" in this context. What ISPs will > > provide > > for what fee is well outside the IETF's competence. As observed on > another > > thread, applications need to be agile, even if they work better if such= a > > request was granted. > > > > I'd say that once this update is done, it may be time to revisit > > RFC4084. > > > > Regards > > Brian > > > > > > > > Regards, > > > Dusan Mudric. > > > > > >> -----Original Message----- > > >> From: v6ops <v6ops-bounces@ietf.org> On Behalf Of Lea Roberts > > >> Sent: Thursday, July 19, 2018 2:08 PM > > >> To: Brian E Carpenter <brian.e.carpenter@gmail.com>; JORDI PALET > > >> MARTINEZ <jordi.palet=3D40consulintel.es@dmarc.ietf.org> > > >> Cc: draft-palet-v6ops-rfc6177-bis@ietf.org; IPv6 Operations > > >> <v6ops@ietf.org> > > >> Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.tx= t > > >> > > >> hi Brian and Jordi - > > >> > > >> excellent comments and I agree also. > > >> > > >> thank you!! > > >> /Lea > > >> > > >> On Thu, 19 Jul 2018, JORDI PALET MARTINEZ wrote: > > >> > > >>> Hi Brian, > > >>> > > >>> > > >>> > > >>> Thanks a lot for commenting and sorry the late answer ... too busy > last > > >> weeks. > > >>> > > >>> > > >>> > > >>> Comments in-line below (subjected to my co-author agreement), > > basically, > > >> agree with all your inputs, except a couple of points. > > >>> > > >>> > > >>> > > >>> Thanks! > > >>> > > >>> > > >>> > > >>> Regards, > > >>> > > >>> Jordi > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> =EF=BB=BF-----Mensaje original----- > > >>> > > >>> De: v6ops <v6ops-bounces@ietf.org> en nombre de Brian E Carpenter > > >> <brian.e.carpenter@gmail.com> > > >>> > > >>> Organizaci?n: University of Auckland > > >>> > > >>> Fecha: domingo, 8 de julio de 2018, 17:43 > > >>> > > >>> Para: <draft-palet-v6ops-rfc6177-bis@ietf.org>, IPv6 Operations > > >> <v6ops@ietf.org> > > >>> > > >>> Asunto: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.tx= t > > >>> > > >>> > > >>> > > >>> Hi, > > >>> > > >>> > > >>> > > >>> Thanks for this draft. > > >>> > > >>> > > >>> > > >>> > Abstract > > >>> > > >>> > > >>> > > >>> This needs to be shorter. Three paragraphs is too much. > > >>> > > >>> > > >>> > > >>> For the next version, I've reduced 50% the length of the 1st > paragraph. > > 3rd > > >> paragraph, I recall is mandatory (IDNits). > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > ... policy should reflect that assignment of a single subnet i= s > > >>> > > >>> > no longer appropriate unless the recipient explicitly agrees t= o > the > > >>> > > >>> > limitations implied by such an assignment. > > >>> > > >>> > > >>> > > >>> I *strongly* suggest deleting the "unless" clause. It leaves a > > >>> > > >>> loophole, and it could easily be hidden in shrink-wrap terms > > >>> > > >>> and conditions so that a subscriber would agree without even > > >>> > > >>> knowing about it. Reduce this simply to: > > >>> > > >>> > > >>> > > >>> ... policy should reflect that assignment of a single subnet = is > > >>> > > >>> never appropriate. > > >>> > > >>> > > >>> > > >>> Agreed and done. > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > 1. Introduction > > >>> > > >>> .... > > >>> > > >>> > 1. It is extremely discouraged that /128s be given out. > While there > > >>> > > >>> > may be some cases where assigning only a single address > may be > > >>> > > >>> > justified, a site, by definition, implies multiple > subnets and > > >>> > > >>> > multiple devices. > > >>> > > >>> > > >>> > > >>> I find this a bit weak. Try: > > >>> > > >>> > > >>> > > >>> 1. It is extremely discouraged that /128s be given out. > While there > > >>> > > >>> may be some applications where assigning only a single > address > > may > > >> be > > >>> > > >>> tolerated, a site, by definition, implies multiple subnet= s > and > > >>> > > >>> multiple devices. Also, a /128 prevents any form of > privacy-based > > >>> > > >>> addressing. > > >>> > > >>> > > >>> > > >>> Agreed! > > >>> > > >>> > > >>> > > >>> > 4. This revision has been created to more clearly assert t= he > > >>> > > >>> > requirement to ensure that address assignments to > end-sites > > >>> > > >>> > provide a sufficiently big number of subnets (/64 on > classic > > >>> > > >>> > networks) to each end-site, taking under consideration > the end- > > >>> > > >>> > site's future expected needs, new deployment > expectations and > > >> new > > >>> > > >>> > protocol requirements, among others. Once all these ar= e > > >>> > > >>> > considered, it seems unlikely that a single subnet (/64= ) > or even > > >>> > > >>> > a small number of them should be assigned, unless very > clearly > > >>> > > >>> > justified and agreed to by the end-site. > > >>> > > >>> > > >>> > > >>> The "unless" clause is dangerous because of shrink-wrap terms an= d > > >>> > > >>> conditions. I suggest deleting it. > > >>> > > >>> > > >>> > > >>> Agreed! > > >>> > > >>> > > >>> > > >>> > 2. Considerations Regarding the Prefix Length > > >>> > > >>> .... > > >>> > > >>> > This consideration should be noticed, across this document, > in the > > >>> > > >>> > sense that end-sites usually have subnets that use, by > default, > > >>> > > >>> > SLAAC, and consequently, the LAP is mandatorily a /64. Oth= er > > >>> > > >>> > technologies, may have a different LAP, which must be used > > >>> > > >>> > accordingly. > > >>> > > >>> > > >>> > > >>> I suggest s/Other/Future/ since /64 prevails everywhere today. > > >>> > > >>> > > >>> > > >>> Agreed! > > >>> > > >>> > > >>> > > >>> > 3. On /48 Assignments to End-Sites > > >>> > > >>> .... > > >>> > > >>> > An important > > >>> > > >>> > goal in IPv6 is to significantly change the default and > minimal end > > >>> > > >>> > site assignment, from "a single address" to "multiple > networks" and > > >>> > > >>> > to ensure that end-sites can easily obtain address space. > > >>> > > >>> > > >>> > > >>> I suggest adding something like this: > > >>> > > >>> > > >>> > > >>> As the operational costs of carrier-grade NAT and address+port > sharing > > >>> > > >>> have shown, availability of multiple addresses and prefixes to > end sites > > >>> > > >>> that need them will be a considerable saving to their ISPs. > > >>> > > >>> > > >>> > > >>> Agreed! > > >>> > > >>> > > >>> > > >>> > It might be tempting to give home sites a single /64, since > that is > > >>> > > >>> > already significantly more address space compared with > today's > > IPv4 > > >>> > > >>> > practice. However, this precludes the expectation that eve= n > home > > >>> > > >>> > sites will grow to support multiple subnets going forward. > Hence, it > > >>> > > >>> > > >>> > > >>> s/expectation/certainty/ > > >>> > > >>> > > >>> > > >>> Agreed! > > >>> > > >>> > > >>> > > >>> .... > > >>> > > >>> > A key goal of the recommendations in [RFC3177] is to > > >>> > > >>> > ensure that upon renumbering, one does not have to deal wit= h > > >>> > > >>> > renumbering into a smaller subnet size. > > >>> > > >>> > > >>> > > >>> Perhaps add: > > >>> > > >>> > > >>> > > >>> In particular this would apply to any site that switches to > > >>> > > >>> an ISP that provides a longer prefix. > > >>> > > >>> > > >>> > > >>> Agreed! > > >>> > > >>> > > >>> > > >>> > It should be noted that similar arguments apply to the > management > > of > > >>> > > >>> > zone files in the DNS. In particular, managing the reverse > > >>> > > >>> > (ip6.arpa) tree is simplified when all links are numbered > using the > > >>> > > >>> > same subnet ids > > >>> > > >>> > > >>> > > >>> s/numbered/renumbered/ > > >>> > > >>> > > >>> > > >>> Agreed! > > >>> > > >>> > > >>> > > >>> .... > > >>> > > >>> > years, and we don't recover back the /48's, we will be able > to use > > >>> > > >>> > IPv6 addressing space for over 100.000 years. > > >>> > > >>> > > >>> > > >>> Perhaps add: > > >>> > > >>> > > >>> > > >>> This document does not advocate careless use of address space, b= ut > > >>> > > >>> there is objectively no reason to be restrictve. > > >>> > > >>> > > >>> > > >>> Agreed! > > >>> > > >>> > > >>> > > >>> .... > > >>> > > >>> > Today typically, a home has already a considerable number o= f > > possible > > >>> > > >>> > subnets (a common CE has 4 LAN ports, 2 WiFi radios which > support > > >>> > > >>> > several SSIDs each one, VoIP subnet, IPTV subnet, additiona= l > > VLANs) > > >>> > > >>> > and if downstream routers are used, there is a need for > further > > >>> > > >>> > subnets. This means that in a short term, assigning a /60 > (16 > > >>> > > >>> > subnets), it is already a really bad decision, as it may > enforce IPv6 > > >>> > > >>> > NAT between the main CE and downstream routers. > > >>> > > >>> > > >>> > > >>> I suggest deleting "as it may enforce IPv6 NAT between the main = CE > > and > > >>> > > >>> downstream routers". Firstly it puts NAT into the reader's mind. > > Secondly, > > >>> > > >>> it isn't the only solution - IIDs shorter than 64 could also be > > implemented. > > >>> > > >>> > > >>> > > >>> Agreed! > > >>> > > >>> > > >>> > > >>> > 4. Impact on IPv6 Standards > > >>> > > >>> > > >>> > > >>> I propose to simply delete this section. > > >>> > > >>> > > >>> > > >>> Firstly, RFC3056 is deprecated so it's irrelevant today. > > >>> > > >>> Secondly, the argument about ULAs (RFC4193) doesn't hold up. > > >>> > > >>> ULAs are like any other /48 prefix - if you are forced to > > >>> > > >>> renumber into a longer prefix, you lose some subnet bits. > > >>> > > >>> That is already covered in the middle of section 3 (the > > >>> > > >>> "key goal" sentence quoted above). > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> I recall we deprecated the 6to4 anycast, but not 6to4, in fact 6to4 > to 6to4 > > >> traffic is still useful for peer to peer. > > >>> > > >>> > > >>> > > >>> > 6. Security Considerations > > >>> > > >>> > > > >>> > > >>> > This document has no known security implications. > > >>> > > >>> > > >>> > > >>> Really? More prefix space offers more potential for scanning > > >>> > > >>> attacks. More prefix space also allows the use of slightly > > >>> > > >>> randomized prefixes and/or prefix-per host. > > >>> > > >>> > > >>> > > >>> Also of course, a /128 would prevent any form of privacy-based > > >>> > > >>> addressing. > > >>> > > >>> > > >>> > > >>> I've introduced new text on those points. > > >>> > > >>> > > >>> > > >>> > 8. Acknowledgements > > >>> > > >>> > > > >>> > > >>> > The authors of this document will like to acknowledge the > authors > > of > > >>> > > >>> > previous versions (Thomas Narten and Geoff Huston) > > >>> > > >>> > > >>> > > >>> RFC3177 was signed by the whole IAB and IESG seated in 2001, and > its > > >>> > > >>> Acknowledgements read: > > >>> > > >>> > > >>> > > >>> >> This document originated from the IETF IPv6 directorate, > with > > much > > >>> > > >>> >> input from the IAB and IESG. The original text forming th= e > basis of > > >>> > > >>> >> this document was contributed by Fred Baker and Brian > Carpenter. > > >>> > > >>> >> Allison Mankin and Thomas Narten merged the original > > contributions > > >>> > > >>> >> into a single document, and Alain Durand edited the docume= nt > > >> through > > >>> > > >>> >> its final stages. > > >>> > > >>> > > >>> > > >>> Agreed! > > >>> > > >>> > > >>> > > >>> Regards > > >>> > > >>> Brian > > >>> > > >>> > > >>> > > >>> _______________________________________________ > > >>> > > >>> v6ops mailing list > > >>> > > >>> v6ops@ietf.org > > >>> > > >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > >> > > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwIDaQ&c=3DBFpWQw8bsuKp > > >> l1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3D- > > >> > > 5rgYq_nYMbSH2HXHnHFCFi2KDYzOClhSiLn0au8Wu0&s=3DiEq1tUDbeQL4f3SLM > > >> f1-xihjJYT0KAAN_BWTl9-779c&e=3D > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> ********************************************** > > >>> IPv4 is over > > >>> Are you ready for the new Internet ? > > >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttp- > > >> > > 3A__www.consulintel.es&d=3DDwIDaQ&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DUT3 > > >> Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3D- > > >> > > 5rgYq_nYMbSH2HXHnHFCFi2KDYzOClhSiLn0au8Wu0&s=3DGMRLdItF8yKbUdE9 > > >> NuXE-U48uk7OHNuEijym9jhE--s&e=3D > > >>> The IPv6 Company > > >>> > > >>> This electronic message contains information which may be privilege= d > or > > >> confidential. The information is intended to be for the exclusive us= e > 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 tha= t > 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://urldefense.proofpoint.com/v2/url?u=3Dhttps- > > >> > > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwIDaQ&c=3DBFpWQw8bsuKp > > >> l1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3D- > > >> > > 5rgYq_nYMbSH2HXHnHFCFi2KDYzOClhSiLn0au8Wu0&s=3DiEq1tUDbeQL4f3SLM > > >> f1-xihjJYT0KAAN_BWTl9-779c&e=3D > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --0000000000004f79b705748290d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">We had such an RFC it was RFC3177, it wasn't very effe= ctive, many disagreed=C2=A0with it and it was ignored. We can say that /48s= MUST be given out on request, but there is nothing to enforce that.=C2=A0Y= ou have to remember RFCs are voluntary, there is no Internet police. If you= think that the IETF can force any network to do anything you misunderstand= =C2=A0the system we have. Networks comply because they agree and see an adv= antage.=C2=A0<div><br><div>However, you can always get IPv6 addresses, even= a /48, you might have to go to a different=C2=A0ISP, or an RIR yourself an= d you may have to route them yourself, which most people are either incapab= le or unwilling to do.</div><div><br></div><div>You might be able to get go= vernment regulators to enforce=C2=A0something like that, but be very carefu= l=C2=A0what you ask for. And at least the US that doesn't seem to be go= ing in that kind of regulatory direction.</div><div><br></div><div>I agree = with Brian's suggestions in a different=C2=A0email, we need to make the= case why /48 makes sense and is in an ISP's and their=C2=A0customer= 9;s interest. Not dictate a magic number to them.=C2=A0 Homenet is a big pa= rt of that, but I'm not sure by itself it's enough.</div><div><br><= /div><div>In most cases, especially when Homenet is not in use /56 seems li= ke plenty of address space for the typical home, even /60 will work=C2=A0in= many cases. The message we need to make clear is a single /64 is not good = enough.</div><div><br></div><div>Thanks.<br><div class=3D"gmail_extra"><br>= <div class=3D"gmail_quote">On Tue, Aug 28, 2018 at 10:06 AM, Mudric, Dusan = (Dusan) <span dir=3D"ltr"><<a href=3D"mailto:dmudric@avaya.com" target= =3D"_blank">dmudric@avaya.com</a>></span> wrote:<br><blockquote class=3D= "gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2= 04,204,204);padding-left:1ex">Hi Brian,<br> <br> There must a way to define how prefixes are assigned to always allow /48, i= f needed. If not in rfc6177-bis than in another RFC. We have already one li= mitation for SLAAC that makes sure every home gets at least one /64. We can= add another one, in another RFC, to make sure /48 is given on a demand. Th= at will insure future flexibility in any network and make the prefix assign= ment non-political process. <br> <br> Regards,<br> Dusan.<br> <br> > -----Original Message-----<br> > From: Brian E Carpenter <<a href=3D"mailto:brian.e.carpenter@gmail.= com" target=3D"_blank">brian.e.carpenter@gmail.com</a>><br> > Sent: Tuesday, August 28, 2018 12:27 AM<br> > To: Mudric, Dusan (Dusan) <<a href=3D"mailto:dmudric@avaya.com" tar= get=3D"_blank">dmudric@avaya.com</a>>; Lea Roberts<br> > <<a href=3D"mailto:lea.roberts@stanford.edu" target=3D"_blank">lea.= roberts@stanford.edu</a>>; JORDI PALET MARTINEZ<br> > <jordi.palet=3D<a href=3D"mailto:40consulintel.es@dmarc.ietf.org" t= arget=3D"_blank">40consulintel.es@<wbr>dmarc.ietf.org</a>><br> > Cc: <a href=3D"mailto:draft-palet-v6ops-rfc6177-bis@ietf.org" target= =3D"_blank">draft-palet-v6ops-rfc6177-bis@<wbr>ietf.org</a>; IPv6 Operation= s<br> > <<a href=3D"mailto:v6ops@ietf.org" target=3D"_blank">v6ops@ietf.org= </a>><br> > Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-<wbr>00= .txt<br> > <br> > On 2018-08-28 06:23, Mudric, Dusan (Dusan) wrote:<br> > > Section 4.<br> > > "=C2=A0 =C2=A0b.=C2=A0 An end-user should be able to receive= any prefix length up to /48<br> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 simply by asking."<br> > ><br> > > Can=C2=A0 this be defined in a way to make sure that new applicat= ions and<br> > devices will always work at end sites without a need for asking ISPs f= or extra<br> > address space? Otherwise, the end-user might not get what he/she asks = for,<br> > without paying for the "higher grade" service. Can the defin= ition impose up<br> > to /48 LAP when needed at end sites? For example, can an application<b= r> > request a home router to request an ISP for /48 prefix and, when reque= sted,<br> > ISP must grant it?<br> > <br> > Unfortunately we can never say "must" in this context. What = ISPs will<br> > provide<br> > for what fee is well outside the IETF's competence. As observed on= another<br> > thread, applications need to be agile, even if they work better if suc= h a<br> > request was granted.<br> > <br> > I'd say that once this update is done, it may be time to revisit<b= r> > RFC4084.<br> > <br> > Regards<br> >=C2=A0 =C2=A0 =C2=A0Brian<br> > <br> > ><br> > > Regards,<br> > > Dusan Mudric.<br> > ><br> > >> -----Original Message-----<br> > >> From: v6ops <<a href=3D"mailto:v6ops-bounces@ietf.org" tar= get=3D"_blank">v6ops-bounces@ietf.org</a>> On Behalf Of Lea Roberts<br> > >> Sent: Thursday, July 19, 2018 2:08 PM<br> > >> To: Brian E Carpenter <<a href=3D"mailto:brian.e.carpenter= @gmail.com" target=3D"_blank">brian.e.carpenter@gmail.com</a>>; JORDI PA= LET<br> > >> MARTINEZ <jordi.palet=3D<a href=3D"mailto:40consulintel.es= @dmarc.ietf.org" target=3D"_blank">40consulintel.es@<wbr>dmarc.ietf.org</a>= ><br> > >> Cc: <a href=3D"mailto:draft-palet-v6ops-rfc6177-bis@ietf.org"= target=3D"_blank">draft-palet-v6ops-rfc6177-bis@<wbr>ietf.org</a>; IPv6 Op= erations<br> > >> <<a href=3D"mailto:v6ops@ietf.org" target=3D"_blank">v6ops= @ietf.org</a>><br> > >> Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bi= s-<wbr>00.txt<br> > >><br> > >> hi Brian and Jordi -<br> > >><br> > >> excellent comments and I agree also.<br> > >><br> > >> thank you!!<br> > >> /Lea<br> > >><br> > >> On Thu, 19 Jul 2018, JORDI PALET MARTINEZ wrote:<br> > >><br> > >>> Hi Brian,<br> > >>><br> > >>><br> > >>><br> > >>> Thanks a lot for commenting and sorry the late answer ...= too busy last<br> > >> weeks.<br> > >>><br> > >>><br> > >>><br> > >>> Comments in-line below (subjected to my co-author agreeme= nt),<br> > basically,<br> > >> agree with all your inputs, except a couple of points.<br> > >>><br> > >>><br> > >>><br> > >>> Thanks!<br> > >>><br> > >>><br> > >>><br> > >>> Regards,<br> > >>><br> > >>> Jordi<br> > >>><br> > >>><br> > >>><br> > >>><br> > >>><br> > >>><br> > >>><br> > >>> =EF=BB=BF-----Mensaje original-----<br> > >>><br> > >>> De: v6ops <<a href=3D"mailto:v6ops-bounces@ietf.org" t= arget=3D"_blank">v6ops-bounces@ietf.org</a>> en nombre de Brian E Carpen= ter<br> > >> <<a href=3D"mailto:brian.e.carpenter@gmail.com" target=3D"= _blank">brian.e.carpenter@gmail.com</a>><br> > >>><br> > >>> Organizaci?n: University of Auckland<br> > >>><br> > >>> Fecha: domingo, 8 de julio de 2018, 17:43<br> > >>><br> > >>> Para: <<a href=3D"mailto:draft-palet-v6ops-rfc6177-bis= @ietf.org" target=3D"_blank">draft-palet-v6ops-rfc6177-bis<wbr>@ietf.org</a= >>, IPv6 Operations<br> > >> <<a href=3D"mailto:v6ops@ietf.org" target=3D"_blank">v6ops= @ietf.org</a>><br> > >>><br> > >>> Asunto: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177= -bis-<wbr>00.txt<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 Hi,<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 Thanks for this draft.<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 > Abstract<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 This needs to be shorter. Three paragraphs i= s too much.<br> > >>><br> > >>><br> > >>><br> > >>> For the next version, I've reduced 50% the length of = the 1st paragraph.<br> > 3rd<br> > >> paragraph, I recall is mandatory (IDNits).<br> > >>><br> > >>><br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 > ... policy should reflect that assignme= nt of a single subnet is<br> > >>><br> > >>>=C2=A0 =C2=A0 > no longer appropriate unless the recipi= ent explicitly agrees to the<br> > >>><br> > >>>=C2=A0 =C2=A0 > limitations implied by such an assignme= nt.<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 I *strongly* suggest deleting the "unle= ss" clause. It leaves a<br> > >>><br> > >>>=C2=A0 =C2=A0 loophole, and it could easily be hidden in s= hrink-wrap terms<br> > >>><br> > >>>=C2=A0 =C2=A0 and conditions so that a subscriber would ag= ree without even<br> > >>><br> > >>>=C2=A0 =C2=A0 knowing about it. Reduce this simply to:<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0... policy should reflect that = assignment of a single subnet is<br> > >>><br> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0never appropriate.<br> > >>><br> > >>><br> > >>><br> > >>> Agreed and done.<br> > >>><br> > >>><br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 > 1.=C2=A0 Introduction<br> > >>><br> > >>>=C2=A0 =C2=A0 ....<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 1.=C2=A0 It is extremely d= iscouraged that /128s be given out.=C2=A0 While there<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 may be some = cases where assigning only a single address may be<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 justified, a= site, by definition, implies multiple subnets and<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 multiple dev= ices.<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 I find this a bit weak. Try:<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A01.=C2=A0 It is extremely discou= raged that /128s be given out.=C2=A0 While there<br> > >>><br> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0may be some appli= cations where assigning only a single address<br> > may<br> > >> be<br> > >>><br> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tolerated, a site= , by definition, implies multiple subnets and<br> > >>><br> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0multiple devices.= Also, a /128 prevents any form of privacy-based<br> > >>><br> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0addressing.<br> > >>><br> > >>><br> > >>><br> > >>> Agreed!<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 4.=C2=A0 This revision has= been created to more clearly assert the<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 requirement = to ensure that address assignments to end-sites<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 provide a su= fficiently big number of subnets (/64 on classic<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 networks) to= each end-site, taking under consideration the end-<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 site's f= uture expected needs, new deployment expectations and<br> > >> new<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 protocol req= uirements, among others.=C2=A0 Once all these are<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 considered, = it seems unlikely that a single subnet (/64) or even<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 a small numb= er of them should be assigned, unless very clearly<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 justified an= d agreed to by the end-site.<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 The "unless" clause is dangerous b= ecause of shrink-wrap terms and<br> > >>><br> > >>>=C2=A0 =C2=A0 conditions. I suggest deleting it.<br> > >>><br> > >>><br> > >>><br> > >>> Agreed!<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 > 2.=C2=A0 Considerations Regarding the P= refix Length<br> > >>><br> > >>>=C2=A0 =C2=A0 ....<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 This consideration should = be noticed, across this document, in the<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 sense that end-sites usual= ly have subnets that use, by default,<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 SLAAC, and consequently, t= he LAP is mandatorily a /64.=C2=A0 Other<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 technologies, may have a d= ifferent LAP, which must be used<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 accordingly.<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 I suggest s/Other/Future/ since /64 prevails= everywhere today.<br> > >>><br> > >>><br> > >>><br> > >>> Agreed!<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 > 3.=C2=A0 On /48 Assignments to End-Site= s<br> > >>><br> > >>>=C2=A0 =C2=A0 ....<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 An important<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 goal in IPv6 is to signifi= cantly change the default and minimal end<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 site assignment, from &quo= t;a single address" to "multiple networks" and<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 to ensure that end-sites c= an easily obtain address space.<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 I suggest adding something like this:<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 As the operational costs of carrier-grade NA= T and address+port sharing<br> > >>><br> > >>>=C2=A0 =C2=A0 have shown, availability of multiple address= es and prefixes to end sites<br> > >>><br> > >>>=C2=A0 =C2=A0 that need them will be a considerable saving= to their ISPs.<br> > >>><br> > >>><br> > >>><br> > >>> Agreed!<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 It might be tempting to gi= ve home sites a single /64, since that is<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 already significantly more= address space compared with today's<br> > IPv4<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 practice.=C2=A0 However, t= his precludes the expectation that even home<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 sites will grow to support= multiple subnets going forward.=C2=A0 Hence, it<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 s/expectation/certainty/<br> > >>><br> > >>><br> > >>><br> > >>> Agreed!<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 ....<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 A key goal of the recommen= dations in [RFC3177] is to<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 ensure that upon renumberi= ng, one does not have to deal with<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 renumbering into a smaller= subnet size.<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 Perhaps add:<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 In particular this would apply to any site t= hat switches to<br> > >>><br> > >>>=C2=A0 =C2=A0 an ISP that provides a longer prefix.<br> > >>><br> > >>><br> > >>><br> > >>> Agreed!<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 It should be noted that si= milar arguments apply to the management<br> > of<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 zone files in the DNS.=C2= =A0 In particular, managing the reverse<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 (ip6.arpa) tree is simplif= ied when all links are numbered using the<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 same subnet ids<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 s/numbered/renumbered/<br> > >>><br> > >>><br> > >>><br> > >>> Agreed!<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 ....<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 years, and we don't re= cover back the /48's, we will be able to use<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 IPv6 addressing space for = over 100.000 years.<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 Perhaps add:<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 This document does not advocate careless use= of address space, but<br> > >>><br> > >>>=C2=A0 =C2=A0 there is objectively no reason to be restric= tve.<br> > >>><br> > >>><br> > >>><br> > >>> Agreed!<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 ....<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 Today typically, a home ha= s already a considerable number of<br> > possible<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 subnets (a common CE has 4= LAN ports, 2 WiFi radios which support<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 several SSIDs each one, Vo= IP subnet, IPTV subnet, additional<br> > VLANs)<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 and if downstream routers = are used, there is a need for further<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 subnets.=C2=A0 This means = that in a short term, assigning a /60 (16<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 subnets), it is already a = really bad decision, as it may enforce IPv6<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 NAT between the main CE an= d downstream routers.<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 I suggest deleting "as it may enforce I= Pv6 NAT between the main CE<br> > and<br> > >>><br> > >>>=C2=A0 =C2=A0 downstream routers". Firstly it puts NA= T into the reader's mind.<br> > Secondly,<br> > >>><br> > >>>=C2=A0 =C2=A0 it isn't the only solution - IIDs shorte= r than 64 could also be<br> > implemented.<br> > >>><br> > >>><br> > >>><br> > >>> Agreed!<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 > 4.=C2=A0 Impact on IPv6 Standards<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 I propose to simply delete this section.<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 Firstly, RFC3056 is deprecated so it's i= rrelevant today.<br> > >>><br> > >>>=C2=A0 =C2=A0 Secondly, the argument about ULAs (RFC4193) = doesn't hold up.<br> > >>><br> > >>>=C2=A0 =C2=A0 ULAs are like any other /48 prefix - if you = are forced to<br> > >>><br> > >>>=C2=A0 =C2=A0 renumber into a longer prefix, you lose some= subnet bits.<br> > >>><br> > >>>=C2=A0 =C2=A0 That is already covered in the middle of sec= tion 3 (the<br> > >>><br> > >>>=C2=A0 =C2=A0 "key goal" sentence quoted above).= <br> > >>><br> > >>><br> > >>><br> > >>><br> > >>><br> > >>> I recall we deprecated the 6to4 anycast, but not 6to4, in= fact 6to4 to 6to4<br> > >> traffic is still useful for peer to peer.<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 > 6.=C2=A0 Security Considerations<br> > >>><br> > >>>=C2=A0 =C2=A0 ><br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 This document has no known= security implications.<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 Really? More prefix space offers more potent= ial for scanning<br> > >>><br> > >>>=C2=A0 =C2=A0 attacks. More prefix space also allows the u= se of slightly<br> > >>><br> > >>>=C2=A0 =C2=A0 randomized prefixes and/or prefix-per host.<= br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 Also of course, a /128 would prevent any for= m of privacy-based<br> > >>><br> > >>>=C2=A0 =C2=A0 addressing.<br> > >>><br> > >>><br> > >>><br> > >>> I've introduced new text on those points.<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 > 8.=C2=A0 Acknowledgements<br> > >>><br> > >>>=C2=A0 =C2=A0 ><br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 The authors of this docume= nt will like to acknowledge the authors<br> > of<br> > >>><br> > >>>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 previous versions (Thomas = Narten and Geoff Huston)<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 RFC3177 was signed by the whole IAB and IESG= seated in 2001, and its<br> > >>><br> > >>>=C2=A0 =C2=A0 Acknowledgements read:<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 This document originat= ed from the IETF IPv6 directorate, with<br> > much<br> > >>><br> > >>>=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 input from the IAB and= IESG.=C2=A0 The original text forming the basis of<br> > >>><br> > >>>=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 this document was cont= ributed by Fred Baker and Brian Carpenter.<br> > >>><br> > >>>=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 Allison Mankin and Tho= mas Narten merged the original<br> > contributions<br> > >>><br> > >>>=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 into a single document= , and Alain Durand edited the document<br> > >> through<br> > >>><br> > >>>=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 its final stages.<br> > >>><br> > >>><br> > >>><br> > >>> Agreed!<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 Regards<br> > >>><br> > >>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Brian<br> > >>><br> > >>><br> > >>><br> > >>>=C2=A0 =C2=A0 ______________________________<wbr>_________= ________<br> > >>><br> > >>>=C2=A0 =C2=A0 v6ops mailing list<br> > >>><br> > >>>=C2=A0 =C2=A0 <a href=3D"mailto:v6ops@ietf.org" target=3D"= _blank">v6ops@ietf.org</a><br> > >>><br> > >>>=C2=A0 =C2=A0 <a href=3D"https://urldefense.proofpoint.com= /v2/url?u=3Dhttps-" rel=3D"noreferrer" target=3D"_blank">https://urldefense= .proofpoint.<wbr>com/v2/url?u=3Dhttps-</a><br> > >><br> > 3A__www.ietf.org_mailman_listi<wbr>nfo_v6ops&d=3DDwIDaQ&c=3DBF= pWQw8bs<wbr>uKp<br> > >> l1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3i<wbr>CrhIoUWB8YLZU23029sM= QGQ2kY&m=3D-<br> > >><br> > 5rgYq_nYMbSH2HXHnHFCFi2KDYzOCl<wbr>hSiLn0au8Wu0&s=3DiEq1tUDbeQL4f3= S<wbr>LM<br> > >> f1-xihjJYT0KAAN_BWTl9-779c&e=3D<br> > >>><br> > >>><br> > >>><br> > >>><br> > >>><br> > >>><br> > >>> ******************************<wbr>****************<br> > >>> IPv4 is over<br> > >>> Are you ready for the new Internet ?<br> > >>> <a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dh= ttp-" rel=3D"noreferrer" target=3D"_blank">https://urldefense.proofpoint.<w= br>com/v2/url?u=3Dhttp-</a><br> > >><br> > <a href=3D"http://3A__www.consulintel.es" rel=3D"noreferrer" target=3D= "_blank">3A__www.consulintel.es</a>&d=3DDwIDa<wbr>Q&c=3DBFpWQw8bsuK= pl1SgiZH64Q&r=3DU<wbr>T3<br> > >> Bk9cbLeaJxhf3iCrhIoUWB8YLZU230<wbr>29sMQGQ2kY&m=3D-<br> > >><br> > 5rgYq_nYMbSH2HXHnHFCFi2KDYzOCl<wbr>hSiLn0au8Wu0&s=3DGMRLdItF8yKbUd= E<wbr>9<br> > >> NuXE-U48uk7OHNuEijym9jhE--s&e=3D<br> > >>> The IPv6 Company<br> > >>><br> > >>> This electronic message contains information which may be= privileged or<br> > >> confidential. The information is intended to be for the exclu= sive use of<br> > the<br> > >> individual(s) named above and further non-explicilty authoriz= ed<br> > disclosure,<br> > >> copying, distribution or use of the contents of this informat= ion, even if<br> > >> partially, including attached files, is strictly prohibited a= nd will be<br> > considered a<br> > >> criminal offense. If you are not the intended recipient be aw= are that any<br> > >> disclosure, copying, distribution or use of the contents of t= his information,<br> > >> even if partially, including attached files, is strictly proh= ibited, will be<br> > >> considered a criminal offense, so you must reply to the origi= nal sender to<br> > >> inform about this communication and delete it.<br> > >>><br> > >>><br> > >>><br> > >>> ______________________________<wbr>_________________<br> > >>> v6ops mailing list<br> > >>> <a href=3D"mailto:v6ops@ietf.org" target=3D"_blank">v6ops= @ietf.org</a><br> > >>> <a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dh= ttps-" rel=3D"noreferrer" target=3D"_blank">https://urldefense.proofpoint.<= wbr>com/v2/url?u=3Dhttps-</a><br> > >><br> > 3A__www.ietf.org_mailman_listi<wbr>nfo_v6ops&d=3DDwIDaQ&c=3DBF= pWQw8bs<wbr>uKp<br> > >> l1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3i<wbr>CrhIoUWB8YLZU23029sM= QGQ2kY&m=3D-<br> > >><br> > 5rgYq_nYMbSH2HXHnHFCFi2KDYzOCl<wbr>hSiLn0au8Wu0&s=3DiEq1tUDbeQL4f3= S<wbr>LM<br> > >> f1-xihjJYT0KAAN_BWTl9-779c&e=3D<br> <br> ______________________________<wbr>_________________<br> v6ops mailing list<br> <a href=3D"mailto:v6ops@ietf.org" target=3D"_blank">v6ops@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/v6ops" rel=3D"noreferrer" = target=3D"_blank">https://www.ietf.org/mailman/l<wbr>istinfo/v6ops</a><br> </blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class= =3D"gmail-m_4355328992084807522m_-5685528606687956189gmail_signature">=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D<wbr>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>Dav= id Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 <a href=3D"= mailto:Email%3Afarmer@umn.edu" target=3D"_blank">Email:farmer@umn.edu</a><b= r>Networking & Telecommunication Services<br>Office of Information Tech= nology<br>University of Minnesota=C2=A0=C2=A0 <br>2218 University Ave SE=C2= =A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815<br>Minneapolis, MN 55414-3029= =C2=A0=C2=A0 Cell: 612-812-9952<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<wbr>=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div> </div></div></div></div> --0000000000004f79b705748290d8-- From nobody Tue Aug 28 11:58:55 2018 Return-Path: <dmudric@avaya.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A218130EC9; Tue, 28 Aug 2018 11:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.909 X-Spam-Level: X-Spam-Status: No, score=-4.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, 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 Mo9CYB9zHbf7; Tue, 28 Aug 2018 11:58:49 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.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 38E6E128B14; Tue, 28 Aug 2018 11:58:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FbAADUmoVb/wUHmMZXAw4LAQEBAQEBA?= =?us-ascii?q?QEBAQEBBwEBAQEBglcjVWVtEigKg2iIEYwqgg2IVY1TFIErFyEDCxgBBwwChD4?= =?us-ascii?q?CF4JiITQYAQIBAQEBAQECAgJpHAyCaC8BAQQHAwwvCQIDAQEBAQEBAQEBJAEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBEgIIBzUSAQEYAQEBAQMBARAIAQgKOgcGBQw?= =?us-ascii?q?CAgIBCA0EBAEBAQoWAQYDAgICGQYFAQsUCQgCBA4EAQgTBAOCWwIjgR1MAxUBD?= =?us-ascii?q?pogiW+BLhoChBEBgnYNgzEFiHCBGxeBQj4mbEaCTIJWRQEBAgEXgQsJARIBIQQ?= =?us-ascii?q?RCgsKCAmCOjGCJgKHbwgBgQaEDYVTiCkrCQKGMXeFNnKCNYE/SIZUAw+FYIZog?= =?us-ascii?q?U+CZ2SHS4FBOWFxcBU7gmkJgWyEDIUUhQQ6bwEBL2WJBoEfAYEQCwEB?= X-IPAS-Result: =?us-ascii?q?A2FbAADUmoVb/wUHmMZXAw4LAQEBAQEBAQEBAQEBBwEBAQE?= =?us-ascii?q?BglcjVWVtEigKg2iIEYwqgg2IVY1TFIErFyEDCxgBBwwChD4CF4JiITQYAQIBA?= =?us-ascii?q?QEBAQECAgJpHAyCaC8BAQQHAwwvCQIDAQEBAQEBAQEBJAEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBEgIIBzUSAQEYAQEBAQMBARAIAQgKOgcGBQwCAgIBCA0EBAEBA?= =?us-ascii?q?QoWAQYDAgICGQYFAQsUCQgCBA4EAQgTBAOCWwIjgR1MAxUBDpogiW+BLhoChBE?= =?us-ascii?q?BgnYNgzEFiHCBGxeBQj4mbEaCTIJWRQEBAgEXgQsJARIBIQQRCgsKCAmCOjGCJ?= =?us-ascii?q?gKHbwgBgQaEDYVTiCkrCQKGMXeFNnKCNYE/SIZUAw+FYIZogU+CZ2SHS4FBOWF?= =?us-ascii?q?xcBU7gmkJgWyEDIUUhQQ6bwEBL2WJBoEfAYEQCwEB?= X-IronPort-AV: E=Sophos;i="5.53,300,1531800000"; d="scan'208,217";a="295492033" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 28 Aug 2018 14:58:45 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC04.global.avaya.com) ([135.11.85.15]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Aug 2018 14:58:45 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC04.global.avaya.com ([135.11.85.15]) with mapi id 14.03.0382.000; Tue, 28 Aug 2018 14:58:44 -0400 From: "Mudric, Dusan (Dusan)" <dmudric@avaya.com> To: David Farmer <farmer@umn.edu> CC: Brian E Carpenter <brian.e.carpenter@gmail.com>, Lea Roberts <lea.roberts@stanford.edu>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>, "draft-palet-v6ops-rfc6177-bis@ietf.org" <draft-palet-v6ops-rfc6177-bis@ietf.org>, IPv6 Operations <v6ops@ietf.org> Thread-Topic: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt Thread-Index: AQHUPvh/Ko70qnLKj0ydLUIQXfett6TVfugA Date: Tue, 28 Aug 2018 18:58:44 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E459CB452E3@AZ-US1EXMB03.global.avaya.com> References: <153017691583.14743.17000446834856511528@ietfa.amsl.com> <78a36a81-3bb3-9d47-aa06-8da8f7594677@gmail.com> <C040E02F-7BEC-4FF9-8585-BE380B6859DE@consulintel.es> <alpine.DEB.2.02.1807191054090.7979@networking.stanford.edu> <9142206A0C5BF24CB22755C8EC422E459CB44344@AZ-US1EXMB03.global.avaya.com> <f1bc1848-abe0-553e-0fdf-623eb0d1a871@gmail.com> <9142206A0C5BF24CB22755C8EC422E459CB44E7E@AZ-US1EXMB03.global.avaya.com> <CAN-Dau2AcL-UvE94tndCfe1aQQ77SEPQ=SxawoJZDUK+bta8vg@mail.gmail.com> In-Reply-To: <CAN-Dau2AcL-UvE94tndCfe1aQQ77SEPQ=SxawoJZDUK+bta8vg@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: multipart/alternative; boundary="_000_9142206A0C5BF24CB22755C8EC422E459CB452E3AZUS1EXMB03glob_" MIME-Version: 1.0 Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/i-JORX0WBn8gLitXDrfwGlSciUk> Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 28 Aug 2018 18:58:54 -0000 --_000_9142206A0C5BF24CB22755C8EC422E459CB452E3AZUS1EXMB03glob_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJpYW4gYW5kIERhdmlkLA0KDQpJbiB0aGlzIGRvY3VtZW50IHRoZXJlIGlzIGFscmVhZHkg d29yZCDigJhtdXN04oCZIHJlbGF0ZWQgdG8gdGhlIHByZWZpeCBsZW5ndGg6DQoNCmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wYWxldC12Nm9wcy1yZmM2MTc3LWJpcy0wMSNzZWN0 aW9uLTINCg0KICAgTG9uZ2VzdCBBY2NlcHRhYmxlIFByZWZpeCAoTEFQLA0KDQogICBbSS1ELmNh cnBlbnRlci02bWFuLWxhcDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGFsZXQt djZvcHMtcmZjNjE3Ny1iaXMtMDEjcmVmLUktRC5jYXJwZW50ZXItNm1hbi1sYXA+XSksIHdob3Nl IGxlbmd0aCBpcyBsb2NhbGx5IGRldGVybWluZWQsIGUuZy4sDQoNCiAgIGEgc2l0ZSBvciBsaW5r IHRoYXQgdXNlcyBTTEFBQyBoYXMgYSBMQVAgb2YgLzY0IGFuZCB3aWxsIG5vdCB3b3JrDQoNCiAg IHdpdGggYSBsb25nZXIgb25lLg0KDQoNCg0KICAgU0xBQUMsIGFuZCBjb25zZXF1ZW50bHksIHRo ZSBMQVAgaXMgbWFuZGF0b3JpbHkgYSAvNjQuICBGdXR1cmUNCg0KICAgdGVjaG5vbG9naWVzLCBt YXkgaGF2ZSBhIGRpZmZlcmVudCBMQVAsIHdoaWNoIG11c3QgYmUgdXNlZA0KDQogICBhY2NvcmRp bmdseS4NCg0KDQpCYXNlZCB0aGUgYW5hbHlzaXMgaW4gc2VjdGlvbiAzPGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1wYWxldC12Nm9wcy1yZmM2MTc3LWJpcy0wMSNzZWN0aW9uLTM+ LiAgT24gLzQ4IEFzc2lnbm1lbnRzIHRvIEVuZC1TaXRlcywgLzQ4IExBUCB3aWxsIGJlIHJlcXVp cmVkIGluIGEgbmVhciBmdXR1cmUuIFRoYXQgbWVhbnMgdGhlIHdvcmRpbmcgb2YgdGhlIHNlbnRl bmNlIGFib3ZlIGNhbiBiZSBjaGFuZ2VkIHRvOg0KDQoNCiAgIFNMQUFDLCBhbmQgY29uc2VxdWVu dGx5LCB0aGUgTEFQIGlzIG1hbmRhdG9yaWx5IGEgLzY0LiAgRnV0dXJlDQoNCiAgIHRlY2hub2xv Z2llcywgbWF5IGhhdmUgYSBkaWZmZXJlbnQgTEFQLCB3aGljaCBtdXN0IGJlIGFzc2lnbmVkDQoN CiAgIHdoZW4gbmVlZGVkIChvciByZXF1ZXN0ZWQpLg0KDQpvdGhlcndpc2UsIHRoZXNlIHRlY2hu b2xvZ2llcyB3aWxsIG5vdCB3b3JrIGFuZCwgbW9zdCBsaWtlbHksIHdvbuKAmXQgYmUgZGV2ZWxv cGVkIGJlY2F1c2UgdGhlaXIgZGVwbG95bWVudCB3aWxsIGJlIGltcGFpcmVkIGJ5IElTUHMgTEFQ IGFzc2lnbm1lbnQuDQoNClJlZ2FyZHMsDQpEdXNhbi4NCg0KRnJvbTogRGF2aWQgRmFybWVyIDxm YXJtZXJAdW1uLmVkdT4NClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAyOCwgMjAxOCAxOjU3IFBNDQpU bzogTXVkcmljLCBEdXNhbiAoRHVzYW4pIDxkbXVkcmljQGF2YXlhLmNvbT4NCkNjOiBCcmlhbiBF IENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPjsgTGVhIFJvYmVydHMgPGxl YS5yb2JlcnRzQHN0YW5mb3JkLmVkdT47IEpPUkRJIFBBTEVUIE1BUlRJTkVaIDxqb3JkaS5wYWxl dD00MGNvbnN1bGludGVsLmVzQGRtYXJjLmlldGYub3JnPjsgZHJhZnQtcGFsZXQtdjZvcHMtcmZj NjE3Ny1iaXNAaWV0Zi5vcmc7IElQdjYgT3BlcmF0aW9ucyA8djZvcHNAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1wYWxldC12Nm9wcy1yZmM2MTc3LWJp cy0wMC50eHQNCg0KV2UgaGFkIHN1Y2ggYW4gUkZDIGl0IHdhcyBSRkMzMTc3LCBpdCB3YXNuJ3Qg dmVyeSBlZmZlY3RpdmUsIG1hbnkgZGlzYWdyZWVkIHdpdGggaXQgYW5kIGl0IHdhcyBpZ25vcmVk LiBXZSBjYW4gc2F5IHRoYXQgLzQ4cyBNVVNUIGJlIGdpdmVuIG91dCBvbiByZXF1ZXN0LCBidXQg dGhlcmUgaXMgbm90aGluZyB0byBlbmZvcmNlIHRoYXQuIFlvdSBoYXZlIHRvIHJlbWVtYmVyIFJG Q3MgYXJlIHZvbHVudGFyeSwgdGhlcmUgaXMgbm8gSW50ZXJuZXQgcG9saWNlLiBJZiB5b3UgdGhp bmsgdGhhdCB0aGUgSUVURiBjYW4gZm9yY2UgYW55IG5ldHdvcmsgdG8gZG8gYW55dGhpbmcgeW91 IG1pc3VuZGVyc3RhbmQgdGhlIHN5c3RlbSB3ZSBoYXZlLiBOZXR3b3JrcyBjb21wbHkgYmVjYXVz ZSB0aGV5IGFncmVlIGFuZCBzZWUgYW4gYWR2YW50YWdlLg0KDQpIb3dldmVyLCB5b3UgY2FuIGFs d2F5cyBnZXQgSVB2NiBhZGRyZXNzZXMsIGV2ZW4gYSAvNDgsIHlvdSBtaWdodCBoYXZlIHRvIGdv IHRvIGEgZGlmZmVyZW50IElTUCwgb3IgYW4gUklSIHlvdXJzZWxmIGFuZCB5b3UgbWF5IGhhdmUg dG8gcm91dGUgdGhlbSB5b3Vyc2VsZiwgd2hpY2ggbW9zdCBwZW9wbGUgYXJlIGVpdGhlciBpbmNh cGFibGUgb3IgdW53aWxsaW5nIHRvIGRvLg0KDQpZb3UgbWlnaHQgYmUgYWJsZSB0byBnZXQgZ292 ZXJubWVudCByZWd1bGF0b3JzIHRvIGVuZm9yY2Ugc29tZXRoaW5nIGxpa2UgdGhhdCwgYnV0IGJl IHZlcnkgY2FyZWZ1bCB3aGF0IHlvdSBhc2sgZm9yLiBBbmQgYXQgbGVhc3QgdGhlIFVTIHRoYXQg ZG9lc24ndCBzZWVtIHRvIGJlIGdvaW5nIGluIHRoYXQga2luZCBvZiByZWd1bGF0b3J5IGRpcmVj dGlvbi4NCg0KSSBhZ3JlZSB3aXRoIEJyaWFuJ3Mgc3VnZ2VzdGlvbnMgaW4gYSBkaWZmZXJlbnQg ZW1haWwsIHdlIG5lZWQgdG8gbWFrZSB0aGUgY2FzZSB3aHkgLzQ4IG1ha2VzIHNlbnNlIGFuZCBp cyBpbiBhbiBJU1AncyBhbmQgdGhlaXIgY3VzdG9tZXIncyBpbnRlcmVzdC4gTm90IGRpY3RhdGUg YSBtYWdpYyBudW1iZXIgdG8gdGhlbS4gIEhvbWVuZXQgaXMgYSBiaWcgcGFydCBvZiB0aGF0LCBi dXQgSSdtIG5vdCBzdXJlIGJ5IGl0c2VsZiBpdCdzIGVub3VnaC4NCg0KSW4gbW9zdCBjYXNlcywg ZXNwZWNpYWxseSB3aGVuIEhvbWVuZXQgaXMgbm90IGluIHVzZSAvNTYgc2VlbXMgbGlrZSBwbGVu dHkgb2YgYWRkcmVzcyBzcGFjZSBmb3IgdGhlIHR5cGljYWwgaG9tZSwgZXZlbiAvNjAgd2lsbCB3 b3JrIGluIG1hbnkgY2FzZXMuIFRoZSBtZXNzYWdlIHdlIG5lZWQgdG8gbWFrZSBjbGVhciBpcyBh IHNpbmdsZSAvNjQgaXMgbm90IGdvb2QgZW5vdWdoLg0KDQpUaGFua3MuDQoNCk9uIFR1ZSwgQXVn IDI4LCAyMDE4IGF0IDEwOjA2IEFNLCBNdWRyaWMsIER1c2FuIChEdXNhbikgPGRtdWRyaWNAYXZh eWEuY29tPG1haWx0bzpkbXVkcmljQGF2YXlhLmNvbT4+IHdyb3RlOg0KSGkgQnJpYW4sDQoNClRo ZXJlIG11c3QgYSB3YXkgdG8gZGVmaW5lIGhvdyBwcmVmaXhlcyBhcmUgYXNzaWduZWQgdG8gYWx3 YXlzIGFsbG93IC80OCwgaWYgbmVlZGVkLiBJZiBub3QgaW4gcmZjNjE3Ny1iaXMgdGhhbiBpbiBh bm90aGVyIFJGQy4gV2UgaGF2ZSBhbHJlYWR5IG9uZSBsaW1pdGF0aW9uIGZvciBTTEFBQyB0aGF0 IG1ha2VzIHN1cmUgZXZlcnkgaG9tZSBnZXRzIGF0IGxlYXN0IG9uZSAvNjQuIFdlIGNhbiBhZGQg YW5vdGhlciBvbmUsIGluIGFub3RoZXIgUkZDLCB0byBtYWtlIHN1cmUgLzQ4IGlzIGdpdmVuIG9u IGEgZGVtYW5kLiBUaGF0IHdpbGwgaW5zdXJlIGZ1dHVyZSBmbGV4aWJpbGl0eSBpbiBhbnkgbmV0 d29yayBhbmQgbWFrZSB0aGUgcHJlZml4IGFzc2lnbm1lbnQgbm9uLXBvbGl0aWNhbCBwcm9jZXNz Lg0KDQpSZWdhcmRzLA0KRHVzYW4uDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogQnJpYW4gRSBDYXJwZW50ZXIgPGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbTxtYWls dG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPj4NCj4gU2VudDogVHVlc2RheSwgQXVndXN0 IDI4LCAyMDE4IDEyOjI3IEFNDQo+IFRvOiBNdWRyaWMsIER1c2FuIChEdXNhbikgPGRtdWRyaWNA YXZheWEuY29tPG1haWx0bzpkbXVkcmljQGF2YXlhLmNvbT4+OyBMZWEgUm9iZXJ0cw0KPiA8bGVh LnJvYmVydHNAc3RhbmZvcmQuZWR1PG1haWx0bzpsZWEucm9iZXJ0c0BzdGFuZm9yZC5lZHU+Pjsg Sk9SREkgUEFMRVQgTUFSVElORVoNCj4gPGpvcmRpLnBhbGV0PTQwY29uc3VsaW50ZWwuZXNAZG1h cmMuaWV0Zi5vcmc8bWFpbHRvOjQwY29uc3VsaW50ZWwuZXNAZG1hcmMuaWV0Zi5vcmc+Pg0KPiBD YzogZHJhZnQtcGFsZXQtdjZvcHMtcmZjNjE3Ny1iaXNAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LXBh bGV0LXY2b3BzLXJmYzYxNzctYmlzQGlldGYub3JnPjsgSVB2NiBPcGVyYXRpb25zDQo+IDx2Nm9w c0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+Pg0KPiBTdWJqZWN0OiBSZTogW3Y2b3Bz XSBJLUQgQWN0aW9uOiBkcmFmdC1wYWxldC12Nm9wcy1yZmM2MTc3LWJpcy0wMC50eHQNCj4NCj4g T24gMjAxOC0wOC0yOCAwNjoyMywgTXVkcmljLCBEdXNhbiAoRHVzYW4pIHdyb3RlOg0KPiA+IFNl Y3Rpb24gNC4NCj4gPiAiICAgYi4gIEFuIGVuZC11c2VyIHNob3VsZCBiZSBhYmxlIHRvIHJlY2Vp dmUgYW55IHByZWZpeCBsZW5ndGggdXAgdG8gLzQ4DQo+ID4gICAgICAgIHNpbXBseSBieSBhc2tp bmcuIg0KPiA+DQo+ID4gQ2FuICB0aGlzIGJlIGRlZmluZWQgaW4gYSB3YXkgdG8gbWFrZSBzdXJl IHRoYXQgbmV3IGFwcGxpY2F0aW9ucyBhbmQNCj4gZGV2aWNlcyB3aWxsIGFsd2F5cyB3b3JrIGF0 IGVuZCBzaXRlcyB3aXRob3V0IGEgbmVlZCBmb3IgYXNraW5nIElTUHMgZm9yIGV4dHJhDQo+IGFk ZHJlc3Mgc3BhY2U/IE90aGVyd2lzZSwgdGhlIGVuZC11c2VyIG1pZ2h0IG5vdCBnZXQgd2hhdCBo ZS9zaGUgYXNrcyBmb3IsDQo+IHdpdGhvdXQgcGF5aW5nIGZvciB0aGUgImhpZ2hlciBncmFkZSIg c2VydmljZS4gQ2FuIHRoZSBkZWZpbml0aW9uIGltcG9zZSB1cA0KPiB0byAvNDggTEFQIHdoZW4g bmVlZGVkIGF0IGVuZCBzaXRlcz8gRm9yIGV4YW1wbGUsIGNhbiBhbiBhcHBsaWNhdGlvbg0KPiBy ZXF1ZXN0IGEgaG9tZSByb3V0ZXIgdG8gcmVxdWVzdCBhbiBJU1AgZm9yIC80OCBwcmVmaXggYW5k LCB3aGVuIHJlcXVlc3RlZCwNCj4gSVNQIG11c3QgZ3JhbnQgaXQ/DQo+DQo+IFVuZm9ydHVuYXRl bHkgd2UgY2FuIG5ldmVyIHNheSAibXVzdCIgaW4gdGhpcyBjb250ZXh0LiBXaGF0IElTUHMgd2ls bA0KPiBwcm92aWRlDQo+IGZvciB3aGF0IGZlZSBpcyB3ZWxsIG91dHNpZGUgdGhlIElFVEYncyBj b21wZXRlbmNlLiBBcyBvYnNlcnZlZCBvbiBhbm90aGVyDQo+IHRocmVhZCwgYXBwbGljYXRpb25z IG5lZWQgdG8gYmUgYWdpbGUsIGV2ZW4gaWYgdGhleSB3b3JrIGJldHRlciBpZiBzdWNoIGENCj4g cmVxdWVzdCB3YXMgZ3JhbnRlZC4NCj4NCj4gSSdkIHNheSB0aGF0IG9uY2UgdGhpcyB1cGRhdGUg aXMgZG9uZSwgaXQgbWF5IGJlIHRpbWUgdG8gcmV2aXNpdA0KPiBSRkM0MDg0Lg0KPg0KPiBSZWdh cmRzDQo+ICAgICBCcmlhbg0KPg0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPiBEdXNhbiBNdWRyaWMu DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogdjZvcHMg PHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc+PiBP biBCZWhhbGYgT2YgTGVhIFJvYmVydHMNCj4gPj4gU2VudDogVGh1cnNkYXksIEp1bHkgMTksIDIw MTggMjowOCBQTQ0KPiA+PiBUbzogQnJpYW4gRSBDYXJwZW50ZXIgPGJyaWFuLmUuY2FycGVudGVy QGdtYWlsLmNvbTxtYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPj47IEpPUkRJIFBB TEVUDQo+ID4+IE1BUlRJTkVaIDxqb3JkaS5wYWxldD00MGNvbnN1bGludGVsLmVzQGRtYXJjLmll dGYub3JnPG1haWx0bzo0MGNvbnN1bGludGVsLmVzQGRtYXJjLmlldGYub3JnPj4NCj4gPj4gQ2M6 IGRyYWZ0LXBhbGV0LXY2b3BzLXJmYzYxNzctYmlzQGlldGYub3JnPG1haWx0bzpkcmFmdC1wYWxl dC12Nm9wcy1yZmM2MTc3LWJpc0BpZXRmLm9yZz47IElQdjYgT3BlcmF0aW9ucw0KPiA+PiA8djZv cHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPj4NCj4gPj4gU3ViamVjdDogUmU6IFt2 Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtcGFsZXQtdjZvcHMtcmZjNjE3Ny1iaXMtMDAudHh0DQo+ ID4+DQo+ID4+IGhpIEJyaWFuIGFuZCBKb3JkaSAtDQo+ID4+DQo+ID4+IGV4Y2VsbGVudCBjb21t ZW50cyBhbmQgSSBhZ3JlZSBhbHNvLg0KPiA+Pg0KPiA+PiB0aGFuayB5b3UhIQ0KPiA+PiAvTGVh DQo+ID4+DQo+ID4+IE9uIFRodSwgMTkgSnVsIDIwMTgsIEpPUkRJIFBBTEVUIE1BUlRJTkVaIHdy b3RlOg0KPiA+Pg0KPiA+Pj4gSGkgQnJpYW4sDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBU aGFua3MgYSBsb3QgZm9yIGNvbW1lbnRpbmcgYW5kIHNvcnJ5IHRoZSBsYXRlIGFuc3dlciAuLi4g dG9vIGJ1c3kgbGFzdA0KPiA+PiB3ZWVrcy4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IENv bW1lbnRzIGluLWxpbmUgYmVsb3cgKHN1YmplY3RlZCB0byBteSBjby1hdXRob3IgYWdyZWVtZW50 KSwNCj4gYmFzaWNhbGx5LA0KPiA+PiBhZ3JlZSB3aXRoIGFsbCB5b3VyIGlucHV0cywgZXhjZXB0 IGEgY291cGxlIG9mIHBvaW50cy4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IFRoYW5rcyEN Cj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IFJlZ2FyZHMsDQo+ID4+Pg0KPiA+Pj4gSm9yZGkN Cj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiDv u78tLS0tLU1lbnNhamUgb3JpZ2luYWwtLS0tLQ0KPiA+Pj4NCj4gPj4+IERlOiB2Nm9wcyA8djZv cHMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZz4+IGVuIG5v bWJyZSBkZSBCcmlhbiBFIENhcnBlbnRlcg0KPiA+PiA8YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwu Y29tPG1haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+Pg0KPiA+Pj4NCj4gPj4+IE9y Z2FuaXphY2k/bjogVW5pdmVyc2l0eSBvZiBBdWNrbGFuZA0KPiA+Pj4NCj4gPj4+IEZlY2hhOiBk b21pbmdvLCA4IGRlIGp1bGlvIGRlIDIwMTgsIDE3OjQzDQo+ID4+Pg0KPiA+Pj4gUGFyYTogPGRy YWZ0LXBhbGV0LXY2b3BzLXJmYzYxNzctYmlzQGlldGYub3JnPG1haWx0bzpkcmFmdC1wYWxldC12 Nm9wcy1yZmM2MTc3LWJpc0BpZXRmLm9yZz4+LCBJUHY2IE9wZXJhdGlvbnMNCj4gPj4gPHY2b3Bz QGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4+DQo+ID4+Pg0KPiA+Pj4gQXN1bnRvOiBS ZTogW3Y2b3BzXSBJLUQgQWN0aW9uOiBkcmFmdC1wYWxldC12Nm9wcy1yZmM2MTc3LWJpcy0wMC50 eHQNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ICAgIEhpLA0KPiA+Pj4NCj4gPj4+DQo+ID4+ Pg0KPiA+Pj4gICAgVGhhbmtzIGZvciB0aGlzIGRyYWZ0Lg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0K PiA+Pj4gICAgPiBBYnN0cmFjdA0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gICAgVGhpcyBu ZWVkcyB0byBiZSBzaG9ydGVyLiBUaHJlZSBwYXJhZ3JhcGhzIGlzIHRvbyBtdWNoLg0KPiA+Pj4N Cj4gPj4+DQo+ID4+Pg0KPiA+Pj4gRm9yIHRoZSBuZXh0IHZlcnNpb24sIEkndmUgcmVkdWNlZCA1 MCUgdGhlIGxlbmd0aCBvZiB0aGUgMXN0IHBhcmFncmFwaC4NCj4gM3JkDQo+ID4+IHBhcmFncmFw aCwgSSByZWNhbGwgaXMgbWFuZGF0b3J5IChJRE5pdHMpLg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0K PiA+Pj4NCj4gPj4+DQo+ID4+PiAgICA+IC4uLiBwb2xpY3kgc2hvdWxkIHJlZmxlY3QgdGhhdCBh c3NpZ25tZW50IG9mIGEgc2luZ2xlIHN1Ym5ldCBpcw0KPiA+Pj4NCj4gPj4+ICAgID4gbm8gbG9u Z2VyIGFwcHJvcHJpYXRlIHVubGVzcyB0aGUgcmVjaXBpZW50IGV4cGxpY2l0bHkgYWdyZWVzIHRv IHRoZQ0KPiA+Pj4NCj4gPj4+ICAgID4gbGltaXRhdGlvbnMgaW1wbGllZCBieSBzdWNoIGFuIGFz c2lnbm1lbnQuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAgICBJICpzdHJvbmdseSogc3Vn Z2VzdCBkZWxldGluZyB0aGUgInVubGVzcyIgY2xhdXNlLiBJdCBsZWF2ZXMgYQ0KPiA+Pj4NCj4g Pj4+ICAgIGxvb3Bob2xlLCBhbmQgaXQgY291bGQgZWFzaWx5IGJlIGhpZGRlbiBpbiBzaHJpbmst d3JhcCB0ZXJtcw0KPiA+Pj4NCj4gPj4+ICAgIGFuZCBjb25kaXRpb25zIHNvIHRoYXQgYSBzdWJz Y3JpYmVyIHdvdWxkIGFncmVlIHdpdGhvdXQgZXZlbg0KPiA+Pj4NCj4gPj4+ICAgIGtub3dpbmcg YWJvdXQgaXQuIFJlZHVjZSB0aGlzIHNpbXBseSB0bzoNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4g Pj4+ICAgICAgIC4uLiBwb2xpY3kgc2hvdWxkIHJlZmxlY3QgdGhhdCBhc3NpZ25tZW50IG9mIGEg c2luZ2xlIHN1Ym5ldCBpcw0KPiA+Pj4NCj4gPj4+ICAgICAgIG5ldmVyIGFwcHJvcHJpYXRlLg0K PiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gQWdyZWVkIGFuZCBkb25lLg0KPiA+Pj4NCj4gPj4+ DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAgICA+IDEuICBJbnRyb2R1Y3Rpb24NCj4gPj4+ DQo+ID4+PiAgICAuLi4uDQo+ID4+Pg0KPiA+Pj4gICAgPiAgICAxLiAgSXQgaXMgZXh0cmVtZWx5 IGRpc2NvdXJhZ2VkIHRoYXQgLzEyOHMgYmUgZ2l2ZW4gb3V0LiAgV2hpbGUgdGhlcmUNCj4gPj4+ DQo+ID4+PiAgICA+ICAgICAgICBtYXkgYmUgc29tZSBjYXNlcyB3aGVyZSBhc3NpZ25pbmcgb25s eSBhIHNpbmdsZSBhZGRyZXNzIG1heSBiZQ0KPiA+Pj4NCj4gPj4+ICAgID4gICAgICAgIGp1c3Rp ZmllZCwgYSBzaXRlLCBieSBkZWZpbml0aW9uLCBpbXBsaWVzIG11bHRpcGxlIHN1Ym5ldHMgYW5k DQo+ID4+Pg0KPiA+Pj4gICAgPiAgICAgICAgbXVsdGlwbGUgZGV2aWNlcy4NCj4gPj4+DQo+ID4+ Pg0KPiA+Pj4NCj4gPj4+ICAgIEkgZmluZCB0aGlzIGEgYml0IHdlYWsuIFRyeToNCj4gPj4+DQo+ ID4+Pg0KPiA+Pj4NCj4gPj4+ICAgICAgIDEuICBJdCBpcyBleHRyZW1lbHkgZGlzY291cmFnZWQg dGhhdCAvMTI4cyBiZSBnaXZlbiBvdXQuICBXaGlsZSB0aGVyZQ0KPiA+Pj4NCj4gPj4+ICAgICAg ICAgICBtYXkgYmUgc29tZSBhcHBsaWNhdGlvbnMgd2hlcmUgYXNzaWduaW5nIG9ubHkgYSBzaW5n bGUgYWRkcmVzcw0KPiBtYXkNCj4gPj4gYmUNCj4gPj4+DQo+ID4+PiAgICAgICAgICAgdG9sZXJh dGVkLCBhIHNpdGUsIGJ5IGRlZmluaXRpb24sIGltcGxpZXMgbXVsdGlwbGUgc3VibmV0cyBhbmQN Cj4gPj4+DQo+ID4+PiAgICAgICAgICAgbXVsdGlwbGUgZGV2aWNlcy4gQWxzbywgYSAvMTI4IHBy ZXZlbnRzIGFueSBmb3JtIG9mIHByaXZhY3ktYmFzZWQNCj4gPj4+DQo+ID4+PiAgICAgICAgICAg YWRkcmVzc2luZy4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IEFncmVlZCENCj4gPj4+DQo+ ID4+Pg0KPiA+Pj4NCj4gPj4+ICAgID4gICAgNC4gIFRoaXMgcmV2aXNpb24gaGFzIGJlZW4gY3Jl YXRlZCB0byBtb3JlIGNsZWFybHkgYXNzZXJ0IHRoZQ0KPiA+Pj4NCj4gPj4+ICAgID4gICAgICAg IHJlcXVpcmVtZW50IHRvIGVuc3VyZSB0aGF0IGFkZHJlc3MgYXNzaWdubWVudHMgdG8gZW5kLXNp dGVzDQo+ID4+Pg0KPiA+Pj4gICAgPiAgICAgICAgcHJvdmlkZSBhIHN1ZmZpY2llbnRseSBiaWcg bnVtYmVyIG9mIHN1Ym5ldHMgKC82NCBvbiBjbGFzc2ljDQo+ID4+Pg0KPiA+Pj4gICAgPiAgICAg ICAgbmV0d29ya3MpIHRvIGVhY2ggZW5kLXNpdGUsIHRha2luZyB1bmRlciBjb25zaWRlcmF0aW9u IHRoZSBlbmQtDQo+ID4+Pg0KPiA+Pj4gICAgPiAgICAgICAgc2l0ZSdzIGZ1dHVyZSBleHBlY3Rl ZCBuZWVkcywgbmV3IGRlcGxveW1lbnQgZXhwZWN0YXRpb25zIGFuZA0KPiA+PiBuZXcNCj4gPj4+ DQo+ID4+PiAgICA+ICAgICAgICBwcm90b2NvbCByZXF1aXJlbWVudHMsIGFtb25nIG90aGVycy4g IE9uY2UgYWxsIHRoZXNlIGFyZQ0KPiA+Pj4NCj4gPj4+ICAgID4gICAgICAgIGNvbnNpZGVyZWQs IGl0IHNlZW1zIHVubGlrZWx5IHRoYXQgYSBzaW5nbGUgc3VibmV0ICgvNjQpIG9yIGV2ZW4NCj4g Pj4+DQo+ID4+PiAgICA+ICAgICAgICBhIHNtYWxsIG51bWJlciBvZiB0aGVtIHNob3VsZCBiZSBh c3NpZ25lZCwgdW5sZXNzIHZlcnkgY2xlYXJseQ0KPiA+Pj4NCj4gPj4+ICAgID4gICAgICAgIGp1 c3RpZmllZCBhbmQgYWdyZWVkIHRvIGJ5IHRoZSBlbmQtc2l0ZS4NCj4gPj4+DQo+ID4+Pg0KPiA+ Pj4NCj4gPj4+ICAgIFRoZSAidW5sZXNzIiBjbGF1c2UgaXMgZGFuZ2Vyb3VzIGJlY2F1c2Ugb2Yg c2hyaW5rLXdyYXAgdGVybXMgYW5kDQo+ID4+Pg0KPiA+Pj4gICAgY29uZGl0aW9ucy4gSSBzdWdn ZXN0IGRlbGV0aW5nIGl0Lg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gQWdyZWVkIQ0KPiA+ Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gICAgPiAyLiAgQ29uc2lkZXJhdGlvbnMgUmVnYXJkaW5n IHRoZSBQcmVmaXggTGVuZ3RoDQo+ID4+Pg0KPiA+Pj4gICAgLi4uLg0KPiA+Pj4NCj4gPj4+ICAg ID4gICAgVGhpcyBjb25zaWRlcmF0aW9uIHNob3VsZCBiZSBub3RpY2VkLCBhY3Jvc3MgdGhpcyBk b2N1bWVudCwgaW4gdGhlDQo+ID4+Pg0KPiA+Pj4gICAgPiAgICBzZW5zZSB0aGF0IGVuZC1zaXRl cyB1c3VhbGx5IGhhdmUgc3VibmV0cyB0aGF0IHVzZSwgYnkgZGVmYXVsdCwNCj4gPj4+DQo+ID4+ PiAgICA+ICAgIFNMQUFDLCBhbmQgY29uc2VxdWVudGx5LCB0aGUgTEFQIGlzIG1hbmRhdG9yaWx5 IGEgLzY0LiAgT3RoZXINCj4gPj4+DQo+ID4+PiAgICA+ICAgIHRlY2hub2xvZ2llcywgbWF5IGhh dmUgYSBkaWZmZXJlbnQgTEFQLCB3aGljaCBtdXN0IGJlIHVzZWQNCj4gPj4+DQo+ID4+PiAgICA+ ICAgIGFjY29yZGluZ2x5Lg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gICAgSSBzdWdnZXN0 IHMvT3RoZXIvRnV0dXJlLyBzaW5jZSAvNjQgcHJldmFpbHMgZXZlcnl3aGVyZSB0b2RheS4NCj4g Pj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IEFncmVlZCENCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4g Pj4+ICAgID4gMy4gIE9uIC80OCBBc3NpZ25tZW50cyB0byBFbmQtU2l0ZXMNCj4gPj4+DQo+ID4+ PiAgICAuLi4uDQo+ID4+Pg0KPiA+Pj4gICAgPiAgICBBbiBpbXBvcnRhbnQNCj4gPj4+DQo+ID4+ PiAgICA+ICAgIGdvYWwgaW4gSVB2NiBpcyB0byBzaWduaWZpY2FudGx5IGNoYW5nZSB0aGUgZGVm YXVsdCBhbmQgbWluaW1hbCBlbmQNCj4gPj4+DQo+ID4+PiAgICA+ICAgIHNpdGUgYXNzaWdubWVu dCwgZnJvbSAiYSBzaW5nbGUgYWRkcmVzcyIgdG8gIm11bHRpcGxlIG5ldHdvcmtzIiBhbmQNCj4g Pj4+DQo+ID4+PiAgICA+ICAgIHRvIGVuc3VyZSB0aGF0IGVuZC1zaXRlcyBjYW4gZWFzaWx5IG9i dGFpbiBhZGRyZXNzIHNwYWNlLg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gICAgSSBzdWdn ZXN0IGFkZGluZyBzb21ldGhpbmcgbGlrZSB0aGlzOg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+ Pj4gICAgQXMgdGhlIG9wZXJhdGlvbmFsIGNvc3RzIG9mIGNhcnJpZXItZ3JhZGUgTkFUIGFuZCBh ZGRyZXNzK3BvcnQgc2hhcmluZw0KPiA+Pj4NCj4gPj4+ICAgIGhhdmUgc2hvd24sIGF2YWlsYWJp bGl0eSBvZiBtdWx0aXBsZSBhZGRyZXNzZXMgYW5kIHByZWZpeGVzIHRvIGVuZCBzaXRlcw0KPiA+ Pj4NCj4gPj4+ICAgIHRoYXQgbmVlZCB0aGVtIHdpbGwgYmUgYSBjb25zaWRlcmFibGUgc2F2aW5n IHRvIHRoZWlyIElTUHMuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBBZ3JlZWQhDQo+ID4+ Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAgICA+ICAgIEl0IG1pZ2h0IGJlIHRlbXB0aW5nIHRvIGdp dmUgaG9tZSBzaXRlcyBhIHNpbmdsZSAvNjQsIHNpbmNlIHRoYXQgaXMNCj4gPj4+DQo+ID4+PiAg ICA+ICAgIGFscmVhZHkgc2lnbmlmaWNhbnRseSBtb3JlIGFkZHJlc3Mgc3BhY2UgY29tcGFyZWQg d2l0aCB0b2RheSdzDQo+IElQdjQNCj4gPj4+DQo+ID4+PiAgICA+ICAgIHByYWN0aWNlLiAgSG93 ZXZlciwgdGhpcyBwcmVjbHVkZXMgdGhlIGV4cGVjdGF0aW9uIHRoYXQgZXZlbiBob21lDQo+ID4+ Pg0KPiA+Pj4gICAgPiAgICBzaXRlcyB3aWxsIGdyb3cgdG8gc3VwcG9ydCBtdWx0aXBsZSBzdWJu ZXRzIGdvaW5nIGZvcndhcmQuICBIZW5jZSwgaXQNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ ICAgIHMvZXhwZWN0YXRpb24vY2VydGFpbnR5Lw0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4g QWdyZWVkIQ0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gICAgLi4uLg0KPiA+Pj4NCj4gPj4+ ICAgID4gICAgQSBrZXkgZ29hbCBvZiB0aGUgcmVjb21tZW5kYXRpb25zIGluIFtSRkMzMTc3XSBp cyB0bw0KPiA+Pj4NCj4gPj4+ICAgID4gICAgZW5zdXJlIHRoYXQgdXBvbiByZW51bWJlcmluZywg b25lIGRvZXMgbm90IGhhdmUgdG8gZGVhbCB3aXRoDQo+ID4+Pg0KPiA+Pj4gICAgPiAgICByZW51 bWJlcmluZyBpbnRvIGEgc21hbGxlciBzdWJuZXQgc2l6ZS4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4N Cj4gPj4+ICAgIFBlcmhhcHMgYWRkOg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gICAgSW4g cGFydGljdWxhciB0aGlzIHdvdWxkIGFwcGx5IHRvIGFueSBzaXRlIHRoYXQgc3dpdGNoZXMgdG8N Cj4gPj4+DQo+ID4+PiAgICBhbiBJU1AgdGhhdCBwcm92aWRlcyBhIGxvbmdlciBwcmVmaXguDQo+ ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBBZ3JlZWQhDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ ID4+PiAgICA+ICAgIEl0IHNob3VsZCBiZSBub3RlZCB0aGF0IHNpbWlsYXIgYXJndW1lbnRzIGFw cGx5IHRvIHRoZSBtYW5hZ2VtZW50DQo+IG9mDQo+ID4+Pg0KPiA+Pj4gICAgPiAgICB6b25lIGZp bGVzIGluIHRoZSBETlMuICBJbiBwYXJ0aWN1bGFyLCBtYW5hZ2luZyB0aGUgcmV2ZXJzZQ0KPiA+ Pj4NCj4gPj4+ICAgID4gICAgKGlwNi5hcnBhKSB0cmVlIGlzIHNpbXBsaWZpZWQgd2hlbiBhbGwg bGlua3MgYXJlIG51bWJlcmVkIHVzaW5nIHRoZQ0KPiA+Pj4NCj4gPj4+ICAgID4gICAgc2FtZSBz dWJuZXQgaWRzDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAgICBzL251bWJlcmVkL3JlbnVt YmVyZWQvDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBBZ3JlZWQhDQo+ID4+Pg0KPiA+Pj4N Cj4gPj4+DQo+ID4+PiAgICAuLi4uDQo+ID4+Pg0KPiA+Pj4gICAgPiAgICB5ZWFycywgYW5kIHdl IGRvbid0IHJlY292ZXIgYmFjayB0aGUgLzQ4J3MsIHdlIHdpbGwgYmUgYWJsZSB0byB1c2UNCj4g Pj4+DQo+ID4+PiAgICA+ICAgIElQdjYgYWRkcmVzc2luZyBzcGFjZSBmb3Igb3ZlciAxMDAuMDAw IHllYXJzLg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gICAgUGVyaGFwcyBhZGQ6DQo+ID4+ Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAgICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IGFkdm9jYXRl IGNhcmVsZXNzIHVzZSBvZiBhZGRyZXNzIHNwYWNlLCBidXQNCj4gPj4+DQo+ID4+PiAgICB0aGVy ZSBpcyBvYmplY3RpdmVseSBubyByZWFzb24gdG8gYmUgcmVzdHJpY3R2ZS4NCj4gPj4+DQo+ID4+ Pg0KPiA+Pj4NCj4gPj4+IEFncmVlZCENCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ICAgIC4u Li4NCj4gPj4+DQo+ID4+PiAgICA+ICAgIFRvZGF5IHR5cGljYWxseSwgYSBob21lIGhhcyBhbHJl YWR5IGEgY29uc2lkZXJhYmxlIG51bWJlciBvZg0KPiBwb3NzaWJsZQ0KPiA+Pj4NCj4gPj4+ICAg ID4gICAgc3VibmV0cyAoYSBjb21tb24gQ0UgaGFzIDQgTEFOIHBvcnRzLCAyIFdpRmkgcmFkaW9z IHdoaWNoIHN1cHBvcnQNCj4gPj4+DQo+ID4+PiAgICA+ICAgIHNldmVyYWwgU1NJRHMgZWFjaCBv bmUsIFZvSVAgc3VibmV0LCBJUFRWIHN1Ym5ldCwgYWRkaXRpb25hbA0KPiBWTEFOcykNCj4gPj4+ DQo+ID4+PiAgICA+ICAgIGFuZCBpZiBkb3duc3RyZWFtIHJvdXRlcnMgYXJlIHVzZWQsIHRoZXJl IGlzIGEgbmVlZCBmb3IgZnVydGhlcg0KPiA+Pj4NCj4gPj4+ICAgID4gICAgc3VibmV0cy4gIFRo aXMgbWVhbnMgdGhhdCBpbiBhIHNob3J0IHRlcm0sIGFzc2lnbmluZyBhIC82MCAoMTYNCj4gPj4+ DQo+ID4+PiAgICA+ICAgIHN1Ym5ldHMpLCBpdCBpcyBhbHJlYWR5IGEgcmVhbGx5IGJhZCBkZWNp c2lvbiwgYXMgaXQgbWF5IGVuZm9yY2UgSVB2Ng0KPiA+Pj4NCj4gPj4+ICAgID4gICAgTkFUIGJl dHdlZW4gdGhlIG1haW4gQ0UgYW5kIGRvd25zdHJlYW0gcm91dGVycy4NCj4gPj4+DQo+ID4+Pg0K PiA+Pj4NCj4gPj4+ICAgIEkgc3VnZ2VzdCBkZWxldGluZyAiYXMgaXQgbWF5IGVuZm9yY2UgSVB2 NiBOQVQgYmV0d2VlbiB0aGUgbWFpbiBDRQ0KPiBhbmQNCj4gPj4+DQo+ID4+PiAgICBkb3duc3Ry ZWFtIHJvdXRlcnMiLiBGaXJzdGx5IGl0IHB1dHMgTkFUIGludG8gdGhlIHJlYWRlcidzIG1pbmQu DQo+IFNlY29uZGx5LA0KPiA+Pj4NCj4gPj4+ICAgIGl0IGlzbid0IHRoZSBvbmx5IHNvbHV0aW9u IC0gSUlEcyBzaG9ydGVyIHRoYW4gNjQgY291bGQgYWxzbyBiZQ0KPiBpbXBsZW1lbnRlZC4NCj4g Pj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IEFncmVlZCENCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4g Pj4+ICAgID4gNC4gIEltcGFjdCBvbiBJUHY2IFN0YW5kYXJkcw0KPiA+Pj4NCj4gPj4+DQo+ID4+ Pg0KPiA+Pj4gICAgSSBwcm9wb3NlIHRvIHNpbXBseSBkZWxldGUgdGhpcyBzZWN0aW9uLg0KPiA+ Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gICAgRmlyc3RseSwgUkZDMzA1NiBpcyBkZXByZWNhdGVk IHNvIGl0J3MgaXJyZWxldmFudCB0b2RheS4NCj4gPj4+DQo+ID4+PiAgICBTZWNvbmRseSwgdGhl IGFyZ3VtZW50IGFib3V0IFVMQXMgKFJGQzQxOTMpIGRvZXNuJ3QgaG9sZCB1cC4NCj4gPj4+DQo+ ID4+PiAgICBVTEFzIGFyZSBsaWtlIGFueSBvdGhlciAvNDggcHJlZml4IC0gaWYgeW91IGFyZSBm b3JjZWQgdG8NCj4gPj4+DQo+ID4+PiAgICByZW51bWJlciBpbnRvIGEgbG9uZ2VyIHByZWZpeCwg eW91IGxvc2Ugc29tZSBzdWJuZXQgYml0cy4NCj4gPj4+DQo+ID4+PiAgICBUaGF0IGlzIGFscmVh ZHkgY292ZXJlZCBpbiB0aGUgbWlkZGxlIG9mIHNlY3Rpb24gMyAodGhlDQo+ID4+Pg0KPiA+Pj4g ICAgImtleSBnb2FsIiBzZW50ZW5jZSBxdW90ZWQgYWJvdmUpLg0KPiA+Pj4NCj4gPj4+DQo+ID4+ Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBJIHJlY2FsbCB3ZSBkZXByZWNhdGVkIHRoZSA2dG80IGFu eWNhc3QsIGJ1dCBub3QgNnRvNCwgaW4gZmFjdCA2dG80IHRvIDZ0bzQNCj4gPj4gdHJhZmZpYyBp cyBzdGlsbCB1c2VmdWwgZm9yIHBlZXIgdG8gcGVlci4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4g Pj4+ICAgID4gNi4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQo+ID4+Pg0KPiA+Pj4gICAgPg0K PiA+Pj4NCj4gPj4+ICAgID4gICAgVGhpcyBkb2N1bWVudCBoYXMgbm8ga25vd24gc2VjdXJpdHkg aW1wbGljYXRpb25zLg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gICAgUmVhbGx5PyBNb3Jl IHByZWZpeCBzcGFjZSBvZmZlcnMgbW9yZSBwb3RlbnRpYWwgZm9yIHNjYW5uaW5nDQo+ID4+Pg0K PiA+Pj4gICAgYXR0YWNrcy4gTW9yZSBwcmVmaXggc3BhY2UgYWxzbyBhbGxvd3MgdGhlIHVzZSBv ZiBzbGlnaHRseQ0KPiA+Pj4NCj4gPj4+ICAgIHJhbmRvbWl6ZWQgcHJlZml4ZXMgYW5kL29yIHBy ZWZpeC1wZXIgaG9zdC4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ICAgIEFsc28gb2YgY291 cnNlLCBhIC8xMjggd291bGQgcHJldmVudCBhbnkgZm9ybSBvZiBwcml2YWN5LWJhc2VkDQo+ID4+ Pg0KPiA+Pj4gICAgYWRkcmVzc2luZy4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IEkndmUg aW50cm9kdWNlZCBuZXcgdGV4dCBvbiB0aG9zZSBwb2ludHMuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ DQo+ID4+PiAgICA+IDguICBBY2tub3dsZWRnZW1lbnRzDQo+ID4+Pg0KPiA+Pj4gICAgPg0KPiA+ Pj4NCj4gPj4+ICAgID4gICAgVGhlIGF1dGhvcnMgb2YgdGhpcyBkb2N1bWVudCB3aWxsIGxpa2Ug dG8gYWNrbm93bGVkZ2UgdGhlIGF1dGhvcnMNCj4gb2YNCj4gPj4+DQo+ID4+PiAgICA+ICAgIHBy ZXZpb3VzIHZlcnNpb25zIChUaG9tYXMgTmFydGVuIGFuZCBHZW9mZiBIdXN0b24pDQo+ID4+Pg0K PiA+Pj4NCj4gPj4+DQo+ID4+PiAgICBSRkMzMTc3IHdhcyBzaWduZWQgYnkgdGhlIHdob2xlIElB QiBhbmQgSUVTRyBzZWF0ZWQgaW4gMjAwMSwgYW5kIGl0cw0KPiA+Pj4NCj4gPj4+ICAgIEFja25v d2xlZGdlbWVudHMgcmVhZDoNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ICAgID4+ICAgIFRo aXMgZG9jdW1lbnQgb3JpZ2luYXRlZCBmcm9tIHRoZSBJRVRGIElQdjYgZGlyZWN0b3JhdGUsIHdp dGgNCj4gbXVjaA0KPiA+Pj4NCj4gPj4+ICAgID4+ICAgIGlucHV0IGZyb20gdGhlIElBQiBhbmQg SUVTRy4gIFRoZSBvcmlnaW5hbCB0ZXh0IGZvcm1pbmcgdGhlIGJhc2lzIG9mDQo+ID4+Pg0KPiA+ Pj4gICAgPj4gICAgdGhpcyBkb2N1bWVudCB3YXMgY29udHJpYnV0ZWQgYnkgRnJlZCBCYWtlciBh bmQgQnJpYW4gQ2FycGVudGVyLg0KPiA+Pj4NCj4gPj4+ICAgID4+ICAgIEFsbGlzb24gTWFua2lu IGFuZCBUaG9tYXMgTmFydGVuIG1lcmdlZCB0aGUgb3JpZ2luYWwNCj4gY29udHJpYnV0aW9ucw0K PiA+Pj4NCj4gPj4+ICAgID4+ICAgIGludG8gYSBzaW5nbGUgZG9jdW1lbnQsIGFuZCBBbGFpbiBE dXJhbmQgZWRpdGVkIHRoZSBkb2N1bWVudA0KPiA+PiB0aHJvdWdoDQo+ID4+Pg0KPiA+Pj4gICAg Pj4gICAgaXRzIGZpbmFsIHN0YWdlcy4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IEFncmVl ZCENCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ICAgIFJlZ2FyZHMNCj4gPj4+DQo+ID4+PiAg ICAgICAgQnJpYW4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ICAgIF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+Pg0KPiA+Pj4gICAgdjZvcHMg bWFpbGluZyBsaXN0DQo+ID4+Pg0KPiA+Pj4gICAgdjZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3Bz QGlldGYub3JnPg0KPiA+Pj4NCj4gPj4+ICAgIGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0NCj4gPj4NCj4gM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xp c3RpbmZvX3Y2b3BzJmQ9RHdJRGFRJmM9QkZwV1F3OGJzdUtwDQo+ID4+IGwxU2dpWkg2NFEmcj1V VDNCazljYkxlYUp4aGYzaUNyaElvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09LQ0KPiA+Pg0KPiA1 cmdZcV9uWU1iU0gySFhIbkhGQ0ZpMktEWXpPQ2xoU2lMbjBhdThXdTAmcz1pRXExdFVEYmVRTDRm M1NMTQ0KPiA+PiBmMS14aWhqSllUMEtBQU5fQldUbDktNzc5YyZlPQ0KPiA+Pj4NCj4gPj4+DQo+ ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKg0KPiA+Pj4gSVB2NCBpcyBvdmVyDQo+ID4+PiBBcmUgeW91 IHJlYWR5IGZvciB0aGUgbmV3IEludGVybmV0ID8NCj4gPj4+IGh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLQ0KPiA+Pg0KPiAzQV9fd3d3LmNvbnN1bGludGVs LmVzPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX18z QS01Ri01Rnd3dy5jb25zdWxpbnRlbC5lcyZkPUR3TUZhUSZjPUJGcFdRdzhic3VLcGwxU2dpWkg2 NFEmcj1VVDNCazljYkxlYUp4aGYzaUNyaElvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJm09TVlHOEJf bXY5aE56enVNdGdnVHdWdHBSZU9YUjVEQWUzVUFacVlBUkRDayZzPWJMWkxReDI4a3BEN3d2Z0FI SkRDVURGWFhsZmFKaEZTSVJxT1lDWGZzVkkmZT0+JmQ9RHdJRGFRJmM9QkZwV1F3OGJzdUtwbDFT Z2laSDY0USZyPVVUMw0KPiA+PiBCazljYkxlYUp4aGYzaUNyaElvVVdCOFlMWlUyMzAyOXNNUUdR MmtZJm09LQ0KPiA+Pg0KPiA1cmdZcV9uWU1iU0gySFhIbkhGQ0ZpMktEWXpPQ2xoU2lMbjBhdThX dTAmcz1HTVJMZEl0Rjh5S2JVZEU5DQo+ID4+IE51WEUtVTQ4dWs3T0hOdUVpanltOWpoRS0tcyZl PQ0KPiA+Pj4gVGhlIElQdjYgQ29tcGFueQ0KPiA+Pj4NCj4gPj4+IFRoaXMgZWxlY3Ryb25pYyBt ZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yDQo+ ID4+IGNvbmZpZGVudGlhbC4gVGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVkIHRvIGJlIGZvciB0 aGUgZXhjbHVzaXZlIHVzZSBvZg0KPiB0aGUNCj4gPj4gaW5kaXZpZHVhbChzKSBuYW1lZCBhYm92 ZSBhbmQgZnVydGhlciBub24tZXhwbGljaWx0eSBhdXRob3JpemVkDQo+IGRpc2Nsb3N1cmUsDQo+ ID4+IGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMg aW5mb3JtYXRpb24sIGV2ZW4gaWYNCj4gPj4gcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQg ZmlsZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIHdpbGwgYmUNCj4gY29uc2lkZXJlZCBh DQo+ID4+IGNyaW1pbmFsIG9mZmVuc2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQgYmUgYXdhcmUgdGhhdCBhbnkNCj4gPj4gZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJp YnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwNCj4gPj4g ZXZlbiBpZiBwYXJ0aWFsbHksIGluY2x1ZGluZyBhdHRhY2hlZCBmaWxlcywgaXMgc3RyaWN0bHkg cHJvaGliaXRlZCwgd2lsbCBiZQ0KPiA+PiBjb25zaWRlcmVkIGEgY3JpbWluYWwgb2ZmZW5zZSwg c28geW91IG11c3QgcmVwbHkgdG8gdGhlIG9yaWdpbmFsIHNlbmRlciB0bw0KPiA+PiBpbmZvcm0g YWJvdXQgdGhpcyBjb21tdW5pY2F0aW9uIGFuZCBkZWxldGUgaXQuDQo+ID4+Pg0KPiA+Pj4NCj4g Pj4+DQo+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiA+Pj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+ID4+PiB2Nm9wc0BpZXRmLm9yZzxtYWlsdG86 djZvcHNAaWV0Zi5vcmc+DQo+ID4+PiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtDQo+ID4+DQo+IDNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5m b192Nm9wcyZkPUR3SURhUSZjPUJGcFdRdzhic3VLcA0KPiA+PiBsMVNnaVpINjRRJnI9VVQzQms5 Y2JMZWFKeGhmM2lDcmhJb1VXQjhZTFpVMjMwMjlzTVFHUTJrWSZtPS0NCj4gPj4NCj4gNXJnWXFf bllNYlNIMkhYSG5IRkNGaTJLRFl6T0NsaFNpTG4wYXU4V3UwJnM9aUVxMXRVRGJlUUw0ZjNTTE0N Cj4gPj4gZjEteGloakpZVDBLQUFOX0JXVGw5LTc3OWMmZT0NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnY2b3BzIG1haWxpbmcgbGlzdA0KdjZvcHNA aWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby92Nm9wczxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3Y2b3BzJmQ9RHdN RmFRJmM9QkZwV1F3OGJzdUtwbDFTZ2laSDY0USZyPVVUM0JrOWNiTGVhSnhoZjNpQ3JoSW9VV0I4 WUxaVTIzMDI5c01RR1Eya1kmbT1NWUc4Ql9tdjloTnp6dU10Z2dUd1Z0cFJlT1hSNURBZTNVQVpx WUFSRENrJnM9Tjh0Z0hwdWVHbHAyMDYyemdrMkNHZzJWbEluckI1d2V4OFc0My1ESGN4SSZlPT4N Cg0KDQoNCi0tDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KRGF2aWQgRmFybWVyICAgICAgICAgICAgICAgRW1haWw6ZmFybWVyQHVtbi5lZHU8bWFpbHRv OkVtYWlsJTNBZmFybWVyQHVtbi5lZHU+DQpOZXR3b3JraW5nICYgVGVsZWNvbW11bmljYXRpb24g U2VydmljZXMNCk9mZmljZSBvZiBJbmZvcm1hdGlvbiBUZWNobm9sb2d5DQpVbml2ZXJzaXR5IG9m IE1pbm5lc290YQ0KMjIxOCBVbml2ZXJzaXR5IEF2ZSBTRSAgICAgICAgUGhvbmU6IDYxMi02MjYt MDgxNQ0KTWlubmVhcG9saXMsIE1OIDU1NDE0LTMwMjkgICBDZWxsOiA2MTItODEyLTk5NTINCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo= --_000_9142206A0C5BF24CB22755C8EC422E459CB452E3AZUS1EXMB03glob_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlByb2dJZCIg Y29udGVudD0iV29yZC5Eb2N1bWVudCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDE1Ij4NCjxtZXRhIG5hbWU9Ik9yaWdpbmF0b3IiIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDE1Ij4NCjxsaW5rIHJlbD0iRmlsZS1MaXN0IiBocmVmPSJjaWQ6ZmlsZWxp c3QueG1sQDAxRDQzRURGLjlDQTJDODkwIj48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9m ZmljZURvY3VtZW50U2V0dGluZ3M+DQo8bzpBbGxvd1BORy8+DQo8L286T2ZmaWNlRG9jdW1lbnRT ZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPHc6 V29yZERvY3VtZW50Pg0KPHc6U3BlbGxpbmdTdGF0ZT5DbGVhbjwvdzpTcGVsbGluZ1N0YXRlPg0K PHc6RG9jdW1lbnRLaW5kPkRvY3VtZW50RW1haWw8L3c6RG9jdW1lbnRLaW5kPg0KPHc6VHJhY2tN b3Zlcy8+DQo8dzpUcmFja0Zvcm1hdHRpbmcvPg0KPHc6RW52ZWxvcGVWaXMvPg0KPHc6VmFsaWRh dGVBZ2FpbnN0U2NoZW1hcy8+DQo8dzpTYXZlSWZYTUxJbnZhbGlkPmZhbHNlPC93OlNhdmVJZlhN TEludmFsaWQ+DQo8dzpJZ25vcmVNaXhlZENvbnRlbnQ+ZmFsc2U8L3c6SWdub3JlTWl4ZWRDb250 ZW50Pg0KPHc6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4dD5mYWxzZTwvdzpBbHdheXNTaG93UGxh Y2Vob2xkZXJUZXh0Pg0KPHc6RG9Ob3RQcm9tb3RlUUYvPg0KPHc6TGlkVGhlbWVPdGhlcj5FTi1V UzwvdzpMaWRUaGVtZU90aGVyPg0KPHc6TGlkVGhlbWVBc2lhbj5YLU5PTkU8L3c6TGlkVGhlbWVB c2lhbj4NCjx3OkxpZFRoZW1lQ29tcGxleFNjcmlwdD5YLU5PTkU8L3c6TGlkVGhlbWVDb21wbGV4 U2NyaXB0Pg0KPHc6Q29tcGF0aWJpbGl0eT4NCjx3OkRvTm90RXhwYW5kU2hpZnRSZXR1cm4vPg0K PHc6QnJlYWtXcmFwcGVkVGFibGVzLz4NCjx3OlNwbGl0UGdCcmVha0FuZFBhcmFNYXJrLz4NCjx3 OkVuYWJsZU9wZW5UeXBlS2VybmluZy8+DQo8L3c6Q29tcGF0aWJpbGl0eT4NCjx3OkJyb3dzZXJM ZXZlbD5NaWNyb3NvZnRJbnRlcm5ldEV4cGxvcmVyNDwvdzpCcm93c2VyTGV2ZWw+DQo8bTptYXRo UHI+DQo8bTptYXRoRm9udCBtOnZhbD0iQ2FtYnJpYSBNYXRoIi8+DQo8bTpicmtCaW4gbTp2YWw9 ImJlZm9yZSIvPg0KPG06YnJrQmluU3ViIG06dmFsPSImIzQ1Oy0iLz4NCjxtOnNtYWxsRnJhYyBt OnZhbD0ib2ZmIi8+DQo8bTpkaXNwRGVmLz4NCjxtOmxNYXJnaW4gbTp2YWw9IjAiLz4NCjxtOnJN YXJnaW4gbTp2YWw9IjAiLz4NCjxtOmRlZkpjIG06dmFsPSJjZW50ZXJHcm91cCIvPg0KPG06d3Jh cEluZGVudCBtOnZhbD0iMTQ0MCIvPg0KPG06aW50TGltIG06dmFsPSJzdWJTdXAiLz4NCjxtOm5h cnlMaW0gbTp2YWw9InVuZE92ciIvPg0KPC9tOm1hdGhQcj48L3c6V29yZERvY3VtZW50Pg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8dzpMYXRlbnRTdHlsZXMg RGVmTG9ja2VkU3RhdGU9ImZhbHNlIiBEZWZVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIERlZlNlbWlI aWRkZW49ImZhbHNlIiBEZWZRRm9ybWF0PSJmYWxzZSIgRGVmUHJpb3JpdHk9Ijk5IiBMYXRlbnRT dHlsZUNvdW50PSIzNzUiPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSIwIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJOb3JtYWwiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAxIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5n IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9Imhl YWRpbmcgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iaGVhZGluZyA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVl IiBOYW1lPSJoZWFkaW5nIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9 InRydWUiIE5hbWU9ImhlYWRpbmcgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZv cm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA3Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgOSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJpbmRleCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgTmFtZT0iaW5kZXggMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCA0Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXgg NiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCA3Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 ImluZGV4IDgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggOSIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0idG9jIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2Mg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyA0Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJ0b2MgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 InRvYyA3Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDgiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgOSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJOb3JtYWwgSW5kZW50Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImZvb3Rub3RlIHRleHQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iYW5ub3RhdGlvbiB0ZXh0Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9ImhlYWRlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJmb290ZXIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgTmFtZT0iaW5kZXggaGVhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIzNSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IFFGb3JtYXQ9InRydWUiIE5hbWU9ImNhcHRpb24iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idGFi bGUgb2YgZmlndXJlcyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJlbnZlbG9wZSBhZGRyZXNzIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9ImVudmVsb3BlIHJldHVybiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJmb290bm90ZSByZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iYW5ub3RhdGlv biByZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0ibGluZSBudW1iZXIiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0icGFnZSBudW1iZXIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iZW5kbm90 ZSByZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iZW5kbm90ZSB0ZXh0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9InRhYmxlIG9mIGF1dGhvcml0aWVzIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9Im1hY3JvIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYSBoZWFkaW5nIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9Ikxpc3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBCdWxsZXQiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBOdW1iZXIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i TGlzdCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgMyIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJMaXN0IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCA1Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9Ikxpc3QgQnVsbGV0IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBCdWxs ZXQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IEJ1bGxldCA0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9Ikxpc3QgQnVsbGV0IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBOdW1i ZXIgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IE51bWJlciAzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9Ikxpc3QgTnVtYmVyIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBOdW1i ZXIgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxMCIgUUZv cm1hdD0idHJ1ZSIgTmFtZT0iVGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQ2xvc2luZyIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJTaWduYXR1cmUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iMSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9IkRlZmF1bHQgUGFyYWdyYXBoIEZvbnQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt ZT0iQm9keSBUZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJvZHkgVGV4dCBJbmRlbnQiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBDb250aW51ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJMaXN0IENvbnRpbnVlIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBDb250aW51ZSAz Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgQ29udGludWUgNCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJMaXN0IENvbnRpbnVlIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTWVzc2FnZSBI ZWFkZXIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMTEiIFFG b3JtYXQ9InRydWUiIE5hbWU9IlN1YnRpdGxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlNhbHV0 YXRpb24iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iRGF0ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJCb2R5IFRleHQgRmlyc3QgSW5kZW50Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJvZHkgVGV4 dCBGaXJzdCBJbmRlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJOb3RlIEhlYWRpbmciLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i Qm9keSBUZXh0IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IEluZGVudCAyIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9IkJvZHkgVGV4dCBJbmRlbnQgMyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJCbG9jayBUZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikh5cGVybGluayIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJGb2xsb3dlZEh5cGVybGluayIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMiIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3Ryb25n Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIwIiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJFbXBoYXNpcyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJEb2N1bWVudCBN YXAiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iUGxhaW4gVGV4dCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJFLW1haWwgU2lnbmF0dXJlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgVG9wIG9m IEZvcm0iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBCb3R0b20gb2YgRm9ybSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJOb3JtYWwgKFdlYikiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRN TCBBY3JvbnltIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgQWRkcmVzcyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJIVE1MIENpdGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBDb2Rl Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgRGVmaW5pdGlvbiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJIVE1MIEtleWJvYXJkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgUHJlZm9y bWF0dGVkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgU2FtcGxlIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9IkhUTUwgVHlwZXdyaXRlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIFZh cmlhYmxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik5vcm1hbCBUYWJsZSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJhbm5vdGF0aW9uIHN1YmplY3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTm8g TGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJPdXRsaW5lIExpc3QgMSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJPdXRsaW5lIExpc3QgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJPdXRsaW5l IExpc3QgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBTaW1wbGUgMSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJUYWJsZSBTaW1wbGUgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJs ZSBTaW1wbGUgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDbGFzc2ljIDEiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ2xhc3NpYyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 IlRhYmxlIENsYXNzaWMgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDbGFzc2ljIDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sb3JmdWwgMSIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJUYWJsZSBDb2xvcmZ1bCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENv bG9yZnVsIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sdW1ucyAxIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9IlRhYmxlIENvbHVtbnMgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJU YWJsZSBDb2x1bW5zIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sdW1ucyA0Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENvbHVtbnMgNSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJUYWJsZSBHcmlkIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3JpZCAyIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdyaWQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJUYWJsZSBHcmlkIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3JpZCA1Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdyaWQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJU YWJsZSBHcmlkIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3JpZCA4Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3QgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJs ZSBMaXN0IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCAzIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9IlRhYmxlIExpc3QgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBM aXN0IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCA2Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9IlRhYmxlIExpc3QgNyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBMaXN0 IDgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgM0QgZWZmZWN0cyAxIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9IlRhYmxlIDNEIGVmZmVjdHMgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJU YWJsZSAzRCBlZmZlY3RzIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29udGVtcG9y YXJ5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEVsZWdhbnQiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0iVGFibGUgUHJvZmVzc2lvbmFsIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxl IFN1YnRsZSAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFN1YnRsZSAyIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9IlRhYmxlIFdlYiAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxl IFdlYiAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFdlYiAzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9IkJhbGxvb24gVGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI1OSIgTmFtZT0iVGFibGUgR3JpZCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJU YWJsZSBUaGVtZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIE5hbWU9IlBsYWNlaG9sZGVyIFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTm8gU3BhY2luZyIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQg U2hhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIg TmFtZT0iTGlnaHQgTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVk aXVtIExpc3QgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 NiIgTmFtZT0iTWVkaXVtIExpc3QgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0i RGFyayBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcx IiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFk aW5nIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjYxIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAxIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hh ZGluZyAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2Vu dCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg TmFtZT0iUmV2aXNpb24iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iMzQiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ikxpc3QgUGFyYWdyYXBoIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJR dW90ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMCIgUUZv cm1hdD0idHJ1ZSIgTmFtZT0iSW50ZW5zZSBRdW90ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgMSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVt IEdyaWQgMSBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQg MSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0i RGFyayBMaXN0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFj Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBO YW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAyIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBOYW1lPSJMaWdodCBMaXN0 IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYy IiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCAyIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0g U2hhZGluZyAyIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2Vu dCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1l PSJNZWRpdW0gR3JpZCAxIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCAyIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAz IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcw IiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDIiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9yZnVs IExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDMi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5hbWU9Ikxp Z2h0IExpc3QgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50 IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9 Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDMiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0 IDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDMiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1 bSBHcmlkIDMgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFtZT0i Q29sb3JmdWwgTGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgMyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQgU2hhZGluZyBB Y2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIg TmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNCIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcg MSBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgNCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0iTWVk aXVtIExpc3QgMiBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2Nl bnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFt ZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5n IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcy IiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA0Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBT aGFkaW5nIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjYxIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA1Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0g U2hhZGluZyAxIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFj Y2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBO YW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA1Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3Jp ZCAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDUiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVs IFNoYWRpbmcgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50 IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9 IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50 IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9 Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDYiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBM aXN0IDEgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDYi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1l ZGl1bSBHcmlkIDIgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQg NiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0i Q29sb3JmdWwgU2hhZGluZyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3Jp ZCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIx OSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGxlIEVtcGhhc2lzIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIxIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRl bnNlIEVtcGhhc2lzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjMxIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdWJ0bGUgUmVmZXJlbmNlIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMyIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJ bnRlbnNlIFJlZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSIzMyIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iQm9vayBUaXRsZSIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNyIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9IkJpYmxpb2dyYXBoeSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlRPQyBIZWFkaW5nIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQxIiBOYW1lPSJQbGFpbiBUYWJsZSAxIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQyIiBOYW1lPSJQbGFp biBUYWJsZSAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQz IiBOYW1lPSJQbGFpbiBUYWJsZSAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjQ0IiBOYW1lPSJQbGFpbiBUYWJsZSA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ1IiBOYW1lPSJQbGFpbiBUYWJsZSA1Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQwIiBOYW1lPSJHcmlkIFRhYmxlIExp Z2h0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1l PSJHcmlkIFRhYmxlIDEgTGlnaHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRhYmxlIDQiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9IkdyaWQg VGFibGUgNSBEYXJrIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjUxIiBOYW1lPSJHcmlkIFRhYmxlIDYgQ29sb3JmdWwiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3JpZCBU YWJsZSAxIExpZ2h0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2Nl bnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFt ZT0iR3JpZCBUYWJsZSA0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgMSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJs ZSA2IENvbG9yZnVsIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDEiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQgVGFi bGUgMSBMaWdodCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50 IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9 IkdyaWQgVGFibGUgNCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDIiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUg NiBDb2xvcmZ1bCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAyIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlkIFRhYmxl IDEgTGlnaHQgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2VudCAz Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJH cmlkIFRhYmxlIDQgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCAzIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxlIDYg Q29sb3JmdWwgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3JpZCBUYWJsZSAx IExpZ2h0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2NlbnQgNCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iR3Jp ZCBUYWJsZSA0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgNCIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJsZSA2IENv bG9yZnVsIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQgVGFibGUgMSBM aWdodCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50IDUiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9IkdyaWQg VGFibGUgNCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xv cmZ1bCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlkIFRhYmxlIDEgTGln aHQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2VudCA2Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRh YmxlIDQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxlIDYgQ29sb3Jm dWwgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJM aXN0IFRhYmxlIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NDgiIE5hbWU9Ikxpc3QgVGFibGUgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJMaXN0IFRhYmxlIDUgRGFyayIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJs ZSA2IENvbG9yZnVsIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjUyIiBOYW1lPSJMaXN0IFRhYmxlIDcgQ29sb3JmdWwiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2NlbnQg MSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0i TGlzdCBUYWJsZSAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBBY2Nl bnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFt ZT0iTGlzdCBUYWJsZSA1IERhcmsgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQg MSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0i TGlzdCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50IDIi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxp c3QgVGFibGUgMiBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50 IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9 Ikxpc3QgVGFibGUgNSBEYXJrIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDIi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxp c3QgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCAzIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJMaXN0 IFRhYmxlIDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2VudCAz Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJM aXN0IFRhYmxlIDUgRGFyayBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCAzIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJMaXN0 IFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2NlbnQgNCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iTGlzdCBU YWJsZSAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBBY2NlbnQgNCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iTGlz dCBUYWJsZSA1IERhcmsgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNTEiIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgNCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iTGlzdCBU YWJsZSA3IENvbG9yZnVsIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50IDUiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3QgVGFi bGUgMiBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50IDUiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxpc3Qg VGFibGUgNSBEYXJrIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDUiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxpc3QgVGFi bGUgNyBDb2xvcmZ1bCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCA2Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJMaXN0IFRhYmxl IDIgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2VudCA2Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJMaXN0IFRh YmxlIDUgRGFyayBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCA2Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJMaXN0IFRhYmxl IDcgQ29sb3JmdWwgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTWVudGlvbiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJTbWFydCBIeXBlcmxpbmsiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt ZT0iSGFzaHRhZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJVbnJlc29sdmVkIE1lbnRpb24iLz4N CjwvdzpMYXRlbnRTdHlsZXM+DQo8L3htbD48IVtlbmRpZl0tLT48c3R5bGU+PCEtLQ0KLyogRm9u dCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRo IjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MDsN Cgltc28tZ2VuZXJpYy1mb250LWZhbWlseTpyb21hbjsNCgltc28tZm9udC1waXRjaDp2YXJpYWJs ZTsNCgltc28tZm9udC1zaWduYXR1cmU6LTUzNjg3MDE0NSAxMTA3MzA1NzI3IDAgMCA0MTUgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7DQoJbXNvLWZvbnQtYWx0OlN5bWFudGVjU2VyaWY7DQoJbXNvLWZvbnQtY2hh cnNldDowOw0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnN3aXNzOw0KCW1zby1mb250LXBpdGNo OnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotNTM2ODU5OTA1IC0xMDczNzMyNDg1IDkg MCA1MTEgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1zdHlsZS1x Zm9ybWF0OnllczsNCgltc28tc3R5bGUtcGFyZW50OiIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJl YXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KaDINCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJ bXNvLXN0eWxlLXVuaGlkZTpubzsNCgltc28tc3R5bGUtcWZvcm1hdDp5ZXM7DQoJbXNvLXN0eWxl LWxpbms6IkhlYWRpbmcgMiBDaGFyIjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJbXNvLW91dGxpbmUtbGV2ZWw6 MjsNCglmb250LXNpemU6MTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVuZGVybGluZTpzaW5nbGU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1ub3Nob3c6 eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVuZGVybGluZTpzaW5nbGU7fQ0KcHJlDQoJe21zby1z dHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ctb3JwaGFuOw0KCWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tZmFyZWFzdC1mb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5t c29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tc3R5bGUtdW5oaWRl Om5vOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCW1zby1wYWdpbmF0 aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJbXNvLXN0 eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXVuaGlkZTpubzsNCgltc28tYW5zaS1mb250LXNp emU6MTEuMHB0Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6Q2Fs aWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtdW5oaWRlOm5vOw0KCW1zby1zdHlsZS1sb2Nr ZWQ6eWVzOw0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCgltc28tYmlkaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJbXNvLWhhbnNp LWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpzcGFuLkhlYWRpbmcyQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSGVhZGluZyAy IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS11bmhpZGU6bm87DQoJ bXNvLXN0eWxlLWxvY2tlZDp5ZXM7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMiI7DQoJbXNv LWFuc2ktZm9udC1zaXplOjE4LjBwdDsNCgltc28tYmlkaS1mb250LXNpemU6MTguMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1hc2NpaS1mb250LWZhbWlseTpD YWxpYnJpOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1z by1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OkNhbGli cmk7DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQpzcGFuLlNwZWxsRQ0KCXttc28tc3R5bGUtbmFtZToi IjsNCgltc28tc3BsLWU6eWVzO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCW1zby1kZWZhdWx0LXByb3BzOnllczsNCgltc28tYXNjaWktZm9udC1mYW1p bHk6Q2FsaWJyaTsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1oYW5z aS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47DQoJbXNvLWhlYWRlci1tYXJnaW46LjVpbjsNCglt c28tZm9vdGVyLW1hcmdpbjouNWluOw0KCW1zby1wYXBlci1zb3VyY2U6MDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDEwXT48c3R5bGU+LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnRhYmxlLk1zb05vcm1hbFRhYmxl DQoJe21zby1zdHlsZS1uYW1lOiJUYWJsZSBOb3JtYWwiOw0KCW1zby10c3R5bGUtcm93YmFuZC1z aXplOjA7DQoJbXNvLXRzdHlsZS1jb2xiYW5kLXNpemU6MDsNCgltc28tc3R5bGUtbm9zaG93Onll czsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsNCgltc28t cGFkZGluZy1hbHQ6MGluIDUuNHB0IDBpbiA1LjRwdDsNCgltc28tcGFyYS1tYXJnaW46MGluOw0K CW1zby1wYXJhLW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1v cnBoYW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgltc28tYXNjaWktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28taGFuc2ktZm9udC1m YW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9 DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSIgc3R5bGU9InRhYi1pbnRlcnZhbDouNWluIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWFzY2lpLWZv bnQtZmFtaWx5OkNhbGlicmk7bXNvLWhhbnNpLWZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWJpZGkt Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij5IaSBCcmlhbiBhbmQgRGF2 aWQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRh Yi1zdG9wczo0NS44cHQgOTEuNnB0IDEzNy40cHQgMTgzLjJwdCAyMjkuMHB0IDI3NC44cHQgMzIw LjZwdCAzNjYuNHB0IDQxMi4ycHQgNDU4LjBwdCA1MDMuOHB0IDU0OS42cHQgNTk1LjRwdCA2NDEu MnB0IDY4Ny4wcHQgNzMyLjhwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYXNjaWktZm9udC1mYW1pbHk6 Q2FsaWJyaTttc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTttc28tYmlkaS1mb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPkluIHRoaXMgZG9jdW1lbnQgdGhlcmUgaXMg YWxyZWFkeSB3b3JkIOKAmG11c3TigJkgcmVsYXRlZCB0byB0aGUgcHJlZml4IGxlbmd0aDo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNv LWFzY2lpLWZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWhhbnNpLWZvbnQtZmFtaWx5OkNhbGlicmk7 bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWhhbnNpLWZvbnQtZmFtaWx5OkNhbGli cmk7bXNvLWJpZGktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGFsZXQtdjZvcHMtcmZjNjE3 Ny1iaXMtMDEjc2VjdGlvbi0yIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcGFs ZXQtdjZvcHMtcmZjNjE3Ny1iaXMtMDEjc2VjdGlvbi0yPC9hPg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOnllcyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7PC9zcGFuPkxvbmdlc3QgQWNjZXB0YWJsZSBQcmVmaXggKExBUCw8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOnllcyI+Jm5ic3A7Jm5ic3A7IDwvc3Bh bj5bPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBhbGV0LXY2b3Bz LXJmYzYxNzctYmlzLTAxI3JlZi1JLUQuY2FycGVudGVyLTZtYW4tbGFwIiB0aXRsZT0iJnF1b3Q7 VGhlIExvbmdlc3QgQWNjZXB0YWJsZSBQcmVmaXggZm9yIElQdjYgTGlua3MmcXVvdDsiPjxzcGFu IHN0eWxlPSJtc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpIj5JLUQuY2FycGVudGVyLTZt YW4tbGFwPC9zcGFuPjwvYT5dKSwgd2hvc2UgbGVuZ3RoIGlzIGxvY2FsbHkgZGV0ZXJtaW5lZCwg ZS5nLiw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOnll cyI+Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5hIHNpdGUgb3IgbGluayB0aGF0IHVzZXMgU0xBQUMgaGFz IGEgTEFQIG9mIC82NCBhbmQgd2lsbCBub3Qgd29yazxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJtc28tc3BhY2VydW46eWVzIj4mbmJzcDsmbmJzcDsgPC9zcGFuPndpdGggYSBs b25nZXIgb25lLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46eWVzIj4mbmJzcDsmbmJzcDsgPC9zcGFu PlNMQUFDLCBhbmQgY29uc2VxdWVudGx5LCB0aGUgTEFQIGlzIG1hbmRhdG9yaWx5IGEgLzY0Ljxz cGFuIHN0eWxlPSJtc28tc3BhY2VydW46eWVzIj4mbmJzcDsgPC9zcGFuPkZ1dHVyZTxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46eWVzIj4mbmJzcDsmbmJz cDsgPC9zcGFuPnRlY2hub2xvZ2llcywgbWF5IGhhdmUgYSBkaWZmZXJlbnQgTEFQLCB3aGljaCA8 YiBzdHlsZT0ibXNvLWJpZGktZm9udC13ZWlnaHQ6bm9ybWFsIj48c3BhbiBzdHlsZT0iYmFja2dy b3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPm11c3Q8L3NwYW4+PC9iPiBiZSB1c2Vk PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZu YnNwOyZuYnNwOyA8L3NwYW4+YWNjb3JkaW5nbHkuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86 cD4mbmJzcDs8L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tYXNjaWktZm9udC1mYW1pbHk6Q2FsaWJyaTttc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJy aTttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPkJhc2Vk IHRoZSBhbmFseXNpcyBpbiBzZWN0aW9uDQo8L3NwYW4+PGEgbmFtZT0ic2VjdGlvbi0zIj48L2E+ PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBhbGV0LXY2b3BzLXJm YzYxNzctYmlzLTAxI3NlY3Rpb24tMyI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpzZWN0aW9u LTMiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Mzwvc3Bhbj48L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6 c2VjdGlvbi0zIj48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6c2VjdGlvbi0z Ij48L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij4uPHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZuYnNwOw0K PC9zcGFuPk9uIC80OCBBc3NpZ25tZW50cyB0byBFbmQtU2l0ZXMsIDwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9Im1zby1hc2NpaS1mb250LWZhbWlseTpDYWxpYnJpO21zby1oYW5zaS1mb250LWZhbWls eTpDYWxpYnJpO21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+LzQ4IExBUCB3aWxsIGJlIHJlcXVpcmVkIGluIGEgbmVhciBmdXR1cmUuIFRoYXQgbWVhbnMg dGhlIHdvcmRpbmcgb2YgdGhlIHNlbnRlbmNlIGFib3ZlIGNhbiBiZQ0KIGNoYW5nZWQgdG86PC9z cGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9iPjwvcD4NCjxwcmU+PHNwYW4g c3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZuYnNwOyZuYnNwOyA8L3NwYW4+U0xBQUMsIGFuZCBj b25zZXF1ZW50bHksIHRoZSBMQVAgaXMgbWFuZGF0b3JpbHkgYSAvNjQuPHNwYW4gc3R5bGU9Im1z by1zcGFjZXJ1bjp5ZXMiPiZuYnNwOyA8L3NwYW4+RnV0dXJlPG86cD48L286cD48L3ByZT4NCjxw cmU+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZuYnNwOyZuYnNwOyA8L3NwYW4+dGVj aG5vbG9naWVzLCBtYXkgaGF2ZSBhIGRpZmZlcmVudCBMQVAsIHdoaWNoIDxiIHN0eWxlPSJtc28t YmlkaS1mb250LXdlaWdodDpub3JtYWwiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdztt c28taGlnaGxpZ2h0OnllbGxvdyI+bXVzdDwvc3Bhbj48L2I+IGJlIGFzc2lnbmVkPG86cD48L286 cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZuYnNwOyZuYnNw OyA8L3NwYW4+d2hlbiBuZWVkZWQgKG9yIHJlcXVlc3RlZCkuPG86cD48L286cD48L3ByZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYXNjaWktZm9udC1mYW1pbHk6Q2Fs aWJyaTttc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTttc28tYmlkaS1mb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYXNjaWktZm9udC1mYW1pbHk6 Q2FsaWJyaTttc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTttc28tYmlkaS1mb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPm90aGVyd2lzZSwgdGhlc2UgdGVjaG5vbG9n aWVzIHdpbGwgbm90IHdvcmsgYW5kLCBtb3N0IGxpa2VseSwgd29u4oCZdCBiZSBkZXZlbG9wZWQg YmVjYXVzZSB0aGVpciBkZXBsb3ltZW50IHdpbGwgYmUgaW1wYWlyZWQNCiBieSBJU1BzIExBUCBh c3NpZ25tZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tYXNjaWktZm9udC1mYW1pbHk6Q2FsaWJyaTttc28taGFuc2ktZm9udC1m YW1pbHk6Q2FsaWJyaTttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tYXNjaWktZm9udC1mYW1pbHk6Q2FsaWJyaTttc28taGFuc2ktZm9u dC1mYW1pbHk6Q2FsaWJyaTttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1hc2NpaS1mb250LWZhbWlseTpDYWxpYnJpO21zby1oYW5z aS1mb250LWZhbWlseTpDYWxpYnJpO21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+RHVzYW4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1hc2NpaS1mb250LWZhbWlseTpDYWxpYnJpO21zby1o YW5zaS1mb250LWZhbWlseTpDYWxpYnJpO21zby1iaWRpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9Im1z by1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+IERhdmlk IEZhcm1lciAmbHQ7ZmFybWVyQHVtbi5lZHUmZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2Rh eSwgQXVndXN0IDI4LCAyMDE4IDE6NTcgUE08YnI+DQo8Yj5Ubzo8L2I+IE11ZHJpYywgRHVzYW4g KER1c2FuKSAmbHQ7ZG11ZHJpY0BhdmF5YS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBCcmlhbiBF IENhcnBlbnRlciAmbHQ7YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tJmd0OzsgTGVhIFJvYmVy dHMgJmx0O2xlYS5yb2JlcnRzQHN0YW5mb3JkLmVkdSZndDs7IEpPUkRJIFBBTEVUIE1BUlRJTkVa ICZsdDtqb3JkaS5wYWxldD00MGNvbnN1bGludGVsLmVzQGRtYXJjLmlldGYub3JnJmd0OzsgZHJh ZnQtcGFsZXQtdjZvcHMtcmZjNjE3Ny1iaXNAaWV0Zi5vcmc7IElQdjYgT3BlcmF0aW9ucyAmbHQ7 djZvcHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIEktRCBB Y3Rpb246IGRyYWZ0LXBhbGV0LXY2b3BzLXJmYzYxNzctYmlzLTAwLnR4dDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBoYWQgc3VjaCBhbiBS RkMgaXQgd2FzIFJGQzMxNzcsIGl0IHdhc24ndCB2ZXJ5IGVmZmVjdGl2ZSwgbWFueSBkaXNhZ3Jl ZWQmbmJzcDt3aXRoIGl0IGFuZCBpdCB3YXMgaWdub3JlZC4gV2UgY2FuIHNheSB0aGF0IC80OHMg TVVTVCBiZSBnaXZlbiBvdXQgb24gcmVxdWVzdCwgYnV0IHRoZXJlIGlzIG5vdGhpbmcgdG8gZW5m b3JjZSB0aGF0LiZuYnNwO1lvdSBoYXZlIHRvIHJlbWVtYmVyIFJGQ3MgYXJlIHZvbHVudGFyeSwg dGhlcmUNCiBpcyBubyBJbnRlcm5ldCBwb2xpY2UuIElmIHlvdSB0aGluayB0aGF0IHRoZSBJRVRG IGNhbiBmb3JjZSBhbnkgbmV0d29yayB0byBkbyBhbnl0aGluZyB5b3UgbWlzdW5kZXJzdGFuZCZu YnNwO3RoZSBzeXN0ZW0gd2UgaGF2ZS4gTmV0d29ya3MgY29tcGx5IGJlY2F1c2UgdGhleSBhZ3Jl ZSBhbmQgc2VlIGFuIGFkdmFudGFnZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Ib3dldmVyLCB5b3UgY2FuIGFsd2F5cyBnZXQgSVB2NiBhZGRyZXNzZXMsIGV2 ZW4gYSAvNDgsIHlvdSBtaWdodCBoYXZlIHRvIGdvIHRvIGEgZGlmZmVyZW50Jm5ic3A7SVNQLCBv ciBhbiBSSVIgeW91cnNlbGYgYW5kIHlvdSBtYXkgaGF2ZSB0byByb3V0ZSB0aGVtIHlvdXJzZWxm LCB3aGljaCBtb3N0IHBlb3BsZSBhcmUgZWl0aGVyIGluY2FwYWJsZSBvciB1bndpbGxpbmcgdG8g ZG8uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PllvdSBtaWdodCBiZSBhYmxlIHRvIGdldCBnb3Zlcm5tZW50IHJlZ3VsYXRvcnMgdG8gZW5mb3Jj ZSZuYnNwO3NvbWV0aGluZyBsaWtlIHRoYXQsIGJ1dCBiZSB2ZXJ5IGNhcmVmdWwmbmJzcDt3aGF0 IHlvdSBhc2sgZm9yLiBBbmQgYXQgbGVhc3QgdGhlIFVTIHRoYXQgZG9lc24ndCBzZWVtIHRvIGJl IGdvaW5nIGluIHRoYXQga2luZCBvZiByZWd1bGF0b3J5IGRpcmVjdGlvbi48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSB3aXRoIEJy aWFuJ3Mgc3VnZ2VzdGlvbnMgaW4gYSBkaWZmZXJlbnQmbmJzcDtlbWFpbCwgd2UgbmVlZCB0byBt YWtlIHRoZSBjYXNlIHdoeSAvNDggbWFrZXMgc2Vuc2UgYW5kIGlzIGluIGFuIElTUCdzIGFuZCB0 aGVpciZuYnNwO2N1c3RvbWVyJ3MgaW50ZXJlc3QuIE5vdCBkaWN0YXRlIGEgbWFnaWMgbnVtYmVy IHRvIHRoZW0uJm5ic3A7IEhvbWVuZXQgaXMgYSBiaWcgcGFydCBvZiB0aGF0LCBidXQgSSdtIG5v dCBzdXJlIGJ5DQogaXRzZWxmIGl0J3MgZW5vdWdoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBtb3N0IGNhc2VzLCBlc3BlY2lhbGx5IHdo ZW4gSG9tZW5ldCBpcyBub3QgaW4gdXNlIC81NiBzZWVtcyBsaWtlIHBsZW50eSBvZiBhZGRyZXNz IHNwYWNlIGZvciB0aGUgdHlwaWNhbCBob21lLCBldmVuIC82MCB3aWxsIHdvcmsmbmJzcDtpbiBt YW55IGNhc2VzLiBUaGUgbWVzc2FnZSB3ZSBuZWVkIHRvIG1ha2UgY2xlYXIgaXMgYSBzaW5nbGUg LzY0IGlzIG5vdCBnb29kIGVub3VnaC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIFR1ZSwgQXVnIDI4LCAyMDE4IGF0IDEwOjA2IEFNLCBNdWRyaWMsIER1c2Fu IChEdXNhbikgJmx0OzxhIGhyZWY9Im1haWx0bzpkbXVkcmljQGF2YXlhLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmRtdWRyaWNAYXZheWEuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDttc28tYm9yZGVyLWxlZnQtYWx0OnNvbGlkICNDQ0NDQ0MgLjc1cHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkhpIEJyaWFuLDxicj4NCjxicj4NClRoZXJlIG11c3QgYSB3YXkgdG8g ZGVmaW5lIGhvdyBwcmVmaXhlcyBhcmUgYXNzaWduZWQgdG8gYWx3YXlzIGFsbG93IC80OCwgaWYg bmVlZGVkLiBJZiBub3QgaW4gcmZjNjE3Ny1iaXMgdGhhbiBpbiBhbm90aGVyIFJGQy4gV2UgaGF2 ZSBhbHJlYWR5IG9uZSBsaW1pdGF0aW9uIGZvciBTTEFBQyB0aGF0IG1ha2VzIHN1cmUgZXZlcnkg aG9tZSBnZXRzIGF0IGxlYXN0IG9uZSAvNjQuIFdlIGNhbiBhZGQgYW5vdGhlciBvbmUsIGluIGFu b3RoZXIgUkZDLA0KIHRvIG1ha2Ugc3VyZSAvNDggaXMgZ2l2ZW4gb24gYSBkZW1hbmQuIFRoYXQg d2lsbCBpbnN1cmUgZnV0dXJlIGZsZXhpYmlsaXR5IGluIGFueSBuZXR3b3JrIGFuZCBtYWtlIHRo ZSBwcmVmaXggYXNzaWdubWVudCBub24tcG9saXRpY2FsIHByb2Nlc3MuDQo8YnI+DQo8YnI+DQpS ZWdhcmRzLDxicj4NCkR1c2FuLjxicj4NCjxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS08YnI+DQomZ3Q7IEZyb206IEJyaWFuIEUgQ2FycGVudGVyICZsdDs8YSBocmVmPSJtYWls dG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YnJpYW4uZS5j YXJwZW50ZXJAZ21haWwuY29tPC9hPiZndDs8YnI+DQomZ3Q7IFNlbnQ6IFR1ZXNkYXksIEF1Z3Vz dCAyOCwgMjAxOCAxMjoyNyBBTTxicj4NCiZndDsgVG86IE11ZHJpYywgRHVzYW4gKER1c2FuKSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmRtdWRyaWNAYXZheWEuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZG11 ZHJpY0BhdmF5YS5jb208L2E+Jmd0OzsgTGVhIFJvYmVydHM8YnI+DQomZ3Q7ICZsdDs8YSBocmVm PSJtYWlsdG86bGVhLnJvYmVydHNAc3RhbmZvcmQuZWR1IiB0YXJnZXQ9Il9ibGFuayI+bGVhLnJv YmVydHNAc3RhbmZvcmQuZWR1PC9hPiZndDs7IEpPUkRJIFBBTEVUIE1BUlRJTkVaPGJyPg0KJmd0 OyAmbHQ7am9yZGkucGFsZXQ9PGEgaHJlZj0ibWFpbHRvOjQwY29uc3VsaW50ZWwuZXNAZG1hcmMu aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGNvbnN1bGludGVsLmVzQGRtYXJjLmlldGYub3Jn PC9hPiZndDs8YnI+DQomZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86ZHJhZnQtcGFsZXQtdjZvcHMt cmZjNjE3Ny1iaXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kcmFmdC1wYWxldC12Nm9wcy1y ZmM2MTc3LWJpc0BpZXRmLm9yZzwvYT47IElQdjYgT3BlcmF0aW9uczxicj4NCiZndDsgJmx0Ozxh IGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnY2b3BzQGlldGYu b3JnPC9hPiZndDs8YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRy YWZ0LXBhbGV0LXY2b3BzLXJmYzYxNzctYmlzLTAwLnR4dDxicj4NCiZndDsgPGJyPg0KJmd0OyBP biAyMDE4LTA4LTI4IDA2OjIzLCBNdWRyaWMsIER1c2FuIChEdXNhbikgd3JvdGU6PGJyPg0KJmd0 OyAmZ3Q7IFNlY3Rpb24gNC48YnI+DQomZ3Q7ICZndDsgJnF1b3Q7Jm5ic3A7ICZuYnNwO2IuJm5i c3A7IEFuIGVuZC11c2VyIHNob3VsZCBiZSBhYmxlIHRvIHJlY2VpdmUgYW55IHByZWZpeCBsZW5n dGggdXAgdG8gLzQ4PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHNp bXBseSBieSBhc2tpbmcuJnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IENhbiZu YnNwOyB0aGlzIGJlIGRlZmluZWQgaW4gYSB3YXkgdG8gbWFrZSBzdXJlIHRoYXQgbmV3IGFwcGxp Y2F0aW9ucyBhbmQ8YnI+DQomZ3Q7IGRldmljZXMgd2lsbCBhbHdheXMgd29yayBhdCBlbmQgc2l0 ZXMgd2l0aG91dCBhIG5lZWQgZm9yIGFza2luZyBJU1BzIGZvciBleHRyYTxicj4NCiZndDsgYWRk cmVzcyBzcGFjZT8gT3RoZXJ3aXNlLCB0aGUgZW5kLXVzZXIgbWlnaHQgbm90IGdldCB3aGF0IGhl L3NoZSBhc2tzIGZvciw8YnI+DQomZ3Q7IHdpdGhvdXQgcGF5aW5nIGZvciB0aGUgJnF1b3Q7aGln aGVyIGdyYWRlJnF1b3Q7IHNlcnZpY2UuIENhbiB0aGUgZGVmaW5pdGlvbiBpbXBvc2UgdXA8YnI+ DQomZ3Q7IHRvIC80OCBMQVAgd2hlbiBuZWVkZWQgYXQgZW5kIHNpdGVzPyBGb3IgZXhhbXBsZSwg Y2FuIGFuIGFwcGxpY2F0aW9uPGJyPg0KJmd0OyByZXF1ZXN0IGEgaG9tZSByb3V0ZXIgdG8gcmVx dWVzdCBhbiBJU1AgZm9yIC80OCBwcmVmaXggYW5kLCB3aGVuIHJlcXVlc3RlZCw8YnI+DQomZ3Q7 IElTUCBtdXN0IGdyYW50IGl0Pzxicj4NCiZndDsgPGJyPg0KJmd0OyBVbmZvcnR1bmF0ZWx5IHdl IGNhbiBuZXZlciBzYXkgJnF1b3Q7bXVzdCZxdW90OyBpbiB0aGlzIGNvbnRleHQuIFdoYXQgSVNQ cyB3aWxsPGJyPg0KJmd0OyBwcm92aWRlPGJyPg0KJmd0OyBmb3Igd2hhdCBmZWUgaXMgd2VsbCBv dXRzaWRlIHRoZSBJRVRGJ3MgY29tcGV0ZW5jZS4gQXMgb2JzZXJ2ZWQgb24gYW5vdGhlcjxicj4N CiZndDsgdGhyZWFkLCBhcHBsaWNhdGlvbnMgbmVlZCB0byBiZSBhZ2lsZSwgZXZlbiBpZiB0aGV5 IHdvcmsgYmV0dGVyIGlmIHN1Y2ggYTxicj4NCiZndDsgcmVxdWVzdCB3YXMgZ3JhbnRlZC48YnI+ DQomZ3Q7IDxicj4NCiZndDsgSSdkIHNheSB0aGF0IG9uY2UgdGhpcyB1cGRhdGUgaXMgZG9uZSwg aXQgbWF5IGJlIHRpbWUgdG8gcmV2aXNpdDxicj4NCiZndDsgUkZDNDA4NC48YnI+DQomZ3Q7IDxi cj4NCiZndDsgUmVnYXJkczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO0JyaWFuPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7ICZn dDsgRHVzYW4gTXVkcmljLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7ICZndDsmZ3Q7IEZyb206IHY2b3BzICZsdDs8 YSBocmVmPSJtYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnY2 b3BzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBPbiBCZWhhbGYgT2YgTGVhIFJvYmVydHM8YnI+ DQomZ3Q7ICZndDsmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDE5LCAyMDE4IDI6MDggUE08YnI+ DQomZ3Q7ICZndDsmZ3Q7IFRvOiBCcmlhbiBFIENhcnBlbnRlciAmbHQ7PGEgaHJlZj0ibWFpbHRv OmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJyaWFuLmUuY2Fy cGVudGVyQGdtYWlsLmNvbTwvYT4mZ3Q7OyBKT1JESSBQQUxFVDxicj4NCiZndDsgJmd0OyZndDsg TUFSVElORVogJmx0O2pvcmRpLnBhbGV0PTxhIGhyZWY9Im1haWx0bzo0MGNvbnN1bGludGVsLmVz QGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBjb25zdWxpbnRlbC5lc0BkbWFyYy5p ZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBDYzogPGEgaHJlZj0ibWFpbHRvOmRy YWZ0LXBhbGV0LXY2b3BzLXJmYzYxNzctYmlzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpk cmFmdC1wYWxldC12Nm9wcy1yZmM2MTc3LWJpc0BpZXRmLm9yZzwvYT47IElQdjYgT3BlcmF0aW9u czxicj4NCiZndDsgJmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnY2b3BzQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7 IFN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBBY3Rpb246IGRyYWZ0LXBhbGV0LXY2b3BzLXJmYzYx NzctYmlzLTAwLnR4dDxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IGhpIEJy aWFuIGFuZCBKb3JkaSAtPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgZXhj ZWxsZW50IGNvbW1lbnRzIGFuZCBJIGFncmVlIGFsc28uPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4N CiZndDsgJmd0OyZndDsgdGhhbmsgeW91ISE8YnI+DQomZ3Q7ICZndDsmZ3Q7IC9MZWE8YnI+DQom Z3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBPbiBUaHUsIDE5IEp1bCAyMDE4LCBKT1JE SSBQQUxFVCBNQVJUSU5FWiB3cm90ZTo8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsgSGkgQnJpYW4sPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgVGhh bmtzIGEgbG90IGZvciBjb21tZW50aW5nIGFuZCBzb3JyeSB0aGUgbGF0ZSBhbnN3ZXIgLi4uIHRv byBidXN5IGxhc3Q8YnI+DQomZ3Q7ICZndDsmZ3Q7IHdlZWtzLjxicj4NCiZndDsgJmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7IENvbW1lbnRzIGluLWxpbmUgYmVsb3cgKHN1YmplY3RlZCB0byBteSBj by1hdXRob3IgYWdyZWVtZW50KSw8YnI+DQomZ3Q7IGJhc2ljYWxseSw8YnI+DQomZ3Q7ICZndDsm Z3Q7IGFncmVlIHdpdGggYWxsIHlvdXIgaW5wdXRzLCBleGNlcHQgYSBjb3VwbGUgb2YgcG9pbnRz Ljxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IFRoYW5rcyE8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBSZWdhcmRzLDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsgSm9yZGk8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IO+7vy0tLS0tTWVuc2FqZSBv cmlnaW5hbC0tLS0tPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyBEZTogdjZvcHMgJmx0OzxhIGhyZWY9Im1haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+djZvcHMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IGVuIG5vbWJyZSBk ZSBCcmlhbiBFIENhcnBlbnRlcjxicj4NCiZndDsgJmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5icmlhbi5lLmNh cnBlbnRlckBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsgT3JnYW5pemFjaT9uOiBVbml2ZXJzaXR5IG9mIEF1Y2tsYW5kPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBGZWNoYTogZG9taW5nbywg OCBkZSBqdWxpbyBkZSAyMDE4LCAxNzo0Mzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsgUGFyYTogJmx0OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1wYWxldC12Nm9w cy1yZmM2MTc3LWJpc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRyYWZ0LXBhbGV0LXY2b3Bz LXJmYzYxNzctYmlzQGlldGYub3JnPC9hPiZndDssIElQdjYgT3BlcmF0aW9uczxicj4NCiZndDsg Jmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnY2b3BzQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7IEFzdW50bzogUmU6IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtcGFs ZXQtdjZvcHMtcmZjNjE3Ny1iaXMtMDAudHh0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmbmJzcDsgJm5ic3A7IEhpLDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jm5ic3A7ICZuYnNwOyBUaGFua3MgZm9yIHRoaXMgZHJhZnQuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZndDsgQWJzdHJhY3Q8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgVGhpcyBuZWVkcyB0byBiZSBzaG9ydGVy LiBUaHJlZSBwYXJhZ3JhcGhzIGlzIHRvbyBtdWNoLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7IEZvciB0aGUgbmV4dCB2ZXJzaW9uLCBJJ3ZlIHJlZHVjZWQgNTAlIHRoZSBsZW5n dGggb2YgdGhlIDFzdCBwYXJhZ3JhcGguPGJyPg0KJmd0OyAzcmQ8YnI+DQomZ3Q7ICZndDsmZ3Q7 IHBhcmFncmFwaCwgSSByZWNhbGwgaXMgbWFuZGF0b3J5IChJRE5pdHMpLjxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJmd0OyAuLi4gcG9saWN5IHNob3VsZCByZWZsZWN0IHRo YXQgYXNzaWdubWVudCBvZiBhIHNpbmdsZSBzdWJuZXQgaXM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmZ3Q7IG5vIGxvbmdlciBhcHBy b3ByaWF0ZSB1bmxlc3MgdGhlIHJlY2lwaWVudCBleHBsaWNpdGx5IGFncmVlcyB0byB0aGU8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAm Z3Q7IGxpbWl0YXRpb25zIGltcGxpZWQgYnkgc3VjaCBhbiBhc3NpZ25tZW50Ljxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBJICpzdHJvbmdseSogc3VnZ2Vz dCBkZWxldGluZyB0aGUgJnF1b3Q7dW5sZXNzJnF1b3Q7IGNsYXVzZS4gSXQgbGVhdmVzIGE8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBs b29waG9sZSwgYW5kIGl0IGNvdWxkIGVhc2lseSBiZSBoaWRkZW4gaW4gc2hyaW5rLXdyYXAgdGVy bXM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZu YnNwOyBhbmQgY29uZGl0aW9ucyBzbyB0aGF0IGEgc3Vic2NyaWJlciB3b3VsZCBhZ3JlZSB3aXRo b3V0IGV2ZW48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jm5i c3A7ICZuYnNwOyBrbm93aW5nIGFib3V0IGl0LiBSZWR1Y2UgdGhpcyBzaW1wbHkgdG86PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsu Li4gcG9saWN5IHNob3VsZCByZWZsZWN0IHRoYXQgYXNzaWdubWVudCBvZiBhIHNpbmdsZSBzdWJu ZXQgaXM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7bmV2ZXIgYXBwcm9wcmlhdGUuPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsgQWdyZWVkIGFuZCBkb25lLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZuYnNwOyAmbmJzcDsgJmd0OyAxLiZuYnNwOyBJbnRyb2R1Y3Rpb248YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAuLi4uPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJmd0OyZu YnNwOyAmbmJzcDsgMS4mbmJzcDsgSXQgaXMgZXh0cmVtZWx5IGRpc2NvdXJhZ2VkIHRoYXQgLzEy OHMgYmUgZ2l2ZW4gb3V0LiZuYnNwOyBXaGlsZSB0aGVyZTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgbWF5IGJlIHNvbWUgY2FzZXMgd2hlcmUgYXNzaWduaW5nIG9ubHkgYSBzaW5n bGUgYWRkcmVzcyBtYXkgYmU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGp1c3Rp ZmllZCwgYSBzaXRlLCBieSBkZWZpbml0aW9uLCBpbXBsaWVzIG11bHRpcGxlIHN1Ym5ldHMgYW5k PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJz cDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBtdWx0aXBsZSBkZXZpY2VzLjxicj4N CiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBJIGZpbmQgdGhpcyBh IGJpdCB3ZWFrLiBUcnk6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsxLiZuYnNwOyBJdCBpcyBleHRyZW1lbHkgZGlzY291cmFnZWQg dGhhdCAvMTI4cyBiZSBnaXZlbiBvdXQuJm5ic3A7IFdoaWxlIHRoZXJlPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7bWF5IGJlIHNvbWUgYXBwbGljYXRpb25zIHdoZXJlIGFzc2lnbmluZyBv bmx5IGEgc2luZ2xlIGFkZHJlc3M8YnI+DQomZ3Q7IG1heTxicj4NCiZndDsgJmd0OyZndDsgYmU8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0b2xlcmF0ZWQsIGEgc2l0ZSwgYnkgZGVmaW5p dGlvbiwgaW1wbGllcyBtdWx0aXBsZSBzdWJuZXRzIGFuZDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO211bHRpcGxlIGRldmljZXMuIEFsc28sIGEgLzEyOCBwcmV2ZW50cyBhbnkgZm9ybSBv ZiBwcml2YWN5LWJhc2VkPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YWRkcmVzc2luZy48 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBBZ3JlZWQhPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7IDQuJm5i c3A7IFRoaXMgcmV2aXNpb24gaGFzIGJlZW4gY3JlYXRlZCB0byBtb3JlIGNsZWFybHkgYXNzZXJ0 IHRoZTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsg Jm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgcmVxdWlyZW1lbnQgdG8gZW5z dXJlIHRoYXQgYWRkcmVzcyBhc3NpZ25tZW50cyB0byBlbmQtc2l0ZXM8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IHByb3ZpZGUgYSBzdWZmaWNpZW50bHkgYmlnIG51bWJlciBvZiBz dWJuZXRzICgvNjQgb24gY2xhc3NpYzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg bmV0d29ya3MpIHRvIGVhY2ggZW5kLXNpdGUsIHRha2luZyB1bmRlciBjb25zaWRlcmF0aW9uIHRo ZSBlbmQtPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNw OyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzaXRlJ3MgZnV0dXJlIGV4 cGVjdGVkIG5lZWRzLCBuZXcgZGVwbG95bWVudCBleHBlY3RhdGlvbnMgYW5kPGJyPg0KJmd0OyAm Z3Q7Jmd0OyBuZXc8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHByb3RvY29sIHJl cXVpcmVtZW50cywgYW1vbmcgb3RoZXJzLiZuYnNwOyBPbmNlIGFsbCB0aGVzZSBhcmU8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGNvbnNpZGVyZWQsIGl0IHNlZW1zIHVubGlrZWx5 IHRoYXQgYSBzaW5nbGUgc3VibmV0ICgvNjQpIG9yIGV2ZW48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IGEgc21hbGwgbnVtYmVyIG9mIHRoZW0gc2hvdWxkIGJlIGFzc2lnbmVkLCB1 bmxlc3MgdmVyeSBjbGVhcmx5PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBqdXN0 aWZpZWQgYW5kIGFncmVlZCB0byBieSB0aGUgZW5kLXNpdGUuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7IFRoZSAmcXVvdDt1bmxlc3MmcXVvdDsgY2xhdXNl IGlzIGRhbmdlcm91cyBiZWNhdXNlIG9mIHNocmluay13cmFwIHRlcm1zIGFuZDxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7IGNvbmRpdGlv bnMuIEkgc3VnZ2VzdCBkZWxldGluZyBpdC48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyBBZ3JlZWQhPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5i c3A7ICZndDsgMi4mbmJzcDsgQ29uc2lkZXJhdGlvbnMgUmVnYXJkaW5nIHRoZSBQcmVmaXggTGVu Z3RoPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAm bmJzcDsgLi4uLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm bmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7IFRoaXMgY29uc2lkZXJhdGlvbiBzaG91bGQg YmUgbm90aWNlZCwgYWNyb3NzIHRoaXMgZG9jdW1lbnQsIGluIHRoZTxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5i c3A7IHNlbnNlIHRoYXQgZW5kLXNpdGVzIHVzdWFsbHkgaGF2ZSBzdWJuZXRzIHRoYXQgdXNlLCBi eSBkZWZhdWx0LDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm bmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7IFNMQUFDLCBhbmQgY29uc2VxdWVudGx5LCB0 aGUgTEFQIGlzIG1hbmRhdG9yaWx5IGEgLzY0LiZuYnNwOyBPdGhlcjxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5i c3A7IHRlY2hub2xvZ2llcywgbWF5IGhhdmUgYSBkaWZmZXJlbnQgTEFQLCB3aGljaCBtdXN0IGJl IHVzZWQ8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7 ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyBhY2NvcmRpbmdseS48YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgSSBzdWdnZXN0IHMvT3RoZXIvRnV0dXJlLyBz aW5jZSAvNjQgcHJldmFpbHMgZXZlcnl3aGVyZSB0b2RheS48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyBBZ3JlZWQhPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm bmJzcDsgJm5ic3A7ICZndDsgMy4mbmJzcDsgT24gLzQ4IEFzc2lnbm1lbnRzIHRvIEVuZC1TaXRl czxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5i c3A7IC4uLi48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jm5i c3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyBBbiBpbXBvcnRhbnQ8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZu YnNwOyBnb2FsIGluIElQdjYgaXMgdG8gc2lnbmlmaWNhbnRseSBjaGFuZ2UgdGhlIGRlZmF1bHQg YW5kIG1pbmltYWwgZW5kPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgc2l0ZSBhc3NpZ25tZW50LCBmcm9t ICZxdW90O2Egc2luZ2xlIGFkZHJlc3MmcXVvdDsgdG8gJnF1b3Q7bXVsdGlwbGUgbmV0d29ya3Mm cXVvdDsgYW5kPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZu YnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgdG8gZW5zdXJlIHRoYXQgZW5kLXNpdGVzIGNh biBlYXNpbHkgb2J0YWluIGFkZHJlc3Mgc3BhY2UuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmbmJzcDsgJm5ic3A7IEkgc3VnZ2VzdCBhZGRpbmcgc29tZXRoaW5nIGxpa2UgdGhp czo8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgQXMgdGhl IG9wZXJhdGlvbmFsIGNvc3RzIG9mIGNhcnJpZXItZ3JhZGUgTkFUIGFuZCBhZGRyZXNzJiM0Mztw b3J0IHNoYXJpbmc8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jm5ic3A7ICZuYnNwOyBoYXZlIHNob3duLCBhdmFpbGFiaWxpdHkgb2YgbXVsdGlwbGUgYWRkcmVz c2VzIGFuZCBwcmVmaXhlcyB0byBlbmQgc2l0ZXM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyB0aGF0IG5lZWQgdGhlbSB3aWxsIGJlIGEg Y29uc2lkZXJhYmxlIHNhdmluZyB0byB0aGVpciBJU1BzLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7IEFncmVlZCE8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZu YnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgSXQgbWlnaHQgYmUgdGVtcHRpbmcgdG8gZ2l2 ZSBob21lIHNpdGVzIGEgc2luZ2xlIC82NCwgc2luY2UgdGhhdCBpczxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5i c3A7IGFscmVhZHkgc2lnbmlmaWNhbnRseSBtb3JlIGFkZHJlc3Mgc3BhY2UgY29tcGFyZWQgd2l0 aCB0b2RheSdzPGJyPg0KJmd0OyBJUHY0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgcHJhY3RpY2UuJm5i c3A7IEhvd2V2ZXIsIHRoaXMgcHJlY2x1ZGVzIHRoZSBleHBlY3RhdGlvbiB0aGF0IGV2ZW4gaG9t ZTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5i c3A7ICZndDsmbmJzcDsgJm5ic3A7IHNpdGVzIHdpbGwgZ3JvdyB0byBzdXBwb3J0IG11bHRpcGxl IHN1Ym5ldHMgZ29pbmcgZm9yd2FyZC4mbmJzcDsgSGVuY2UsIGl0PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7IHMvZXhwZWN0YXRpb24vY2VydGFpbnR5Lzxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IEFncmVlZCE8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgLi4uLjxicj4NCiZndDsgJmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7 IEEga2V5IGdvYWwgb2YgdGhlIHJlY29tbWVuZGF0aW9ucyBpbiBbUkZDMzE3N10gaXMgdG88YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAm Z3Q7Jm5ic3A7ICZuYnNwOyBlbnN1cmUgdGhhdCB1cG9uIHJlbnVtYmVyaW5nLCBvbmUgZG9lcyBu b3QgaGF2ZSB0byBkZWFsIHdpdGg8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyByZW51bWJlcmluZyBpbnRv IGEgc21hbGxlciBzdWJuZXQgc2l6ZS48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZuYnNwOyAmbmJzcDsgUGVyaGFwcyBhZGQ6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmbmJzcDsgJm5ic3A7IEluIHBhcnRpY3VsYXIgdGhpcyB3b3VsZCBhcHBseSB0byBhbnkg c2l0ZSB0aGF0IHN3aXRjaGVzIHRvPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgYW4gSVNQIHRoYXQgcHJvdmlkZXMgYSBsb25nZXIgcHJl Zml4Ljxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IEFncmVlZCE8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsg SXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQgc2ltaWxhciBhcmd1bWVudHMgYXBwbHkgdG8gdGhlIG1h bmFnZW1lbnQ8YnI+DQomZ3Q7IG9mPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgem9uZSBmaWxlcyBpbiB0 aGUgRE5TLiZuYnNwOyBJbiBwYXJ0aWN1bGFyLCBtYW5hZ2luZyB0aGUgcmV2ZXJzZTxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZndDsm bmJzcDsgJm5ic3A7IChpcDYuYXJwYSkgdHJlZSBpcyBzaW1wbGlmaWVkIHdoZW4gYWxsIGxpbmtz IGFyZSBudW1iZXJlZCB1c2luZyB0aGU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyBzYW1lIHN1Ym5ldCBp ZHM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgcy9udW1i ZXJlZC9yZW51bWJlcmVkLzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IEFncmVl ZCE8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgLi4uLjxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7 ICZndDsmbmJzcDsgJm5ic3A7IHllYXJzLCBhbmQgd2UgZG9uJ3QgcmVjb3ZlciBiYWNrIHRoZSAv NDgncywgd2Ugd2lsbCBiZSBhYmxlIHRvIHVzZTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7IElQdjYgYWRk cmVzc2luZyBzcGFjZSBmb3Igb3ZlciAxMDAuMDAwIHllYXJzLjxicj4NCiZndDsgJmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBQZXJoYXBzIGFkZDo8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBh ZHZvY2F0ZSBjYXJlbGVzcyB1c2Ugb2YgYWRkcmVzcyBzcGFjZSwgYnV0PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgdGhlcmUgaXMgb2Jq ZWN0aXZlbHkgbm8gcmVhc29uIHRvIGJlIHJlc3RyaWN0dmUuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsgQWdyZWVkITxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 Jm5ic3A7ICZuYnNwOyAuLi4uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgVG9kYXkgdHlwaWNhbGx5LCBh IGhvbWUgaGFzIGFscmVhZHkgYSBjb25zaWRlcmFibGUgbnVtYmVyIG9mPGJyPg0KJmd0OyBwb3Nz aWJsZTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsg Jm5ic3A7ICZndDsmbmJzcDsgJm5ic3A7IHN1Ym5ldHMgKGEgY29tbW9uIENFIGhhcyA0IExBTiBw b3J0cywgMiBXaUZpIHJhZGlvcyB3aGljaCBzdXBwb3J0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgc2V2 ZXJhbCBTU0lEcyBlYWNoIG9uZSwgVm9JUCBzdWJuZXQsIElQVFYgc3VibmV0LCBhZGRpdGlvbmFs PGJyPg0KJmd0OyBWTEFOcyk8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyBhbmQgaWYgZG93bnN0cmVhbSBy b3V0ZXJzIGFyZSB1c2VkLCB0aGVyZSBpcyBhIG5lZWQgZm9yIGZ1cnRoZXI8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7 ICZuYnNwOyBzdWJuZXRzLiZuYnNwOyBUaGlzIG1lYW5zIHRoYXQgaW4gYSBzaG9ydCB0ZXJtLCBh c3NpZ25pbmcgYSAvNjAgKDE2PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsm Z3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAmbmJzcDsgc3VibmV0cyksIGl0IGlzIGFs cmVhZHkgYSByZWFsbHkgYmFkIGRlY2lzaW9uLCBhcyBpdCBtYXkgZW5mb3JjZSBJUHY2PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJmd0 OyZuYnNwOyAmbmJzcDsgTkFUIGJldHdlZW4gdGhlIG1haW4gQ0UgYW5kIGRvd25zdHJlYW0gcm91 dGVycy48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgSSBz dWdnZXN0IGRlbGV0aW5nICZxdW90O2FzIGl0IG1heSBlbmZvcmNlIElQdjYgTkFUIGJldHdlZW4g dGhlIG1haW4gQ0U8YnI+DQomZ3Q7IGFuZDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7IGRvd25zdHJlYW0gcm91dGVycyZxdW90Oy4gRmly c3RseSBpdCBwdXRzIE5BVCBpbnRvIHRoZSByZWFkZXIncyBtaW5kLjxicj4NCiZndDsgU2Vjb25k bHksPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAm bmJzcDsgaXQgaXNuJ3QgdGhlIG9ubHkgc29sdXRpb24gLSBJSURzIHNob3J0ZXIgdGhhbiA2NCBj b3VsZCBhbHNvIGJlPGJyPg0KJmd0OyBpbXBsZW1lbnRlZC48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyBBZ3JlZWQhPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm bmJzcDsgJm5ic3A7ICZndDsgNC4mbmJzcDsgSW1wYWN0IG9uIElQdjYgU3RhbmRhcmRzPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7IEkgcHJvcG9zZSB0byBz aW1wbHkgZGVsZXRlIHRoaXMgc2VjdGlvbi48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyZuYnNwOyAmbmJzcDsgRmlyc3RseSwgUkZDMzA1NiBpcyBkZXByZWNhdGVkIHNvIGl0J3Mg aXJyZWxldmFudCB0b2RheS48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jm5ic3A7ICZuYnNwOyBTZWNvbmRseSwgdGhlIGFyZ3VtZW50IGFib3V0IFVMQXMgKFJG QzQxOTMpIGRvZXNuJ3QgaG9sZCB1cC48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBVTEFzIGFyZSBsaWtlIGFueSBvdGhlciAvNDggcHJl Zml4IC0gaWYgeW91IGFyZSBmb3JjZWQgdG88YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyByZW51bWJlciBpbnRvIGEgbG9uZ2VyIHByZWZp eCwgeW91IGxvc2Ugc29tZSBzdWJuZXQgYml0cy48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBUaGF0IGlzIGFscmVhZHkgY292ZXJlZCBp biB0aGUgbWlkZGxlIG9mIHNlY3Rpb24gMyAodGhlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJnF1b3Q7a2V5IGdvYWwmcXVvdDsgc2Vu dGVuY2UgcXVvdGVkIGFib3ZlKS48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgSSByZWNhbGwgd2Ug ZGVwcmVjYXRlZCB0aGUgNnRvNCBhbnljYXN0LCBidXQgbm90IDZ0bzQsIGluIGZhY3QgNnRvNCB0 byA2dG80PGJyPg0KJmd0OyAmZ3Q7Jmd0OyB0cmFmZmljIGlzIHN0aWxsIHVzZWZ1bCBmb3IgcGVl ciB0byBwZWVyLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNw OyAmZ3Q7IDYuJm5ic3A7IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJmd0Ozxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZndDsmbmJz cDsgJm5ic3A7IFRoaXMgZG9jdW1lbnQgaGFzIG5vIGtub3duIHNlY3VyaXR5IGltcGxpY2F0aW9u cy48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgUmVhbGx5 PyBNb3JlIHByZWZpeCBzcGFjZSBvZmZlcnMgbW9yZSBwb3RlbnRpYWwgZm9yIHNjYW5uaW5nPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsg YXR0YWNrcy4gTW9yZSBwcmVmaXggc3BhY2UgYWxzbyBhbGxvd3MgdGhlIHVzZSBvZiBzbGlnaHRs eTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5i c3A7IHJhbmRvbWl6ZWQgcHJlZml4ZXMgYW5kL29yIHByZWZpeC1wZXIgaG9zdC48YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgQWxzbyBvZiBjb3Vyc2UsIGEg LzEyOCB3b3VsZCBwcmV2ZW50IGFueSBmb3JtIG9mIHByaXZhY3ktYmFzZWQ8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBhZGRyZXNzaW5n Ljxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IEkndmUgaW50cm9kdWNlZCBuZXcg dGV4dCBvbiB0aG9zZSBwb2ludHMuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm bmJzcDsgJm5ic3A7ICZndDsgOC4mbmJzcDsgQWNrbm93bGVkZ2VtZW50czxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZndDs8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmZ3Q7 Jm5ic3A7ICZuYnNwOyBUaGUgYXV0aG9ycyBvZiB0aGlzIGRvY3VtZW50IHdpbGwgbGlrZSB0byBh Y2tub3dsZWRnZSB0aGUgYXV0aG9yczxicj4NCiZndDsgb2Y8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmZ3Q7Jm5ic3A7ICZuYnNwOyBw cmV2aW91cyB2ZXJzaW9ucyAoVGhvbWFzIE5hcnRlbiBhbmQgR2VvZmYgSHVzdG9uKTxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBSRkMzMTc3IHdhcyBzaWdu ZWQgYnkgdGhlIHdob2xlIElBQiBhbmQgSUVTRyBzZWF0ZWQgaW4gMjAwMSwgYW5kIGl0czxicj4N CiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7IEFj a25vd2xlZGdlbWVudHMgcmVhZDo8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZu YnNwOyAmbmJzcDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7IFRoaXMgZG9jdW1lbnQgb3JpZ2luYXRl ZCBmcm9tIHRoZSBJRVRGIElQdjYgZGlyZWN0b3JhdGUsIHdpdGg8YnI+DQomZ3Q7IG11Y2g8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAm Z3Q7Jmd0OyZuYnNwOyAmbmJzcDsgaW5wdXQgZnJvbSB0aGUgSUFCIGFuZCBJRVNHLiZuYnNwOyBU aGUgb3JpZ2luYWwgdGV4dCBmb3JtaW5nIHRoZSBiYXNpcyBvZjxicj4NCiZndDsgJmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZndDsmZ3Q7Jm5ic3A7ICZu YnNwOyB0aGlzIGRvY3VtZW50IHdhcyBjb250cmlidXRlZCBieSBGcmVkIEJha2VyIGFuZCBCcmlh biBDYXJwZW50ZXIuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZuYnNwOyAmbmJzcDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7IEFsbGlzb24gTWFua2luIGFuZCBU aG9tYXMgTmFydGVuIG1lcmdlZCB0aGUgb3JpZ2luYWw8YnI+DQomZ3Q7IGNvbnRyaWJ1dGlvbnM8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNw OyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgaW50byBhIHNpbmdsZSBkb2N1bWVudCwgYW5kIEFsYWlu IER1cmFuZCBlZGl0ZWQgdGhlIGRvY3VtZW50PGJyPg0KJmd0OyAmZ3Q7Jmd0OyB0aHJvdWdoPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsg Jmd0OyZndDsmbmJzcDsgJm5ic3A7IGl0cyBmaW5hbCBzdGFnZXMuPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsgQWdyZWVkITxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsm Z3Q7Jm5ic3A7ICZuYnNwOyBSZWdhcmRzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBCcmlhbjxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7IHY2b3BzIG1haWxpbmcgbGlzdDxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7IDxhIGhy ZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnY2b3BzQGlldGYub3Jn PC9hPjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsg Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwcy0iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy08L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgM0Ff X3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3Y2b3BzJmFtcDtkPUR3SURhUSZhbXA7Yz1C RnBXUXc4YnN1S3A8YnI+DQomZ3Q7ICZndDsmZ3Q7IGwxU2dpWkg2NFEmYW1wO3I9VVQzQms5Y2JM ZWFKeGhmM2lDcmhJb1VXQjhZTFpVMjMwMjlzTVFHUTJrWSZhbXA7bT0tPGJyPg0KJmd0OyAmZ3Q7 Jmd0Ozxicj4NCiZndDsgNXJnWXFfbllNYlNIMkhYSG5IRkNGaTJLRFl6T0NsaFNpTG4wYXU4V3Uw JmFtcDtzPWlFcTF0VURiZVFMNGYzU0xNPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBmMS14aWhqSllUMEtB QU5fQldUbDktNzc5YyZhbXA7ZT08YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgSVB2NCBpcyBvdmVyPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsgQXJlIHlvdSByZWFkeSBmb3IgdGhlIG5ldyBJbnRlcm5ldCA/PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHAtIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cC08L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgPGEgaHJl Zj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfXzNB LTVGLTVGd3d3LmNvbnN1bGludGVsLmVzJmFtcDtkPUR3TUZhUSZhbXA7Yz1CRnBXUXc4YnN1S3Bs MVNnaVpINjRRJmFtcDtyPVVUM0JrOWNiTGVhSnhoZjNpQ3JoSW9VV0I4WUxaVTIzMDI5c01RR1Ey a1kmYW1wO209TVlHOEJfbXY5aE56enVNdGdnVHdWdHBSZU9YUjVEQWUzVUFacVlBUkRDayZhbXA7 cz1iTFpMUXgyOGtwRDd3dmdBSEpEQ1VERlhYbGZhSmhGU0lScU9ZQ1hmc1ZJJmFtcDtlPSIgdGFy Z2V0PSJfYmxhbmsiPg0KM0FfX3d3dy5jb25zdWxpbnRlbC5lczwvYT4mYW1wO2Q9RHdJRGFRJmFt cDtjPUJGcFdRdzhic3VLcGwxU2dpWkg2NFEmYW1wO3I9VVQzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBC azljYkxlYUp4aGYzaUNyaElvVVdCOFlMWlUyMzAyOXNNUUdRMmtZJmFtcDttPS08YnI+DQomZ3Q7 ICZndDsmZ3Q7PGJyPg0KJmd0OyA1cmdZcV9uWU1iU0gySFhIbkhGQ0ZpMktEWXpPQ2xoU2lMbjBh dThXdTAmYW1wO3M9R01STGRJdEY4eUtiVWRFOTxicj4NCiZndDsgJmd0OyZndDsgTnVYRS1VNDh1 azdPSE51RWlqeW05amhFLS1zJmFtcDtlPTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IFRoZSBJUHY2 IENvbXBhbnk8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IFRo aXMgZWxlY3Ryb25pYyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIG1heSBiZSBw cml2aWxlZ2VkIG9yPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBjb25maWRlbnRpYWwuIFRoZSBpbmZvcm1h dGlvbiBpcyBpbnRlbmRlZCB0byBiZSBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2Y8YnI+DQomZ3Q7 IHRoZTxicj4NCiZndDsgJmd0OyZndDsgaW5kaXZpZHVhbChzKSBuYW1lZCBhYm92ZSBhbmQgZnVy dGhlciBub24tZXhwbGljaWx0eSBhdXRob3JpemVkPGJyPg0KJmd0OyBkaXNjbG9zdXJlLDxicj4N CiZndDsgJmd0OyZndDsgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVu dHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgZXZlbiBpZjxicj4NCiZndDsgJmd0OyZndDsgcGFydGlh bGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5k IHdpbGwgYmU8YnI+DQomZ3Q7IGNvbnNpZGVyZWQgYTxicj4NCiZndDsgJmd0OyZndDsgY3JpbWlu YWwgb2ZmZW5zZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBiZSBhd2Fy ZSB0aGF0IGFueTxicj4NCiZndDsgJmd0OyZndDsgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJp YnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVudHMgb2YgdGhpcyBpbmZvcm1hdGlvbiw8YnI+DQom Z3Q7ICZndDsmZ3Q7IGV2ZW4gaWYgcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMs IGlzIHN0cmljdGx5IHByb2hpYml0ZWQsIHdpbGwgYmU8YnI+DQomZ3Q7ICZndDsmZ3Q7IGNvbnNp ZGVyZWQgYSBjcmltaW5hbCBvZmZlbnNlLCBzbyB5b3UgbXVzdCByZXBseSB0byB0aGUgb3JpZ2lu YWwgc2VuZGVyIHRvPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBpbmZvcm0gYWJvdXQgdGhpcyBjb21tdW5p Y2F0aW9uIGFuZCBkZWxldGUgaXQuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyB2Nm9wcyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyA8 YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52Nm9wc0BpZXRm Lm9yZzwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3VybGRlZmVu c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtPC9hPjxicj4NCiZn dDsgJmd0OyZndDs8YnI+DQomZ3Q7IDNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb192 Nm9wcyZhbXA7ZD1Ed0lEYVEmYW1wO2M9QkZwV1F3OGJzdUtwPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBs MVNnaVpINjRRJmFtcDtyPVVUM0JrOWNiTGVhSnhoZjNpQ3JoSW9VV0I4WUxaVTIzMDI5c01RR1Ey a1kmYW1wO209LTxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7IDVyZ1lxX25ZTWJTSDJIWEhu SEZDRmkyS0RZek9DbGhTaUxuMGF1OFd1MCZhbXA7cz1pRXExdFVEYmVRTDRmM1NMTTxicj4NCiZn dDsgJmd0OyZndDsgZjEteGloakpZVDBLQUFOX0JXVGw5LTc3OWMmYW1wO2U9PGJyPg0KPGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQp2Nm9w cyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWls bWFuX2xpc3RpbmZvX3Y2b3BzJmFtcDtkPUR3TUZhUSZhbXA7Yz1CRnBXUXc4YnN1S3BsMVNnaVpI NjRRJmFtcDtyPVVUM0JrOWNiTGVhSnhoZjNpQ3JoSW9VV0I4WUxaVTIzMDI5c01RR1Eya1kmYW1w O209TVlHOEJfbXY5aE56enVNdGdnVHdWdHBSZU9YUjVEQWUzVUFacVlBUkRDayZhbXA7cz1OOHRn SHB1ZUdscDIwNjJ6Z2syQ0dnMlZsSW5yQjV3ZXg4VzQzLURIY3hJJmFtcDtlPSIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxicj4NCjxiciBjbGVhcj0iYWxsIiBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOmxpbmUt YnJlYWsiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KRGF2aWQgRmFybWVyJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7IDxhIGhyZWY9Im1h aWx0bzpFbWFpbCUzQWZhcm1lckB1bW4uZWR1IiB0YXJnZXQ9Il9ibGFuayI+DQpFbWFpbDpmYXJt ZXJAdW1uLmVkdTwvYT48YnI+DQpOZXR3b3JraW5nICZhbXA7IFRlbGVjb21tdW5pY2F0aW9uIFNl cnZpY2VzPGJyPg0KT2ZmaWNlIG9mIEluZm9ybWF0aW9uIFRlY2hub2xvZ3k8YnI+DQpVbml2ZXJz aXR5IG9mIE1pbm5lc290YSZuYnNwOyZuYnNwOyA8YnI+DQoyMjE4IFVuaXZlcnNpdHkgQXZlIFNF Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFBob25lOiA2MTItNjI2LTA4MTU8YnI+DQpNaW5u ZWFwb2xpcywgTU4gNTU0MTQtMzAyOSZuYnNwOyZuYnNwOyBDZWxsOiA2MTItODEyLTk5NTI8YnI+ DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9142206A0C5BF24CB22755C8EC422E459CB452E3AZUS1EXMB03glob_-- From nobody Tue Aug 28 15:02:38 2018 Return-Path: <rajiva@cisco.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08792130F44 for <v6ops@ietfa.amsl.com>; Tue, 28 Aug 2018 15:02:36 -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_MED=-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 MsTKLAqCC6W3 for <v6ops@ietfa.amsl.com>; Tue, 28 Aug 2018 15:02:34 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D98B2130F34 for <v6ops@ietf.org>; Tue, 28 Aug 2018 15:02:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4074; q=dns/txt; s=iport; t=1535493753; x=1536703353; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EWPvREiGidzvp7pQbJp8ZrFrpqivcvbwRQkt0KVXVGg=; b=kNapaBBdjpB8/ZdnRGUdF1Z0/+pzndPpvDlTGWYbBwQZWtwqD+73i6Ec d6k8KbwWNyBJeu8NmRQFY9JBBBgTQyWjMSCBY4FJ4nkkfimEc/17DeLv+ juJ7ygHQSCRlWpf5nargVfgBejehqY4S/tH22P4HUXSJMpPyL/RzXz0UC U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CVAQBqxYVb/5xdJa1aGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNPZX8omC+CDYhVj00LGAuESQKCeCE3FQECAQECAQECbRw?= =?us-ascii?q?MhTcBAQEBAgEBATg0CwULAgEIGB4QIQYLJQEBBA4FFIMNAYFpAw0ID6VdhC0?= =?us-ascii?q?BPYI8DYMsBYoQF4FBP4ESJx+CTIJWRQEBgTongzKCJgKbBysJAoxegxAXjk2?= =?us-ascii?q?MAockAhEUgSQzIoFScBU7KgGCPoIlF4hZhT5vAYoBgkoBAQ?= X-IronPort-AV: E=Sophos;i="5.53,300,1531785600"; d="scan'208";a="163775947" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Aug 2018 22:02:33 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id w7SM2WDU026705 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Aug 2018 22:02:32 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 28 Aug 2018 17:02:32 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1367.000; Tue, 28 Aug 2018 17:02:32 -0500 From: "Rajiv Asati (rajiva)" <rajiva@cisco.com> To: Brian E Carpenter <brian.e.carpenter@gmail.com> CC: Ron Bonica <rbonica@juniper.net>, "v6ops@ietf.org" <v6ops@ietf.org> Thread-Topic: [v6ops] draft-palet-v6ops-rfc6177-bis Thread-Index: AdQ+ERSkgrY6L5QoTzWBeUJlAjTblQApmRSAABjWLeE= Date: Tue, 28 Aug 2018 22:02:32 +0000 Message-ID: <16634B7C-B8B0-49B5-B98E-D889F77571F5@cisco.com> References: <CO1PR05MB443BFFA74AAEB374E38BD8FAE0B0@CO1PR05MB443.namprd05.prod.outlook.com>, <80ec965c-4a6c-3cc8-b92f-ad03603f9223@gmail.com> In-Reply-To: <80ec965c-4a6c-3cc8-b92f-ad03603f9223@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/vsYHFpPVqVs4BhT8oMNqiQnVzg0> Subject: Re: [v6ops] draft-palet-v6ops-rfc6177-bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 28 Aug 2018 22:02:36 -0000 This draft should provide a definition for the end-site. Is it a connectivi= ty device such as a home GW/router or consumption device such as a mobile t= ablet or ...? Answer is all of the above.=20 This draft should also explicitly cover cellular/mobile devices that curren= tly get limited to /64, since they could also qualify as end-site.=20 Cheers, Rajiv Asati =20 > On Aug 28, 2018, at 1:11 AM, Brian E Carpenter <brian.e.carpenter@gmail.c= om> wrote: >=20 > Hi, >=20 > I fully support this draft. Here are a few (minor) wording issues > and some nits. >=20 > Issues: > ------- >> [RFC3177] called for a default end-site IPv6 assignment size of /48. >> Subsequently, the Regional Internet Registries (RIRs) developed and >> adopted IPv6 address assignment and allocation policies consistent >> with those recommendations, and it triggered the development of >> [RFC6177]. However, some of the RIRs, have later on updated those >> policies, which still allow using /48, but leave the decision in the >> hands of the ISP, or even, in some cases, encourage the assignment of >> smaller (e.g., /56) blocks to residential end-sites, while keeping >> /48 for business. >=20 > I don't think that is accurate. Actually there was push-back *from* > the RIRs against the wording of 3177, because some ISPs did not wish > to be consistent with it. Here's another version: >=20 > [RFC3177] called for a default end-site IPv6 assignment size of /48. > Subsequently, the Regional Internet Registries (RIRs) developed and > adopted IPv6 address assignment and allocation policies consistent > with ISP practices, and this triggered the development of [RFC6177]. > Current RIR policies still allow using /48, but leave the decision in t= he > hands of the ISP, or even, in some cases, endorse the assignment of > smaller (e.g., /56) blocks to residential end-sites, while keeping > /48 for business. >=20 >> This raises the question of a possible misinterpretation of [RFC6177] >> by at least 1/3rd of the operational community and consequently, the >> need to revisit it. >=20 > No, I don't think there's any misinterpretation. I think it's quite > clear (as in my previous comment) that this is exactly why the ISP > community pushed for RFC6177. I think we should phrase this a bit > differently. >=20 > This raises the question of over-zealous interpretation of [RFC6177] > by at least one third of the ISP community and consequently, the > need to revisit it. >=20 >> It might be tempting to give home sites a single /64, since that is >> already significantly more address space compared with today's IPv4 >> practice. However, this precludes the certainty that even home sites >> will grow to support multiple subnets going forward. Hence, it is >> strongly intended that even home sites be given a big number of >> subnets worth of space, by default. Hence, this document still >> recommends giving home sites significantly many more than a single >> /64. >=20 > I think a reference to RFC7368 and RFC7788 would be useful here, to make > it clear that this is not guesswork. (Note that HNCP is mentioned later, > so there is a little repetition in the argument.) >=20 > Nits: > ----- >=20 >> Abstract >>=20 >> The Regional Internet Registries (RIRs) policies, have different > Delete the comma >=20 >> requires an ever-increasing availability of subnets at the end-site >> and so, policy should reflect that assignment of a single subnet is >=20 > NEW > requires an ever-increasing availability of subnets at the end-site, > so policy should reflect that the assignment of a single subnet is >=20 > I see a number of other minor syntax and punctuation nits in the > text, but I'm afraid I'm going to leave those for the copy-editor. >=20 > Regards, > Brian >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Aug 28 15:33:02 2018 Return-Path: <fredbaker.ietf@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A43130F25; Tue, 28 Aug 2018 15:33:01 -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 2i09pMWEp-9n; Tue, 28 Aug 2018 15:32:59 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 401BF130DE8; Tue, 28 Aug 2018 15:32:59 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id l202-v6so5764142oig.7; Tue, 28 Aug 2018 15:32:59 -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=cudVxcQCCVg1L0lJTqJ+AmSajFBPNoUAFOWbX81smtg=; b=GSVXqoyasEXlrkbOQbCH6isPV2Bv64X9dvEBtw9KxySFZMeBJmWF3kQARr6DODuYrI L27iS2LHSDwoox6GP9HFvGDvKUZVmTxtv1cR69mSjqxug2YexYB9UBsQ4/9kILWedtvP uKLD7YS/9WAIpdqwwOlU/fdsFRl7CJERStkQSdbiayvoZlvZxazDWEfGKHs+/24bCWl1 9Ro/yoIgbwcWEOMpDYumIw4Opuz1Q+TixLlfFhT17M+nm2e40m/5RQmhEHgoRtCnVbbp HFPz8SFPsklxhD6DbmR0FDgXW1Q2orVpBL7RpsqbQaGwZTS4TZ2x1z4DUfk0g4F9rSli io6Q== 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=cudVxcQCCVg1L0lJTqJ+AmSajFBPNoUAFOWbX81smtg=; b=jAk4M/bUanFlYUHzniENfvIZhbAAkQl5qYSsyq6S78wfQrciMn/E2CO266cjzxylFq t1HQzMQZ28paT2Z6lPqna6J+bwFG4I4HqViFSzZskwT4cP1he4oMqoDZQBIFIYxnQF6v dmLKDIt+SP97Fik/IBZNMCyBcT4ThB0UTJGQRA2R5W6IWz5+L1U+x+0CN3dV63tlk5pr apxLJqwLhxa+z0RfbWqzSvFPvA1QZOopCXk3IqC+p0AJdgam5j4jzfJ5H1+NoBhoXOnR b55sJGn6pk68gFOjaBuLb9LCm97/SG7zNcl4TI7EnEoaFKxFctY//YEwrclkJHJ9kyNM gq8A== X-Gm-Message-State: APzg51Cr34omL8S8uWxEGe5zJNqgUds3MQkd2KwYY0ctgvRiqIj9HrlM Bii7K2xZijWwS4xEA3AUpBg= X-Google-Smtp-Source: ANB0Vdakr9o6BuFOl+JenfuDfNXoKa2c92P5q1vrOSHG54GB5a4b/ivyJX7I+rouBDflVTn7tnj4Ow== X-Received: by 2002:aca:171a:: with SMTP id j26-v6mr78910oii.277.1535495578642; Tue, 28 Aug 2018 15:32:58 -0700 (PDT) Received: from ?IPv6:2600:8802:5600:1546::1053? ([2600:8802:5600:1546::1053]) by smtp.gmail.com with ESMTPSA id f4-v6sm3306973oic.52.2018.08.28.15.32.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Aug 2018 15:32:57 -0700 (PDT) From: Fred Baker <fredbaker.ietf@gmail.com> Message-Id: <A82D3E92-C68D-4685-BD3D-6B2656F9A8A6@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_AF3DCC37-C441-4932-B8F3-AC4744D70C24"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Tue, 28 Aug 2018 15:32:55 -0700 In-Reply-To: <9142206A0C5BF24CB22755C8EC422E459CB44E7E@AZ-US1EXMB03.global.avaya.com> Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Lea Roberts <lea.roberts@stanford.edu>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org>, "draft-palet-v6ops-rfc6177-bis@ietf.org" <draft-palet-v6ops-rfc6177-bis@ietf.org>, IPv6 Operations <v6ops@ietf.org> To: "Mudric, Dusan (Dusan)" <dmudric@avaya.com> References: <153017691583.14743.17000446834856511528@ietfa.amsl.com> <78a36a81-3bb3-9d47-aa06-8da8f7594677@gmail.com> <C040E02F-7BEC-4FF9-8585-BE380B6859DE@consulintel.es> <alpine.DEB.2.02.1807191054090.7979@networking.stanford.edu> <9142206A0C5BF24CB22755C8EC422E459CB44344@AZ-US1EXMB03.global.avaya.com> <f1bc1848-abe0-553e-0fdf-623eb0d1a871@gmail.com> <9142206A0C5BF24CB22755C8EC422E459CB44E7E@AZ-US1EXMB03.global.avaya.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/U-Ejjo-9c5kTXH1lRZzmtN4FCMM> Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 28 Aug 2018 22:33:01 -0000 --Apple-Mail=_AF3DCC37-C441-4932-B8F3-AC4744D70C24 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 28, 2018, at 8:06 AM, Mudric, Dusan (Dusan) <dmudric@avaya.com> = wrote: > There must a way to define how prefixes are assigned to always allow = /48, if needed. If not in rfc6177-bis than in another RFC. We have = already one limitation for SLAAC that makes sure every home gets at = least one /64. We can add another one, in another RFC, to make sure /48 = is given on a demand. That will insure future flexibility in any network = and make the prefix assignment non-political process. My understanding, no hats and potentially incorrect, is that any ISP I = know of will respond to a DHCPv6 IA_PD with a prefix at least as large = as requested, up to /48. = --------------------------------------------------------------------------= ------ The fact that there is a highway to hell and a stairway to heaven is an = interesting comment on projected traffic volume... --Apple-Mail=_AF3DCC37-C441-4932-B8F3-AC4744D70C24 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+AFAluFzZgACgkQEhdRnd2G P+Czmg//VVMQG5/T6uJEDt13lh/Xurb5QvoQnr/aryO9vLuyXtfUNIEZLPwiDjaL twtVCQGFP0QiK8nRjCFuxqF0ItjEItNxwA3n8o/B+vAA6376fwixi4HsxUm9vwOb Eegk71C5MYwRlJzWp8+FFATH1+9NuhOYQrU8PEubQiIcRrEjzRRHJkU1qNKN+1An lXv6XR0XJpRo5LcHxbvpwkJUW5skQiqrQZTtJzhr2Wa2mULJeVRaoxwrZe2Om2rP oWtBaeUlDGYIeAhwmoZFtswCmwR/G9WB+MA2vNPCJKx2nMVfiDBmOY5vWcCHSNhD E/J4mDdoeBXlqu0YMcxSko3Q17mLFF2a7MVAUW1fOOgBZ73+depYGiwFIb1ayoUY nYxLLrxK5Dfkcr3tZJuaR9dJs//B5xJSu9KQ5L21c10NNaapWgTBzjN6cOErnVr5 tEkx2ypRTON0G4J4yBSMxLtCW97KjMecd/zuqphZmy6hifS83bNjs2LLbzg4imD9 A3wMxp6yaAuGlaOs160mKv3GS8VknngkovLsAng71v0THwm8hduoiNicyGpkXQa9 xFMAGEfDfWIwLHG33sxvIll5kkKW3eJOUCdNSJm1OPBBlyciu2wD/B1bSTip4QP1 dIzILdFY3tq5w4/QL4MciwaZ2yoyxe9Y0OGXTIl9gVMSkIjkvuY= =EUdF -----END PGP SIGNATURE----- --Apple-Mail=_AF3DCC37-C441-4932-B8F3-AC4744D70C24-- From nobody Tue Aug 28 17:04:10 2018 Return-Path: <farmer@umn.edu> 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 E006B12426A for <v6ops@ietfa.amsl.com>; Tue, 28 Aug 2018 17:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.289 X-Spam-Level: X-Spam-Status: No, score=-4.289 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_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu 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 T74FlZEETLcy for <v6ops@ietfa.amsl.com>; Tue, 28 Aug 2018 17:04:07 -0700 (PDT) Received: from mta-p6.oit.umn.edu (mta-p6.oit.umn.edu [134.84.196.206]) (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 59FDE130E29 for <v6ops@ietf.org>; Tue, 28 Aug 2018 17:04:06 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p6.oit.umn.edu (Postfix) with ESMTP id C5E13F9E for <v6ops@ietf.org>; Wed, 29 Aug 2018 00:04:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p6.oit.umn.edu ([127.0.0.1]) by localhost (mta-p6.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zp4tEKejau-1 for <v6ops@ietf.org>; Tue, 28 Aug 2018 19:04:04 -0500 (CDT) Received: from mail-vk0-f70.google.com (mail-vk0-f70.google.com [209.85.213.70]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p6.oit.umn.edu (Postfix) with ESMTPS id 78C8FCCC for <v6ops@ietf.org>; Tue, 28 Aug 2018 19:04:04 -0500 (CDT) Received: by mail-vk0-f70.google.com with SMTP id r11-v6so1348061vke.10 for <v6ops@ietf.org>; Tue, 28 Aug 2018 17:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DLBR9U0HE6vqgOATjk6+2zLFsG620Y9MzYRAaTOjqto=; b=Iq8jl+l1zYcSxAY7NMTp2ohop57iKlPMGLrbFGkKNVscH4hWbd2YxAJSBgyTMMs2X/ sBGCgWLehL3zEEWhQe31UBgKrHNJsBZYxtd5lAwqsbu41gpMDDbRQrnKFMt7Rk9/keIr 3yDnA+MHU8ejaPzyXMeDeVbGTpfgN0lQ07I8fN0v5vAx2MJRVkZZiHpnl3UwEZd/Z9U8 6aUvOVjlJ6G9b+DFK0xsDiWnSBPNiAXMYsHNpKHLttJkUt5u6VczcQB9Ns7FWm62sqvU FWwh/36THMQznv4QjM1FQ00v6i6kPTVOspX2VEkhEaxJnu6DV7HaDzfjkgpreYMgC1fM EUsw== 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=DLBR9U0HE6vqgOATjk6+2zLFsG620Y9MzYRAaTOjqto=; b=WU8hof9tcmgM7cK2UOcbmCQiETneuezckjXgtt/cIri8MHf1c2czJSw1qLJ/Y4vPyx SAe1B+YPCtaX+gwxRQsVXL4evvo3EtEnqbvo/oxClqn6IrJJNIMOUVfYfRCRjHxrCG9v JrVv33IKAlBzOOOUcSaHGyBleUVzjnZ3QwQB3gL9+z7qpWpjCLgN35nvXIkx//YGMzBy yM1egomhBITrlDlvoVyuIIZWd6BaTGPLJAP0vgE18YhT3ETVypWD8sKPFcVvpdbOUFU/ p8s8AV+gLrkvvLm71SndjcTMhTBenQbjQZBMqPqI3fa1+kF3Ydg7zT//5WSPccYFO4gG sQNw== X-Gm-Message-State: APzg51BBuEYvk6w5oa/CwSqDxEAWJBJ6WPWEPaOmnDEXRJHMGMkM1sZr fNSOXi3UvwoN3IPf0QOfriLE3I57Nx1+KHuqAXiupK+ATKBAzEG1j9AQk4VjK16LsEycfzY7YFW sGJhgCnaupHB3+yNWGCLu6kW+aA== X-Received: by 2002:a1f:9807:: with SMTP id a7-v6mr2555978vke.65.1535501043119; Tue, 28 Aug 2018 17:04:03 -0700 (PDT) X-Google-Smtp-Source: ANB0Vdacxdb9MUZXeE9hArcfoyanqe3tb4+5rWuA92lb3+emKuR6ZlSDvzK7fruOX9k4Q7ORZaXT1J2pCpKUN50I6EY= X-Received: by 2002:a1f:9807:: with SMTP id a7-v6mr2555963vke.65.1535501042707; Tue, 28 Aug 2018 17:04:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a67:3bc7:0:0:0:0:0 with HTTP; Tue, 28 Aug 2018 17:04:01 -0700 (PDT) In-Reply-To: <A82D3E92-C68D-4685-BD3D-6B2656F9A8A6@gmail.com> References: <153017691583.14743.17000446834856511528@ietfa.amsl.com> <78a36a81-3bb3-9d47-aa06-8da8f7594677@gmail.com> <C040E02F-7BEC-4FF9-8585-BE380B6859DE@consulintel.es> <alpine.DEB.2.02.1807191054090.7979@networking.stanford.edu> <9142206A0C5BF24CB22755C8EC422E459CB44344@AZ-US1EXMB03.global.avaya.com> <f1bc1848-abe0-553e-0fdf-623eb0d1a871@gmail.com> <9142206A0C5BF24CB22755C8EC422E459CB44E7E@AZ-US1EXMB03.global.avaya.com> <A82D3E92-C68D-4685-BD3D-6B2656F9A8A6@gmail.com> From: David Farmer <farmer@umn.edu> Date: Tue, 28 Aug 2018 19:04:01 -0500 Message-ID: <CAN-Dau0-HgSeCxAvSBXMXnuOh0BhY7i_Tm_K7BE4of5jZtnCdA@mail.gmail.com> To: Fred Baker <fredbaker.ietf@gmail.com> Cc: "Mudric, Dusan (Dusan)" <dmudric@avaya.com>, "draft-palet-v6ops-rfc6177-bis@ietf.org" <draft-palet-v6ops-rfc6177-bis@ietf.org>, IPv6 Operations <v6ops@ietf.org>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org> Content-Type: multipart/alternative; boundary="000000000000340441057487b2e5" Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/RKAToSn_icZYoyyNMcN6KE91-q0> Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 29 Aug 2018 00:04:09 -0000 --000000000000340441057487b2e5 Content-Type: text/plain; charset="UTF-8" On Tue, Aug 28, 2018 at 5:32 PM, Fred Baker <fredbaker.ietf@gmail.com> wrote: > > > On Aug 28, 2018, at 8:06 AM, Mudric, Dusan (Dusan) <dmudric@avaya.com> > wrote: > > There must a way to define how prefixes are assigned to always allow > /48, if needed. If not in rfc6177-bis than in another RFC. We have already > one limitation for SLAAC that makes sure every home gets at least one /64. > We can add another one, in another RFC, to make sure /48 is given on a > demand. That will insure future flexibility in any network and make the > prefix assignment non-political process. > > My understanding, no hats and potentially incorrect, is that any ISP I > know of will respond to a DHCPv6 IA_PD with a prefix at least as large as > requested, up to /48. > Fred, the statement you are making I believe is true for many or most ISP's providing IPv6 today, but not all. However, way too many ISPs are still not yet providing IPv6. Further, many of the early IPv6 capable CPE or terminal devices only ask for a /64 and can't be told otherwise. So when I look at the current state of things, I'm both optimistic and pessimistic at the same time. Dusan, it's not as simple as the ISP are not providing /48s, as Fred says many, if not most, doing IPv6 are, a big part of the issue is too many CPEs only ask for a /64, and don't allow a different option. But from the perspective of a normal end-user they are being limited, and who is at fault is complicated. There is plenty of blame to go around for everyone, the ISPs, the CPE manufacturers, the IETF, and even a little for the end-users themselves. RFC7084; WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating router the size of the prefix it requires. If so, it MUST ask for a prefix large enough to assign one /64 for each of its interfaces, rounded up to the nearest nibble, and SHOULD be configurable to ask for more. I think at least part of the problem is a common one, too many inexpensive CPE do not implement optional features. Because both ISP's and end-users have economic incentives to use inexpensive CPE, this creates an incentive for CPE manufacturers to make inexpensive CPE do not implement optional features. Around and around we go. It is a complicated systemic failure mode we have going here. Maybe we need "MUST be configurable to ask for more.", which is the IETF's fault! Thanks. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --000000000000340441057487b2e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div style=3D"font-size:small;text-decoration-style:initia= l;text-decoration-color:initial"><div><div style=3D"font-size:small;backgro= und-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-co= lor:initial"><br></div></div></div><div class=3D"gmail_extra"><div class=3D= "gmail_quote">On Tue, Aug 28, 2018 at 5:32 PM, Fred Baker <span dir=3D"ltr"= ><<a href=3D"mailto:fredbaker.ietf@gmail.com" target=3D"_blank">fredbake= r.ietf@gmail.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote"= style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p= adding-left:1ex"><br> <br> On Aug 28, 2018, at 8:06 AM, Mudric, Dusan (Dusan) <<a href=3D"mailto:dm= udric@avaya.com">dmudric@avaya.com</a>> wrote:<br> > There must a way to define how prefixes are assigned to always allow /= 48, if needed. If not in rfc6177-bis than in another RFC. We have already o= ne limitation for SLAAC that makes sure every home gets at least one /64. W= e can add another one, in another RFC, to make sure /48 is given on a deman= d. That will insure future flexibility in any network and make the prefix a= ssignment non-political process.<br> <br> My understanding, no hats and potentially incorrect, is that any ISP I know= of will respond to a DHCPv6 IA_PD with a prefix at least as large as reque= sted, up to /48.<br></blockquote><div><br></div><div><div style=3D"font-siz= e:small;text-decoration-style:initial;text-decoration-color:initial"><div s= tyle=3D"background-color:rgb(255,255,255);text-decoration-style:initial;tex= t-decoration-color:initial"><span style=3D"font-size:small;text-decoration-= style:initial;text-decoration-color:initial;background-color:rgb(255,255,25= 5);float:none;display:inline">Fred, the statement you are making I believe = is true for many or most ISP's providing IPv6 today, but not all. Howev= er, way too many ISPs are still not yet providing IPv6. Further,=C2=A0<span= style=3D"font-size:small;text-decoration-style:initial;text-decoration-col= or:initial;float:none;display:inline">many of the early IPv6 capable CPE or= terminal devices only ask for a /64 and can't be told otherwise. S</sp= an></span><span style=3D"font-size:small;background-color:rgb(255,255,255);= text-decoration-style:initial;text-decoration-color:initial;float:none;disp= lay:inline">o when I look at the current state of things, I'm both opti= mistic and pessimistic at the same time.</span><br class=3D"gmail-Apple-int= erchange-newline"><br></div><div style=3D"background-color:rgb(255,255,255)= ;text-decoration-style:initial;text-decoration-color:initial"><span style= =3D"font-size:small;text-decoration-style:initial;text-decoration-color:ini= tial;float:none;display:inline">Dusan,</span>=C2=A0it's not as simple a= s the ISP are not providing /48s, as Fred says many, if not most, doing IPv= 6 are, a big part of the issue is too many CPEs only ask for a /64, and don= 't allow a different option. But from the perspective of a normal end-u= ser they are being limited, and who is at fault is complicated.=C2=A0 There= is plenty of blame to go around for everyone, the ISPs, the CPE manufactur= ers, the IETF, and even a little for the end-users themselves.</div></div><= div style=3D"font-size:small;text-decoration-style:initial;text-decoration-= color:initial"><br></div><div style=3D"font-size:small;text-decoration-styl= e:initial;text-decoration-color:initial">RFC7084;</div><div style=3D"font-s= ize:small;text-decoration-style:initial;text-decoration-color:initial">=C2= =A0 =C2=A0WPD-2:=C2=A0 The IPv6 CE router MAY indicate as a hint to the del= egating</div><div style=3D"font-size:small;text-decoration-style:initial;te= xt-decoration-color:initial">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0route= r the size of the prefix it requires.=C2=A0 If so, it MUST</div><div style= =3D"font-size:small;text-decoration-style:initial;text-decoration-color:ini= tial">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ask for a prefix large enoug= h to assign one /64 for each of</div><div style=3D"font-size:small;text-dec= oration-style:initial;text-decoration-color:initial">=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0its<span>=C2=A0</span><span class=3D"gmail-gr_ gmail-gr= _1236 gmail-gr-alert gmail-gr_gramm gmail-gr_inline_cards gmail-gr_disable_= anim_appear gmail-Punctuation gmail-only-del gmail-replaceWithoutSep" id=3D= "gmail-1236" style=3D"display:inline;border-bottom:2px solid transparent;ba= ckground-repeat:no-repeat;color:inherit;font-size:inherit">interfaces,</spa= n><span>=C2=A0</span>rounded up to the nearest nibble, and SHOULD</div><div= style=3D"font-size:small;text-decoration-style:initial;text-decoration-col= or:initial">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be configurable to ask= for more.</div><div style=3D"font-size:small;text-decoration-style:initial= ;text-decoration-color:initial"><span style=3D"background-color:rgb(255,255= ,255);text-decoration-style:initial;text-decoration-color:initial;float:non= e;display:inline"><br></span></div><div style=3D"font-size:small;text-decor= ation-style:initial;text-decoration-color:initial"><span style=3D"backgroun= d-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-colo= r:initial;float:none;display:inline">I think at least part of=C2=A0the prob= lem is a common one, too many inexpensive CPE do not implement optional fea= tures. Because</span><span style=3D"background-color:rgb(255,255,255);text-= decoration-style:initial;text-decoration-color:initial;float:none;display:i= nline">=C2=A0both ISP's and end-users have economic incentives to use i= nexpensive CPE, this creates an incentive for CPE manufacturers<span style= =3D"font-size:small;text-decoration-style:initial;text-decoration-color:ini= tial;float:none;display:inline"><span></span></span><span>=C2=A0</span>to m= ake=C2=A0<span style=3D"font-size:small;text-decoration-style:initial;text-= decoration-color:initial;float:none;display:inline">inexpensive CPE do not = implement optional features.=C2=A0 Around and around we go.=C2=A0</span></s= pan><br></div><div style=3D"font-size:small;text-decoration-style:initial;t= ext-decoration-color:initial"><br></div><div style=3D"text-decoration-style= :initial;text-decoration-color:initial">It is a complicated systemic failur= e mode we have going here.<br></div><div style=3D"text-decoration-style:ini= tial;text-decoration-color:initial"><br></div><div style=3D"text-decoration= -style:initial;text-decoration-color:initial">Maybe we need "MUST be c= onfigurable to ask for more.", which is the IETF's fault!</div><di= v><br></div><div style=3D"text-decoration-style:initial;text-decoration-col= or:initial">Thanks.</div><br></div></div><div><br></div>-- <br><div class= =3D"gmail_signature">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D<br>David Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0=C2=A0 <a href=3D"mailto:Email%3Afarmer@umn.edu" target=3D"_blank">Email= :farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Offic= e of Information Technology<br>University of Minnesota=C2=A0=C2=A0 <br>2218= University Ave SE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815<br>Minnea= polis, MN 55414-3029=C2=A0=C2=A0 Cell: 612-812-9952<br>=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div> </div></div> --000000000000340441057487b2e5-- From nobody Wed Aug 29 05:13:15 2018 Return-Path: <bs7652@att.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20C9130E84; Wed, 29 Aug 2018 05:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 AiUnADWiTjFu; Wed, 29 Aug 2018 05:13:11 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 8C8F1130DD4; Wed, 29 Aug 2018 05:13:09 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id w7TC5qtq020457; Wed, 29 Aug 2018 08:11:40 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 2m5tuvgm2c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Aug 2018 08:11:40 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w7TCBdOi008445; Wed, 29 Aug 2018 08:11:40 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [135.47.91.93]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id w7TCBYjY008371; Wed, 29 Aug 2018 08:11:35 -0400 Received: from zlp30488.vci.att.com (zlp30488.vci.att.com [127.0.0.1]) by zlp30488.vci.att.com (Service) with ESMTP id F1FB04048C25; Wed, 29 Aug 2018 12:11:34 +0000 (GMT) Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (unknown [130.8.218.154]) by zlp30488.vci.att.com (Service) with ESMTPS id E02824048C21; Wed, 29 Aug 2018 12:11:34 +0000 (GMT) Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.179]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0408.000; Wed, 29 Aug 2018 08:11:34 -0400 From: "STARK, BARBARA H" <bs7652@att.com> To: "'Fred Baker'" <fredbaker.ietf@gmail.com>, "Mudric, Dusan (Dusan)" <dmudric@avaya.com> CC: "draft-palet-v6ops-rfc6177-bis@ietf.org" <draft-palet-v6ops-rfc6177-bis@ietf.org>, IPv6 Operations <v6ops@ietf.org>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org> Thread-Topic: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt Thread-Index: AQHUH3NaZWefO7PE5UO6xLlEY9uInaSW+0GAgAAwrwCAPQk0kIAA3boAgACyxoCAAHyjgP//zKLg Date: Wed, 29 Aug 2018 12:11:34 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6114DE872CA@GAALPA1MSGUSRBF.ITServices.sbc.com> References: <153017691583.14743.17000446834856511528@ietfa.amsl.com> <78a36a81-3bb3-9d47-aa06-8da8f7594677@gmail.com> <C040E02F-7BEC-4FF9-8585-BE380B6859DE@consulintel.es> <alpine.DEB.2.02.1807191054090.7979@networking.stanford.edu> <9142206A0C5BF24CB22755C8EC422E459CB44344@AZ-US1EXMB03.global.avaya.com> <f1bc1848-abe0-553e-0fdf-623eb0d1a871@gmail.com> <9142206A0C5BF24CB22755C8EC422E459CB44E7E@AZ-US1EXMB03.global.avaya.com> <A82D3E92-C68D-4685-BD3D-6B2656F9A8A6@gmail.com> In-Reply-To: <A82D3E92-C68D-4685-BD3D-6B2656F9A8A6@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.10.246.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-08-29_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=645 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1808290131 Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/aeB0MNuPM5y5PnDsztyJhdLda1I> Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 29 Aug 2018 12:13:14 -0000 > My understanding, no hats and potentially incorrect, is that any ISP I kn= ow of > will respond to a DHCPv6 IA_PD with a prefix at least as large as request= ed, > up to /48. I don't think this is correct. Of course, any provider using 6rd won't resp= ond to DHCPv6 at all. I'm aware of a lot of 6rd out there. Wireless LTE providers don't tend to support DHCPv6, either. The /64 advert= ised by the RA in an LTE environment is all the LTE UE will get. That inclu= des the case where the LTE UE is supporting a fixed wireless installation. For ISPs that support DHCPv6, it may or may not be the case. I've heard sev= eral say they do, but I'm not aware of a survey of all ISPs that would tell= me how prevalent it is. BTW, I disagree with the abstract's statement that the "policy should refle= ct that assignment of a single subnet is never appropriate." I do not belie= ve this takes into consideration the fact that it would be tremendously exp= ensive for some ISPs to replace their current equipment when those current = equipment vendors are being slow about supporting certain features. Cost is= always an appropriate consideration. It also does not take into account CE= routers that only request a single /64. I think it's inappropriate for IET= F to be trying to dictate what is and isn't "appropriate". Recommending a b= est current practice is fine. But that's not the same as saying something i= s "never appropriate". Barbara From nobody Wed Aug 29 08:01:57 2018 Return-Path: <dmudric@avaya.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28817130E80; Wed, 29 Aug 2018 08:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 GJgTGifmU5GI; Wed, 29 Aug 2018 08:01:52 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.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 ED5C9130DF6; Wed, 29 Aug 2018 08:01:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GdAAA8tIZb/yYyC4dXAw4LAQEBAQEBA?= =?us-ascii?q?QEBAQEBBwEBAQEBglcjVWVtEigKg2iIEYwpgg2IVYpCgxEUgWYLLIRAAheCdSE?= =?us-ascii?q?0GAECAQEBAQEBAgICaSiFOAEBAQECARIRCkwFCQICAQgNBAQBAQEKFgEGAwICA?= =?us-ascii?q?hkGBQwUCQgCBAENBAEIGoMAgR1MAw0IAZoRiW+BLhoChwgNgzEFigsXgUI+gRE?= =?us-ascii?q?BRoJMglZFBIEsAQsHASEEEQoFEBGCOjGCJgKIKoRnhVOIKisJAoxhgyeIXQOFc?= =?us-ascii?q?YZrhRyHUYFBOWFxcBWDJJAZOm8BAS9liREPF4EIAYEbAQE?= X-IPAS-Result: =?us-ascii?q?A2GdAAA8tIZb/yYyC4dXAw4LAQEBAQEBAQEBAQEBBwEBAQE?= =?us-ascii?q?BglcjVWVtEigKg2iIEYwpgg2IVYpCgxEUgWYLLIRAAheCdSE0GAECAQEBAQEBA?= =?us-ascii?q?gICaSiFOAEBAQECARIRCkwFCQICAQgNBAQBAQEKFgEGAwICAhkGBQwUCQgCBAE?= =?us-ascii?q?NBAEIGoMAgR1MAw0IAZoRiW+BLhoChwgNgzEFigsXgUI+gREBRoJMglZFBIEsA?= =?us-ascii?q?QsHASEEEQoFEBGCOjGCJgKIKoRnhVOIKisJAoxhgyeIXQOFcYZrhRyHUYFBOWF?= =?us-ascii?q?xcBWDJJAZOm8BAS9liREPF4EIAYEbAQE?= X-IronPort-AV: E=Sophos;i="5.53,303,1531800000"; d="scan'208,217";a="301758502" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 29 Aug 2018 11:01:49 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Aug 2018 11:01:48 -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; Wed, 29 Aug 2018 11:01:48 -0400 From: "Mudric, Dusan (Dusan)" <dmudric@avaya.com> To: David Farmer <farmer@umn.edu>, Fred Baker <fredbaker.ietf@gmail.com> CC: "draft-palet-v6ops-rfc6177-bis@ietf.org" <draft-palet-v6ops-rfc6177-bis@ietf.org>, IPv6 Operations <v6ops@ietf.org>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org> Thread-Topic: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt Thread-Index: AQHUPx8eUFztXZOFtEugH7bwjLKBe6TWHGSAgAC2tNA= Date: Wed, 29 Aug 2018 15:01:47 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E459CB45F34@AZ-US1EXMB03.global.avaya.com> References: <153017691583.14743.17000446834856511528@ietfa.amsl.com> <78a36a81-3bb3-9d47-aa06-8da8f7594677@gmail.com> <C040E02F-7BEC-4FF9-8585-BE380B6859DE@consulintel.es> <alpine.DEB.2.02.1807191054090.7979@networking.stanford.edu> <9142206A0C5BF24CB22755C8EC422E459CB44344@AZ-US1EXMB03.global.avaya.com> <f1bc1848-abe0-553e-0fdf-623eb0d1a871@gmail.com> <9142206A0C5BF24CB22755C8EC422E459CB44E7E@AZ-US1EXMB03.global.avaya.com> <A82D3E92-C68D-4685-BD3D-6B2656F9A8A6@gmail.com> <CAN-Dau0-HgSeCxAvSBXMXnuOh0BhY7i_Tm_K7BE4of5jZtnCdA@mail.gmail.com> In-Reply-To: <CAN-Dau0-HgSeCxAvSBXMXnuOh0BhY7i_Tm_K7BE4of5jZtnCdA@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: multipart/alternative; boundary="_000_9142206A0C5BF24CB22755C8EC422E459CB45F34AZUS1EXMB03glob_" MIME-Version: 1.0 Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/uZaRXBu-8NK8C9fA9Pv4M691TYI> Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 29 Aug 2018 15:01:55 -0000 --_000_9142206A0C5BF24CB22755C8EC422E459CB45F34AZUS1EXMB03glob_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGF2aWQsDQoNCj5SRkM3MDg0Ow0KPiAgIFdQRC0yOiAgVGhlIElQdjYgQ0Ugcm91dGVyIE1B WSBpbmRpY2F0ZSBhcyBhIGhpbnQgdG8gdGhlIGRlbGVnYXRpbmcNCj4gICAgICAgICAgIHJvdXRl ciB0aGUgc2l6ZSBvZiB0aGUgcHJlZml4IGl0IHJlcXVpcmVzLiAgSWYgc28sIGl0IE1VU1QNCj4g ICAgICAgICAgIGFzayBmb3IgYSBwcmVmaXggbGFyZ2UgZW5vdWdoIHRvIGFzc2lnbiBvbmUgLzY0 IGZvciBlYWNoIG9mDQo+ICAgICAgICAgICBpdHMgaW50ZXJmYWNlcywgcm91bmRlZCB1cCB0byB0 aGUgbmVhcmVzdCBuaWJibGUsIGFuZCBTSE9VTEQNCj4gICAgICAgICAgIGJlIGNvbmZpZ3VyYWJs ZSB0byBhc2sgZm9yIG1vcmUuDQo+TWF5YmUgd2UgbmVlZCAiTVVTVCBiZSBjb25maWd1cmFibGUg dG8gYXNrIGZvciBtb3JlLiIsIHdoaWNoIGlzIHRoZSBJRVRGJ3MgZmF1bHQhDQoNCkkgYmVsaWV2 ZSB0aGlzIHRoZSByaWdodCBhcHByb2FjaC4gV2UgY2Fubm90IGhhdmUgSVB2NiBuZXR3b3JrIHdo ZXJlIGRldmljZSBhbmQgYXBwbGljYXRpb24gdmVuZG9ycyBuZWVkIGZpcnN0IHRvIGdvIGFyb3Vu ZCB0aGUgd29ybGQgYW5kIG5lZ290aWF0ZSB3aXRoIGFsbCBJU1BzIHRvIHByb3ZpZGUgLzQ4LCBi ZWZvcmUgdGhleSBzdGFydCBidWlsZGluZyBuZXcgcHJvZHVjdHMgdGhhdCByZXF1aXJlIC80OC4g VGhlIG5ldHdvcmsgTVVTVCBiZSBmbGV4aWJsZSwgYnkgZGVmYXVsdC4NCg0KVGhhbmtzLA0KRHVz YW4uDQoNCkZyb206IERhdmlkIEZhcm1lciA8ZmFybWVyQHVtbi5lZHU+DQpTZW50OiBUdWVzZGF5 LCBBdWd1c3QgMjgsIDIwMTggODowNCBQTQ0KVG86IEZyZWQgQmFrZXIgPGZyZWRiYWtlci5pZXRm QGdtYWlsLmNvbT4NCkNjOiBNdWRyaWMsIER1c2FuIChEdXNhbikgPGRtdWRyaWNAYXZheWEuY29t PjsgZHJhZnQtcGFsZXQtdjZvcHMtcmZjNjE3Ny1iaXNAaWV0Zi5vcmc7IElQdjYgT3BlcmF0aW9u cyA8djZvcHNAaWV0Zi5vcmc+OyBKT1JESSBQQUxFVCBNQVJUSU5FWiA8am9yZGkucGFsZXQ9NDBj b25zdWxpbnRlbC5lc0BkbWFyYy5pZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdjZvcHNdIEktRCBB Y3Rpb246IGRyYWZ0LXBhbGV0LXY2b3BzLXJmYzYxNzctYmlzLTAwLnR4dA0KDQoNCk9uIFR1ZSwg QXVnIDI4LCAyMDE4IGF0IDU6MzIgUE0sIEZyZWQgQmFrZXIgPGZyZWRiYWtlci5pZXRmQGdtYWls LmNvbTxtYWlsdG86ZnJlZGJha2VyLmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQoNCg0KT24gQXVn IDI4LCAyMDE4LCBhdCA4OjA2IEFNLCBNdWRyaWMsIER1c2FuIChEdXNhbikgPGRtdWRyaWNAYXZh eWEuY29tPG1haWx0bzpkbXVkcmljQGF2YXlhLmNvbT4+IHdyb3RlOg0KPiBUaGVyZSBtdXN0IGEg d2F5IHRvIGRlZmluZSBob3cgcHJlZml4ZXMgYXJlIGFzc2lnbmVkIHRvIGFsd2F5cyBhbGxvdyAv NDgsIGlmIG5lZWRlZC4gSWYgbm90IGluIHJmYzYxNzctYmlzIHRoYW4gaW4gYW5vdGhlciBSRkMu IFdlIGhhdmUgYWxyZWFkeSBvbmUgbGltaXRhdGlvbiBmb3IgU0xBQUMgdGhhdCBtYWtlcyBzdXJl IGV2ZXJ5IGhvbWUgZ2V0cyBhdCBsZWFzdCBvbmUgLzY0LiBXZSBjYW4gYWRkIGFub3RoZXIgb25l LCBpbiBhbm90aGVyIFJGQywgdG8gbWFrZSBzdXJlIC80OCBpcyBnaXZlbiBvbiBhIGRlbWFuZC4g VGhhdCB3aWxsIGluc3VyZSBmdXR1cmUgZmxleGliaWxpdHkgaW4gYW55IG5ldHdvcmsgYW5kIG1h a2UgdGhlIHByZWZpeCBhc3NpZ25tZW50IG5vbi1wb2xpdGljYWwgcHJvY2Vzcy4NCg0KTXkgdW5k ZXJzdGFuZGluZywgbm8gaGF0cyBhbmQgcG90ZW50aWFsbHkgaW5jb3JyZWN0LCBpcyB0aGF0IGFu eSBJU1AgSSBrbm93IG9mIHdpbGwgcmVzcG9uZCB0byBhIERIQ1B2NiBJQV9QRCB3aXRoIGEgcHJl Zml4IGF0IGxlYXN0IGFzIGxhcmdlIGFzIHJlcXVlc3RlZCwgdXAgdG8gLzQ4Lg0KDQpGcmVkLCB0 aGUgc3RhdGVtZW50IHlvdSBhcmUgbWFraW5nIEkgYmVsaWV2ZSBpcyB0cnVlIGZvciBtYW55IG9y IG1vc3QgSVNQJ3MgcHJvdmlkaW5nIElQdjYgdG9kYXksIGJ1dCBub3QgYWxsLiBIb3dldmVyLCB3 YXkgdG9vIG1hbnkgSVNQcyBhcmUgc3RpbGwgbm90IHlldCBwcm92aWRpbmcgSVB2Ni4gRnVydGhl ciwgbWFueSBvZiB0aGUgZWFybHkgSVB2NiBjYXBhYmxlIENQRSBvciB0ZXJtaW5hbCBkZXZpY2Vz IG9ubHkgYXNrIGZvciBhIC82NCBhbmQgY2FuJ3QgYmUgdG9sZCBvdGhlcndpc2UuIFNvIHdoZW4g SSBsb29rIGF0IHRoZSBjdXJyZW50IHN0YXRlIG9mIHRoaW5ncywgSSdtIGJvdGggb3B0aW1pc3Rp YyBhbmQgcGVzc2ltaXN0aWMgYXQgdGhlIHNhbWUgdGltZS4NCkR1c2FuLCBpdCdzIG5vdCBhcyBz aW1wbGUgYXMgdGhlIElTUCBhcmUgbm90IHByb3ZpZGluZyAvNDhzLCBhcyBGcmVkIHNheXMgbWFu eSwgaWYgbm90IG1vc3QsIGRvaW5nIElQdjYgYXJlLCBhIGJpZyBwYXJ0IG9mIHRoZSBpc3N1ZSBp cyB0b28gbWFueSBDUEVzIG9ubHkgYXNrIGZvciBhIC82NCwgYW5kIGRvbid0IGFsbG93IGEgZGlm ZmVyZW50IG9wdGlvbi4gQnV0IGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIGEgbm9ybWFsIGVuZC11 c2VyIHRoZXkgYXJlIGJlaW5nIGxpbWl0ZWQsIGFuZCB3aG8gaXMgYXQgZmF1bHQgaXMgY29tcGxp Y2F0ZWQuICBUaGVyZSBpcyBwbGVudHkgb2YgYmxhbWUgdG8gZ28gYXJvdW5kIGZvciBldmVyeW9u ZSwgdGhlIElTUHMsIHRoZSBDUEUgbWFudWZhY3R1cmVycywgdGhlIElFVEYsIGFuZCBldmVuIGEg bGl0dGxlIGZvciB0aGUgZW5kLXVzZXJzIHRoZW1zZWx2ZXMuDQoNClJGQzcwODQ7DQogICBXUEQt MjogIFRoZSBJUHY2IENFIHJvdXRlciBNQVkgaW5kaWNhdGUgYXMgYSBoaW50IHRvIHRoZSBkZWxl Z2F0aW5nDQogICAgICAgICAgIHJvdXRlciB0aGUgc2l6ZSBvZiB0aGUgcHJlZml4IGl0IHJlcXVp cmVzLiAgSWYgc28sIGl0IE1VU1QNCiAgICAgICAgICAgYXNrIGZvciBhIHByZWZpeCBsYXJnZSBl bm91Z2ggdG8gYXNzaWduIG9uZSAvNjQgZm9yIGVhY2ggb2YNCiAgICAgICAgICAgaXRzIGludGVy ZmFjZXMsIHJvdW5kZWQgdXAgdG8gdGhlIG5lYXJlc3QgbmliYmxlLCBhbmQgU0hPVUxEDQogICAg ICAgICAgIGJlIGNvbmZpZ3VyYWJsZSB0byBhc2sgZm9yIG1vcmUuDQoNCkkgdGhpbmsgYXQgbGVh c3QgcGFydCBvZiB0aGUgcHJvYmxlbSBpcyBhIGNvbW1vbiBvbmUsIHRvbyBtYW55IGluZXhwZW5z aXZlIENQRSBkbyBub3QgaW1wbGVtZW50IG9wdGlvbmFsIGZlYXR1cmVzLiBCZWNhdXNlIGJvdGgg SVNQJ3MgYW5kIGVuZC11c2VycyBoYXZlIGVjb25vbWljIGluY2VudGl2ZXMgdG8gdXNlIGluZXhw ZW5zaXZlIENQRSwgdGhpcyBjcmVhdGVzIGFuIGluY2VudGl2ZSBmb3IgQ1BFIG1hbnVmYWN0dXJl cnMgdG8gbWFrZSBpbmV4cGVuc2l2ZSBDUEUgZG8gbm90IGltcGxlbWVudCBvcHRpb25hbCBmZWF0 dXJlcy4gIEFyb3VuZCBhbmQgYXJvdW5kIHdlIGdvLg0KDQpJdCBpcyBhIGNvbXBsaWNhdGVkIHN5 c3RlbWljIGZhaWx1cmUgbW9kZSB3ZSBoYXZlIGdvaW5nIGhlcmUuDQoNCk1heWJlIHdlIG5lZWQg Ik1VU1QgYmUgY29uZmlndXJhYmxlIHRvIGFzayBmb3IgbW9yZS4iLCB3aGljaCBpcyB0aGUgSUVU RidzIGZhdWx0IQ0KDQpUaGFua3MuDQoNCg0KLS0NCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09DQpEYXZpZCBGYXJtZXIgICAgICAgICAgICAgICBFbWFpbDpm YXJtZXJAdW1uLmVkdTxtYWlsdG86RW1haWwlM0FmYXJtZXJAdW1uLmVkdT4NCk5ldHdvcmtpbmcg JiBUZWxlY29tbXVuaWNhdGlvbiBTZXJ2aWNlcw0KT2ZmaWNlIG9mIEluZm9ybWF0aW9uIFRlY2hu b2xvZ3kNClVuaXZlcnNpdHkgb2YgTWlubmVzb3RhDQoyMjE4IFVuaXZlcnNpdHkgQXZlIFNFICAg ICAgICBQaG9uZTogNjEyLTYyNi0wODE1DQpNaW5uZWFwb2xpcywgTU4gNTU0MTQtMzAyOSAgIENl bGw6IDYxMi04MTItOTk1Mg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0NCg== --_000_9142206A0C5BF24CB22755C8EC422E459CB45F34AZUS1EXMB03glob_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IlByb2dJZCIg Y29udGVudD0iV29yZC5Eb2N1bWVudCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDE1Ij4NCjxtZXRhIG5hbWU9Ik9yaWdpbmF0b3IiIGNvbnRlbnQ9Ik1p Y3Jvc29mdCBXb3JkIDE1Ij4NCjxsaW5rIHJlbD0iRmlsZS1MaXN0IiBocmVmPSJjaWQ6ZmlsZWxp c3QueG1sQDAxRDQzRjg3LkFEOEU1QzcwIj48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOk9m ZmljZURvY3VtZW50U2V0dGluZ3M+DQo8bzpBbGxvd1BORy8+DQo8L286T2ZmaWNlRG9jdW1lbnRT ZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPHc6 V29yZERvY3VtZW50Pg0KPHc6U3BlbGxpbmdTdGF0ZT5DbGVhbjwvdzpTcGVsbGluZ1N0YXRlPg0K PHc6RG9jdW1lbnRLaW5kPkRvY3VtZW50RW1haWw8L3c6RG9jdW1lbnRLaW5kPg0KPHc6VHJhY2tN b3Zlcy8+DQo8dzpUcmFja0Zvcm1hdHRpbmcvPg0KPHc6RW52ZWxvcGVWaXMvPg0KPHc6VmFsaWRh dGVBZ2FpbnN0U2NoZW1hcy8+DQo8dzpTYXZlSWZYTUxJbnZhbGlkPmZhbHNlPC93OlNhdmVJZlhN TEludmFsaWQ+DQo8dzpJZ25vcmVNaXhlZENvbnRlbnQ+ZmFsc2U8L3c6SWdub3JlTWl4ZWRDb250 ZW50Pg0KPHc6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4dD5mYWxzZTwvdzpBbHdheXNTaG93UGxh Y2Vob2xkZXJUZXh0Pg0KPHc6RG9Ob3RQcm9tb3RlUUYvPg0KPHc6TGlkVGhlbWVPdGhlcj5FTi1V UzwvdzpMaWRUaGVtZU90aGVyPg0KPHc6TGlkVGhlbWVBc2lhbj5YLU5PTkU8L3c6TGlkVGhlbWVB c2lhbj4NCjx3OkxpZFRoZW1lQ29tcGxleFNjcmlwdD5YLU5PTkU8L3c6TGlkVGhlbWVDb21wbGV4 U2NyaXB0Pg0KPHc6Q29tcGF0aWJpbGl0eT4NCjx3OkRvTm90RXhwYW5kU2hpZnRSZXR1cm4vPg0K PHc6QnJlYWtXcmFwcGVkVGFibGVzLz4NCjx3OlNwbGl0UGdCcmVha0FuZFBhcmFNYXJrLz4NCjx3 OkVuYWJsZU9wZW5UeXBlS2VybmluZy8+DQo8L3c6Q29tcGF0aWJpbGl0eT4NCjx3OkJyb3dzZXJM ZXZlbD5NaWNyb3NvZnRJbnRlcm5ldEV4cGxvcmVyNDwvdzpCcm93c2VyTGV2ZWw+DQo8bTptYXRo UHI+DQo8bTptYXRoRm9udCBtOnZhbD0iQ2FtYnJpYSBNYXRoIi8+DQo8bTpicmtCaW4gbTp2YWw9 ImJlZm9yZSIvPg0KPG06YnJrQmluU3ViIG06dmFsPSImIzQ1Oy0iLz4NCjxtOnNtYWxsRnJhYyBt OnZhbD0ib2ZmIi8+DQo8bTpkaXNwRGVmLz4NCjxtOmxNYXJnaW4gbTp2YWw9IjAiLz4NCjxtOnJN YXJnaW4gbTp2YWw9IjAiLz4NCjxtOmRlZkpjIG06dmFsPSJjZW50ZXJHcm91cCIvPg0KPG06d3Jh cEluZGVudCBtOnZhbD0iMTQ0MCIvPg0KPG06aW50TGltIG06dmFsPSJzdWJTdXAiLz4NCjxtOm5h cnlMaW0gbTp2YWw9InVuZE92ciIvPg0KPC9tOm1hdGhQcj48L3c6V29yZERvY3VtZW50Pg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8dzpMYXRlbnRTdHlsZXMg RGVmTG9ja2VkU3RhdGU9ImZhbHNlIiBEZWZVbmhpZGVXaGVuVXNlZD0iZmFsc2UiIERlZlNlbWlI aWRkZW49ImZhbHNlIiBEZWZRRm9ybWF0PSJmYWxzZSIgRGVmUHJpb3JpdHk9Ijk5IiBMYXRlbnRT dHlsZUNvdW50PSIzNzUiPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSIwIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJOb3JtYWwiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAxIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5n IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9Imhl YWRpbmcgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFt ZT0iaGVhZGluZyA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVl IiBOYW1lPSJoZWFkaW5nIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9 InRydWUiIE5hbWU9ImhlYWRpbmcgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZv cm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA3Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgOSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJpbmRleCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgTmFtZT0iaW5kZXggMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCA0Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXgg NiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCA3Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 ImluZGV4IDgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggOSIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0idG9jIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2Mg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyA0Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJ0b2MgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 InRvYyA3Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDgiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgOSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJOb3JtYWwgSW5kZW50Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImZvb3Rub3RlIHRleHQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iYW5ub3RhdGlvbiB0ZXh0Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IE5hbWU9ImhlYWRlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJmb290ZXIiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSIgTmFtZT0iaW5kZXggaGVhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSIzNSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi IFFGb3JtYXQ9InRydWUiIE5hbWU9ImNhcHRpb24iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idGFi bGUgb2YgZmlndXJlcyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJlbnZlbG9wZSBhZGRyZXNzIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9ImVudmVsb3BlIHJldHVybiIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJmb290bm90ZSByZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iYW5ub3RhdGlv biByZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0ibGluZSBudW1iZXIiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0icGFnZSBudW1iZXIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iZW5kbm90 ZSByZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iZW5kbm90ZSB0ZXh0Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9InRhYmxlIG9mIGF1dGhvcml0aWVzIi8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9Im1hY3JvIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYSBoZWFkaW5nIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9Ikxpc3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBCdWxsZXQiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBOdW1iZXIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i TGlzdCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgMyIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJMaXN0IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCA1Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9Ikxpc3QgQnVsbGV0IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBCdWxs ZXQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IEJ1bGxldCA0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9Ikxpc3QgQnVsbGV0IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBOdW1i ZXIgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IE51bWJlciAzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9Ikxpc3QgTnVtYmVyIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBOdW1i ZXIgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxMCIgUUZv cm1hdD0idHJ1ZSIgTmFtZT0iVGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQ2xvc2luZyIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJTaWduYXR1cmUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iMSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9IkRlZmF1bHQgUGFyYWdyYXBoIEZvbnQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt ZT0iQm9keSBUZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJvZHkgVGV4dCBJbmRlbnQiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBDb250aW51ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJMaXN0IENvbnRpbnVlIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCBDb250aW51ZSAz Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgQ29udGludWUgNCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJMaXN0IENvbnRpbnVlIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTWVzc2FnZSBI ZWFkZXIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMTEiIFFG b3JtYXQ9InRydWUiIE5hbWU9IlN1YnRpdGxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlNhbHV0 YXRpb24iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iRGF0ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJCb2R5IFRleHQgRmlyc3QgSW5kZW50Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJvZHkgVGV4 dCBGaXJzdCBJbmRlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJOb3RlIEhlYWRpbmciLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i Qm9keSBUZXh0IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IEluZGVudCAyIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9IkJvZHkgVGV4dCBJbmRlbnQgMyIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJCbG9jayBUZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikh5cGVybGluayIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJGb2xsb3dlZEh5cGVybGluayIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMiIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3Ryb25n Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIwIiBRRm9ybWF0 PSJ0cnVlIiBOYW1lPSJFbXBoYXNpcyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJEb2N1bWVudCBN YXAiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iUGxhaW4gVGV4dCIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJFLW1haWwgU2lnbmF0dXJlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgVG9wIG9m IEZvcm0iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBCb3R0b20gb2YgRm9ybSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIiBOYW1lPSJOb3JtYWwgKFdlYikiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRN TCBBY3JvbnltIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgQWRkcmVzcyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJIVE1MIENpdGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBDb2Rl Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgRGVmaW5pdGlvbiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJIVE1MIEtleWJvYXJkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgUHJlZm9y bWF0dGVkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgU2FtcGxlIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9IkhUTUwgVHlwZXdyaXRlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIFZh cmlhYmxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik5vcm1hbCBUYWJsZSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJhbm5vdGF0aW9uIHN1YmplY3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTm8g TGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJPdXRsaW5lIExpc3QgMSIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBOYW1lPSJPdXRsaW5lIExpc3QgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJPdXRsaW5l IExpc3QgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBTaW1wbGUgMSIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIiBOYW1lPSJUYWJsZSBTaW1wbGUgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJs ZSBTaW1wbGUgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDbGFzc2ljIDEiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu VXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ2xhc3NpYyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 IlRhYmxlIENsYXNzaWMgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDbGFzc2ljIDQi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sb3JmdWwgMSIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJUYWJsZSBDb2xvcmZ1bCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENv bG9yZnVsIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sdW1ucyAxIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9IlRhYmxlIENvbHVtbnMgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJU YWJsZSBDb2x1bW5zIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sdW1ucyA0Ii8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENvbHVtbnMgNSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO YW1lPSJUYWJsZSBHcmlkIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3JpZCAyIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdyaWQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l PSJUYWJsZSBHcmlkIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3JpZCA1Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdyaWQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJU YWJsZSBHcmlkIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgR3JpZCA4Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3QgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJs ZSBMaXN0IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCAzIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9IlRhYmxlIExpc3QgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBM aXN0IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgTGlzdCA2Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9IlRhYmxlIExpc3QgNyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBMaXN0 IDgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgM0QgZWZmZWN0cyAxIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiIE5hbWU9IlRhYmxlIDNEIGVmZmVjdHMgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJU YWJsZSAzRCBlZmZlY3RzIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29udGVtcG9y YXJ5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEVsZWdhbnQiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgTmFtZT0iVGFibGUgUHJvZmVzc2lvbmFsIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxl IFN1YnRsZSAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFN1YnRsZSAyIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIE5hbWU9IlRhYmxlIFdlYiAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxl IFdlYiAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1 ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFdlYiAzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiIE5hbWU9IkJhbGxvb24gVGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI1OSIgTmFtZT0iVGFibGUgR3JpZCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJU YWJsZSBUaGVtZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIE5hbWU9IlBsYWNlaG9sZGVyIFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTm8gU3BhY2luZyIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQg U2hhZGluZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIg TmFtZT0iTGlnaHQgTGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVk aXVtIExpc3QgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 NiIgTmFtZT0iTWVkaXVtIExpc3QgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0i RGFyayBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcx IiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFk aW5nIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjYxIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAxIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hh ZGluZyAxIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2Vu dCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg TmFtZT0iUmV2aXNpb24iLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iMzQiIFFGb3JtYXQ9InRydWUiIE5hbWU9Ikxpc3QgUGFyYWdyYXBoIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJR dW90ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMCIgUUZv cm1hdD0idHJ1ZSIgTmFtZT0iSW50ZW5zZSBRdW90ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgMSIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVt IEdyaWQgMSBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQg MSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0i RGFyayBMaXN0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFj Y2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBO YW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCAyIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBOYW1lPSJMaWdodCBMaXN0 IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYy IiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCAyIi8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0g U2hhZGluZyAyIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2Vu dCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1l PSJNZWRpdW0gR3JpZCAxIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCAyIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAz IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcw IiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDIiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9yZnVs IExpc3QgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDMi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5hbWU9Ikxp Z2h0IExpc3QgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50 IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9 Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDMiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0 IDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDMiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1 bSBHcmlkIDMgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQg MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFtZT0i Q29sb3JmdWwgTGlzdCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgMyIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQgU2hhZGluZyBB Y2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIg TmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNCIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcg MSBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgNCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0iTWVk aXVtIExpc3QgMiBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2Nl bnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFt ZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5n IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcy IiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA0Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBT aGFkaW5nIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjYxIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA1Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0g U2hhZGluZyAxIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFj Y2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBO YW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA1Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3Jp ZCAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDUiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVs IFNoYWRpbmcgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50 IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9 IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50 IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9 Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDYiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBM aXN0IDEgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDYi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1l ZGl1bSBHcmlkIDIgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQg NiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0i Q29sb3JmdWwgU2hhZGluZyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNiIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3Jp ZCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIx OSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iU3VidGxlIEVtcGhhc2lzIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIxIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJbnRl bnNlIEVtcGhhc2lzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjMxIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdWJ0bGUgUmVmZXJlbmNlIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMyIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJJ bnRlbnNlIFJlZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSIzMyIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iQm9vayBUaXRsZSIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNyIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9IkJpYmxpb2dyYXBoeSIvPg0KPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlRPQyBIZWFkaW5nIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQxIiBOYW1lPSJQbGFpbiBUYWJsZSAxIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQyIiBOYW1lPSJQbGFp biBUYWJsZSAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQz IiBOYW1lPSJQbGFpbiBUYWJsZSAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjQ0IiBOYW1lPSJQbGFpbiBUYWJsZSA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ1IiBOYW1lPSJQbGFpbiBUYWJsZSA1Ii8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQwIiBOYW1lPSJHcmlkIFRhYmxlIExp Z2h0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1l PSJHcmlkIFRhYmxlIDEgTGlnaHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIi8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRhYmxlIDQiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9IkdyaWQg VGFibGUgNSBEYXJrIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjUxIiBOYW1lPSJHcmlkIFRhYmxlIDYgQ29sb3JmdWwiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3JpZCBU YWJsZSAxIExpZ2h0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2Nl bnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFt ZT0iR3JpZCBUYWJsZSA0IEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgMSIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJs ZSA2IENvbG9yZnVsIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDEiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQgVGFi bGUgMSBMaWdodCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50 IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9 IkdyaWQgVGFibGUgNCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDIiLz4NCjx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUg NiBDb2xvcmZ1bCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAyIi8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlkIFRhYmxl IDEgTGlnaHQgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2VudCAz Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJH cmlkIFRhYmxlIDQgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCAzIi8+DQo8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxlIDYg Q29sb3JmdWwgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMyIvPg0KPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3JpZCBUYWJsZSAx IExpZ2h0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2NlbnQgNCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iR3Jp ZCBUYWJsZSA0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjUwIiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgNCIvPg0KPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJsZSA2IENv bG9yZnVsIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjUyIiBOYW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDQiLz4NCjx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQgVGFibGUgMSBM aWdodCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50IDUiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9IkdyaWQg VGFibGUgNCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xv cmZ1bCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlkIFRhYmxlIDEgTGln aHQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NDciIE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2VudCA2Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRh YmxlIDQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxlIDYgQ29sb3Jm dWwgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NTIiIE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0 Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJM aXN0IFRhYmxlIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NDgiIE5hbWU9Ikxpc3QgVGFibGUgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJMaXN0IFRhYmxlIDUgRGFyayIvPg0KPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJs ZSA2IENvbG9yZnVsIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjUyIiBOYW1lPSJMaXN0IFRhYmxlIDcgQ29sb3JmdWwiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2NlbnQg MSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0i TGlzdCBUYWJsZSAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBBY2Nl bnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFt ZT0iTGlzdCBUYWJsZSA1IERhcmsgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQg MSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0i TGlzdCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50IDIi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxp c3QgVGFibGUgMiBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50 IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9 Ikxpc3QgVGFibGUgNSBEYXJrIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDIi Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxp c3QgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCAzIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJMaXN0 IFRhYmxlIDIgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2VudCAz Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJM aXN0IFRhYmxlIDUgRGFyayBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCAzIi8+ DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJMaXN0 IFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2NlbnQgNCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iTGlzdCBU YWJsZSAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjQ4IiBOYW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBBY2NlbnQgNCIv Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iTGlz dCBUYWJsZSA1IERhcmsgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNTEiIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgNCIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iTGlzdCBU YWJsZSA3IENvbG9yZnVsIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50IDUiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3QgVGFi bGUgMiBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50IDUiLz4N Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxpc3Qg VGFibGUgNSBEYXJrIEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDUiLz4NCjx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxpc3QgVGFi bGUgNyBDb2xvcmZ1bCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCA2Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJMaXN0IFRhYmxl IDIgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2VudCA2Ii8+DQo8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJMaXN0IFRh YmxlIDUgRGFyayBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCA2Ii8+DQo8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJMaXN0IFRhYmxl IDcgQ29sb3JmdWwgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTWVudGlvbiIvPg0K PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJTbWFydCBIeXBlcmxpbmsiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt ZT0iSGFzaHRhZyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJVbnJlc29sdmVkIE1lbnRpb24iLz4N CjwvdzpMYXRlbnRTdHlsZXM+DQo8L3htbD48IVtlbmRpZl0tLT48c3R5bGU+PCEtLQ0KLyogRm9u dCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRo IjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MDsN Cgltc28tZ2VuZXJpYy1mb250LWZhbWlseTpyb21hbjsNCgltc28tZm9udC1waXRjaDp2YXJpYWJs ZTsNCgltc28tZm9udC1zaWduYXR1cmU6LTUzNjg3MDE0NSAxMTA3MzA1NzI3IDAgMCA0MTUgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7DQoJbXNvLWZvbnQtYWx0OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1mb250 LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTpzd2lzczsNCgltc28tZm9udC1w aXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6LTUzNjg1OTkwNSAtMTA3MzczMjQ4 NSA5IDAgNTExIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bXNvLXN0eWxlLXVuaGlkZTpubzsNCgltc28tc3R5 bGUtcWZvcm1hdDp5ZXM7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsNCgltYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28t ZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVuZGVybGluZTpzaW5n bGU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1u b3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgl0ZXh0LXVuZGVybGluZTpzaW5nbGU7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLXN0eWxlLXVuaGlkZTpubzsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBpbjsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFz dC1mb250LWZhbWlseTpDYWxpYnJpO30NCnNwYW4uZ21haWwtZ3INCgl7bXNvLXN0eWxlLW5hbWU6 Z21haWwtZ3JfOw0KCW1zby1zdHlsZS11bmhpZGU6bm87fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJ bXNvLXN0eWxlLXVuaGlkZTpubzsNCgltc28tYW5zaS1mb250LXNpemU6MTEuMHB0Ow0KCW1zby1i aWRpLWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJbXNvLWFzY2lpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6Q2FsaWJyaTsNCgltc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1m b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u U3BlbGxFDQoJe21zby1zdHlsZS1uYW1lOiIiOw0KCW1zby1zcGwtZTp5ZXM7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLWRlZmF1bHQtcHJvcHM6 eWVzOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1hc2NpaS1mb250 LWZhbWlseTpDYWxpYnJpOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNv LWhhbnNpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjsNCgltc28taGVhZGVyLW1hcmdpbjouNWlu Ow0KCW1zby1mb290ZXItbWFyZ2luOi41aW47DQoJbXNvLXBhcGVyLXNvdXJjZTowO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gMTBdPjxzdHlsZT4vKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KdGFibGUuTXNvTm9ybWFs VGFibGUNCgl7bXNvLXN0eWxlLW5hbWU6IlRhYmxlIE5vcm1hbCI7DQoJbXNvLXRzdHlsZS1yb3di YW5kLXNpemU6MDsNCgltc28tdHN0eWxlLWNvbGJhbmQtc2l6ZTowOw0KCW1zby1zdHlsZS1ub3No b3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtcGFyZW50OiIiOw0K CW1zby1wYWRkaW5nLWFsdDowaW4gNS40cHQgMGluIDUuNHB0Ow0KCW1zby1wYXJhLW1hcmdpbjow aW47DQoJbXNvLXBhcmEtbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndp ZG93LW9ycGhhbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCW1zby1hc2NpaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1oYW5zaS1m b250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIiBzdHlsZT0idGFiLWludGVydmFsOi41aW4iPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYXNj aWktZm9udC1mYW1pbHk6Q2FsaWJyaTttc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTttc28t YmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPkhpIERhdmlkLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tYXNjaWktZm9udC1mYW1pbHk6Q2FsaWJyaTttc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJy aTttc28tYmlkaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij4mZ3Q7UkZDNzA4NDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jmd0OyZu YnNwOyAmbmJzcDtXUEQtMjombmJzcDsgVGhlIElQdjYgQ0Ugcm91dGVyIE1BWSBpbmRpY2F0ZSBh cyBhIGhpbnQgdG8gdGhlIGRlbGVnYXRpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cm91dGVyIHRoZSBzaXplIG9mIHRoZSBw cmVmaXggaXQgcmVxdWlyZXMuJm5ic3A7IElmIHNvLCBpdCBNVVNUPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi PiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2FzayBmb3IgYSBw cmVmaXggbGFyZ2UgZW5vdWdoIHRvIGFzc2lnbiBvbmUgLzY0IGZvciBlYWNoIG9mPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2l0 cyZuYnNwOzxzcGFuIGNsYXNzPSJnbWFpbC1nciI+aW50ZXJmYWNlcyw8L3NwYW4+Jm5ic3A7cm91 bmRlZCB1cCB0byB0aGUgbmVhcmVzdCBuaWJibGUsIGFuZCBTSE9VTEQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YmUgY29uZmln dXJhYmxlIHRvIGFzayBmb3IgbW9yZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mZ3Q7TWF5YmUgd2UgbmVlZCAmcXVvdDtNVVNUIGJlIGNvbmZpZ3VyYWJsZSB0 byBhc2sgZm9yIG1vcmUuJnF1b3Q7LCB3aGljaCBpcyB0aGUgSUVURidzIGZhdWx0ITxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1hc2NpaS1mb250 LWZhbWlseTpDYWxpYnJpO21zby1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpO21zby1iaWRpLWZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1hc2NpaS1m b250LWZhbWlseTpDYWxpYnJpO21zby1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpO21zby1iaWRp LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+SSBiZWxpZXZlIHRoaXMg dGhlIHJpZ2h0IGFwcHJvYWNoLiBXZSBjYW5ub3QgaGF2ZSBJUHY2IG5ldHdvcmsgd2hlcmUgZGV2 aWNlIGFuZCBhcHBsaWNhdGlvbiB2ZW5kb3JzIG5lZWQgZmlyc3QgdG8gZ28gYXJvdW5kDQogdGhl IHdvcmxkIGFuZCBuZWdvdGlhdGUgd2l0aCBhbGwgSVNQcyB0byBwcm92aWRlIC80OCwgYmVmb3Jl IHRoZXkgc3RhcnQgYnVpbGRpbmcgbmV3IHByb2R1Y3RzIHRoYXQgcmVxdWlyZSAvNDguIFRoZSBu ZXR3b3JrIE1VU1QgYmUgZmxleGlibGUsIGJ5IGRlZmF1bHQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1hc2NpaS1mb250LWZhbWls eTpDYWxpYnJpO21zby1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpO21zby1iaWRpLWZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1hc2NpaS1mb250LWZh bWlseTpDYWxpYnJpO21zby1oYW5zaS1mb250LWZhbWlseTpDYWxpYnJpO21zby1iaWRpLWZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+VGhhbmtzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYXNjaWktZm9u dC1mYW1pbHk6Q2FsaWJyaTttc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTttc28tYmlkaS1m b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPkR1c2FuLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tYXNjaWkt Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28taGFuc2ktZm9udC1mYW1pbHk6Q2FsaWJyaTttc28tYmlk aS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9Im1z by1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiBEYXZpZCBGYXJtZXIgJmx0O2Zhcm1lckB1bW4uZWR1Jmd0Ow0K PGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEF1Z3VzdCAyOCwgMjAxOCA4OjA0IFBNPGJyPg0K PGI+VG86PC9iPiBGcmVkIEJha2VyICZsdDtmcmVkYmFrZXIuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiBNdWRyaWMsIER1c2FuIChEdXNhbikgJmx0O2RtdWRyaWNAYXZheWEuY29t Jmd0OzsgZHJhZnQtcGFsZXQtdjZvcHMtcmZjNjE3Ny1iaXNAaWV0Zi5vcmc7IElQdjYgT3BlcmF0 aW9ucyAmbHQ7djZvcHNAaWV0Zi5vcmcmZ3Q7OyBKT1JESSBQQUxFVCBNQVJUSU5FWiAmbHQ7am9y ZGkucGFsZXQ9NDBjb25zdWxpbnRlbC5lc0BkbWFyYy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFt2Nm9wc10gSS1EIEFjdGlvbjogZHJhZnQtcGFsZXQtdjZvcHMtcmZjNjE3 Ny1iaXMtMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBUdWUsIEF1ZyAyOCwgMjAxOCBhdCA1OjMyIFBNLCBGcmVkIEJha2VyICZsdDs8YSBo cmVmPSJtYWlsdG86ZnJlZGJha2VyLmlldGZAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZnJl ZGJha2VyLmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDttc28tYm9yZGVyLWxlZnQtYWx0OnNvbGlkICNDQ0NDQ0MgLjc1cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCk9uIEF1ZyAyOCwgMjAxOCwgYXQgODowNiBBTSwgTXVk cmljLCBEdXNhbiAoRHVzYW4pICZsdDs8YSBocmVmPSJtYWlsdG86ZG11ZHJpY0BhdmF5YS5jb20i PmRtdWRyaWNAYXZheWEuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyBUaGVyZSBtdXN0IGEg d2F5IHRvIGRlZmluZSBob3cgcHJlZml4ZXMgYXJlIGFzc2lnbmVkIHRvIGFsd2F5cyBhbGxvdyAv NDgsIGlmIG5lZWRlZC4gSWYgbm90IGluIHJmYzYxNzctYmlzIHRoYW4gaW4gYW5vdGhlciBSRkMu IFdlIGhhdmUgYWxyZWFkeSBvbmUgbGltaXRhdGlvbiBmb3IgU0xBQUMgdGhhdCBtYWtlcyBzdXJl IGV2ZXJ5IGhvbWUgZ2V0cyBhdCBsZWFzdCBvbmUgLzY0LiBXZSBjYW4gYWRkIGFub3RoZXIgb25l LCBpbiBhbm90aGVyIFJGQywNCiB0byBtYWtlIHN1cmUgLzQ4IGlzIGdpdmVuIG9uIGEgZGVtYW5k LiBUaGF0IHdpbGwgaW5zdXJlIGZ1dHVyZSBmbGV4aWJpbGl0eSBpbiBhbnkgbmV0d29yayBhbmQg bWFrZSB0aGUgcHJlZml4IGFzc2lnbm1lbnQgbm9uLXBvbGl0aWNhbCBwcm9jZXNzLjxicj4NCjxi cj4NCk15IHVuZGVyc3RhbmRpbmcsIG5vIGhhdHMgYW5kIHBvdGVudGlhbGx5IGluY29ycmVjdCwg aXMgdGhhdCBhbnkgSVNQIEkga25vdyBvZiB3aWxsIHJlc3BvbmQgdG8gYSBESENQdjYgSUFfUEQg d2l0aCBhIHByZWZpeCBhdCBsZWFzdCBhcyBsYXJnZSBhcyByZXF1ZXN0ZWQsIHVwIHRvIC80OC48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPkZy ZWQsIHRoZSBzdGF0ZW1lbnQgeW91IGFyZSBtYWtpbmcgSSBiZWxpZXZlIGlzIHRydWUgZm9yIG1h bnkgb3IgbW9zdCBJU1AncyBwcm92aWRpbmcgSVB2NiB0b2RheSwgYnV0IG5vdCBhbGwuIEhvd2V2 ZXIsIHdheSB0b28gbWFueSBJU1BzIGFyZQ0KIHN0aWxsIG5vdCB5ZXQgcHJvdmlkaW5nIElQdjYu IEZ1cnRoZXIsJm5ic3A7bWFueSBvZiB0aGUgZWFybHkgSVB2NiBjYXBhYmxlIENQRSBvciB0ZXJt aW5hbCBkZXZpY2VzIG9ubHkgYXNrIGZvciBhIC82NCBhbmQgY2FuJ3QgYmUgdG9sZCBvdGhlcndp c2UuIFNvIHdoZW4gSSBsb29rIGF0IHRoZSBjdXJyZW50IHN0YXRlIG9mIHRoaW5ncywgSSdtIGJv dGggb3B0aW1pc3RpYyBhbmQgcGVzc2ltaXN0aWMgYXQgdGhlIHNhbWUgdGltZS48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+RHVzYW4sJm5ic3A7aXQncyBub3QgYXMgc2lt cGxlIGFzIHRoZSBJU1AgYXJlIG5vdCBwcm92aWRpbmcgLzQ4cywgYXMgRnJlZCBzYXlzIG1hbnks IGlmIG5vdCBtb3N0LCBkb2luZyBJUHY2IGFyZSwgYSBiaWcgcGFydCBvZiB0aGUgaXNzdWUgaXMg dG9vIG1hbnkgQ1BFcyBvbmx5IGFzayBmb3IgYSAvNjQsIGFuZCBkb24ndA0KIGFsbG93IGEgZGlm ZmVyZW50IG9wdGlvbi4gQnV0IGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIGEgbm9ybWFsIGVuZC11 c2VyIHRoZXkgYXJlIGJlaW5nIGxpbWl0ZWQsIGFuZCB3aG8gaXMgYXQgZmF1bHQgaXMgY29tcGxp Y2F0ZWQuJm5ic3A7IFRoZXJlIGlzIHBsZW50eSBvZiBibGFtZSB0byBnbyBhcm91bmQgZm9yIGV2 ZXJ5b25lLCB0aGUgSVNQcywgdGhlIENQRSBtYW51ZmFjdHVyZXJzLCB0aGUgSUVURiwgYW5kIGV2 ZW4gYSBsaXR0bGUgZm9yIHRoZSBlbmQtdXNlcnMNCiB0aGVtc2VsdmVzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij5SRkM3MDg0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJz cDsgJm5ic3A7V1BELTI6Jm5ic3A7IFRoZSBJUHY2IENFIHJvdXRlciBNQVkgaW5kaWNhdGUgYXMg YSBoaW50IHRvIHRoZSBkZWxlZ2F0aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cm91dGVyIHRoZSBzaXpl IG9mIHRoZSBwcmVmaXggaXQgcmVxdWlyZXMuJm5ic3A7IElmIHNvLCBpdCBNVVNUPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7YXNrIGZvciBhIHByZWZpeCBsYXJnZSBlbm91Z2ggdG8gYXNzaWduIG9uZSAvNjQg Zm9yIGVhY2ggb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpdHMmbmJzcDs8c3BhbiBjbGFzcz0iZ21haWwt Z3IiPmludGVyZmFjZXMsPC9zcGFuPiZuYnNwO3JvdW5kZWQgdXAgdG8gdGhlIG5lYXJlc3Qgbmli YmxlLCBhbmQgU0hPVUxEPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YmUgY29uZmlndXJhYmxlIHRvIGFzayBm b3IgbW9yZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+SSB0aGluayBhdCBsZWFz dCBwYXJ0IG9mJm5ic3A7dGhlIHByb2JsZW0gaXMgYSBjb21tb24gb25lLCB0b28gbWFueSBpbmV4 cGVuc2l2ZSBDUEUgZG8gbm90IGltcGxlbWVudCBvcHRpb25hbCBmZWF0dXJlcy4gQmVjYXVzZSZu YnNwO2JvdGggSVNQJ3MgYW5kIGVuZC11c2VycyBoYXZlIGVjb25vbWljIGluY2VudGl2ZXMgdG8g dXNlIGluZXhwZW5zaXZlDQogQ1BFLCB0aGlzIGNyZWF0ZXMgYW4gaW5jZW50aXZlIGZvciBDUEUg bWFudWZhY3R1cmVycyZuYnNwO3RvIG1ha2UmbmJzcDtpbmV4cGVuc2l2ZSBDUEUgZG8gbm90IGlt cGxlbWVudCBvcHRpb25hbCBmZWF0dXJlcy4mbmJzcDsgQXJvdW5kIGFuZCBhcm91bmQgd2UgZ28u Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgaXMgYSBjb21wbGljYXRlZCBzeXN0ZW1p YyBmYWlsdXJlIG1vZGUgd2UgaGF2ZSBnb2luZyBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYXliZSB3ZSBuZWVkICZxdW90O01VU1Qg YmUgY29uZmlndXJhYmxlIHRvIGFzayBmb3IgbW9yZS4mcXVvdDssIHdoaWNoIGlzIHRoZSBJRVRG J3MgZmF1bHQhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYW5rcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj49 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCkRhdmlk IEZhcm1lciZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZu YnNwOyA8YSBocmVmPSJtYWlsdG86RW1haWwlM0FmYXJtZXJAdW1uLmVkdSIgdGFyZ2V0PSJfYmxh bmsiPg0KRW1haWw6ZmFybWVyQHVtbi5lZHU8L2E+PGJyPg0KTmV0d29ya2luZyAmYW1wOyBUZWxl Y29tbXVuaWNhdGlvbiBTZXJ2aWNlczxicj4NCk9mZmljZSBvZiBJbmZvcm1hdGlvbiBUZWNobm9s b2d5PGJyPg0KVW5pdmVyc2l0eSBvZiBNaW5uZXNvdGEmbmJzcDsmbmJzcDsgPGJyPg0KMjIxOCBV bml2ZXJzaXR5IEF2ZSBTRSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQaG9uZTogNjEyLTYy Ni0wODE1PGJyPg0KTWlubmVhcG9saXMsIE1OIDU1NDE0LTMwMjkmbmJzcDsmbmJzcDsgQ2VsbDog NjEyLTgxMi05OTUyPGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9142206A0C5BF24CB22755C8EC422E459CB45F34AZUS1EXMB03glob_-- From nobody Wed Aug 29 12:02:21 2018 Return-Path: <dmudric@avaya.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B864B130E07 for <v6ops@ietfa.amsl.com>; Wed, 29 Aug 2018 12:02:18 -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 e9Zw3DbCpxFb for <v6ops@ietfa.amsl.com>; Wed, 29 Aug 2018 12:02:16 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.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 8342D130E06 for <v6ops@ietf.org>; Wed, 29 Aug 2018 12:02:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EMAgCu7IZb/yYyC4dQChoBAQEBAQIBA?= =?us-ascii?q?QEBCAEBAQGCelVlbRIoCoNoiBGMKYINgz2Sa4E/OwsjCQKEPgIXgnUhNBgBAgE?= =?us-ascii?q?BAQEBAQICAmkcDIJoLwEBBAcDDC8JAgMBAQEBAQEBTwIPRwEBGAEBAQECARIRE?= =?us-ascii?q?ToQBwQCAQgNBAQBAQECAgYgAgICMBUICAIEARIIGoMAgXkIAQ6aXIlvgS4aAol?= =?us-ascii?q?gBYELiQUXgUI+gRJGgh4ugxsEGIEcLRWCajGCJgKbOQkChjGCeoZdiF0DhXGLI?= =?us-ascii?q?4g1gUE5gVJwFTuCaYYBilJvgRaKPwGBGwEB?= X-IPAS-Result: =?us-ascii?q?A2EMAgCu7IZb/yYyC4dQChoBAQEBAQIBAQEBCAEBAQGCelV?= =?us-ascii?q?lbRIoCoNoiBGMKYINgz2Sa4E/OwsjCQKEPgIXgnUhNBgBAgEBAQEBAQICAmkcD?= =?us-ascii?q?IJoLwEBBAcDDC8JAgMBAQEBAQEBTwIPRwEBGAEBAQECARIREToQBwQCAQgNBAQ?= =?us-ascii?q?BAQECAgYgAgICMBUICAIEARIIGoMAgXkIAQ6aXIlvgS4aAolgBYELiQUXgUI+g?= =?us-ascii?q?RJGgh4ugxsEGIEcLRWCajGCJgKbOQkChjGCeoZdiF0DhXGLI4g1gUE5gVJwFTu?= =?us-ascii?q?CaYYBilJvgRaKPwGBGwEB?= X-IronPort-AV: E=Sophos;i="5.53,304,1531800000"; d="scan'208";a="295663763" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 29 Aug 2018 15:02:15 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Aug 2018 15:02:14 -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; Wed, 29 Aug 2018 15:02:14 -0400 From: "Mudric, Dusan (Dusan)" <dmudric@avaya.com> To: Lee Howard <lee@asgard.org>, "v6ops@ietf.org" <v6ops@ietf.org> Thread-Topic: [v6ops] Thinking about problems in IPv6-only networks Thread-Index: AQHUNlUbwY2Dk8XmmUa2xka+HPWvRqTEhQ4AgAFeugCAAYKZgIACN7yAgAEN+4CACp1coA== Date: Wed, 29 Aug 2018 19:02:14 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E459CB46310@AZ-US1EXMB03.global.avaya.com> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> <CAD6AjGQ_OBFGJb_C+mP_87nu7q_oXPrTvxhaV_=RcubeHtMy2Q@mail.gmail.com> <E345387F-6C1D-49D4-8B03-52D04498DDA5@lists.zabbadoz.net> <a9eeba1b-76dc-a69f-aabe-04fa4ddc3a4f@gmail.com> <e560c82c-085e-60fe-2076-70e3624696c0@asgard.org> In-Reply-To: <e560c82c-085e-60fe-2076-70e3624696c0@asgard.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/xW1-GXmMxPRIxeoh8Ne_6De2AWQ> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 29 Aug 2018 19:02:19 -0000 PiBJIHdpbGwgYm9sZGx5IGFzc2VydCB0aGF0IHRoZXJlIGFyZSBubyBSRkNzIHJlcXVpcmluZyB1 cGRhdGVzIGluIG9yZGVyDQo+IHRvIGRlcGxveSBJUHY2LW9ubHkuDQoNCkkgc3VnZ2VzdCBib3Ro IERIQ1B2NiBhbmQgU0xBQUMgdG8gYmUgZW5hYmxlZCBieSBkZWZhdWx0LiBDdXJyZW50bHksIFJG QzQ4NjEgcmVjb21tZW5kcyB0byBkaXNhYmxlIERIQ1B2NiBieSBkZWZhdWx0Lg0KDQpSRkM0ODYy IGFscmVhZHkgbWFuZGF0ZXMgU0xBQUMgYnkgZGVmYXVsdC4gU2VjdGlvbiA1LjU6DQoJCQkJCQki dGhlIHByb2Nlc3NpbmcgZGVzY3JpYmVkIGJlbG93IE1VU1QgYmUNCgkJCQkJCWVuYWJsZWQgYnkg ZGVmYXVsdC4iDQpCdXQsIHRoaXMgc2hvdWxkIGJlIGNoYW5nZWQ6DQoJLSBSRkM0ODYxIHNlY3Rp b24gNi4yLjE6IEFkdk1hbmFnZWRGbGFnIGFuZCBBZHZPdGhlckNvbmZpZ0ZsYWc6IERlZmF1bHQ6 IEZBTFNFDQoJPT0+IENoYW5nZSAnTycgYml0IGRlZmF1bHQgdmFsdWUgdG8gVFJVRSAoQWR2T3Ro ZXJDb25maWdGbGFnOiBEZWZhdWx0OiBUUlVFKS4NCg0KIHRvIGFsbG93IGhvc3RzIHRvIGJlIGRl cGxveWVkIGFuZCBhdXRvbWF0aWNhbGx5IGNvbmZpZ3VyZWQgKGkuZS4gZ2V0IElQdjYgYWRkcmVz cyBhbmQgb3RoZXIgY29uZmlndXJhdGlvbiBhdXRvbWF0aWNhbGx5KSBpbiBhbnkgZW52aXJvbm1l bnQ6DQotIERIQ1B2NiBvbmx5IGVudmlyb25tZW50IChubyBjb25maWcgdmlhIFJBIGFuZCBTTEFB QyBjYW4gYmUgZGlzYWJsZWQpLCBvcg0KLSBTTEFBQyBvbmx5IGVudmlyb25tZW50IChubyBESENQ djYgY29uZmlnIGFuZCBESENQdjYgY2FuIGJlIGRpc2FibGVkKSwgb3INCi0gREhDUHY2IGFuZCBT TEFBQyBlbnZpcm9ubWVudC4NCnVzaW5nIHRoZSBkZWZhdWx0IHNldHRpbmdzLg0KDQpXaXRoIHRo ZSBjdXJyZW50IFJGQzQ4NjEgcmVjb21tZW5kYXRpb24gKEFkdk1hbmFnZWRGbGFnIGFuZCBBZHZP dGhlckNvbmZpZ0ZsYWc6IERlZmF1bHQ6IEZBTFNFKSwgaWYgREhDUHY2IGlzIGRpc2FibGVkIG9u IGhvc3RzIHRoYXQgYXJlIGRlcGxveWVkIGluIHRoZSBuZXR3b3JrIHdoaWNoIGNvbmZpZ3VyZXMg aG9zdHMgdXNpbmcgREhDUCAoREhDUHY2IG9ubHkgZW52aXJvbm1lbnQpLCB0aGUgaG9zdHMgd2ls bCBub3Qgd29yay4gQ2hhbmdpbmcgQWR2T3RoZXJDb25maWdGbGFnOiBEZWZhdWx0OiBUUlVFIHdp bGwgYWxsb3cgaG9zdHMgdG8gYXNzaWduIFNMTEFDIGFkZHJlc3NlcyBhbmQgb2J0YWluIHRoZSBh cHBsaWNhdGlvbiBjb25maWd1cmF0aW9uIHVzaW5nIHN0YXRlbGVzcyBESENQdjYuDQoNClJlZ2Fy ZHMsDQpEdXNhbi4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB2Nm9w cyA8djZvcHMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIExlZSBIb3dhcmQNCj4gU2Vu dDogVHVlc2RheSwgQXVndXN0IDIxLCAyMDE4IDEyOjIwIFBNDQo+IFRvOiB2Nm9wc0BpZXRmLm9y Zw0KPiBTdWJqZWN0OiBSZTogW3Y2b3BzXSBUaGlua2luZyBhYm91dCBwcm9ibGVtcyBpbiBJUHY2 LW9ubHkgbmV0d29ya3MNCj4gDQo+IA0KPiANCj4gT24gMDgvMjAvMjAxOCAwODoxNCBQTSwgQnJp YW4gRSBDYXJwZW50ZXIgd3JvdGU6DQo+ID4gV2VsbCwgZmlyc3Qgd2UgbmVlZCB0byBrbm93IG91 ciBvYmplY3RpdmUuIEkgc3VnZ2VzdCB0aGF0IG91cg0KPiA+IG9iamVjdGl2ZSBzaG91bGQgYmUg dG8gaWRlbnRpZnkgdGhpbmdzIHRoYXQgdGhlIElFVEYgc2hvdWxkDQo+ID4gZG8gdG8gYWxsZXZp YXRlIHRoZSBhbGxlZ2VkIHByb2JsZW1zLiBTaW5jZSB3aGF0IHdlIGNhbiBkbw0KPiA+IGlzIHdy aXRlIHN0YW5kYXJkcy10cmFjaywgQkNQIG9yIGluZm9ybWF0aW9uYWwgUkZDcywgdGhlIHJlYWwN Cj4gPiBxdWVzdGlvbiBpczogd2hpY2ggb2YgdGhlIGFsbGVnZWQgcHJvYmxlbXMgY291bGQgaW4g ZmFjdCBiZSBmaXhlZA0KPiA+IGJ5IG5ldyBSRkMgdGV4dD8NCj4gDQo+IFRoYXQgd2FzIGV4YWN0 bHkgdGhlIGNoYXJ0ZXIgb2Ygc3Vuc2V0NCwgd2hpY2ggaXMgaW4gYSBjb21hIGZyb20gbGFjayBv Zg0KPiB3b3JrLg0KPiA+DQo+ID4gSSBkb24ndCBrbm93IGhvdyB0byBkbyB0aGF0IGV4Y2VwdCBi eSBtYWtpbmcgYSBsaXN0IG9mIHRoZQ0KPiA+IGFsbGVnZWQgcHJvYmxlbXMgYW5kIGNoZWNraW5n IG9mZiB0aGUgb25lcyB0aGF0IFJGQyB0ZXh0DQo+ID4gY291bGQgZml4LiBCb3JpbmcsIG5vPw0K PiANCj4gSSB3aWxsIGJvbGRseSBhc3NlcnQgdGhhdCB0aGVyZSBhcmUgbm8gUkZDcyByZXF1aXJp bmcgdXBkYXRlcyBpbiBvcmRlcg0KPiB0byBkZXBsb3kgSVB2Ni1vbmx5Lg0KPiANCj4gSSBtYWtl IHRoYXQgYXNzZXJ0aW9uIG5vdCBzbyBtdWNoIGZyb20gY29tcGxldGUgY29uZmlkZW5jZSwgYnV0 IGFzIGENCj4gY2hhbGxlbmdlIHRvIHByb3ZlIG1lIHdyb25nLg0KPiANCj4gSVB2Ni1vbmx5IGRl cGxveW1lbnQgc3VmZmVycyBmcm9tIHNjYXJjZSBidXNpbmVzcyBkcml2ZXJzLCBidWdneQ0KPiBp bXBsZW1lbnRhdGlvbnMsIGFuZCB2ZW5kb3Igc3VwcG9ydC4gVGhlcmUncyBhbiBlbnRlcnByaXNl DQo+ICJtdWx0aS1ob21pbmciIHByb2JsZW0gdGhhdCBJIHRoaW5rIGhhcyBiZWVuIGFkZHJlc3Nl ZCBzZXZlcmFsIHdheXMuDQo+IFRoZXJlJ3MgdGhlIGludGVyYWN0aW9uIG9mIGZyYWdtZW50YXRp b24gaGVhZGVycyBhbmQgRE5TU2VjIChvciBvdGhlcg0KPiBhcHBzIHVzaW5nIHRyYW5zcG9ydCB3 aXRob3V0IHNlc3Npb24gbWFuYWdlbWVudCwgb3IgYW55Y2FzdDsgc2VlDQo+IGRyYWZ0LWlldGYt aW50YXJlYS1mcmFnLWZyYWdpbGUpLsKgIEkgZG9uJ3QgdGhpbmsgdGhlcmUncyBtb3JlIHRoZSBJ RVRGDQo+IGNhbiBkby4NCj4gDQo+IExlZQ0KPiANCj4gPg0KPiA+ICAgICAgQnJpYW4NCj4gPg0K PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4g djZvcHMgbWFpbGluZyBsaXN0DQo+ID4gdjZvcHNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+IDNBX193d3cuaWV0Zi5vcmdf bWFpbG1hbl9saXN0aW5mb192Nm9wcyZkPUR3SUdhUSZjPUJGcFdRdzhic3VLcA0KPiBsMVNnaVpI NjRRJnI9VVQzQms5Y2JMZWFKeGhmM2lDcmhJb1VXQjhZTFpVMjMwMjlzTVFHUTJrWSZtPUxfOTMN Cj4gQUVPcnF2MUJqQ1Vxa28yLXRfSy1QZUtYNEtoYmlXRHNnSEh4YTkwJnM9VmItDQo+IEhSTUNw bll2bkhkRUw1cEZLMnlGYkFtS3FQVTZBcTBSVHhCdHlpWncmZT0NCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHY2b3BzIG1haWxpbmcgbGlz dA0KPiB2Nm9wc0BpZXRmLm9yZw0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtDQo+IDNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb192Nm9w cyZkPUR3SUdhUSZjPUJGcFdRdzhic3VLcA0KPiBsMVNnaVpINjRRJnI9VVQzQms5Y2JMZWFKeGhm M2lDcmhJb1VXQjhZTFpVMjMwMjlzTVFHUTJrWSZtPUxfOTMNCj4gQUVPcnF2MUJqQ1Vxa28yLXRf Sy1QZUtYNEtoYmlXRHNnSEh4YTkwJnM9VmItDQo+IEhSTUNwbll2bkhkRUw1cEZLMnlGYkFtS3FQ VTZBcTBSVHhCdHlpWncmZT0NCg== From nobody Wed Aug 29 13:29:48 2018 Return-Path: <owen@delong.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01DF128B14 for <v6ops@ietfa.amsl.com>; Wed, 29 Aug 2018 13:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, 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 I1WlL13tYUKn for <v6ops@ietfa.amsl.com>; Wed, 29 Aug 2018 13:29:45 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDB1126BED for <v6ops@ietf.org>; Wed, 29 Aug 2018 13:29:44 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id w7TKSX7N025435 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Aug 2018 13:28:33 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com w7TKSX7N025435 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Owen DeLong <owen@delong.com> In-Reply-To: <9142206A0C5BF24CB22755C8EC422E459CB46310@AZ-US1EXMB03.global.avaya.com> Date: Wed, 29 Aug 2018 13:28:33 -0700 Cc: Lee Howard <lee@asgard.org>, "v6ops@ietf.org" <v6ops@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <76055AE4-FF87-47E1-988A-CDB7E157C6AD@delong.com> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> <CAD6AjGQ_OBFGJb_C+mP_87nu7q_oXPrTvxhaV_=RcubeHtMy2Q@mail.gmail.com> <E345387F-6C1D-49D4-8B03-52D04498DDA5@lists.zabbadoz.net> <a9eeba1b-76dc-a69f-aabe-04fa4ddc3a4f@gmail.com> <e560c82c-085e-60fe-2076-70e3624696c0@asgard.org> <9142206A0C5BF24CB22755C8EC422E459CB46310@AZ-US1EXMB03.global.avaya.com> To: "Mudric, Dusan (Dusan)" <dmudric@avaya.com> X-Mailer: Apple Mail (2.3445.9.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Wed, 29 Aug 2018 13:28:38 -0700 (PDT) Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/i7SuLTQ7_dGYoln9t8UOjM62Xig> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 29 Aug 2018 20:29:47 -0000 > On Aug 29, 2018, at 12:02 , Mudric, Dusan (Dusan) <dmudric@avaya.com> = wrote: >=20 >> I will boldly assert that there are no RFCs requiring updates in = order >> to deploy IPv6-only. >=20 > I suggest both DHCPv6 and SLAAC to be enabled by default. Currently, = RFC4861 recommends to disable DHCPv6 by default. >=20 > RFC4862 already mandates SLAAC by default. Section 5.5: > "the processing = described below MUST be > enabled by default." > But, this should be changed: > - RFC4861 section 6.2.1: AdvManagedFlag and AdvOtherConfigFlag: = Default: FALSE > =3D=3D> Change 'O' bit default value to TRUE = (AdvOtherConfigFlag: Default: TRUE). Why? Most environments have no need for DHCPv6 and setting the M flag on = by default creates a situation where no environment can be functional until the administrator takes one = of the following actions: A. Turn the M flag back off. B. (arguably worse) Configure and manage a DHCPv6 server = and set up forwarders as needed. > to allow hosts to be deployed and automatically configured (i.e. get = IPv6 address and other configuration automatically) in any environment: > - DHCPv6 only environment (no config via RA and SLAAC can be = disabled), or > - SLAAC only environment (no DHCPv6 config and DHCPv6 can be = disabled), or > - DHCPv6 and SLAAC environment. > using the default settings. One of us is misunderstanding the situation here. The flags you are talking about are, to the best of my knowledge, flags = sent in a Router Advertisement. Routers don=E2=80=99t do DHCPv6 by default, nor is there any rational = default DHCP server address for them to automatically forward to. As such, since configuration is required in order to make DHCPv6 = functional, is it not also reasonable to require that the M and/or O flag be set by the administrator if they are desired in the environment? Simply turning on those flags by default will break things in = environments that don=E2=80=99t have DHCPv6 servers and saves one line of configuration effort for administrators that have DHCPv6 servers. I do not see an advantage to doing so. > With the current RFC4861 recommendation (AdvManagedFlag and = AdvOtherConfigFlag: Default: FALSE), if DHCPv6 is disabled on hosts that = are deployed in the network which configures hosts using DHCP (DHCPv6 = only environment), the hosts will not work. Changing AdvOtherConfigFlag: = Default: TRUE will allow hosts to assign SLLAC addresses and obtain the = application configuration using stateless DHCPv6. Again, I think you=E2=80=99re looking at the wrong side of the equation = here. These flags do not (if I understand things correctly) affect what = is enabled or disabled on the host. They control the defaults for how Routers construct Router = Advertisements. Owen >=20 > Regards, > Dusan. >=20 >> -----Original Message----- >> From: v6ops <v6ops-bounces@ietf.org> On Behalf Of Lee Howard >> Sent: Tuesday, August 21, 2018 12:20 PM >> To: v6ops@ietf.org >> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks >>=20 >>=20 >>=20 >> On 08/20/2018 08:14 PM, Brian E Carpenter wrote: >>> Well, first we need to know our objective. I suggest that our >>> objective should be to identify things that the IETF should >>> do to alleviate the alleged problems. Since what we can do >>> is write standards-track, BCP or informational RFCs, the real >>> question is: which of the alleged problems could in fact be fixed >>> by new RFC text? >>=20 >> That was exactly the charter of sunset4, which is in a coma from lack = of >> work. >>>=20 >>> I don't know how to do that except by making a list of the >>> alleged problems and checking off the ones that RFC text >>> could fix. Boring, no? >>=20 >> I will boldly assert that there are no RFCs requiring updates in = order >> to deploy IPv6-only. >>=20 >> I make that assertion not so much from complete confidence, but as a >> challenge to prove me wrong. >>=20 >> IPv6-only deployment suffers from scarce business drivers, buggy >> implementations, and vendor support. There's an enterprise >> "multi-homing" problem that I think has been addressed several ways. >> There's the interaction of fragmentation headers and DNSSec (or other >> apps using transport without session management, or anycast; see >> draft-ietf-intarea-frag-fragile). I don't think there's more the = IETF >> can do. >>=20 >> Lee >>=20 >>>=20 >>> Brian >>>=20 >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwIGaQ&c=3DBFpWQw8bsuKp >> l1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3DL_93 >> AEOrqv1BjCUqko2-t_K-PeKX4KhbiWDsgHHxa90&s=3DVb- >> HRMCpnYvnHdEL5pFK2yFbAmKqPU6Aq0RTxBtyiZw&e=3D >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- >> 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwIGaQ&c=3DBFpWQw8bsuKp >> l1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3DL_93 >> AEOrqv1BjCUqko2-t_K-PeKX4KhbiWDsgHHxa90&s=3DVb- >> HRMCpnYvnHdEL5pFK2yFbAmKqPU6Aq0RTxBtyiZw&e=3D > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Aug 29 13:37:32 2018 Return-Path: <dmudric@avaya.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB365128CE4 for <v6ops@ietfa.amsl.com>; Wed, 29 Aug 2018 13:37:29 -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 kv-AWF5LWLDi for <v6ops@ietfa.amsl.com>; Wed, 29 Aug 2018 13:37:25 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.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 2DE16126BED for <v6ops@ietf.org>; Wed, 29 Aug 2018 13:37:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EsAQDgAodb/yYyC4dQChkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCelVlfygKg2iIEYwqgg2DPZJrgT87CyMJAoQ+AheCdSE0GAE?= =?us-ascii?q?CAQEBAQEBAgICaRwMgmgvAQEEBwMMLwkCAwEBAQEBAQFPAg9HAQEYAQEBAQIBE?= =?us-ascii?q?hEROgsFBwQCAQgNBAQBAQECAgYgAgICMBUICAIEDgUIGoMAgXkIAQ6aaIlvgS4?= =?us-ascii?q?aAoljBYELiQUXgUI+gRJGgh4ugxsEGIEcFRgVgmoxgiYCmzkJAoYxgnqGXYhdA?= =?us-ascii?q?4VxiyOINYFBOYFScBU7gmmCIINhilJvgRaKNgGBGwEB?= X-IPAS-Result: =?us-ascii?q?A2EsAQDgAodb/yYyC4dQChkBAQEBAQEBAQEBAQEHAQEBAQG?= =?us-ascii?q?CelVlfygKg2iIEYwqgg2DPZJrgT87CyMJAoQ+AheCdSE0GAECAQEBAQEBAgICa?= =?us-ascii?q?RwMgmgvAQEEBwMMLwkCAwEBAQEBAQFPAg9HAQEYAQEBAQIBEhEROgsFBwQCAQg?= =?us-ascii?q?NBAQBAQECAgYgAgICMBUICAIEDgUIGoMAgXkIAQ6aaIlvgS4aAoljBYELiQUXg?= =?us-ascii?q?UI+gRJGgh4ugxsEGIEcFRgVgmoxgiYCmzkJAoYxgnqGXYhdA4VxiyOINYFBOYF?= =?us-ascii?q?ScBU7gmmCIINhilJvgRaKNgGBGwEB?= X-IronPort-AV: E=Sophos;i="5.53,304,1531800000"; d="scan'208";a="301809510" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 29 Aug 2018 16:37:23 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Aug 2018 16:37:23 -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; Wed, 29 Aug 2018 16:37:22 -0400 From: "Mudric, Dusan (Dusan)" <dmudric@avaya.com> To: Owen DeLong <owen@delong.com> CC: Lee Howard <lee@asgard.org>, "v6ops@ietf.org" <v6ops@ietf.org> Thread-Topic: [v6ops] Thinking about problems in IPv6-only networks Thread-Index: AQHUP9b1/k8reRtyPEiX/AUpq68cpaTXL6Rg Date: Wed, 29 Aug 2018 20:37:22 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E459CB4644F@AZ-US1EXMB03.global.avaya.com> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> <CAD6AjGQ_OBFGJb_C+mP_87nu7q_oXPrTvxhaV_=RcubeHtMy2Q@mail.gmail.com> <E345387F-6C1D-49D4-8B03-52D04498DDA5@lists.zabbadoz.net> <a9eeba1b-76dc-a69f-aabe-04fa4ddc3a4f@gmail.com> <e560c82c-085e-60fe-2076-70e3624696c0@asgard.org> <9142206A0C5BF24CB22755C8EC422E459CB46310@AZ-US1EXMB03.global.avaya.com> <76055AE4-FF87-47E1-988A-CDB7E157C6AD@delong.com> In-Reply-To: <76055AE4-FF87-47E1-988A-CDB7E157C6AD@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/5M_0eZZllvRpigsbjtQ7TDS-qnE> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 29 Aug 2018 20:37:30 -0000 PiBUaGV5IGNvbnRyb2wgdGhlIGRlZmF1bHRzIGZvciBob3cgUm91dGVycyBjb25zdHJ1Y3QgUm91 dGVyIEFkdmVydGlzZW1lbnRzLg0KDQpBbmQgZGVmYXVsdCAnTycgZmxhZyBzZXQgdG8gVFJVRSBz aG91bGQgZW5hYmxlZCBzdGF0ZWxlc3MgREhDUHY2IHRvIG9idGFpbiBjb25maWd1cmF0aW9uIGZv ciBob3N0cy4NCg0KPiBXaHk/IE1vc3QgZW52aXJvbm1lbnRzIGhhdmUgbm8gbmVlZCBmb3IgREhD UHY2IGFuZCBzZXR0aW5nIHRoZSBNIGZsYWcNCj4gb24gYnkgZGVmYXVsdCBjcmVhdGVzIGEgc2l0 dWF0aW9uDQo+IHdoZXJlIG5vIGVudmlyb25tZW50IGNhbiBiZSBmdW5jdGlvbmFsIHVudGlsIHRo ZSBhZG1pbmlzdHJhdG9yIHRha2VzIG9uZSBvZg0KPiB0aGUgZm9sbG93aW5nIGFjdGlvbnM6DQo+ IA0KPiAJQS4JVHVybiB0aGUgTSBmbGFnIGJhY2sgb2ZmLg0KDQpXaHkgdGhlIGhvc3RzIHdpbGwg YmUgdW5mdW5jdGlvbmFsIHdoZW4gJ00nIG9yICdPJyBpcyBzZXQgYnkgZGVmYXVsdCB0byBUUlVF Pw0KDQpUaGFua3MsDQpEdXNhbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IE93ZW4gRGVMb25nIDxvd2VuQGRlbG9uZy5jb20+DQo+IFNlbnQ6IFdlZG5lc2RheSwgQXVn dXN0IDI5LCAyMDE4IDQ6MjkgUE0NCj4gVG86IE11ZHJpYywgRHVzYW4gKER1c2FuKSA8ZG11ZHJp Y0BhdmF5YS5jb20+DQo+IENjOiBMZWUgSG93YXJkIDxsZWVAYXNnYXJkLm9yZz47IHY2b3BzQGll dGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIFRoaW5raW5nIGFib3V0IHByb2JsZW1zIGlu IElQdjYtb25seSBuZXR3b3Jrcw0KPiANCj4gDQo+IA0KPiA+IE9uIEF1ZyAyOSwgMjAxOCwgYXQg MTI6MDIgLCBNdWRyaWMsIER1c2FuIChEdXNhbikgPGRtdWRyaWNAYXZheWEuY29tPg0KPiB3cm90 ZToNCj4gPg0KPiA+PiBJIHdpbGwgYm9sZGx5IGFzc2VydCB0aGF0IHRoZXJlIGFyZSBubyBSRkNz IHJlcXVpcmluZyB1cGRhdGVzIGluIG9yZGVyDQo+ID4+IHRvIGRlcGxveSBJUHY2LW9ubHkuDQo+ ID4NCj4gPiBJIHN1Z2dlc3QgYm90aCBESENQdjYgYW5kIFNMQUFDIHRvIGJlIGVuYWJsZWQgYnkg ZGVmYXVsdC4gQ3VycmVudGx5LA0KPiBSRkM0ODYxIHJlY29tbWVuZHMgdG8gZGlzYWJsZSBESENQ djYgYnkgZGVmYXVsdC4NCj4gPg0KPiA+IFJGQzQ4NjIgYWxyZWFkeSBtYW5kYXRlcyBTTEFBQyBi eSBkZWZhdWx0LiBTZWN0aW9uIDUuNToNCj4gPiAJCQkJCQkidGhlIHByb2Nlc3NpbmcgZGVzY3Jp YmVkDQo+IGJlbG93IE1VU1QgYmUNCj4gPiAJCQkJCQllbmFibGVkIGJ5IGRlZmF1bHQuIg0KPiA+ IEJ1dCwgdGhpcyBzaG91bGQgYmUgY2hhbmdlZDoNCj4gPiAJLSBSRkM0ODYxIHNlY3Rpb24gNi4y LjE6IEFkdk1hbmFnZWRGbGFnIGFuZCBBZHZPdGhlckNvbmZpZ0ZsYWc6DQo+IERlZmF1bHQ6IEZB TFNFDQo+ID4gCT09PiBDaGFuZ2UgJ08nIGJpdCBkZWZhdWx0IHZhbHVlIHRvIFRSVUUgKEFkdk90 aGVyQ29uZmlnRmxhZzoNCj4gRGVmYXVsdDogVFJVRSkuDQo+IA0KPiBXaHk/IE1vc3QgZW52aXJv bm1lbnRzIGhhdmUgbm8gbmVlZCBmb3IgREhDUHY2IGFuZCBzZXR0aW5nIHRoZSBNIGZsYWcNCj4g b24gYnkgZGVmYXVsdCBjcmVhdGVzIGEgc2l0dWF0aW9uDQo+IHdoZXJlIG5vIGVudmlyb25tZW50 IGNhbiBiZSBmdW5jdGlvbmFsIHVudGlsIHRoZSBhZG1pbmlzdHJhdG9yIHRha2VzIG9uZSBvZg0K PiB0aGUgZm9sbG93aW5nIGFjdGlvbnM6DQo+IA0KPiAJQS4JVHVybiB0aGUgTSBmbGFnIGJhY2sg b2ZmLg0KPiAJQi4JKGFyZ3VhYmx5IHdvcnNlKSBDb25maWd1cmUgYW5kIG1hbmFnZSBhIERIQ1B2 NiBzZXJ2ZXIgYW5kDQo+IHNldCB1cCBmb3J3YXJkZXJzIGFzIG5lZWRlZC4NCj4gDQo+ID4gdG8g YWxsb3cgaG9zdHMgdG8gYmUgZGVwbG95ZWQgYW5kIGF1dG9tYXRpY2FsbHkgY29uZmlndXJlZCAo aS5lLiBnZXQgSVB2Ng0KPiBhZGRyZXNzIGFuZCBvdGhlciBjb25maWd1cmF0aW9uIGF1dG9tYXRp Y2FsbHkpIGluIGFueSBlbnZpcm9ubWVudDoNCj4gPiAtIERIQ1B2NiBvbmx5IGVudmlyb25tZW50 IChubyBjb25maWcgdmlhIFJBIGFuZCBTTEFBQyBjYW4gYmUgZGlzYWJsZWQpLA0KPiBvcg0KPiA+ IC0gU0xBQUMgb25seSBlbnZpcm9ubWVudCAobm8gREhDUHY2IGNvbmZpZyBhbmQgREhDUHY2IGNh biBiZSBkaXNhYmxlZCksDQo+IG9yDQo+ID4gLSBESENQdjYgYW5kIFNMQUFDIGVudmlyb25tZW50 Lg0KPiA+IHVzaW5nIHRoZSBkZWZhdWx0IHNldHRpbmdzLg0KPiANCj4gT25lIG9mIHVzIGlzIG1p c3VuZGVyc3RhbmRpbmcgdGhlIHNpdHVhdGlvbiBoZXJlLg0KPiANCj4gVGhlIGZsYWdzIHlvdSBh cmUgdGFsa2luZyBhYm91dCBhcmUsIHRvIHRoZSBiZXN0IG9mIG15IGtub3dsZWRnZSwgZmxhZ3Mg c2VudCBpbg0KPiBhIFJvdXRlciBBZHZlcnRpc2VtZW50Lg0KPiANCj4gUm91dGVycyBkb27igJl0 IGRvIERIQ1B2NiBieSBkZWZhdWx0LCBub3IgaXMgdGhlcmUgYW55IHJhdGlvbmFsIGRlZmF1bHQg REhDUA0KPiBzZXJ2ZXIgYWRkcmVzcyBmb3IgdGhlbSB0byBhdXRvbWF0aWNhbGx5IGZvcndhcmQg dG8uDQo+IA0KPiBBcyBzdWNoLCBzaW5jZSBjb25maWd1cmF0aW9uIGlzIHJlcXVpcmVkIGluIG9y ZGVyIHRvIG1ha2UgREhDUHY2IGZ1bmN0aW9uYWwsDQo+IGlzIGl0IG5vdCBhbHNvIHJlYXNvbmFi bGUgdG8gcmVxdWlyZSB0aGF0IHRoZSBNIGFuZC9vciBPDQo+IGZsYWcgYmUgc2V0IGJ5IHRoZSBh ZG1pbmlzdHJhdG9yIGlmIHRoZXkgYXJlIGRlc2lyZWQgaW4gdGhlIGVudmlyb25tZW50Pw0KPiAN Cj4gU2ltcGx5IHR1cm5pbmcgb24gdGhvc2UgZmxhZ3MgYnkgZGVmYXVsdCB3aWxsIGJyZWFrIHRo aW5ncyBpbiBlbnZpcm9ubWVudHMNCj4gdGhhdCBkb27igJl0IGhhdmUgREhDUHY2IHNlcnZlcnMg YW5kIHNhdmVzIG9uZSBsaW5lDQo+IG9mIGNvbmZpZ3VyYXRpb24gZWZmb3J0IGZvciBhZG1pbmlz dHJhdG9ycyB0aGF0IGhhdmUgREhDUHY2IHNlcnZlcnMuDQo+IA0KPiBJIGRvIG5vdCBzZWUgYW4g YWR2YW50YWdlIHRvIGRvaW5nIHNvLg0KPiANCj4gPiBXaXRoIHRoZSBjdXJyZW50IFJGQzQ4NjEg cmVjb21tZW5kYXRpb24gKEFkdk1hbmFnZWRGbGFnIGFuZA0KPiBBZHZPdGhlckNvbmZpZ0ZsYWc6 IERlZmF1bHQ6IEZBTFNFKSwgaWYgREhDUHY2IGlzIGRpc2FibGVkIG9uIGhvc3RzIHRoYXQgYXJl DQo+IGRlcGxveWVkIGluIHRoZSBuZXR3b3JrIHdoaWNoIGNvbmZpZ3VyZXMgaG9zdHMgdXNpbmcg REhDUCAoREhDUHY2IG9ubHkNCj4gZW52aXJvbm1lbnQpLCB0aGUgaG9zdHMgd2lsbCBub3Qgd29y ay4gQ2hhbmdpbmcgQWR2T3RoZXJDb25maWdGbGFnOg0KPiBEZWZhdWx0OiBUUlVFIHdpbGwgYWxs b3cgaG9zdHMgdG8gYXNzaWduIFNMTEFDIGFkZHJlc3NlcyBhbmQgb2J0YWluIHRoZQ0KPiBhcHBs aWNhdGlvbiBjb25maWd1cmF0aW9uIHVzaW5nIHN0YXRlbGVzcyBESENQdjYuDQo+IA0KPiBBZ2Fp biwgSSB0aGluayB5b3XigJlyZSBsb29raW5nIGF0IHRoZSB3cm9uZyBzaWRlIG9mIHRoZSBlcXVh dGlvbiBoZXJlLiBUaGVzZQ0KPiBmbGFncyBkbyBub3QgKGlmIEkgdW5kZXJzdGFuZCB0aGluZ3Mg Y29ycmVjdGx5KSBhZmZlY3Qgd2hhdCBpcyBlbmFibGVkIG9yDQo+IGRpc2FibGVkIG9uIHRoZSBo b3N0Lg0KPiANCj4gVGhleSBjb250cm9sIHRoZSBkZWZhdWx0cyBmb3IgaG93IFJvdXRlcnMgY29u c3RydWN0IFJvdXRlciBBZHZlcnRpc2VtZW50cy4NCj4gDQo+IE93ZW4NCj4gDQo+ID4NCj4gPiBS ZWdhcmRzLA0KPiA+IER1c2FuLg0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4+IEZyb206IHY2b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2Yg TGVlIEhvd2FyZA0KPiA+PiBTZW50OiBUdWVzZGF5LCBBdWd1c3QgMjEsIDIwMTggMTI6MjAgUE0N Cj4gPj4gVG86IHY2b3BzQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIFRoaW5r aW5nIGFib3V0IHByb2JsZW1zIGluIElQdjYtb25seSBuZXR3b3Jrcw0KPiA+Pg0KPiA+Pg0KPiA+ Pg0KPiA+PiBPbiAwOC8yMC8yMDE4IDA4OjE0IFBNLCBCcmlhbiBFIENhcnBlbnRlciB3cm90ZToN Cj4gPj4+IFdlbGwsIGZpcnN0IHdlIG5lZWQgdG8ga25vdyBvdXIgb2JqZWN0aXZlLiBJIHN1Z2dl c3QgdGhhdCBvdXINCj4gPj4+IG9iamVjdGl2ZSBzaG91bGQgYmUgdG8gaWRlbnRpZnkgdGhpbmdz IHRoYXQgdGhlIElFVEYgc2hvdWxkDQo+ID4+PiBkbyB0byBhbGxldmlhdGUgdGhlIGFsbGVnZWQg cHJvYmxlbXMuIFNpbmNlIHdoYXQgd2UgY2FuIGRvDQo+ID4+PiBpcyB3cml0ZSBzdGFuZGFyZHMt dHJhY2ssIEJDUCBvciBpbmZvcm1hdGlvbmFsIFJGQ3MsIHRoZSByZWFsDQo+ID4+PiBxdWVzdGlv biBpczogd2hpY2ggb2YgdGhlIGFsbGVnZWQgcHJvYmxlbXMgY291bGQgaW4gZmFjdCBiZSBmaXhl ZA0KPiA+Pj4gYnkgbmV3IFJGQyB0ZXh0Pw0KPiA+Pg0KPiA+PiBUaGF0IHdhcyBleGFjdGx5IHRo ZSBjaGFydGVyIG9mIHN1bnNldDQsIHdoaWNoIGlzIGluIGEgY29tYSBmcm9tIGxhY2sgb2YNCj4g Pj4gd29yay4NCj4gPj4+DQo+ID4+PiBJIGRvbid0IGtub3cgaG93IHRvIGRvIHRoYXQgZXhjZXB0 IGJ5IG1ha2luZyBhIGxpc3Qgb2YgdGhlDQo+ID4+PiBhbGxlZ2VkIHByb2JsZW1zIGFuZCBjaGVj a2luZyBvZmYgdGhlIG9uZXMgdGhhdCBSRkMgdGV4dA0KPiA+Pj4gY291bGQgZml4LiBCb3Jpbmcs IG5vPw0KPiA+Pg0KPiA+PiBJIHdpbGwgYm9sZGx5IGFzc2VydCB0aGF0IHRoZXJlIGFyZSBubyBS RkNzIHJlcXVpcmluZyB1cGRhdGVzIGluIG9yZGVyDQo+ID4+IHRvIGRlcGxveSBJUHY2LW9ubHku DQo+ID4+DQo+ID4+IEkgbWFrZSB0aGF0IGFzc2VydGlvbiBub3Qgc28gbXVjaCBmcm9tIGNvbXBs ZXRlIGNvbmZpZGVuY2UsIGJ1dCBhcyBhDQo+ID4+IGNoYWxsZW5nZSB0byBwcm92ZSBtZSB3cm9u Zy4NCj4gPj4NCj4gPj4gSVB2Ni1vbmx5IGRlcGxveW1lbnQgc3VmZmVycyBmcm9tIHNjYXJjZSBi dXNpbmVzcyBkcml2ZXJzLCBidWdneQ0KPiA+PiBpbXBsZW1lbnRhdGlvbnMsIGFuZCB2ZW5kb3Ig c3VwcG9ydC4gVGhlcmUncyBhbiBlbnRlcnByaXNlDQo+ID4+ICJtdWx0aS1ob21pbmciIHByb2Js ZW0gdGhhdCBJIHRoaW5rIGhhcyBiZWVuIGFkZHJlc3NlZCBzZXZlcmFsIHdheXMuDQo+ID4+IFRo ZXJlJ3MgdGhlIGludGVyYWN0aW9uIG9mIGZyYWdtZW50YXRpb24gaGVhZGVycyBhbmQgRE5TU2Vj IChvciBvdGhlcg0KPiA+PiBhcHBzIHVzaW5nIHRyYW5zcG9ydCB3aXRob3V0IHNlc3Npb24gbWFu YWdlbWVudCwgb3IgYW55Y2FzdDsgc2VlDQo+ID4+IGRyYWZ0LWlldGYtaW50YXJlYS1mcmFnLWZy YWdpbGUpLiAgSSBkb24ndCB0aGluayB0aGVyZSdzIG1vcmUgdGhlIElFVEYNCj4gPj4gY2FuIGRv Lg0KPiA+Pg0KPiA+PiBMZWUNCj4gPj4NCj4gPj4+DQo+ID4+PiAgICAgQnJpYW4NCj4gPj4+DQo+ ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ Pj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+ID4+PiB2Nm9wc0BpZXRmLm9yZw0KPiA+Pj4gaHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLQ0KPiA+Pg0KPiAzQV9f d3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fdjZvcHMmZD1Ed0lHYVEmYz1CRnBXUXc4YnN1 S3ANCj4gPj4NCj4gbDFTZ2laSDY0USZyPVVUM0JrOWNiTGVhSnhoZjNpQ3JoSW9VV0I4WUxaVTIz MDI5c01RR1Eya1kmbT1MXzkzDQo+ID4+IEFFT3JxdjFCakNVcWtvMi10X0stUGVLWDRLaGJpV0Rz Z0hIeGE5MCZzPVZiLQ0KPiA+PiBIUk1DcG5Zdm5IZEVMNXBGSzJ5RmJBbUtxUFU2QXEwUlR4QnR5 aVp3JmU9DQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiA+PiB2Nm9wc0BpZXRmLm9yZw0K PiA+PiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+ ID4+DQo+IDNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb192Nm9wcyZkPUR3SUdhUSZj PUJGcFdRdzhic3VLcA0KPiA+Pg0KPiBsMVNnaVpINjRRJnI9VVQzQms5Y2JMZWFKeGhmM2lDcmhJ b1VXQjhZTFpVMjMwMjlzTVFHUTJrWSZtPUxfOTMNCj4gPj4gQUVPcnF2MUJqQ1Vxa28yLXRfSy1Q ZUtYNEtoYmlXRHNnSEh4YTkwJnM9VmItDQo+ID4+IEhSTUNwbll2bkhkRUw1cEZLMnlGYkFtS3FQ VTZBcTBSVHhCdHlpWncmZT0NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiA+IHY2b3BzQGlldGYub3Jn DQo+ID4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLQ0K PiAzQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fdjZvcHMmZD1Ed0lGYVEmYz1CRnBX UXc4YnN1S3BsDQo+IDFTZ2laSDY0USZyPVVUM0JrOWNiTGVhSnhoZjNpQ3JoSW9VV0I4WUxaVTIz MDI5c01RR1Eya1kmbT1CT1INCj4gWmcwUmIwVDBqZnJ3SUdsTDRvcXNNdkctDQo+IExHS1BzVkJF X2h4UDNJSE0mcz1VODdmR0d5SDNMQ292NlQ4bGwzMGs0QjA1WFY1R1BoQUJsRkVVaTdsYldVDQo+ ICZlPQ0KDQo= From nobody Wed Aug 29 13:52:54 2018 Return-Path: <farmer@umn.edu> 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 ED3FE128CE4 for <v6ops@ietfa.amsl.com>; Wed, 29 Aug 2018 13:52:52 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umn.edu 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 19mRrqZ72oej for <v6ops@ietfa.amsl.com>; Wed, 29 Aug 2018 13:52:51 -0700 (PDT) Received: from mta-p5.oit.umn.edu (mta-p5.oit.umn.edu [134.84.196.205]) (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 E159D126BED for <v6ops@ietf.org>; Wed, 29 Aug 2018 13:52:50 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mta-p5.oit.umn.edu (Postfix) with ESMTP id 19F1EDCD for <v6ops@ietf.org>; Wed, 29 Aug 2018 20:52:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at umn.edu Received: from mta-p5.oit.umn.edu ([127.0.0.1]) by localhost (mta-p5.oit.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9uFaynK3I8G for <v6ops@ietf.org>; Wed, 29 Aug 2018 15:52:49 -0500 (CDT) Received: from mail-ua1-f70.google.com (mail-ua1-f70.google.com [209.85.222.70]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta-p5.oit.umn.edu (Postfix) with ESMTPS id DB90F9AD for <v6ops@ietf.org>; Wed, 29 Aug 2018 15:52:48 -0500 (CDT) Received: by mail-ua1-f70.google.com with SMTP id d22-v6so2691657uaq.11 for <v6ops@ietf.org>; Wed, 29 Aug 2018 13:52:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zTJ7v+KW0eFZfr3AJpYFWkphxC/z57Rcb5NXQiH3NUM=; b=l3MSNtUKcrIvHQnOzIt1X+YFFrbptUjGD/dKVMt2cwMnuuyujAlEyOlmyp/1kvnezF 7af66yaJsebGJ+VBp3z7mCbuulMBpqVCyPlJj4bHjRPpNTwHoXHM6Fqe7kj/GPvz2Iml XybihqE244KlvDOgZlfMgZqP8Z4PPq+7sGZd8LotY/rp9rTP4nYkSkyxwtBzKquJIoeb 5TzcOPGTBUA8fyQFnqM3gbarKwKs7k7iJ/INDYvbe+BrCmqVfkSHqMEm9MDFo3FwELkc 6/47NkrGwKly3V6CwWM2bF75LbnD74hsmwjBTDW4vD/+DJNQFEfTZW2jmquetOK9KIFj hk/g== 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=zTJ7v+KW0eFZfr3AJpYFWkphxC/z57Rcb5NXQiH3NUM=; b=V67S0Sjr8ax/AUGEvMUks0r+tSttEafN3dqgzTwyo13z0XHC8Iosf2Hicq9bSW/NbA l07oBWxGry1olttA+vv+Uz6GyO1ZmbHCTTHe5KCwemtkgjlhlTug47jKSvIyIdRNZc/A CC7bpC8ayqfQIY+9S0fLg3E0wgKvjgUCyXeW8YYrUubF/tyn2PhBEN6s15/wnJAI5iX7 zgaoNjnVURWaOv5RnIIwiEx4TUGyzXwkuDx/2iu5Ytxgk6EOP73eqO1ZRnmC/exN/bfT YdwJ3gXySViHglcoH/1SuwhMZ/b31TCs/YEz8TjxdS4DhDks4TDhqZ5eZOk+lxZ1eejq rPMQ== X-Gm-Message-State: APzg51CCSG7A5CZyqs2blY2iaVr31fOpEhaw9VrGZktl/8G5KPrZasLe tv8JNQPgqHpEbm3snmyjMt1FfAqegkTyJioIEraFlcmgxGnqo2xA3P518GMLPH1TlsjEvw+5or+ GOFedDdEk7pUZwrGDcCPG7MhZzg== X-Received: by 2002:a9f:3d1a:: with SMTP id l26-v6mr5445746uai.29.1535575968021; Wed, 29 Aug 2018 13:52:48 -0700 (PDT) X-Google-Smtp-Source: ANB0VdaZXQh0EK3yVUKoOFeReNffZU4O12Y+RvXfNFPn1UcD3PYbhpEAsU1PKIFml4MfnnP+/ZQHry4HWicVLSV61ZI= X-Received: by 2002:a9f:3d1a:: with SMTP id l26-v6mr5445734uai.29.1535575967709; Wed, 29 Aug 2018 13:52:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a67:3bc7:0:0:0:0:0 with HTTP; Wed, 29 Aug 2018 13:52:46 -0700 (PDT) In-Reply-To: <9142206A0C5BF24CB22755C8EC422E459CB4644F@AZ-US1EXMB03.global.avaya.com> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> <CAD6AjGQ_OBFGJb_C+mP_87nu7q_oXPrTvxhaV_=RcubeHtMy2Q@mail.gmail.com> <E345387F-6C1D-49D4-8B03-52D04498DDA5@lists.zabbadoz.net> <a9eeba1b-76dc-a69f-aabe-04fa4ddc3a4f@gmail.com> <e560c82c-085e-60fe-2076-70e3624696c0@asgard.org> <9142206A0C5BF24CB22755C8EC422E459CB46310@AZ-US1EXMB03.global.avaya.com> <76055AE4-FF87-47E1-988A-CDB7E157C6AD@delong.com> <9142206A0C5BF24CB22755C8EC422E459CB4644F@AZ-US1EXMB03.global.avaya.com> From: David Farmer <farmer@umn.edu> Date: Wed, 29 Aug 2018 15:52:46 -0500 Message-ID: <CAN-Dau26+uOpa9+CSf5QGmbqbmW5UisM3zxitLv12pLWRmZ8rQ@mail.gmail.com> To: "Mudric, Dusan (Dusan)" <dmudric@avaya.com> Cc: Owen DeLong <owen@delong.com>, "v6ops@ietf.org" <v6ops@ietf.org> Content-Type: multipart/alternative; boundary="00000000000014e82a057499248c" Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/0R7baUXmKfleRtj4h5VrkjqlNMg> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 29 Aug 2018 20:52:53 -0000 --00000000000014e82a057499248c Content-Type: text/plain; charset="UTF-8" On Wed, Aug 29, 2018 at 3:37 PM, Mudric, Dusan (Dusan) <dmudric@avaya.com> wrote: > > They control the defaults for how Routers construct Router > Advertisements. > > And default 'O' flag set to TRUE should enabled stateless DHCPv6 to obtain > configuration for hosts. Only if there is, in fact, a DHCPv6 server and it is configured with appropriate information. Maybe you wish to recommend net operators deploy DHCPv6, but change the default for the O flag in RAs is more that. While I could be sympathetic to recommendations to provide DHCPv6 servers on networks. However, changing the defaults for the M or O flags is not something I can support. If I provide a DHCPv6 server then it is my job to set the flags appropriately in the RA. If I don't provide a DHCPv6 I should not have to do anything. This is how the defaults for the M and O flag are currently set. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== --00000000000014e82a057499248c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"= gmail_extra"><br></div><div class=3D"gmail_quote">On Wed, Aug 29, 2018 at 3= :37 PM, Mudric, Dusan (Dusan) <span dir=3D"ltr"><<a href=3D"mailto:dmudr= ic@avaya.com" target=3D"_blank">dmudric@avaya.com</a>></span> wrote:<br>= <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left:1px solid rgb(204,204,204);padding-left:1ex">> They control the def= aults for how Routers construct Router Advertisements.<br> <br> And default 'O' flag set to TRUE should enabled stateless DHCPv6 to= obtain configuration for hosts.</blockquote><div><br></div><div><div class= =3D"gmail_extra" style=3D"font-size:small;background-color:rgb(255,255,255)= ;text-decoration-style:initial;text-decoration-color:initial">Only if there= is, in fact, a DHCPv6 server and it is configured with appropriate informa= tion.=C2=A0 Maybe you wish to recommend net operators deploy DHCPv6, but ch= ange the default for the O flag in RAs is more that.=C2=A0</div><div class= =3D"gmail_extra" style=3D"font-size:small;background-color:rgb(255,255,255)= ;text-decoration-style:initial;text-decoration-color:initial"><br></div><di= v class=3D"gmail_extra" style=3D"font-size:small;background-color:rgb(255,2= 55,255);text-decoration-style:initial;text-decoration-color:initial">While = I could be sympathetic to recommendations to provide DHCPv6 servers on netw= orks. However, changing the defaults for the M or O flags is not something = I can support.=C2=A0 If I provide a DHCPv6 server then it is my job to set = the flags appropriately in the RA. If I don't provide a DHCPv6 I should= not have to do anything. This is how the defaults for the M and O flag are= currently set.</div><div class=3D"gmail_extra" style=3D"font-size:small;ba= ckground-color:rgb(255,255,255);text-decoration-style:initial;text-decorati= on-color:initial"><br></div></div></div>-- <br><div class=3D"gmail_signatur= e">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>Da= vid Farmer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 <a href=3D= "mailto:Email%3Afarmer@umn.edu" target=3D"_blank">Email:farmer@umn.edu</a><= br>Networking & Telecommunication Services<br>Office of Information Tec= hnology<br>University of Minnesota=C2=A0=C2=A0 <br>2218 University Ave SE= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Phone: 612-626-0815<br>Minneapolis, MN 55414-30= 29=C2=A0=C2=A0 Cell: 612-812-9952<br>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</div> </div></div></div> --00000000000014e82a057499248c-- From nobody Wed Aug 29 15:24:17 2018 Return-Path: <brian.e.carpenter@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE9F130DCB for <v6ops@ietfa.amsl.com>; Wed, 29 Aug 2018 15:24:15 -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 Az0eGJo0VqYh for <v6ops@ietfa.amsl.com>; Wed, 29 Aug 2018 15:24:13 -0700 (PDT) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 7BC79130DC8 for <v6ops@ietf.org>; Wed, 29 Aug 2018 15:24:13 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id d19-v6so2947414pgv.1 for <v6ops@ietf.org>; Wed, 29 Aug 2018 15:24:13 -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=PTCObuQxZzowcMzuh9FJ/wPxDYvQCf7KtzsbOLWWcEY=; b=JiFBAr8YFrfzB5nu2jjnAJQaEYbwWTGn76YDpSoRteKKelC/tsHbl2Z1K5h+tpn2yu uSgutWAb1xqxj1ZaOVO1CNTGr8uNUC03b3CSKZn/HtWAXG4JzNEPwHJaw+UbdrnuhbjX JYxoPvJfpA+uh7ibydFLuhCglE+/OQvose6Zyeg+xdH/0gJzXHAyZ9OSWmzUvudiziX1 VR6KQWhEMWOApIxemdqRnwvSBYrZMS2a2X//hwdqvOwdxDfE6y/dtE72ErO5DJIRPh2b D83ppZzCcD3ybg74Hxo2tfW5RnnyQM6zJKTKTXRBno7H8nTIl4bTyI4Wok8rS4YIfRdb 3eXg== 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=PTCObuQxZzowcMzuh9FJ/wPxDYvQCf7KtzsbOLWWcEY=; b=A48fDP43ZxjcN/cLOoGD3nZ34R21xAUazFp77D9op77ssLNtN5aBR5vSZ+4kJZcQXE RNjL0M+TOWfLhY/MJNrv1wg5Ix2YX0fbEx27O+N5VdqIOJyf1LbH2Wop04v0IFMnlC+U sOFgX6AMbnSMtpI2NIi074D6So7ZmgrWnUQk+4QLZCTr1RtnnrF8zZzmLIBh3U69UQA1 KU6yAEMiErdFoAYVzvg38hva+UWzPszJleA2YGUtf61f05PsQMMNjy1WKxQJt9Bh4YiN eKTrpMg+dKMVmiWBOYY+VgmxmNQfKhAFHlqPDCPvwOixKtKCWiJUXDH/2dRedeMPkMiq 14Ew== X-Gm-Message-State: APzg51AuS6z56RX6966DIzKNLSIyTDI4VoDOUiKlclJi3Fml7Oo6oIsH OH1Xt0TwndCyr5TeaWcUftANbNEv X-Google-Smtp-Source: ANB0VdYsWpkd/9gIZUrYQ3xzhdB76am9lTbClC2SS22F6zFe1kLjRK640nK4PfmgpYvwNvKkomz+HQ== X-Received: by 2002:a62:2f84:: with SMTP id v126-v6mr7732573pfv.115.1535581452684; Wed, 29 Aug 2018 15:24:12 -0700 (PDT) Received: from [192.168.178.30] ([118.148.68.33]) by smtp.gmail.com with ESMTPSA id b21-v6sm12599276pfm.97.2018.08.29.15.24.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Aug 2018 15:24:11 -0700 (PDT) To: David Farmer <farmer@umn.edu>, "Mudric, Dusan (Dusan)" <dmudric@avaya.com> Cc: "v6ops@ietf.org" <v6ops@ietf.org> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> <CAD6AjGQ_OBFGJb_C+mP_87nu7q_oXPrTvxhaV_=RcubeHtMy2Q@mail.gmail.com> <E345387F-6C1D-49D4-8B03-52D04498DDA5@lists.zabbadoz.net> <a9eeba1b-76dc-a69f-aabe-04fa4ddc3a4f@gmail.com> <e560c82c-085e-60fe-2076-70e3624696c0@asgard.org> <9142206A0C5BF24CB22755C8EC422E459CB46310@AZ-US1EXMB03.global.avaya.com> <76055AE4-FF87-47E1-988A-CDB7E157C6AD@delong.com> <9142206A0C5BF24CB22755C8EC422E459CB4644F@AZ-US1EXMB03.global.avaya.com> <CAN-Dau26+uOpa9+CSf5QGmbqbmW5UisM3zxitLv12pLWRmZ8rQ@mail.gmail.com> From: Brian E Carpenter <brian.e.carpenter@gmail.com> Message-ID: <f2d934cb-5075-fc1c-49d5-71d4613b3b9c@gmail.com> Date: Thu, 30 Aug 2018 10:24:07 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <CAN-Dau26+uOpa9+CSf5QGmbqbmW5UisM3zxitLv12pLWRmZ8rQ@mail.gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/3croQj7njn89m__m_RKjay1vRGk> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 29 Aug 2018 22:24:16 -0000 On 2018-08-30 08:52, David Farmer wrote: > On Wed, Aug 29, 2018 at 3:37 PM, Mudric, Dusan (Dusan) <dmudric@avaya.com> > wrote: > >>> They control the defaults for how Routers construct Router >> Advertisements. >> >> And default 'O' flag set to TRUE should enabled stateless DHCPv6 to obtain >> configuration for hosts. > > > Only if there is, in fact, a DHCPv6 server and it is configured with > appropriate information. Maybe you wish to recommend net operators deploy > DHCPv6, but change the default for the O flag in RAs is more that. > > While I could be sympathetic to recommendations to provide DHCPv6 servers > on networks. However, changing the defaults for the M or O flags is not > something I can support. If I provide a DHCPv6 server then it is my job to > set the flags appropriately in the RA. If I don't provide a DHCPv6 I should > not have to do anything. This is how the defaults for the M and O flag are > currently set. Exactly. Working out of the box on an unmanaged network has always been a goal for IPv6, even back when it was called IPng. The defaults are set appropriately for that goal. Brian From nobody Wed Aug 29 15:29:25 2018 Return-Path: <brian.e.carpenter@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD9D130DEA; Wed, 29 Aug 2018 15:29:23 -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=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 T98Alu2TIveE; Wed, 29 Aug 2018 15:29:21 -0700 (PDT) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 2AD0C130DE9; Wed, 29 Aug 2018 15:29:21 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id a13-v6so249218pgt.7; Wed, 29 Aug 2018 15:29:21 -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=ayI5Tq6tNu4xpDxYnSPEcEK0QWZbaahfJYiDxDSW4xA=; b=ZpdsV7vbhcNx1b71Oi6vEFFEAZ/zzeelWmij9tR+SZWUkNlNKIePeqXcVaWhi8Hur6 cV9E1eOLskNxpT8TC625Qwh2cqxDNuYeGv5K5sxtcfLluN5OnwO5Uc9IzXbpjsL8jIJw MmWliKwnOqbDN0vGhQtDKJBaCzd/AG+sJntiUoTKEdLLsKeoDRUcp7AvMHLFGI+qYpGw U6TOHvrcJd8VNmEtaOt0UdanQn5VOA2bgQgD4FKOrmQKjhFwWfQntR5/Ga4xqNieQGka 65ZXA1TS9S41km0TyD4s0PF6X5oFMH6Ifmrb2Z2oCa44j8a7j0qwyZEbMEMyLb3eUf/C NkEg== 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=ayI5Tq6tNu4xpDxYnSPEcEK0QWZbaahfJYiDxDSW4xA=; b=jVE9k16bGw4Wl5N5hx5k8FYll2KJTfYiVcpO2C1TQiCzW/BcgI9fMD9QgNhT2FPXYb Xid6wbBRJmQHShAwHcbahhJU1Fuvv/zU+B6UYvO5BTvi6nF6cZWSyrfuLFudSHRDkKZl 3kB2NmzClvh11k+rqY8VVtFlH3mBGUW/Jhob2RzXC28Ne7nFrag+l9BHDQ0PyiD349PG Q9l+QtiCqbT4VAnH87Sq3+8FOU1gXS+uR2FiPBJOR2lKo9Vm0pea/Wp+JcpLOu15pT3P sYgb1IQjOxKf2D4KL/6hXi/cXX5/hVT262r3hKyKn/KaLDfEcgSnLb0A9jXvciLw6nXr aWTQ== X-Gm-Message-State: APzg51D/TEUYTVBGICFj0rESyToj01VQDJWwIlQ+J/7KCAN21PsShAg4 sR1wsBJInjWZD5dn5BuLrpI= X-Google-Smtp-Source: ANB0VdYZOwxNRBS/R90SwEGfnC4WO0i7u4e5CtBi9m/K4fFDzJ1uEfI09ke434ttPL7qkMCFTwD9cg== X-Received: by 2002:a63:1021:: with SMTP id f33-v6mr7235720pgl.72.1535581760608; Wed, 29 Aug 2018 15:29:20 -0700 (PDT) Received: from [192.168.178.30] ([118.148.68.33]) by smtp.gmail.com with ESMTPSA id k69-v6sm8237775pgd.9.2018.08.29.15.29.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Aug 2018 15:29:19 -0700 (PDT) To: "STARK, BARBARA H" <bs7652@att.com>, 'Fred Baker' <fredbaker.ietf@gmail.com>, "Mudric, Dusan (Dusan)" <dmudric@avaya.com> Cc: "draft-palet-v6ops-rfc6177-bis@ietf.org" <draft-palet-v6ops-rfc6177-bis@ietf.org>, IPv6 Operations <v6ops@ietf.org>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org> References: <153017691583.14743.17000446834856511528@ietfa.amsl.com> <78a36a81-3bb3-9d47-aa06-8da8f7594677@gmail.com> <C040E02F-7BEC-4FF9-8585-BE380B6859DE@consulintel.es> <alpine.DEB.2.02.1807191054090.7979@networking.stanford.edu> <9142206A0C5BF24CB22755C8EC422E459CB44344@AZ-US1EXMB03.global.avaya.com> <f1bc1848-abe0-553e-0fdf-623eb0d1a871@gmail.com> <9142206A0C5BF24CB22755C8EC422E459CB44E7E@AZ-US1EXMB03.global.avaya.com> <A82D3E92-C68D-4685-BD3D-6B2656F9A8A6@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DE872CA@GAALPA1MSGUSRBF.ITServices.sbc.com> From: Brian E Carpenter <brian.e.carpenter@gmail.com> Message-ID: <e4ac2192-e18b-9d64-c33a-79523d642e1d@gmail.com> Date: Thu, 30 Aug 2018 10:29:15 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114DE872CA@GAALPA1MSGUSRBF.ITServices.sbc.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/yo4EF4Bbxiy2GTMJ7VQf6CDmZrc> Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 29 Aug 2018 22:29:24 -0000 Barbara, On 2018-08-30 00:11, STARK, BARBARA H wrote: >> My understanding, no hats and potentially incorrect, is that any ISP I know of >> will respond to a DHCPv6 IA_PD with a prefix at least as large as requested, >> up to /48. > > I don't think this is correct. Of course, any provider using 6rd won't respond to DHCPv6 at all. I'm aware of a lot of 6rd out there. > Wireless LTE providers don't tend to support DHCPv6, either. The /64 advertised by the RA in an LTE environment is all the LTE UE will get. That includes the case where the LTE UE is supporting a fixed wireless installation. > For ISPs that support DHCPv6, it may or may not be the case. I've heard several say they do, but I'm not aware of a survey of all ISPs that would tell me how prevalent it is. > > BTW, I disagree with the abstract's statement that the "policy should reflect that assignment of a single subnet is never appropriate." I do not believe this takes into consideration the fact that it would be tremendously expensive for some ISPs to replace their current equipment when those current equipment vendors are being slow about supporting certain features. Cost is always an appropriate consideration. I disagree. Yes, of course cost is always a consideration, but that doesn't make a lower case "should" inappropriate. > It also does not take into account CE routers that only request a single /64. That's irrelevant. The customer might have bought such a router, but the next customer along might have bought a full homenet-supporting CE. > I think it's inappropriate for IETF to be trying to dictate what is and isn't "appropriate". Recommending a best current practice is fine. But that's not the same as saying something is "never appropriate". Let's say "never recommended" then. Brian From nobody Wed Aug 29 15:42:09 2018 Return-Path: <ggm@algebras.org> 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 1D398130DBE for <v6ops@ietfa.amsl.com>; Wed, 29 Aug 2018 15:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=algebras-org.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 EYFqC9z4oJ0l for <v6ops@ietfa.amsl.com>; Wed, 29 Aug 2018 15:42:04 -0700 (PDT) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 DA646128CB7 for <v6ops@ietf.org>; Wed, 29 Aug 2018 15:42:03 -0700 (PDT) Received: by mail-wr1-x42c.google.com with SMTP id o37-v6so6249876wrf.6 for <v6ops@ietf.org>; Wed, 29 Aug 2018 15:42:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0+5FfAVGx/iBg6TSb5r6kh6mYhGa5GOua/w0DuLSCNY=; b=HHF4SbW6utUQtBODGbgEmV2NKLXT2GoVNtb4/xZiNtwqdfCDmvsDTWMQ9FtR+JIgnW bbZZeatp/o/CvW0kMBrXrRzsYZ5m55OfkY1dkouVH84XouIsU29sM5lkKImm4/Lkfn+4 GztAGy/Yi6tbOFgsqp1WKl8calWk9szFX+J2+TzF7Fv2cl2KLp4Xi8ZInEJMyLzr+w9k Sch6EcJs9hqdH2mcE+5Ak8mYYqb1garMdXNIO3H8Qx23nQysUgPemMRy1oV+t6KrkanK qucrX/iyZNym1w3z0j4TqPLEfJ91Xpkp4/bMcd/UitPh0U5GVaKdwvugoKR+iV61j7z+ WvMQ== 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=0+5FfAVGx/iBg6TSb5r6kh6mYhGa5GOua/w0DuLSCNY=; b=OyLtn//g4I3NhP1D2+XClw9sECN5IYmZcF8x3gVsi8TmFWawY2A52OyhCENX0n0l1Y ZsMgAJQW7tEYkjA/AVSlP4XaLXEiCjLS+cHMAS8YRJuUupHotE8xQFhMQAygNLcYEWpQ PwPifDoS8Zk/pN0TKUYxKyJgX8ZUqhjAdYYmbtDGhsrsX5pS0WFe6ikDSGobcyCGaEBH 4eTp3kBRJixHoTnuX/gdLJaSk+SwX7m6C+k1icEzmaUvGVg4zOL1AjoXiBbtlTiNRwZG JgaIVAfHlCBV7NxC+8F/6C5+cGeeNBup+q9p2kk220i9t/9n9iSPfwcJvto96Hwx0wKe mBfQ== X-Gm-Message-State: APzg51AWv+qCnPr4TnMZKsib+hXrrACrIyjxod+EMRwWZfAaGUk1FD+m G5x8Ye/I2+13tZnJsrrHYuPiOl4w0842TgY3Lyc9eQ== X-Google-Smtp-Source: ANB0VdZxzmQJfUBqveOp6CWevfBDrtrnkJm/Fi4v7352pJHp4p8bekvgdSV5EyRHL9I1jjKMcL3oaEI4wliINAtWTlU= X-Received: by 2002:adf:f112:: with SMTP id r18-v6mr5594222wro.29.1535582522216; Wed, 29 Aug 2018 15:42:02 -0700 (PDT) MIME-Version: 1.0 References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> <CAD6AjGQ_OBFGJb_C+mP_87nu7q_oXPrTvxhaV_=RcubeHtMy2Q@mail.gmail.com> <E345387F-6C1D-49D4-8B03-52D04498DDA5@lists.zabbadoz.net> <a9eeba1b-76dc-a69f-aabe-04fa4ddc3a4f@gmail.com> <e560c82c-085e-60fe-2076-70e3624696c0@asgard.org> <9142206A0C5BF24CB22755C8EC422E459CB46310@AZ-US1EXMB03.global.avaya.com> <76055AE4-FF87-47E1-988A-CDB7E157C6AD@delong.com> <9142206A0C5BF24CB22755C8EC422E459CB4644F@AZ-US1EXMB03.global.avaya.com> <CAN-Dau26+uOpa9+CSf5QGmbqbmW5UisM3zxitLv12pLWRmZ8rQ@mail.gmail.com> <f2d934cb-5075-fc1c-49d5-71d4613b3b9c@gmail.com> In-Reply-To: <f2d934cb-5075-fc1c-49d5-71d4613b3b9c@gmail.com> From: George Michaelson <ggm@algebras.org> Date: Thu, 30 Aug 2018 08:41:50 +1000 Message-ID: <CAKr6gn2UJiEr2B4O9z7niMxm46fHzmw26+g++H=7i49wYh8Khg@mail.gmail.com> To: Brian E Carpenter <brian.e.carpenter@gmail.com> Cc: David Farmer <farmer@umn.edu>, dmudric@avaya.com, "<v6ops@ietf.org>" <v6ops@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/w8KO-PnglAbbY4HEFd7NrIZeRfQ> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 29 Aug 2018 22:42:07 -0000 despite having stood up at a microphone and accused Brian of propagating 'the evil bit' again, I actually think an advisory 'this is a v6 only managed network' is a good idea. It would allow people to write code which does: test if v6only, in getting your v6 bindings: On Thu, Aug 30, 2018 at 8:24 AM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote: > > On 2018-08-30 08:52, David Farmer wrote: > > On Wed, Aug 29, 2018 at 3:37 PM, Mudric, Dusan (Dusan) <dmudric@avaya.com> > > wrote: > > > >>> They control the defaults for how Routers construct Router > >> Advertisements. > >> > >> And default 'O' flag set to TRUE should enabled stateless DHCPv6 to obtain > >> configuration for hosts. > > > > > > Only if there is, in fact, a DHCPv6 server and it is configured with > > appropriate information. Maybe you wish to recommend net operators deploy > > DHCPv6, but change the default for the O flag in RAs is more that. > > > > While I could be sympathetic to recommendations to provide DHCPv6 servers > > on networks. However, changing the defaults for the M or O flags is not > > something I can support. If I provide a DHCPv6 server then it is my job to > > set the flags appropriately in the RA. If I don't provide a DHCPv6 I should > > not have to do anything. This is how the defaults for the M and O flag are > > currently set. > > Exactly. Working out of the box on an unmanaged network has always been > a goal for IPv6, even back when it was called IPng. The defaults are > set appropriately for that goal. > > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Aug 30 11:24:33 2018 Return-Path: <owen@delong.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C25C7130EE5 for <v6ops@ietfa.amsl.com>; Thu, 30 Aug 2018 11:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 LHnEE5Ghqaaq for <v6ops@ietfa.amsl.com>; Thu, 30 Aug 2018 11:24:29 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id D9A36130DD8 for <v6ops@ietf.org>; Thu, 30 Aug 2018 11:24:28 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id w7UINGCt000470 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Aug 2018 11:23:16 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com w7UINGCt000470 From: Owen DeLong <owen@delong.com> Message-Id: <895F6889-B434-4008-B9C2-A04F7CDA0FA8@delong.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_88FFC38A-7064-45FD-B21D-63C419540E81" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 30 Aug 2018 11:23:16 -0700 In-Reply-To: <9142206A0C5BF24CB22755C8EC422E459CB4644F@AZ-US1EXMB03.global.avaya.com> Cc: Lee Howard <lee@asgard.org>, "v6ops@ietf.org" <v6ops@ietf.org> To: "Mudric, Dusan (Dusan)" <dmudric@avaya.com> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> <CAD6AjGQ_OBFGJb_C+mP_87nu7q_oXPrTvxhaV_=RcubeHtMy2Q@mail.gmail.com> <E345387F-6C1D-49D4-8B03-52D04498DDA5@lists.zabbadoz.net> <a9eeba1b-76dc-a69f-aabe-04fa4ddc3a4f@gmail.com> <e560c82c-085e-60fe-2076-70e3624696c0@asgard.org> <9142206A0C5BF24CB22755C8EC422E459CB46310@AZ-US1EXMB03.global.avaya.com> <76055AE4-FF87-47E1-988A-CDB7E157C6AD@delong.com> <9142206A0C5BF24CB22755C8EC422E459CB4644F@AZ-US1EXMB03.global.avaya.com> X-Mailer: Apple Mail (2.3445.9.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Thu, 30 Aug 2018 11:23:18 -0700 (PDT) Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/w9ULvZvogigfq8CaJnVoJgX1y94> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 30 Aug 2018 18:24:32 -0000 --Apple-Mail=_88FFC38A-7064-45FD-B21D-63C419540E81 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 29, 2018, at 13:37 , Mudric, Dusan (Dusan) <dmudric@avaya.com> = wrote: >=20 >> They control the defaults for how Routers construct Router = Advertisements. >=20 > And default 'O' flag set to TRUE should enabled stateless DHCPv6 to = obtain configuration for hosts. Only if there=E2=80=99s a DHCP server to provide the =E2=80=9COther=E2=80=9D= information. If you=E2=80=99re setting up a DHCPv6 server, then turn the O and/or M = bits on in your RAs as appropriate. If you=E2=80=99re not setting one up, you shouldn=E2=80=99t have to = change your RA flags just to tell it that you didn=E2=80=99t do so. >> Why? Most environments have no need for DHCPv6 and setting the M flag >> on by default creates a situation >> where no environment can be functional until the administrator takes = one of >> the following actions: >>=20 >> A. Turn the M flag back off. >=20 > Why the hosts will be unfunctional when 'M' or 'O' is set by default = to TRUE? Because if you didn=E2=80=99t set up a DHCP server and you set the M = flag, the host will (if it is doing as it should) not get an address via SLAAC and go hunting for one from the = non-existent DHCPv6 server. Have you tried any of this in a DHCP-less environment, or are you just = assuming blindly that everyone needs DHCPv6 and therefore it should always be enabled by default? I=E2=80=99m running just fine on my IPv6-only networks here WITHOUT any = DHCPv6 server. If my routers switched to M+O set on RAs by default, I=E2=80=99d have to = go in and change that for my network to keep functioning. Owen --Apple-Mail=_88FFC38A-7064-45FD-B21D-63C419540E81 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><br = class=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div = class=3D"">On Aug 29, 2018, at 13:37 , Mudric, Dusan (Dusan) <<a = href=3D"mailto:dmudric@avaya.com" class=3D"">dmudric@avaya.com</a>> = wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div = style=3D"" class=3D""><blockquote type=3D"cite" style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: normal; letter-spacing: normal; orphans: auto; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; = -webkit-text-stroke-width: 0px; text-decoration: none;" class=3D"">They = control the defaults for how Routers construct Router Advertisements.<br = class=3D""></blockquote><br style=3D"caret-color: rgb(0, 0, 0); = font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, = 0); font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline !important;" = class=3D"">And default 'O' flag set to TRUE should enabled stateless = DHCPv6 to obtain configuration for hosts.</span><br style=3D"caret-color: = rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = normal; font-variant-caps: normal; font-weight: normal; letter-spacing: = normal; text-align: start; text-indent: 0px; text-transform: none; = white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;" class=3D""></div></div></blockquote><div><br = class=3D""></div>Only if there=E2=80=99s a DHCP server to provide the = =E2=80=9COther=E2=80=9D information.</div><div><br = class=3D""></div><div>If you=E2=80=99re setting up a DHCPv6 server, then = turn the O and/or M bits on in your RAs as appropriate.</div><div><br = class=3D""></div><div>If you=E2=80=99re not setting one up, you = shouldn=E2=80=99t have to change your RA flags just to tell it that you = didn=E2=80=99t do so.</div><div><br class=3D""><blockquote type=3D"cite" = class=3D""><div class=3D""><div style=3D"" class=3D""><blockquote = type=3D"cite" style=3D"font-family: Helvetica; font-size: 12px; = font-style: normal; font-variant-caps: normal; font-weight: normal; = letter-spacing: normal; orphans: auto; text-align: start; text-indent: = 0px; text-transform: none; white-space: normal; widows: auto; = word-spacing: 0px; -webkit-text-size-adjust: auto; = -webkit-text-stroke-width: 0px; text-decoration: none;" class=3D"">Why? = Most environments have no need for DHCPv6 and setting the M flag<br = class=3D"">on by default creates a situation<br class=3D"">where no = environment can be functional until the administrator takes one of<br = class=3D"">the following actions:<br class=3D""><br class=3D""><span = class=3D"Apple-tab-span" style=3D"white-space: pre;"> </span>A.<span = class=3D"Apple-tab-span" style=3D"white-space: pre;"> </span>Turn the = M flag back off.<br class=3D""></blockquote><br style=3D"caret-color: = rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: = normal; font-variant-caps: normal; font-weight: normal; letter-spacing: = normal; text-align: start; text-indent: 0px; text-transform: none; = white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, = 0); font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline !important;" = class=3D"">Why the hosts will be unfunctional when 'M' or 'O' is set by = default to TRUE?</span><br style=3D"caret-color: rgb(0, 0, 0); = font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;" class=3D""></div></div></blockquote><div><br = class=3D""></div>Because if you didn=E2=80=99t set up a DHCP server and = you set the M flag, the host will (if it is doing as it = should)</div><div>not get an address via SLAAC and go hunting for one = from the non-existent DHCPv6 server.</div><div><br = class=3D""></div><div>Have you tried any of this in a DHCP-less = environment, or are you just assuming blindly that = everyone</div><div>needs DHCPv6 and therefore it should always be = enabled by default?</div><div><br class=3D""></div><div>I=E2=80=99m = running just fine on my IPv6-only networks here WITHOUT any DHCPv6 = server.</div><div><br class=3D""></div><div>If my routers switched to = M+O set on RAs by default, I=E2=80=99d have to go in and change that for = my network to keep</div><div>functioning.</div><div><br = class=3D""></div><div>Owen</div><div><br class=3D""></div><br = class=3D""></body></html>= --Apple-Mail=_88FFC38A-7064-45FD-B21D-63C419540E81-- From nobody Thu Aug 30 11:36:21 2018 Return-Path: <owen@delong.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82069130DF7; Thu, 30 Aug 2018 11:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, 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 RrfTlFqZxWOM; Thu, 30 Aug 2018 11:36:18 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBFD130DD8; Thu, 30 Aug 2018 11:36:18 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [IPv6:2620:0:930:0:0:0:200:5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id w7UIY5il002164 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Aug 2018 11:34:06 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com w7UIY5il002164 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Owen DeLong <owen@delong.com> In-Reply-To: <e4ac2192-e18b-9d64-c33a-79523d642e1d@gmail.com> Date: Thu, 30 Aug 2018 11:34:05 -0700 Cc: "STARK, BARBARA H" <bs7652@att.com>, Fred Baker <fredbaker.ietf@gmail.com>, "Mudric, Dusan (Dusan)" <dmudric@avaya.com>, "draft-palet-v6ops-rfc6177-bis@ietf.org" <draft-palet-v6ops-rfc6177-bis@ietf.org>, IPv6 Operations <v6ops@ietf.org>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <2825C26D-3AF8-430C-90A8-C33ABF036C10@delong.com> References: <153017691583.14743.17000446834856511528@ietfa.amsl.com> <78a36a81-3bb3-9d47-aa06-8da8f7594677@gmail.com> <C040E02F-7BEC-4FF9-8585-BE380B6859DE@consulintel.es> <alpine.DEB.2.02.1807191054090.7979@networking.stanford.edu> <9142206A0C5BF24CB22755C8EC422E459CB44344@AZ-US1EXMB03.global.avaya.com> <f1bc1848-abe0-553e-0fdf-623eb0d1a871@gmail.com> <9142206A0C5BF24CB22755C8EC422E459CB44E7E@AZ-US1EXMB03.global.avaya.com> <A82D3E92-C68D-4685-BD3D-6B2656F9A8A6@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DE872CA@GAALPA1MSGUSRBF.ITServices.sbc.com> <e4ac2192-e18b-9d64-c33a-79523d642e1d@gmail.com> To: Brian E Carpenter <brian.e.carpenter@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Thu, 30 Aug 2018 11:34:09 -0700 (PDT) Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/XZduQr1euqyzfw8o0bR2pqsDvhk> Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 30 Aug 2018 18:36:20 -0000 > On Aug 29, 2018, at 15:29 , Brian E Carpenter = <brian.e.carpenter@gmail.com> wrote: >=20 > Barbara, > On 2018-08-30 00:11, STARK, BARBARA H wrote: >>> My understanding, no hats and potentially incorrect, is that any ISP = I know of >>> will respond to a DHCPv6 IA_PD with a prefix at least as large as = requested, >>> up to /48. >>=20 >> I don't think this is correct. Of course, any provider using 6rd = won't respond to DHCPv6 at all. I'm aware of a lot of 6rd out there. >> Wireless LTE providers don't tend to support DHCPv6, either. The /64 = advertised by the RA in an LTE environment is all the LTE UE will get. = That includes the case where the LTE UE is supporting a fixed wireless = installation. >> For ISPs that support DHCPv6, it may or may not be the case. I've = heard several say they do, but I'm not aware of a survey of all ISPs = that would tell me how prevalent it is. I can guarantee you that it=E2=80=99s false in a big way = (unfortunately). Comcast=E2=80=99s victims (or customers, depending on = your perspective), for example, cannot get a /48 no matter what. IIRC, they will allow a business customer to get up to a /56 and = residential customers are limited to a /60. I believe they have or are in the process of resolving issues they = previously had where if you requested larger than they would allow, they = simply didn=E2=80=99t give you anything at all=E2=80=A6 Not even a = DENIED response. I wish they would fix this. When I discussed the matter last with JJMB, = his response was =E2=80=9Cwe don=E2=80=99t feel that=E2=80=99s = reasonable=E2=80=A6 If we were to do that, we=E2=80=99d have to ask ARIN = for a /12.=E2=80=9D My response was =E2=80=9Cduh!! You guys probably should have a /12. = It=E2=80=99s permitted under existing policy. So what=E2=80=99s the = issue?=E2=80=9D He simply shook his head and walked away. I=E2=80=99m guessing this will eventually be like Verizon=E2=80=99s = resistance to routing /48s. The v4think will eventually get sorted out, = but likely persist for some time first. >> BTW, I disagree with the abstract's statement that the "policy should = reflect that assignment of a single subnet is never appropriate." I do = not believe this takes into consideration the fact that it would be = tremendously expensive for some ISPs to replace their current equipment = when those current equipment vendors are being slow about supporting = certain features. Cost is always an appropriate consideration.=20 >=20 > I disagree. Yes, of course cost is always a consideration, but that = doesn't > make a lower case "should" inappropriate. I feel that there are actually cases where single-subnet assignment is = perfectly reasonable. They are limited and should be determined by the = customer, not the service provider, IMHO, but I also believe that all of = these decisions really are outside the purview of the IETF. The IETF = should be mandating that the standards for the equipment and the = protocol enable the service provider and the customer to handle multiple = subnets. Specifying operational behavior beyond that which is necessary = to enable the needed functionality is scope creep that we should try to = avoid. >> It also does not take into account CE routers that only request a = single /64.=20 >=20 > That's irrelevant. The customer might have bought such a router, but = the > next customer along might have bought a full homenet-supporting CE. That=E2=80=99s irrelevant. The protocol should enable the service = provider and customer to support either environment. We can make = operational best practice recommendations to offer more than one subnet, = but beyond that, we=E2=80=99re looking at the IETF putting its nose = where it doesn=E2=80=99t belong, IMHO. >> I think it's inappropriate for IETF to be trying to dictate what is = and isn't "appropriate". Recommending a best current practice is fine. = But that's not the same as saying something is "never appropriate". >=20 > Let's say "never recommended" then. Meh=E2=80=A6 I could live with that. Owen From nobody Thu Aug 30 12:26:48 2018 Return-Path: <dmudric@avaya.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA11130F0D for <v6ops@ietfa.amsl.com>; Thu, 30 Aug 2018 12:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 S6XyHI4766L5 for <v6ops@ietfa.amsl.com>; Thu, 30 Aug 2018 12:26:41 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.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 95ADC130F0A for <v6ops@ietf.org>; Thu, 30 Aug 2018 12:26:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GkAQB9Q4hb/yYyC4daDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCelWBUhIoCoNoiBGMK4INgz2FGI1UgXoLLIRAAheDDSE0GAE?= =?us-ascii?q?CAQEBAQEBAgICaSiFOAEBAQECARIREUUFBwQCAQgNBAQBAQECAgYgAgICHxEVC?= =?us-ascii?q?AgCBAENBQgahGkDDQgBmguJb4EuGgKHDw2CToELiQYXgUI+gViCHi6CVoISGBW?= =?us-ascii?q?CajGCJgKbEisJAoxhgymIXQOFcowIh1GBQTmBUnAVgySQGTpvAYEVinoBgRsBA?= =?us-ascii?q?Q?= X-IPAS-Result: =?us-ascii?q?A2GkAQB9Q4hb/yYyC4daDgsBAQEBAQEBAQEBAQEHAQEBAQG?= =?us-ascii?q?CelWBUhIoCoNoiBGMK4INgz2FGI1UgXoLLIRAAheDDSE0GAECAQEBAQEBAgICa?= =?us-ascii?q?SiFOAEBAQECARIREUUFBwQCAQgNBAQBAQECAgYgAgICHxEVCAgCBAENBQgahGk?= =?us-ascii?q?DDQgBmguJb4EuGgKHDw2CToELiQYXgUI+gViCHi6CVoISGBWCajGCJgKbEisJA?= =?us-ascii?q?oxhgymIXQOFcowIh1GBQTmBUnAVgySQGTpvAYEVinoBgRsBAQ?= X-IronPort-AV: E=Sophos;i="5.53,308,1531800000"; d="scan'208";a="301931333" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 30 Aug 2018 15:26:26 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC02.global.avaya.com) ([135.11.85.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Aug 2018 15:26:26 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC02.global.avaya.com ([::1]) with mapi id 14.03.0382.000; Thu, 30 Aug 2018 15:26:26 -0400 From: "Mudric, Dusan (Dusan)" <dmudric@avaya.com> To: Brian E Carpenter <brian.e.carpenter@gmail.com>, David Farmer <farmer@umn.edu> CC: "v6ops@ietf.org" <v6ops@ietf.org> Thread-Topic: [v6ops] Thinking about problems in IPv6-only networks Thread-Index: AQHUP9pJgyT9kwsoz02Ikgn5fOjK1aTXkVmAgAEaaMA= Date: Thu, 30 Aug 2018 19:26:26 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E459CB47368@AZ-US1EXMB03.global.avaya.com> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> <CAD6AjGQ_OBFGJb_C+mP_87nu7q_oXPrTvxhaV_=RcubeHtMy2Q@mail.gmail.com> <E345387F-6C1D-49D4-8B03-52D04498DDA5@lists.zabbadoz.net> <a9eeba1b-76dc-a69f-aabe-04fa4ddc3a4f@gmail.com> <e560c82c-085e-60fe-2076-70e3624696c0@asgard.org> <9142206A0C5BF24CB22755C8EC422E459CB46310@AZ-US1EXMB03.global.avaya.com> <76055AE4-FF87-47E1-988A-CDB7E157C6AD@delong.com> <9142206A0C5BF24CB22755C8EC422E459CB4644F@AZ-US1EXMB03.global.avaya.com> <CAN-Dau26+uOpa9+CSf5QGmbqbmW5UisM3zxitLv12pLWRmZ8rQ@mail.gmail.com> <f2d934cb-5075-fc1c-49d5-71d4613b3b9c@gmail.com> In-Reply-To: <f2d934cb-5075-fc1c-49d5-71d4613b3b9c@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Hu-fXoVmNmT8pXEICjU6k1WBzkI> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 30 Aug 2018 19:26:45 -0000 PiBFeGFjdGx5LiBXb3JraW5nIG91dCBvZiB0aGUgYm94IG9uIGFuIHVubWFuYWdlZCBuZXR3b3Jr IGhhcyBhbHdheXMgYmVlbg0KPiBhIGdvYWwgZm9yIElQdjYsDQpJIGV4cGVjdGVkIHBsdWctYW5k LXBsYXksIG9yIHVubWFuYWdlZCBuZXR3b3JrLCBtZWFucyBkZXZpY2VzIGRlcGxveWVkIHRvIHRo b3NlIG5ldHdvcmtzIHNob3VsZCB3b3JrIGJhc2VkIG9uIHRoZSBuZXR3b3JrIGRlZmF1bHRzLiBJ ZiBESENQdjYgaXMgYWRkZWQgdG8gdGhlIG5ldHdvcmssICdPJyBmbGFnIG5lZWRzIHRvIGJlIHNl dC4gVGhhdCBtZWFucyBtYW5hZ2luZyB0aGUgbmV0d29yay4NCg0KPiA+IElmIEkgZG9uJ3QgcHJv dmlkZSBhIERIQ1B2NiBJIHNob3VsZA0KPiA+IG5vdCBoYXZlIHRvIGRvIGFueXRoaW5nLg0KUmln aHQuIElmIG5vdGhpbmcgaXMgYWRkZWQgdG8gdGhlIG5ldHdvcmssIHRoZXJlIGlzIG5vIG5lZWQg dG8gY2hhbmdlIHRoZSBuZXR3b3JrIGNvbmZpZ3VyYXRpb24uIEJ1dCB0aGF0IGlzIG5vdCB0aGUg cG9pbnQuIFBsdWctYW5kLXBsYXkgaXMgdXNlZCB3aGVuIHNvbWV0aGluZyBpcyBhZGRlZCB0byB0 aGUgbmV0d29yay4gVGhlcmUgc2hvdWxkIG5vdCBiZSBhIG5lZWQgdG8gY2hhbmdlICdPJyBiaXQg d2hlbiBESENQdjYgc2VydmVyIGFuZCBESENQdjYgY2FwYWJsZSBob3N0cyBhcmUgYWRkZWQgdG8g dGhlIG5ldHdvcmsuIEFuZCwgaWYgdGhlcmUgYXJlIG5vIERIQ1B2NiBzZXJ2ZXJzIGFuZCBESENQ djYgY2FwYWJsZSBob3N0cyBpbiB0aGF0IG5ldHdvcmssIHNlbmRpbmcgJ08nPVRSVUUgd2lsbCBu b3QgaW1wYWN0ICB0aGUgbmV0d29yay4NCg0KRHVzYW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJAZ21h aWwuY29tPg0KPiBTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAyOSwgMjAxOCA2OjI0IFBNDQo+IFRv OiBEYXZpZCBGYXJtZXIgPGZhcm1lckB1bW4uZWR1PjsgTXVkcmljLCBEdXNhbiAoRHVzYW4pDQo+ IDxkbXVkcmljQGF2YXlhLmNvbT4NCj4gQ2M6IHY2b3BzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJl OiBbdjZvcHNdIFRoaW5raW5nIGFib3V0IHByb2JsZW1zIGluIElQdjYtb25seSBuZXR3b3Jrcw0K PiANCj4gT24gMjAxOC0wOC0zMCAwODo1MiwgRGF2aWQgRmFybWVyIHdyb3RlOg0KPiA+IE9uIFdl ZCwgQXVnIDI5LCAyMDE4IGF0IDM6MzcgUE0sIE11ZHJpYywgRHVzYW4gKER1c2FuKQ0KPiA8ZG11 ZHJpY0BhdmF5YS5jb20+DQo+ID4gd3JvdGU6DQo+ID4NCj4gPj4+IFRoZXkgY29udHJvbCB0aGUg ZGVmYXVsdHMgZm9yIGhvdyBSb3V0ZXJzIGNvbnN0cnVjdCBSb3V0ZXINCj4gPj4gQWR2ZXJ0aXNl bWVudHMuDQo+ID4+DQo+ID4+IEFuZCBkZWZhdWx0ICdPJyBmbGFnIHNldCB0byBUUlVFIHNob3Vs ZCBlbmFibGVkIHN0YXRlbGVzcyBESENQdjYgdG8NCj4gb2J0YWluDQo+ID4+IGNvbmZpZ3VyYXRp b24gZm9yIGhvc3RzLg0KPiA+DQo+ID4NCj4gPiBPbmx5IGlmIHRoZXJlIGlzLCBpbiBmYWN0LCBh IERIQ1B2NiBzZXJ2ZXIgYW5kIGl0IGlzIGNvbmZpZ3VyZWQgd2l0aA0KPiA+IGFwcHJvcHJpYXRl IGluZm9ybWF0aW9uLiAgTWF5YmUgeW91IHdpc2ggdG8gcmVjb21tZW5kIG5ldCBvcGVyYXRvcnMN Cj4gZGVwbG95DQo+ID4gREhDUHY2LCBidXQgY2hhbmdlIHRoZSBkZWZhdWx0IGZvciB0aGUgTyBm bGFnIGluIFJBcyBpcyBtb3JlIHRoYXQuDQo+ID4NCj4gPiBXaGlsZSBJIGNvdWxkIGJlIHN5bXBh dGhldGljIHRvIHJlY29tbWVuZGF0aW9ucyB0byBwcm92aWRlIERIQ1B2Ng0KPiBzZXJ2ZXJzDQo+ ID4gb24gbmV0d29ya3MuIEhvd2V2ZXIsIGNoYW5naW5nIHRoZSBkZWZhdWx0cyBmb3IgdGhlIE0g b3IgTyBmbGFncyBpcyBub3QNCj4gPiBzb21ldGhpbmcgSSBjYW4gc3VwcG9ydC4gIElmIEkgcHJv dmlkZSBhIERIQ1B2NiBzZXJ2ZXIgdGhlbiBpdCBpcyBteSBqb2IgdG8NCj4gPiBzZXQgdGhlIGZs YWdzIGFwcHJvcHJpYXRlbHkgaW4gdGhlIFJBLiBJZiBJIGRvbid0IHByb3ZpZGUgYSBESENQdjYg SSBzaG91bGQNCj4gPiBub3QgaGF2ZSB0byBkbyBhbnl0aGluZy4gVGhpcyBpcyBob3cgdGhlIGRl ZmF1bHRzIGZvciB0aGUgTSBhbmQgTyBmbGFnIGFyZQ0KPiA+IGN1cnJlbnRseSBzZXQuDQo+IA0K PiBFeGFjdGx5LiBXb3JraW5nIG91dCBvZiB0aGUgYm94IG9uIGFuIHVubWFuYWdlZCBuZXR3b3Jr IGhhcyBhbHdheXMgYmVlbg0KPiBhIGdvYWwgZm9yIElQdjYsIGV2ZW4gYmFjayB3aGVuIGl0IHdh cyBjYWxsZWQgSVBuZy4gVGhlIGRlZmF1bHRzIGFyZQ0KPiBzZXQgYXBwcm9wcmlhdGVseSBmb3Ig dGhhdCBnb2FsLg0KPiANCj4gICAgICBCcmlhbg0K From nobody Thu Aug 30 13:30:52 2018 Return-Path: <brian.e.carpenter@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34411130EA2; Thu, 30 Aug 2018 13:30:50 -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 P1xfvw4NKxtf; Thu, 30 Aug 2018 13:30:48 -0700 (PDT) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 166F6130E9C; Thu, 30 Aug 2018 13:30:48 -0700 (PDT) Received: by mail-pg1-x535.google.com with SMTP id 2-v6so3872749pgo.4; Thu, 30 Aug 2018 13:30:48 -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=USl8o1kkwuSgKve7CqhLQeSWvHohgK26oFIBAGTaICw=; b=d2fgu/ZcSUCFIXej6DCQxhnCR86jRCE8BRzptWsHfdJpRQYy9nf/pu8kcXYHgIaE13 pXIZG+/kwgJ9oY52lftEl/zxIfs9UuwF7+AoEiaDdGnKg7e2cAXK6VSPEgaCvVnjL3Y2 F39lE2uiXoypPoG+JZY1/9bejohipRoTp2nuRHpsIjx9PKvOyLmFCzQnAJd3MwD2VxqA 9J7ggX2nKuQPlWZiMnJEiqthAMR6qG7ifGyXY9Dx15OShGCvnr6PW6XqsC7VJu7lZqDJ noM3SMS//LNBIC82DW4cXuKljMltxSwx7G6XXFd9srNiTqPvKWZTwVFtTQ/1X2G9gloh Ivnw== 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=USl8o1kkwuSgKve7CqhLQeSWvHohgK26oFIBAGTaICw=; b=XrWTUjuY4KQcxnCaBgPS7o+nPWuKTC2pRXOhChvckNtKZljefAMn0iQ+mpR9iW2yH4 lLa/OBfHVwQqpcaTdxdjWDRz5dtmEqCSTH3OyPvhlrlquuWuxUa2Kyl165pxUfIUcFrx vsvdBU11xKv682mc9BTob51ClbcXUfP2Mbpqhg01U3g21dMF0W1CwKCkHTiYHZC62fso BHxU7CRALrx6WhtuFbaZPWKWmrw+U93MnDo0R7VThZCYU3z5SlTrLQZu3glUe9OUkbqv LhwVyXzqelX5K8+aPCxFc/Unp1LVYZwrENFEC6YXvdvkFqAvt9YfX+JrONwCY07kWcz6 UE2g== X-Gm-Message-State: APzg51BY5YC+jFIZ4Nzy4KnA+7FqYmTBsohjJMtC/PvqiZ/3fgyCRyow fNkSArFKhy6BXiYrFmslnts= X-Google-Smtp-Source: ANB0VdaFYWbKDa5fIcfyAd2cecRkZNssHljJNaDj+hgSrL8Q9LfqOGCLAha7ptj/6njvMI7wMW/JCQ== X-Received: by 2002:aa7:818f:: with SMTP id g15-v6mr12096419pfi.71.1535661047598; Thu, 30 Aug 2018 13:30:47 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id l127-v6sm11510591pfc.55.2018.08.30.13.30.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Aug 2018 13:30:46 -0700 (PDT) To: Owen DeLong <owen@delong.com> Cc: "STARK, BARBARA H" <bs7652@att.com>, Fred Baker <fredbaker.ietf@gmail.com>, "Mudric, Dusan (Dusan)" <dmudric@avaya.com>, "draft-palet-v6ops-rfc6177-bis@ietf.org" <draft-palet-v6ops-rfc6177-bis@ietf.org>, IPv6 Operations <v6ops@ietf.org>, JORDI PALET MARTINEZ <jordi.palet=40consulintel.es@dmarc.ietf.org> References: <153017691583.14743.17000446834856511528@ietfa.amsl.com> <78a36a81-3bb3-9d47-aa06-8da8f7594677@gmail.com> <C040E02F-7BEC-4FF9-8585-BE380B6859DE@consulintel.es> <alpine.DEB.2.02.1807191054090.7979@networking.stanford.edu> <9142206A0C5BF24CB22755C8EC422E459CB44344@AZ-US1EXMB03.global.avaya.com> <f1bc1848-abe0-553e-0fdf-623eb0d1a871@gmail.com> <9142206A0C5BF24CB22755C8EC422E459CB44E7E@AZ-US1EXMB03.global.avaya.com> <A82D3E92-C68D-4685-BD3D-6B2656F9A8A6@gmail.com> <2D09D61DDFA73D4C884805CC7865E6114DE872CA@GAALPA1MSGUSRBF.ITServices.sbc.com> <e4ac2192-e18b-9d64-c33a-79523d642e1d@gmail.com> <2825C26D-3AF8-430C-90A8-C33ABF036C10@delong.com> From: Brian E Carpenter <brian.e.carpenter@gmail.com> Message-ID: <75b9afb7-f0f1-bf2b-1957-428bebe24108@gmail.com> Date: Fri, 31 Aug 2018 08:30:40 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <2825C26D-3AF8-430C-90A8-C33ABF036C10@delong.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/wpZy2JnKNIcrnNu6c4YsF0DXuQw> Subject: Re: [v6ops] I-D Action: draft-palet-v6ops-rfc6177-bis-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 30 Aug 2018 20:30:50 -0000 Owen, On 2018-08-31 06:34, Owen DeLong wrote: >=20 >=20 >> On Aug 29, 2018, at 15:29 , Brian E Carpenter <brian.e.carpenter@gmail= =2Ecom> wrote: >> >> Barbara, >> On 2018-08-30 00:11, STARK, BARBARA H wrote: >>>> My understanding, no hats and potentially incorrect, is that any ISP= I know of >>>> will respond to a DHCPv6 IA_PD with a prefix at least as large as re= quested, >>>> up to /48. >>> >>> I don't think this is correct. Of course, any provider using 6rd won'= t respond to DHCPv6 at all. I'm aware of a lot of 6rd out there. >>> Wireless LTE providers don't tend to support DHCPv6, either. The /64 = advertised by the RA in an LTE environment is all the LTE UE will get. Th= at includes the case where the LTE UE is supporting a fixed wireless inst= allation. >>> For ISPs that support DHCPv6, it may or may not be the case. I've hea= rd several say they do, but I'm not aware of a survey of all ISPs that wo= uld tell me how prevalent it is. >=20 > I can guarantee you that it=E2=80=99s false in a big way (unfortunately= ). Comcast=E2=80=99s victims (or customers, depending on your perspective= ), for example, cannot get a /48 no matter what. >=20 > IIRC, they will allow a business customer to get up to a /56 and reside= ntial customers are limited to a /60. >=20 > I believe they have or are in the process of resolving issues they prev= iously had where if you requested larger than they would allow, they simp= ly didn=E2=80=99t give you anything at all=E2=80=A6 Not even a DENIED res= ponse. >=20 > I wish they would fix this. When I discussed the matter last with JJMB,= his response was =E2=80=9Cwe don=E2=80=99t feel that=E2=80=99s reasonabl= e=E2=80=A6 If we were to do that, we=E2=80=99d have to ask ARIN for a /12= =2E=E2=80=9D >=20 > My response was =E2=80=9Cduh!! You guys probably should have a /12. It=E2= =80=99s permitted under existing policy. So what=E2=80=99s the issue?=E2=80= =9D He simply shook his head and walked away. >=20 > I=E2=80=99m guessing this will eventually be like Verizon=E2=80=99s res= istance to routing /48s. The v4think will eventually get sorted out, but = likely persist for some time first. >=20 >>> BTW, I disagree with the abstract's statement that the "policy should= reflect that assignment of a single subnet is never appropriate." I do n= ot believe this takes into consideration the fact that it would be tremen= dously expensive for some ISPs to replace their current equipment when th= ose current equipment vendors are being slow about supporting certain fea= tures. Cost is always an appropriate consideration.=20 >> >> I disagree. Yes, of course cost is always a consideration, but that do= esn't >> make a lower case "should" inappropriate. >=20 > I feel that there are actually cases where single-subnet assignment is = perfectly reasonable. They are limited and should be determined by the cu= stomer, not the service provider, IMHO, but I also believe that all of th= ese decisions really are outside the purview of the IETF. The IETF should= be mandating that the standards for the equipment and the protocol enabl= e the service provider and the customer to handle multiple subnets. Speci= fying operational behavior beyond that which is necessary to enable the n= eeded functionality is scope creep that we should try to avoid. >=20 >>> It also does not take into account CE routers that only request a sin= gle /64.=20 >> >> That's irrelevant. The customer might have bought such a router, but t= he >> next customer along might have bought a full homenet-supporting CE. >=20 > That=E2=80=99s irrelevant. The protocol should enable the service provi= der and customer to support either environment. That's what I meant. If some customers only request a /64, and others req= uest a /48 (because they happened to buy different CE boxes), either should wo= rk. > We can make operational best practice recommendations to offer more tha= n one subnet, but beyond that, we=E2=80=99re looking at the IETF putting = its nose where it doesn=E2=80=99t belong, IMHO. I think the IETF can say "/56 is inadequate for some customers. /48 is ad= equate for most customers." Of course, we can't dictate terms to ISPs, and neith= er can the RIRs. >>> I think it's inappropriate for IETF to be trying to dictate what is a= nd isn't "appropriate". Recommending a best current practice is fine. But= that's not the same as saying something is "never appropriate". >> >> Let's say "never recommended" then. >=20 > Meh=E2=80=A6 I could live with that. OK then ;-) Regards Brian >=20 > Owen >=20 >=20 From nobody Thu Aug 30 17:18:51 2018 Return-Path: <owen@delong.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4C7130F55 for <v6ops@ietfa.amsl.com>; Thu, 30 Aug 2018 17:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.1 X-Spam-Level: X-Spam-Status: No, score=-6.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, 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 gtD43RgUNqOe for <v6ops@ietfa.amsl.com>; Thu, 30 Aug 2018 17:18:47 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id D6CD6130DC4 for <v6ops@ietf.org>; Thu, 30 Aug 2018 17:18:46 -0700 (PDT) Received: from [IPv6:2607:fb90:363f:2ace:65ed:5c35:d7a:5534] ([IPv6:2607:fb90:363f:2ace:65ed:5c35:d7a:5534]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id w7V0HVGL015928 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Aug 2018 17:17:37 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com w7V0HVGL015928 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: Owen DeLong <owen@delong.com> Mime-Version: 1.0 (1.0) Date: Thu, 30 Aug 2018 17:17:05 -0700 Message-Id: <5BECF927-9AD4-49A4-BBF7-4D590F0F557C@delong.com> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> <CAD6AjGQ_OBFGJb_C+mP_87nu7q_oXPrTvxhaV_=RcubeHtMy2Q@mail.gmail.com> <E345387F-6C1D-49D4-8B03-52D04498DDA5@lists.zabbadoz.net> <a9eeba1b-76dc-a69f-aabe-04fa4ddc3a4f@gmail.com> <e560c82c-085e-60fe-2076-70e3624696c0@asgard.org> <9142206A0C5BF24CB22755C8EC422E459CB46310@AZ-US1EXMB03.global.avaya.com> <76055AE4-FF87-47E1-988A-CDB7E157C6AD@delong.com> <9142206A0C5BF24CB22755C8EC422E459CB4644F@AZ-US1EXMB03.global.avaya.com> <CAN-Dau26+uOpa9+CSf5QGmbqbmW5UisM3zxitLv12pLWRmZ8rQ@mail.gmail.com> <f2d934cb-5075-fc1c-49d5-71d4613b3b9c@gmail.com> <9142206A0C5BF24CB22755C8EC422E459CB47368@AZ-US1EXMB03.global.avaya.com> Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, David Farmer <farmer@umn.edu>, "v6ops@ietf.org" <v6ops@ietf.org> In-Reply-To: <9142206A0C5BF24CB22755C8EC422E459CB47368@AZ-US1EXMB03.global.avaya.com> To: "Mudric, Dusan (Dusan)" <dmudric@avaya.com> X-Mailer: iPhone Mail (15G77) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Thu, 30 Aug 2018 17:17:43 -0700 (PDT) Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/BgLR9mzawBgE8aYaKEODZFpAwrk> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 31 Aug 2018 00:18:50 -0000 On Aug 30, 2018, at 12:26, Mudric, Dusan (Dusan) <dmudric@avaya.com> wrote: >> Exactly. Working out of the box on an unmanaged network has always been >> a goal for IPv6, > I expected plug-and-play, or unmanaged network, means devices deployed to t= hose networks should work based on the network defaults. If DHCPv6 is added t= o the network, 'O' flag needs to be set. That means managing the network. >=20 >>> If I don't provide a DHCPv6 I should >>> not have to do anything. > Right. If nothing is added to the network, there is no need to change the n= etwork configuration. But that is not the point. Plug-and-play is used when s= omething is added to the network. There should not be a need to change 'O' b= it when DHCPv6 server and DHCPv6 capable hosts are added to the network. And= , if there are no DHCPv6 servers and DHCPv6 capable hosts in that network, s= ending 'O'=3DTRUE will not impact the network. You are badly mistaken.=20 The O flag will cause hosts to seek information from a DHCPv6 server, hangin= g (possibly indefinitely) until that information is received. If there is no= DHCPv6 server available to provide that information, you have now broken th= e network by changing the O flag without any reason to do so.=20 Owen >=20 > Dusan >=20 >> -----Original Message----- >> From: Brian E Carpenter <brian.e.carpenter@gmail.com> >> Sent: Wednesday, August 29, 2018 6:24 PM >> To: David Farmer <farmer@umn.edu>; Mudric, Dusan (Dusan) >> <dmudric@avaya.com> >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks >>=20 >>> On 2018-08-30 08:52, David Farmer wrote: >>> On Wed, Aug 29, 2018 at 3:37 PM, Mudric, Dusan (Dusan) >> <dmudric@avaya.com> >>> wrote: >>>=20 >>>>> They control the defaults for how Routers construct Router >>>> Advertisements. >>>>=20 >>>> And default 'O' flag set to TRUE should enabled stateless DHCPv6 to >> obtain >>>> configuration for hosts. >>>=20 >>>=20 >>> Only if there is, in fact, a DHCPv6 server and it is configured with >>> appropriate information. Maybe you wish to recommend net operators >> deploy >>> DHCPv6, but change the default for the O flag in RAs is more that. >>>=20 >>> While I could be sympathetic to recommendations to provide DHCPv6 >> servers >>> on networks. However, changing the defaults for the M or O flags is not >>> something I can support. If I provide a DHCPv6 server then it is my job= to >>> set the flags appropriately in the RA. If I don't provide a DHCPv6 I sho= uld >>> not have to do anything. This is how the defaults for the M and O flag a= re >>> currently set. >>=20 >> Exactly. Working out of the box on an unmanaged network has always been >> a goal for IPv6, even back when it was called IPng. The defaults are >> set appropriately for that goal. >>=20 >> Brian > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Aug 30 18:23:20 2018 Return-Path: <rajiva@cisco.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37FB6130DF5 for <v6ops@ietfa.amsl.com>; Thu, 30 Aug 2018 18:23:19 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 IdGnDcc61lVy for <v6ops@ietfa.amsl.com>; Thu, 30 Aug 2018 18:23:16 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABEDF130DF4 for <v6ops@ietf.org>; Thu, 30 Aug 2018 18:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29907; q=dns/txt; s=iport; t=1535678596; x=1536888196; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MsX52sr7L851lpJz7GnJT7TNCVO6+yd08fp60xb8lQE=; b=I1ASnFLjLPIH/bmGWEwHlZ23TSM7S2oPiBBEwh0EVdBltJGmpI3yoONa tGdwNeYYIg94kOvFVRnWiD/RPGo0aJdnp2a/4xCPK4jqjidxCl6RT4aKi vGSuIuXB8z1hmVqiJzUvT4fAArvb+gKxAeRPDyeP6FSRzU8+TNoI3pi6p 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CbAADHl4hb/4QNJK1aGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYMgL2V/KINyiBGOEyWIVY1UFIFmCxgBCoFUgnUCF4MMITQ?= =?us-ascii?q?YAQIBAQIBAQJtHAyFOAIBAwEBIUsLEAIBCD8DAgICHwYLFBECBA4FGwODAwG?= =?us-ascii?q?BHUwDFQ+icYEuhC0BPYI9DYJOiHaBGxeBQT8mbCcME4IeLoJWRQEBAgGBIkw?= =?us-ascii?q?HFRKCQzGCJgKHcAgBGYUBhVSIKysJAoYxd4U5dIIeF4E/jROLJGSHKgIRFIE?= =?us-ascii?q?kHTiBUnAVOyoBgj4JhnOEGYU+b40hCwEB?= X-IronPort-AV: E=Sophos;i="5.53,309,1531785600"; d="scan'208,217";a="165141633" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Aug 2018 01:23:15 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id w7V1NFbh031368 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 31 Aug 2018 01:23:15 GMT Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 30 Aug 2018 20:23:14 -0500 Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1367.000; Thu, 30 Aug 2018 20:23:14 -0500 From: "Rajiv Asati (rajiva)" <rajiva@cisco.com> To: Fred Baker <fredbaker.ietf@gmail.com> CC: "Alejandro D'Egidio" <adegidio@telecentro.net.ar>, "v6ops@ietf.org list" <v6ops@ietf.org> Thread-Topic: [v6ops] Thinking about problems in IPv6-only networks Thread-Index: AQHUOWLCjEhXMdULFEa2AVlIRAaJcaTKw5WAgA5cBi0= Date: Fri, 31 Aug 2018 01:23:14 +0000 Message-ID: <7A8DE6A6-9444-4160-B981-F92D9A0550A0@cisco.com> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <3BE77332-B5FA-48F3-B881-45F60DA6643B@consulintel.es> <87CD2261-3226-47FA-BE60-ED0924B68A07@gmail.com> <58654503.37560057.1534864882045.JavaMail.zimbra@telecentro.net.ar>, <8643A800-7A79-4D5A-A584-E719294F3530@gmail.com> In-Reply-To: <8643A800-7A79-4D5A-A584-E719294F3530@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_7A8DE6A694444160B981F92D9A0550A0ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/9aBaETRpDP3gxENmEEjJJHoAWcM> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 31 Aug 2018 01:23:19 -0000 --_000_7A8DE6A694444160B981F92D9A0550A0ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWN0dWFsbHksIG5vLiBSRkMgNTM0MCAoT1NQRiBmb3IgSVB2NiwgYWthIE9TUEZ2Mykgc3BlY2lm aWVzIHRoYXQgcm91dGVyIGlkcyBhbmQgbHNpZHMgcmVtYWluIDMyIGJpdHMgYXMgaW4gdGhlIElQ djQgY2FzZSwgYnV0IGRvZXMgbm90IHNwZWNpZnkgdGhhdCB0aGV5IGFyZSBJUHY0IGFkZHJlc3Nl cy4NCg0KRGl0dG8uIEFuZCBTYW1lIGJlaGF2aW9yIGZvciBCR1AgYW5kIExEUCBhcyB3ZWxsLg0K aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1NTIjc2VjdGlvbi00DQoNCkNoZWVycywN ClJhaml2IEFzYXRpDQpEaXN0aW5ndWlzaGVkIEVuZ2luZWVyLCBDaXNjbyBTZXJ2aWNlcw0KDQoN Ck9uIEF1ZyAyMSwgMjAxOCwgYXQgMToxMCBQTSwgRnJlZCBCYWtlciA8ZnJlZGJha2VyLmlldGZA Z21haWwuY29tPG1haWx0bzpmcmVkYmFrZXIuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCg0KDQoN Ck9uIEF1ZyAyMSwgMjAxOCwgYXQgODoyMSBBTSwgQWxlamFuZHJvIEQnRWdpZGlvIDxhZGVnaWRp b0B0ZWxlY2VudHJvLm5ldC5hcjxtYWlsdG86YWRlZ2lkaW9AdGVsZWNlbnRyby5uZXQuYXI+PiB3 cm90ZToNCg0KSGVsbG8gRnJlZCwNCkZpcnN0IGF0IGFsbCwgSSB0aGluayBpdCBjb3VsZCBiZSBh IGdvb2QgZGlzY3Vzc2lvbiBhbmQgSSB3b3VsZCBsaWtlIHRvIGhlbHAgd2l0aCBhbnl0aGluZyBJ IGNhbi4NCkkgdGhpbmsgdGhlICJJcHY2LW9ubHkgbmV0d29ya3MiIGlzIHRvbyBtYXRjaCBnZW5l cmFsLCBidXQgSSB0aGluayBhbHNvIGl0IGNvdWxkIGJlIHRoZSBpbnRlbnRpb24sIHJpZ2h0Pw0K DQpJdCBtYXkgYmUgdG9vIGdlbmVyYWwuDQoNClNvLCBmcm9tIElTUCBwb2ludCBvZiB2aWV3IHdl IG5vcm1hbGx5IHRhbGsgYWJvdXQgSVB2NiBuZXR3b3JrcyB0aGlua2luZyBvZiBmaW5hbCB1c2Vy cyAocmVzaWRlbnRpYWwgY3VzdG9tZXJzKSBvIGFjY2VzcyBuZXR3b3JrcyBidXQgdGhlcmUgYXJl IG90aGVyIHBhcnRzOg0KLUNPUkU6IEFzIHdlIG5vcm1hbGx5IGhhdmUgYSBNUExTIE5ldHdvcmss IHdlIGp1c3QgdHJhbnNwb3J0IElQdjYgYXMgYSBwYXJ0IG9mIEludGVybmV0ICJzZXJ2aWNlIiBi dXQgd2Ugc3RpbGwgaGF2ZSBhbiBJUHY0IENvcmUgKElHUCwgTVAtQkdQLCBJRHMsIGV0YykuIERl cGVuZGluZyBvbiBkZXZpY2VzIGFuZCBzb2Z0d2FyZSByZWxlYXNlcyB3ZSBjYW4gZG8gbW9yZSBv ciBsZXNzIHRoaW5ncy4gU29tZXRoaW5nIHZlcnkgc2ltcGxlLCBpbiBPU1BGdjMgcm91dGVyLWlk IGlzIElQdjQNCg0KQWN0dWFsbHksIG5vLiBSRkMgNTM0MCAoT1NQRiBmb3IgSVB2NiwgYWthIE9T UEZ2Mykgc3BlY2lmaWVzIHRoYXQgcm91dGVyIGlkcyBhbmQgbHNpZHMgcmVtYWluIDMyIGJpdHMg YXMgaW4gdGhlIElQdjQgY2FzZSwgYnV0IGRvZXMgbm90IHNwZWNpZnkgdGhhdCB0aGV5IGFyZSBJ UHY0IGFkZHJlc3Nlcy4gRXZlbiBpbiBPU1BGdjIsIG1hbnkgaW1wbGVtZW50YXRpb25zIHVzZSBv bmUgb2YgdGhlIElQdjQgYWRkcmVzc2VzIG9mIGEgc3lzdGVtIGJ5IGRlZmF1bHQsIGJ1dCB0aGUg cHJvdG9jb2wgc2ltcGx5IHNwZWNpZmllcyBhIDMyIGJpdCBudW1iZXIuDQoNCi1Qcm92aXNpb25p bmc6IFdlIG5vcm1hbGx5IHByZXBhcmUgdGhlIHByb3Zpc2lvbmluZyBzeXN0ZW0gdG8gcHJvdmlk ZSBJUHY2IHRvIGN1c3RvbWVycyBhbmQgQ1BFcyBidXQgaXRzIGludGVybmFsIGluZnJhc3RydWN0 dXJlIGtlZXBzIGluIElQdjQuDQotVmlkZW86IEluIHRoZSB3b3JsZCBvZiBWaWRlbyAoaGVhZGVu ZCkgYXJlIHVzaW5nIG1vcmUgYW5kIG1vcmUgTXVsdGljYXN0IGJ1dCBpbiBJUHY0LCBtb3N0IG9m IGRldmljZXMgZG9uJ3QgZXZlbiBoYXZlIG9wdGlvbnMgZm9yIElQdjYuDQotTW9uaXRvcmluZyBh bmQgd29ya3N0YXRpb25zOiBJIGhhdmUgc2VlbiBzb21lIElQdjYgaW1wbGVtZW50YXRpb25zIGlu IElTUHMgdG8gcHJvdmlkZSBpdCB0byBpdHMgY3VzdG9tZXJzIHdpdGhvdXQgaGF2aW5nIElQdjYg aW4gdGhlaXIgb3duIFBDcyBhbmQgbW9uaXRvcmluZyBzeXN0ZW1zLiBGaXJld2FsbHMgYW5kIFZQ TnMgYXJlIGFsc28gaW5jbHVkZWQuDQoNClNvLCBvcGVyYXRpb25hbGx5LCB0aGVyZSBpcyBuZWl0 aGVyIGludGVudGlvbiBub3IgY2FwYWJpbGl0eSB0byB0dXJuIElQdjQgb2ZmIGV4Y2VwdCBhcyBh IHNlcnZpY2UuIENsb3NlPw0KDQpSZWdhcmRzLA0KQWxlamFuZHJvDQoNCi0tLS0tIE1lbnNhamUg b3JpZ2luYWwgLS0tLS0NCkRlOiAiRnJlZCBCYWtlciIgPGZyZWRiYWtlci5pZXRmQGdtYWlsLmNv bTxtYWlsdG86ZnJlZGJha2VyLmlldGZAZ21haWwuY29tPj4NClBhcmE6ICJKT1JESSBQQUxFVCBN QVJUSU5FWiIgPGpvcmRpLnBhbGV0QGNvbnN1bGludGVsLmVzPG1haWx0bzpqb3JkaS5wYWxldEBj b25zdWxpbnRlbC5lcz4+DQpDQzogInY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9y Zz4gbGlzdCIgPHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4+DQpFbnZpYWRv czogRG9taW5nbywgMTkgZGUgQWdvc3RvIDIwMTggMTM6Mjg6MzENCkFzdW50bzogUmU6IFt2Nm9w c10gVGhpbmtpbmcgYWJvdXQgcHJvYmxlbXMgaW4gSVB2Ni1vbmx5IG5ldHdvcmtzDQoNCkkgdGhp bmsgdGhpcyBpcyBzb21ldGhpbmcgdGhlIGRyYWZ0IG1pZ2h0IGRpc2N1c3MuIFRvIG1lLCAiSVB2 Ni1vbmx5IiBtZWFucyB0aGF0IHRoZSBvYmplY3QgaW4gcXVlc3Rpb24gaXMgdXNpbmcgb25seSBJ UHY2LiBJZiBpdCdzIGFuIGFwcGxpY2F0aW9uLCBpdCBkb2Vzbid0IGhhdmUgb3IgY2FuJ3QgdXNl IGFueXRoaW5nIGVsc2UuIElmIGl0J3MgYSBob3N0LCBpdCBkb2Vzbid0IGhhdmUgYW4gSVB2NCBh ZGRyZXNzLCB3aGV0aGVyIGl0IGNhbiB1c2Ugb25lIG9yIG5vdC4gSWYgaXQncyBhIG5ldHdvcmss IG9ubHkgSVB2NiBpcyBkZXBsb3llZCBpbiBpdC4gQXQgd2hhdGV2ZXIgc2NhbGUgaXMgdW5kZXIg ZGlzY3Vzc2lvbiwgSVB2NCBpcyBub3QgYSBmYWN0b3IgYW5kIElQdjYgaGFzIHJlcGxhY2VkIGl0 Lg0KDQpNYWtpbmcgaXQgbW9yZSBjb21wbGljYXRlZCB0aGFuIHRoYXQgZG9lc24ndCBoZWxwLCBJ TUhPLg0KDQpPbiBBdWcgMTcsIDIwMTgsIGF0IDY6MDkgUE0sIEpPUkRJIFBBTEVUIE1BUlRJTkVa IDxqb3JkaS5wYWxldEBjb25zdWxpbnRlbC5lczxtYWlsdG86am9yZGkucGFsZXRAY29uc3VsaW50 ZWwuZXM+PiB3cm90ZToNCg0KSGkgRnJlZCwNCg0KSSB3aWxsIGJlIGhhcHB5IHRvIGpvaW4sIGJ1 dCBmaXJzdCBJIHRoaW5rIHdlIG5lZWQgdG8gY2xhcmlmeSB3aGF0IGlzIElQdjYtb25seSBpbiB0 aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC93b3JrIC4uLg0KDQpBcmUgd2UgdGFsa2luZyBhYm91 dCBhIG5ldHdvcmsgdGhhdCBpbiB0aGUgImN1c3RvbWVyIiBMQU5zIGRvZXNuJ3QgaGF2ZSBBTlkg SVB2NCBhbmQgbmV2ZXIgY29ubmVjdHMgdG8gYW55ICJJUHY0LW9ubHkgcmVtb3RlIHNpdGUiLg0K DQpBcmUgdGhlIGFjY2VzcyBsaW5rcyBJUHY2LW9ubHkgPyBPciB0aGUgTEFOcyBhcmUgSVB2NiBv bmx5LCBidXQgdGhlIGFjY2VzcyBsaW5rcyBhcmUgZHVhbC1zdGFjaz8NCg0KT3IgdGhlIExBTidz IGRvbid0IGhhdmUgSVB2NCwgYnV0IGFwcHMsIHJ1bm5pbmcgSVB2NiBjYW4gY29ubmVjdCB0byBy ZW1vdGUgIklQdjQtb25seSBzaXRlcyIgKHNvIHRoZSBuZXR3b3JrIG9yIHRoZSBhY2Nlc3MgcHJv dmlkZXIpIGhhcyBhIE5BVDY0IG9yIGVxdWl2YWxlbnQgbWVjaGFuaXNtPw0KDQpJIHJlY2FsbCB3 ZSB0cmllZCB0byBjbGFyaWZ5IHRoaXMgZGVmaW5pdGlvbiBpbiBhIHByZXZpb3VzIGRvY3VtZW50 LCBhbmQgSSBzdGlsbCBzZWUgZXZlcnlib2R5IHJlYWRpbmcgZGlmZmVyZW50IHRoaW5ncyAuLi4N Cg0KUmVnYXJkcywNCkpvcmRpDQoNCg0KDQrvu78tLS0tLU1lbnNhamUgb3JpZ2luYWwtLS0tLQ0K RGU6IHY2b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp2Nm9wcy1ib3VuY2VzQGll dGYub3JnPj4gZW4gbm9tYnJlIGRlIEZyZWQgQmFrZXIgPGZyZWRiYWtlci5pZXRmQGdtYWlsLmNv bTxtYWlsdG86ZnJlZGJha2VyLmlldGZAZ21haWwuY29tPj4NCkZlY2hhOiB2aWVybmVzLCAxNyBk ZSBhZ29zdG8gZGUgMjAxOCwgMTM6MDYNClBhcmE6ICJ2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZv cHNAaWV0Zi5vcmc+IGxpc3QiIDx2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+ Pg0KQXN1bnRvOiBbdjZvcHNdIFRoaW5raW5nIGFib3V0IHByb2JsZW1zIGluIElQdjYtb25seSBu ZXR3b3Jrcw0KDQogUm9uIGFuZCBJIGp1c3QgaGFkIG91ciBiaS13ZWVrbHkgcGhvbmUgY2FsbCwg YW5kIGlkZW50aWZpZWQgYSB0b3BpYyB0aGF0IG1pZ2h0IGJlIGludGVyZXN0aW5nIGFuZCB1c2Vm dWwuIFdlJ2QgbGlrZSB0byBpbnZpdGUgYSBkcmFmdCBmcm9tIHBlb3BsZSB0aGF0IGFyZSBkZXBs b3lpbmcgSVB2Ni1vbmx5IG5ldHdvcmtzIG9yIHBhcnRzIG9mIG5ldHdvcmtzIGlkZW50aWZ5aW5n IHRoZSBwcm9ibGVtcyB0aGV5IGFyZSBleHBlcmllbmNpbmcgdGhhdCB0aGUgSUVURiBtaWdodCBi ZSBpbiBhIHBvc2l0aW9uIHRvIGFkZHJlc3MuIFRoZSBvYmplY3RpdmUsIGFzIGFsd2F5cywgaXMg dG8gc29sdmUgcHJvYmxlbXMgcHJldmVudGluZyBzdWNoIGEgZGVwbG95bWVudCBpbiB0aW1lIGZv ciB2ZW5kb3JzIGFuZCBvcGVuIHNvdXJjZSB0byBwcm92aWRlIHNvbHV0aW9ucy4NCiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KIFZpY3RvcmlvdXMgd2FycmlvcnMgd2luIGZpcnN0IGFuZCB0aGVu IGdvIHRvIHdhciwNCiBEZWZlYXRlZCB3YXJyaW9ycyBnbyB0byB3YXIgZmlyc3QgYW5kIHRoZW4g c2VlayB0byB3aW4uDQogICAgICBTdW4gVHp1DQoNCiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KIHY2b3BzIG1haWxpbmcgbGlzdA0KIHY2b3BzQGlldGYu b3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Y2b3BzDQoNCg0KDQoNCioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioNCklQdjQgaXMgb3Zlcg0KQXJlIHlvdSByZWFkeSBmb3IgdGhlIG5ldyBJ bnRlcm5ldCA/DQpodHRwOi8vd3d3LmNvbnN1bGludGVsLmVzDQpUaGUgSVB2NiBDb21wYW55DQoN ClRoaXMgZWxlY3Ryb25pYyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIG1heSBi ZSBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbC4gVGhlIGluZm9ybWF0aW9uIGlzIGludGVuZGVk IHRvIGJlIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbChzKSBuYW1lZCBh Ym92ZSBhbmQgZnVydGhlciBub24tZXhwbGljaWx0eSBhdXRob3JpemVkIGRpc2Nsb3N1cmUsIGNv cHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3Jt YXRpb24sIGV2ZW4gaWYgcGFydGlhbGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHN0 cmljdGx5IHByb2hpYml0ZWQgYW5kIHdpbGwgYmUgY29uc2lkZXJlZCBhIGNyaW1pbmFsIG9mZmVu c2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgYmUgYXdhcmUgdGhhdCBh bnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVu dHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgZXZlbiBpZiBwYXJ0aWFsbHksIGluY2x1ZGluZyBhdHRh Y2hlZCBmaWxlcywgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCwgd2lsbCBiZSBjb25zaWRlcmVkIGEg Y3JpbWluYWwgb2ZmZW5zZSwgc28geW91IG11c3QgcmVwbHkgdG8gdGhlIG9yaWdpbmFsIHNlbmRl ciB0byBpbmZvcm0gYWJvdXQgdGhpcyBjb21tdW5pY2F0aW9uIGFuZCBkZWxldGUgaXQuDQoNCg0K DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGUgZmFjdCB0aGF0IHRoZXJlIGlzIGEgaGln aHdheSB0byBoZWxsIGFuZCBhIHN0YWlyd2F5IHRvIGhlYXZlbiBpcyBhbiBpbnRlcmVzdGluZyBj b21tZW50IG9uIHByb2plY3RlZCB0cmFmZmljIHZvbHVtZS4uLg0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp2Nm9wcyBtYWlsaW5nIGxpc3QNCnY2 b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoZSBm YWN0IHRoYXQgdGhlcmUgaXMgYSBoaWdod2F5IHRvIGhlbGwgYW5kIGEgc3RhaXJ3YXkgdG8gaGVh dmVuIGlzIGFuIGludGVyZXN0aW5nIGNvbW1lbnQgb24gcHJvamVjdGVkIHRyYWZmaWMgdm9sdW1l Li4uDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQp2 Nm9wcyBtYWlsaW5nIGxpc3QNCnY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9wc0BpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== --_000_7A8DE6A694444160B981F92D9A0550A0ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjxzcGFuPjwvc3Bhbj48L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48 Zm9udCBjb2xvcj0iIzAwMDAwMCI+PHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwg MCk7IGJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij5BY3R1YWxseSwg bm8uIFJGQyA1MzQwIChPU1BGIGZvciBJUHY2LCBha2EgT1NQRnYzKSBzcGVjaWZpZXMgdGhhdCBy b3V0ZXIgaWRzIGFuZCBsc2lkcyByZW1haW4gMzIgYml0cyBhcyBpbiB0aGUgSVB2NCBjYXNlLCBi dXQgZG9lcw0KIG5vdCBzcGVjaWZ5IHRoYXQgdGhleSBhcmUgSVB2NCBhZGRyZXNzZXMuPC9zcGFu PjwvZm9udD48L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KRGl0dG8uIEFuZCBTYW1l IGJlaGF2aW9yIGZvciBCR1AgYW5kIExEUCBhcyB3ZWxsLiZuYnNwOzxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTUyI3NlY3Rpb24tNCI+aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzc1NTIjc2VjdGlvbi00PC9hPjxicj4NCjxicj4NCjxkaXYgaWQ9 IkFwcGxlTWFpbFNpZ25hdHVyZSI+Q2hlZXJzLA0KPGRpdj5SYWppdiBBc2F0aTwvZGl2Pg0KPGRp dj5EaXN0aW5ndWlzaGVkIEVuZ2luZWVyLCBDaXNjbyBTZXJ2aWNlczwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQpPbiBBdWcgMjEsIDIwMTgsIGF0IDE6MTAgUE0s IEZyZWQgQmFrZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpmcmVkYmFrZXIuaWV0ZkBnbWFpbC5jb20i PmZyZWRiYWtlci5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2PjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bh bj48L3NwYW4+PGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+T24gQXVnIDIxLCAy MDE4LCBhdCA4OjIxIEFNLCBBbGVqYW5kcm8gRCdFZ2lkaW8gJmx0OzxhIGhyZWY9Im1haWx0bzph ZGVnaWRpb0B0ZWxlY2VudHJvLm5ldC5hciI+YWRlZ2lkaW9AdGVsZWNlbnRyby5uZXQuYXI8L2E+ Jmd0OyB3cm90ZTo8L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+PHNwYW4+PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPjxzcGFuPkhlbGxvIEZyZWQsPC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPkZpcnN0IGF0IGFsbCwgSSB0aGluayBpdCBjb3VsZCBi ZSBhIGdvb2QgZGlzY3Vzc2lvbiBhbmQgSSB3b3VsZCBsaWtlIHRvIGhlbHAgd2l0aCBhbnl0aGlu ZyBJIGNhbi48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+PHNwYW4+SSB0aGluayB0aGUgJnF1b3Q7SXB2Ni1vbmx5IG5ldHdvcmtzJnF1b3Q7IGlzIHRv byBtYXRjaCBnZW5lcmFsLCBidXQgSSB0aGluayBhbHNvIGl0IGNvdWxkIGJlIHRoZSBpbnRlbnRp b24sIHJpZ2h0Pzwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8c3Bhbj48L3NwYW4+PGJyPg0K PHNwYW4+SXQgbWF5IGJlIHRvbyBnZW5lcmFsLjwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJy Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+U28sIGZyb20gSVNQIHBvaW50IG9mIHZp ZXcgd2Ugbm9ybWFsbHkgdGFsayBhYm91dCBJUHY2IG5ldHdvcmtzIHRoaW5raW5nIG9mIGZpbmFs IHVzZXJzIChyZXNpZGVudGlhbCBjdXN0b21lcnMpIG8gYWNjZXNzIG5ldHdvcmtzIGJ1dCB0aGVy ZSBhcmUgb3RoZXIgcGFydHM6PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPjxzcGFuPi1DT1JFOiBBcyB3ZSBub3JtYWxseSBoYXZlIGEgTVBMUyBOZXR3 b3JrLCB3ZSBqdXN0IHRyYW5zcG9ydCBJUHY2IGFzIGEgcGFydCBvZiBJbnRlcm5ldCAmcXVvdDtz ZXJ2aWNlJnF1b3Q7IGJ1dCB3ZSBzdGlsbCBoYXZlIGFuIElQdjQgQ29yZSAoSUdQLCBNUC1CR1As IElEcywgZXRjKS4gRGVwZW5kaW5nIG9uIGRldmljZXMgYW5kIHNvZnR3YXJlIHJlbGVhc2VzIHdl IGNhbiBkbyBtb3JlIG9yIGxlc3MgdGhpbmdzLg0KIFNvbWV0aGluZyB2ZXJ5IHNpbXBsZSwgaW4g T1NQRnYzIHJvdXRlci1pZCBpcyBJUHY0PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxzcGFu Pjwvc3Bhbj48YnI+DQo8c3Bhbj5BY3R1YWxseSwgbm8uIFJGQyA1MzQwIChPU1BGIGZvciBJUHY2 LCBha2EgT1NQRnYzKSBzcGVjaWZpZXMgdGhhdCByb3V0ZXIgaWRzIGFuZCBsc2lkcyByZW1haW4g MzIgYml0cyBhcyBpbiB0aGUgSVB2NCBjYXNlLCBidXQgZG9lcyBub3Qgc3BlY2lmeSB0aGF0IHRo ZXkgYXJlIElQdjQgYWRkcmVzc2VzLiBFdmVuIGluIE9TUEZ2MiwgbWFueSBpbXBsZW1lbnRhdGlv bnMgdXNlIG9uZSBvZiB0aGUgSVB2NCBhZGRyZXNzZXMgb2YgYSBzeXN0ZW0NCiBieSBkZWZhdWx0 LCBidXQgdGhlIHByb3RvY29sIHNpbXBseSBzcGVjaWZpZXMgYSAzMiBiaXQgbnVtYmVyLjwvc3Bh bj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+ LVByb3Zpc2lvbmluZzogV2Ugbm9ybWFsbHkgcHJlcGFyZSB0aGUgcHJvdmlzaW9uaW5nIHN5c3Rl bSB0byBwcm92aWRlIElQdjYgdG8gY3VzdG9tZXJzIGFuZCBDUEVzIGJ1dCBpdHMgaW50ZXJuYWwg aW5mcmFzdHJ1Y3R1cmUga2VlcHMgaW4gSVB2NC48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+LVZpZGVvOiBJbiB0aGUgd29ybGQgb2YgVmlk ZW8gKGhlYWRlbmQpIGFyZSB1c2luZyBtb3JlIGFuZCBtb3JlIE11bHRpY2FzdCBidXQgaW4gSVB2 NCwgbW9zdCBvZiBkZXZpY2VzIGRvbid0IGV2ZW4gaGF2ZSBvcHRpb25zIGZvciBJUHY2Ljwvc3Bh bj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4tTW9u aXRvcmluZyBhbmQgd29ya3N0YXRpb25zOiBJIGhhdmUgc2VlbiBzb21lIElQdjYgaW1wbGVtZW50 YXRpb25zIGluIElTUHMgdG8gcHJvdmlkZSBpdCB0byBpdHMgY3VzdG9tZXJzIHdpdGhvdXQgaGF2 aW5nIElQdjYgaW4gdGhlaXIgb3duIFBDcyBhbmQgbW9uaXRvcmluZyBzeXN0ZW1zLiBGaXJld2Fs bHMgYW5kIFZQTnMgYXJlIGFsc28gaW5jbHVkZWQuPC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4N CjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj5Tbywgb3BlcmF0aW9uYWxseSwgdGhlcmUgaXMgbmVp dGhlciBpbnRlbnRpb24gbm9yIGNhcGFiaWxpdHkgdG8gdHVybiBJUHY0IG9mZiBleGNlcHQgYXMg YSBzZXJ2aWNlLiBDbG9zZT88L3NwYW4+PGJyPg0KPHNwYW4+PC9zcGFuPjxicj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPjxzcGFuPlJlZ2FyZHMsPC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPkFsZWphbmRybzwvc3Bhbj48YnI+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+LS0tLS0gTWVuc2FqZSBv cmlnaW5hbCAtLS0tLTwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIj48c3Bhbj5EZTogJnF1b3Q7RnJlZCBCYWtlciZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOmZyZWRiYWtlci5pZXRmQGdtYWlsLmNvbSI+ZnJlZGJha2VyLmlldGZAZ21haWwuY29tPC9h PiZndDs8L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ PHNwYW4+UGFyYTogJnF1b3Q7Sk9SREkgUEFMRVQgTUFSVElORVomcXVvdDsgJmx0OzxhIGhyZWY9 Im1haWx0bzpqb3JkaS5wYWxldEBjb25zdWxpbnRlbC5lcyI+am9yZGkucGFsZXRAY29uc3VsaW50 ZWwuZXM8L2E+Jmd0Ozwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIj48c3Bhbj5DQzogJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52 Nm9wc0BpZXRmLm9yZzwvYT4gbGlzdCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGll dGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT4mZ3Q7PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPkVudmlhZG9zOiBEb21pbmdvLCAxOSBkZSBB Z29zdG8gMjAxOCAxMzoyODozMTwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj48c3Bhbj5Bc3VudG86IFJlOiBbdjZvcHNdIFRoaW5raW5nIGFib3V0IHBy b2JsZW1zIGluIElQdjYtb25seSBuZXR3b3Jrczwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+SSB0aGluayB0aGlzIGlzIHNvbWV0aGluZyB0 aGUgZHJhZnQgbWlnaHQgZGlzY3Vzcy4gVG8gbWUsICZxdW90O0lQdjYtb25seSZxdW90OyBtZWFu cyB0aGF0IHRoZSBvYmplY3QgaW4gcXVlc3Rpb24gaXMgdXNpbmcgb25seSBJUHY2LiBJZiBpdCdz IGFuIGFwcGxpY2F0aW9uLCBpdCBkb2Vzbid0IGhhdmUgb3IgY2FuJ3QgdXNlIGFueXRoaW5nIGVs c2UuIElmIGl0J3MgYSBob3N0LCBpdCBkb2Vzbid0IGhhdmUgYW4NCiBJUHY0IGFkZHJlc3MsIHdo ZXRoZXIgaXQgY2FuIHVzZSBvbmUgb3Igbm90LiBJZiBpdCdzIGEgbmV0d29yaywgb25seSBJUHY2 IGlzIGRlcGxveWVkIGluIGl0LiBBdCB3aGF0ZXZlciBzY2FsZSBpcyB1bmRlciBkaXNjdXNzaW9u LCBJUHY0IGlzIG5vdCBhIGZhY3RvciBhbmQgSVB2NiBoYXMgcmVwbGFjZWQgaXQuPC9zcGFuPjxi cj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48 YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5NYWtpbmcg aXQgbW9yZSBjb21wbGljYXRlZCB0aGFuIHRoYXQgZG9lc24ndCBoZWxwLCBJTUhPLjwvc3Bhbj48 YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+ PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj48c3Bhbj5PbiBBdWcgMTcsIDIwMTgsIGF0IDY6MDkgUE0sIEpPUkRJIFBB TEVUIE1BUlRJTkVaICZsdDs8YSBocmVmPSJtYWlsdG86am9yZGkucGFsZXRAY29uc3VsaW50ZWwu ZXMiPmpvcmRpLnBhbGV0QGNvbnN1bGludGVsLmVzPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxicj4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+PHNwYW4+SGkgRnJlZCw8L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij48c3Bhbj48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5JIHdpbGwg YmUgaGFwcHkgdG8gam9pbiwgYnV0IGZpcnN0IEkgdGhpbmsgd2UgbmVlZCB0byBjbGFyaWZ5IHdo YXQgaXMgSVB2Ni1vbmx5IGluIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50L3dvcmsgLi4uPC9z cGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+QXJlIHdlIHRhbGtpbmcgYWJvdXQgYSBuZXR3b3JrIHRo YXQgaW4gdGhlICZxdW90O2N1c3RvbWVyJnF1b3Q7IExBTnMgZG9lc24ndCBoYXZlIEFOWSBJUHY0 IGFuZCBuZXZlciBjb25uZWN0cyB0byBhbnkgJnF1b3Q7SVB2NC1vbmx5IHJlbW90ZSBzaXRlJnF1 b3Q7Ljwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPkFyZSB0aGUgYWNjZXNzIGxpbmtzIElQdjYt b25seSA/IE9yIHRoZSBMQU5zIGFyZSBJUHY2IG9ubHksIGJ1dCB0aGUgYWNjZXNzIGxpbmtzIGFy ZSBkdWFsLXN0YWNrPzwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwv c3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPk9yIHRoZSBMQU4ncyBkb24n dCBoYXZlIElQdjQsIGJ1dCBhcHBzLCBydW5uaW5nIElQdjYgY2FuIGNvbm5lY3QgdG8gcmVtb3Rl ICZxdW90O0lQdjQtb25seSBzaXRlcyZxdW90OyAoc28gdGhlIG5ldHdvcmsgb3IgdGhlIGFjY2Vz cyBwcm92aWRlcikgaGFzIGEgTkFUNjQgb3IgZXF1aXZhbGVudCBtZWNoYW5pc20/PC9zcGFuPjxi cj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+PHNwYW4+SSByZWNhbGwgd2UgdHJpZWQgdG8gY2xhcmlmeSB0aGlzIGRlZmlu aXRpb24gaW4gYSBwcmV2aW91cyBkb2N1bWVudCwgYW5kIEkgc3RpbGwgc2VlIGV2ZXJ5Ym9keSBy ZWFkaW5nIGRpZmZlcmVudCB0aGluZ3MgLi4uPC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+PHNwYW4+PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+UmVn YXJkcyw8L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5Kb3JkaTwvc3Bh bj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi PjxzcGFuPjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPu+7vy0tLS0t TWVuc2FqZSBvcmlnaW5hbC0tLS0tPC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ PHNwYW4+RGU6IHY2b3BzICZsdDs8YSBocmVmPSJtYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9y ZyI+djZvcHMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IGVuIG5vbWJyZSBkZSBGcmVkIEJha2Vy ICZsdDs8YSBocmVmPSJtYWlsdG86ZnJlZGJha2VyLmlldGZAZ21haWwuY29tIj5mcmVkYmFrZXIu aWV0ZkBnbWFpbC5jb208L2E+Jmd0Ozwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi PjxzcGFuPkZlY2hhOiB2aWVybmVzLCAxNyBkZSBhZ29zdG8gZGUgMjAxOCwgMTM6MDY8L3NwYW4+ PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5QYXJhOiAmcXVvdDs8YSBocmVmPSJt YWlsdG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPiBsaXN0JnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPiZndDs8L3Nw YW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj5Bc3VudG86IFt2Nm9wc10gVGhp bmtpbmcgYWJvdXQgcHJvYmxlbXMgaW4gSVB2Ni1vbmx5IG5ldHdvcmtzPC9zcGFuPjxicj4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+PHNwYW4+Jm5ic3A7Um9uIGFuZCBJIGp1c3QgaGFkIG91ciBiaS13ZWVrbHkgcGhvbmUg Y2FsbCwgYW5kIGlkZW50aWZpZWQgYSB0b3BpYyB0aGF0IG1pZ2h0IGJlIGludGVyZXN0aW5nIGFu ZCB1c2VmdWwuIFdlJ2QgbGlrZSB0byBpbnZpdGUgYSBkcmFmdCBmcm9tIHBlb3BsZSB0aGF0IGFy ZSBkZXBsb3lpbmcgSVB2Ni1vbmx5IG5ldHdvcmtzIG9yIHBhcnRzIG9mIG5ldHdvcmtzIGlkZW50 aWZ5aW5nIHRoZSBwcm9ibGVtcw0KIHRoZXkgYXJlIGV4cGVyaWVuY2luZyB0aGF0IHRoZSBJRVRG IG1pZ2h0IGJlIGluIGEgcG9zaXRpb24gdG8gYWRkcmVzcy4gVGhlIG9iamVjdGl2ZSwgYXMgYWx3 YXlzLCBpcyB0byBzb2x2ZSBwcm9ibGVtcyBwcmV2ZW50aW5nIHN1Y2ggYSBkZXBsb3ltZW50IGlu IHRpbWUgZm9yIHZlbmRvcnMgYW5kIG9wZW4gc291cmNlIHRvIHByb3ZpZGUgc29sdXRpb25zLjwv c3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPiZuYnNwOy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+Jm5i c3A7VmljdG9yaW91cyB3YXJyaW9ycyB3aW4gZmlyc3QgYW5kIHRoZW4gZ28gdG8gd2FyLDwvc3Bh bj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPiZuYnNwO0RlZmVhdGVkIHdhcnJp b3JzIGdvIHRvIHdhciBmaXJzdCBhbmQgdGhlbiBzZWVrIHRvIHdpbi48L3NwYW4+PGJyPg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtTdW4gVHp1PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9z cGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+Jm5ic3A7X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj48c3Bhbj4mbmJzcDt2Nm9wcyBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj4mbmJzcDs8YSBocmVmPSJtYWlsdG86djZvcHNA aWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9 ImNpdGUiPjxzcGFuPiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdjZvcHMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZv cHM8L2E+PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxi cj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNw YW4+PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+KioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPjxzcGFuPklQdjQgaXMgb3Zlcjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxzcGFuPkFyZSB5b3UgcmVhZHkgZm9yIHRoZSBuZXcgSW50ZXJuZXQgPzwvc3Bh bj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjxhIGhyZWY9Imh0dHA6Ly93d3cu Y29uc3VsaW50ZWwuZXMiPmh0dHA6Ly93d3cuY29uc3VsaW50ZWwuZXM8L2E+PC9zcGFuPjxicj4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+VGhlIElQdjYgQ29tcGFueTwvc3Bhbj48YnI+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPjxzcGFuPlRoaXMgZWxlY3Ryb25pYyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0 aW9uIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbC4gVGhlIGluZm9ybWF0 aW9uIGlzIGludGVuZGVkIHRvIGJlIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgaW5kaXZp ZHVhbChzKSBuYW1lZCBhYm92ZSBhbmQgZnVydGhlciBub24tZXhwbGljaWx0eSBhdXRob3JpemVk IGRpc2Nsb3N1cmUsIGNvcHlpbmcsDQogZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiB0aGUgY29udGVu dHMgb2YgdGhpcyBpbmZvcm1hdGlvbiwgZXZlbiBpZiBwYXJ0aWFsbHksIGluY2x1ZGluZyBhdHRh Y2hlZCBmaWxlcywgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgd2lsbCBiZSBjb25zaWRlcmVk IGEgY3JpbWluYWwgb2ZmZW5zZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCBiZSBhd2FyZSB0aGF0IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24NCiBv ciB1c2Ugb2YgdGhlIGNvbnRlbnRzIG9mIHRoaXMgaW5mb3JtYXRpb24sIGV2ZW4gaWYgcGFydGlh bGx5LCBpbmNsdWRpbmcgYXR0YWNoZWQgZmlsZXMsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQsIHdp bGwgYmUgY29uc2lkZXJlZCBhIGNyaW1pbmFsIG9mZmVuc2UsIHNvIHlvdSBtdXN0IHJlcGx5IHRv IHRoZSBvcmlnaW5hbCBzZW5kZXIgdG8gaW5mb3JtIGFib3V0IHRoaXMgY29tbXVuaWNhdGlvbiBh bmQgZGVsZXRlIGl0Ljwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwv c3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBl PSJjaXRlIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48c3Bhbj48L3NwYW4+PGJyPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+LS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+PHNwYW4+VGhlIGZhY3QgdGhhdCB0aGVyZSBpcyBhIGhpZ2h3YXkgdG8gaGVsbCBhbmQgYSBz dGFpcndheSB0byBoZWF2ZW4gaXMgYW4gaW50ZXJlc3RpbmcgY29tbWVudCBvbiBwcm9qZWN0ZWQg dHJhZmZpYyB2b2x1bWUuLi48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+PHNwYW4+PC9zcGFuPjxicj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJj aXRlIj48c3Bhbj52Nm9wcyBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYu b3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby92Nm9wcyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by92Nm9wczwvYT48L3NwYW4+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPHNwYW4+PC9zcGFuPjxicj4N CjxzcGFuPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9zcGFuPjxicj4NCjxzcGFuPlRoZSBmYWN0 IHRoYXQgdGhlcmUgaXMgYSBoaWdod2F5IHRvIGhlbGwgYW5kIGEgc3RhaXJ3YXkgdG8gaGVhdmVu IGlzIGFuIGludGVyZXN0aW5nIGNvbW1lbnQgb24gcHJvamVjdGVkIHRyYWZmaWMgdm9sdW1lLi4u PC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+DQo8c3Bhbj52Nm9wcyBtYWlsaW5n IGxpc3Q8L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIj52 Nm9wc0BpZXRmLm9yZzwvYT48L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby92Nm9wczwvYT48L3NwYW4+PGJyPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7A8DE6A694444160B981F92D9A0550A0ciscocom_-- From nobody Fri Aug 31 06:47:51 2018 Return-Path: <lee@asgard.org> 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 B3136127AC2 for <v6ops@ietfa.amsl.com>; Fri, 31 Aug 2018 06:47:37 -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 a8jCEjMkuGaO for <v6ops@ietfa.amsl.com>; Fri, 31 Aug 2018 06:47:35 -0700 (PDT) Received: from atl4mhob23.registeredsite.com (atl4mhob23.registeredsite.com [209.17.115.117]) (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 6A6D9130E41 for <v6ops@ietf.org>; Fri, 31 Aug 2018 06:47:35 -0700 (PDT) Received: from mailpod.hostingplatform.com (atl4qobmail02pod6.registeredsite.com [10.30.71.210]) by atl4mhob23.registeredsite.com (8.14.4/8.14.4) with ESMTP id w7VDlVrf001605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <v6ops@ietf.org>; Fri, 31 Aug 2018 09:47:31 -0400 Received: (qmail 28190 invoked by uid 0); 31 Aug 2018 13:47:31 -0000 X-TCPREMOTEIP: 174.64.33.182 X-Authenticated-UID: lee@asgard.org Received: from unknown (HELO ?192.168.2.103?) (lee@asgard.org@174.64.33.182) by 0 with ESMTPA; 31 Aug 2018 13:47:31 -0000 To: v6ops@ietf.org References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> <CAD6AjGQ_OBFGJb_C+mP_87nu7q_oXPrTvxhaV_=RcubeHtMy2Q@mail.gmail.com> <E345387F-6C1D-49D4-8B03-52D04498DDA5@lists.zabbadoz.net> <a9eeba1b-76dc-a69f-aabe-04fa4ddc3a4f@gmail.com> <e560c82c-085e-60fe-2076-70e3624696c0@asgard.org> <9142206A0C5BF24CB22755C8EC422E459CB46310@AZ-US1EXMB03.global.avaya.com> <76055AE4-FF87-47E1-988A-CDB7E157C6AD@delong.com> <9142206A0C5BF24CB22755C8EC422E459CB4644F@AZ-US1EXMB03.global.avaya.com> <CAN-Dau26+uOpa9+CSf5QGmbqbmW5UisM3zxitLv12pLWRmZ8rQ@mail.gmail.com> <f2d934cb-5075-fc1c-49d5-71d4613b3b9c@gmail.com> <9142206A0C5BF24CB22755C8EC422E459CB47368@AZ-US1EXMB03.global.avaya.com> From: Lee Howard <lee@asgard.org> Message-ID: <8661280d-fc91-eb1b-2531-29bd6dbb23d8@asgard.org> Date: Fri, 31 Aug 2018 09:47:31 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <9142206A0C5BF24CB22755C8EC422E459CB47368@AZ-US1EXMB03.global.avaya.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Kc6HbGI2MYBFRh7rfS_T7lYmD4s> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 31 Aug 2018 13:47:38 -0000 On 08/30/2018 03:26 PM, Mudric, Dusan (Dusan) wrote: >> Exactly. Working out of the box on an unmanaged network has always been >> a goal for IPv6, > I expected plug-and-play, or unmanaged network, means devices deployed to those networks should work based on the network defaults. If DHCPv6 is added to the network, 'O' flag needs to be set. That means managing the network. An "unmanaged network" that is "based on the network defaults" sounds like it's in conflict with a server being "added to the network." The M bit means there are addresses available via DHCPv6. It doesn't mean you have to use them. The O bit means there is other configuration information available via DHCPv6. It is redundant if the M bit is set. Neither requires a device to pay attention to them. > >>> If I don't provide a DHCPv6 I should >>> not have to do anything. > Right. If nothing is added to the network, there is no need to change the network configuration. But that is not the point. Plug-and-play is used when something is added to the network. There should not be a need to change 'O' bit when DHCPv6 server and DHCPv6 capable hosts are added to the network. And, if there are no DHCPv6 servers and DHCPv6 capable hosts in that network, sending 'O'=TRUE will not impact the network. How does a router (a thing sending RAs) know a DHCPv6 server has been added to the network? Even if a router is configured as a DHCPv6 relay, how does it know whether the M and/or O bits apply? That is, how does it know whether the DHCPv6 server is supplying addresses (M bit), or no addresses but DNS/NTP/other configuration (O bit)? (If the M bit is set, O is implied, per rfc4861). You could require DHCPv6 snooping, but it's several layers of logic to compare what the client requests vs. what the response is. And to revise RAs based on changing DHCPv6 configurations. If the router *is* the DHCPv6 server, the logic is much simpler. I'm content to say that if you add a server to provide network layer information, you are managing the network, and are therefore overriding defaults and are expected to manage the network. Essentially, the M bit. Lee > > Dusan > >> -----Original Message----- >> From: Brian E Carpenter <brian.e.carpenter@gmail.com> >> Sent: Wednesday, August 29, 2018 6:24 PM >> To: David Farmer <farmer@umn.edu>; Mudric, Dusan (Dusan) >> <dmudric@avaya.com> >> Cc: v6ops@ietf.org >> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks >> >> On 2018-08-30 08:52, David Farmer wrote: >>> On Wed, Aug 29, 2018 at 3:37 PM, Mudric, Dusan (Dusan) >> <dmudric@avaya.com> >>> wrote: >>> >>>>> They control the defaults for how Routers construct Router >>>> Advertisements. >>>> >>>> And default 'O' flag set to TRUE should enabled stateless DHCPv6 to >> obtain >>>> configuration for hosts. >>> >>> Only if there is, in fact, a DHCPv6 server and it is configured with >>> appropriate information. Maybe you wish to recommend net operators >> deploy >>> DHCPv6, but change the default for the O flag in RAs is more that. >>> >>> While I could be sympathetic to recommendations to provide DHCPv6 >> servers >>> on networks. However, changing the defaults for the M or O flags is not >>> something I can support. If I provide a DHCPv6 server then it is my job to >>> set the flags appropriately in the RA. If I don't provide a DHCPv6 I should >>> not have to do anything. This is how the defaults for the M and O flag are >>> currently set. >> Exactly. Working out of the box on an unmanaged network has always been >> a goal for IPv6, even back when it was called IPng. The defaults are >> set appropriately for that goal. >> >> Brian > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Aug 31 13:21:09 2018 Return-Path: <dmudric@avaya.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29D2130E1B for <v6ops@ietfa.amsl.com>; Fri, 31 Aug 2018 13:21:06 -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 Hdj-2T7S6ibk for <v6ops@ietfa.amsl.com>; Fri, 31 Aug 2018 13:21:05 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.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 2ED50124C04 for <v6ops@ietf.org>; Fri, 31 Aug 2018 13:21:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FzAABvoolb/yYyC4daGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJ6VGVtEigKi3mMLYINiFeNVYE/OwsjCQKEPgKDLSE0GAECAQE?= =?us-ascii?q?BAQEBAgICaRwMgmgvAQEEBwMMLwkCAwEBAQEBAQFPAg9HAQEYAQEBAQIBEig0C?= =?us-ascii?q?wUHBAIBCA0EBAEBAQoUECERHQgCBA4FCBqCfoFpAw0IAQ6ZRosdGgKHDA2CSQW?= =?us-ascii?q?KHBeBQj6BWIIeLoJWRQQYgTEYgzCCJgKbKysJAoYyhjODKYhhA4V1iydkh1qBQ?= =?us-ascii?q?TmBVXAVO4JshgGKUm8BgRWLdQGBGwEB?= X-IPAS-Result: =?us-ascii?q?A2FzAABvoolb/yYyC4daGQEBAQEBAQEBAQEBAQcBAQEBAYJ?= =?us-ascii?q?6VGVtEigKi3mMLYINiFeNVYE/OwsjCQKEPgKDLSE0GAECAQEBAQEBAgICaRwMg?= =?us-ascii?q?mgvAQEEBwMMLwkCAwEBAQEBAQFPAg9HAQEYAQEBAQIBEig0CwUHBAIBCA0EBAE?= =?us-ascii?q?BAQoUECERHQgCBA4FCBqCfoFpAw0IAQ6ZRosdGgKHDA2CSQWKHBeBQj6BWIIeL?= =?us-ascii?q?oJWRQQYgTEYgzCCJgKbKysJAoYyhjODKYhhA4V1iydkh1qBQTmBVXAVO4JshgG?= =?us-ascii?q?KUm8BgRWLdQGBGwEB?= X-IronPort-AV: E=Sophos;i="5.53,313,1531800000"; d="scan'208";a="295941238" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 31 Aug 2018 16:21:03 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-US1EXHC04.global.avaya.com) ([135.11.85.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Aug 2018 16:21:03 -0400 Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC04.global.avaya.com ([135.11.85.15]) with mapi id 14.03.0382.000; Fri, 31 Aug 2018 16:21:03 -0400 From: "Mudric, Dusan (Dusan)" <dmudric@avaya.com> To: Owen DeLong <owen@delong.com> CC: Brian E Carpenter <brian.e.carpenter@gmail.com>, David Farmer <farmer@umn.edu>, "v6ops@ietf.org" <v6ops@ietf.org> Thread-Topic: [v6ops] Thinking about problems in IPv6-only networks Thread-Index: AQHUQL/ygyT9kwsoz02Ikgn5fOjK1aTaS9DA Date: Fri, 31 Aug 2018 20:21:02 +0000 Message-ID: <9142206A0C5BF24CB22755C8EC422E459CB483D1@AZ-US1EXMB03.global.avaya.com> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> <CAD6AjGQ_OBFGJb_C+mP_87nu7q_oXPrTvxhaV_=RcubeHtMy2Q@mail.gmail.com> <E345387F-6C1D-49D4-8B03-52D04498DDA5@lists.zabbadoz.net> <a9eeba1b-76dc-a69f-aabe-04fa4ddc3a4f@gmail.com> <e560c82c-085e-60fe-2076-70e3624696c0@asgard.org> <9142206A0C5BF24CB22755C8EC422E459CB46310@AZ-US1EXMB03.global.avaya.com> <76055AE4-FF87-47E1-988A-CDB7E157C6AD@delong.com> <9142206A0C5BF24CB22755C8EC422E459CB4644F@AZ-US1EXMB03.global.avaya.com> <CAN-Dau26+uOpa9+CSf5QGmbqbmW5UisM3zxitLv12pLWRmZ8rQ@mail.gmail.com> <f2d934cb-5075-fc1c-49d5-71d4613b3b9c@gmail.com> <9142206A0C5BF24CB22755C8EC422E459CB47368@AZ-US1EXMB03.global.avaya.com> <5BECF927-9AD4-49A4-BBF7-4D590F0F557C@delong.com> In-Reply-To: <5BECF927-9AD4-49A4-BBF7-4D590F0F557C@delong.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/SpDjnt3rIV3s4DmAtddpeNKrL7U> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 31 Aug 2018 20:21:07 -0000 > The O flag will cause hosts to seek information from a DHCPv6 server, > hanging (possibly indefinitely) until that information is received. If th= ere is no > DHCPv6 server available to provide that information, you have now broken > the network by changing the O flag without any reason to do so. Possible but it is not required, by any standard that I know about, that ap= plications should wait indefinitely for DHCPv6 server response. Dusan > -----Original Message----- > From: Owen DeLong <owen@delong.com> > Sent: Thursday, August 30, 2018 8:17 PM > To: Mudric, Dusan (Dusan) <dmudric@avaya.com> > Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>; David Farmer > <farmer@umn.edu>; v6ops@ietf.org > Subject: Re: [v6ops] Thinking about problems in IPv6-only networks >=20 >=20 >=20 > On Aug 30, 2018, at 12:26, Mudric, Dusan (Dusan) <dmudric@avaya.com> > wrote: >=20 > >> Exactly. Working out of the box on an unmanaged network has always > been > >> a goal for IPv6, > > I expected plug-and-play, or unmanaged network, means devices > deployed to those networks should work based on the network defaults. If > DHCPv6 is added to the network, 'O' flag needs to be set. That means > managing the network. > > > >>> If I don't provide a DHCPv6 I should > >>> not have to do anything. > > Right. If nothing is added to the network, there is no need to change t= he > network configuration. But that is not the point. Plug-and-play is used w= hen > something is added to the network. There should not be a need to change > 'O' bit when DHCPv6 server and DHCPv6 capable hosts are added to the > network. And, if there are no DHCPv6 servers and DHCPv6 capable hosts in > that network, sending 'O'=3DTRUE will not impact the network. >=20 > You are badly mistaken. >=20 > The O flag will cause hosts to seek information from a DHCPv6 server, > hanging (possibly indefinitely) until that information is received. If th= ere is no > DHCPv6 server available to provide that information, you have now broken > the network by changing the O flag without any reason to do so. >=20 > Owen >=20 > > > > Dusan > > > >> -----Original Message----- > >> From: Brian E Carpenter <brian.e.carpenter@gmail.com> > >> Sent: Wednesday, August 29, 2018 6:24 PM > >> To: David Farmer <farmer@umn.edu>; Mudric, Dusan (Dusan) > >> <dmudric@avaya.com> > >> Cc: v6ops@ietf.org > >> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks > >> > >>> On 2018-08-30 08:52, David Farmer wrote: > >>> On Wed, Aug 29, 2018 at 3:37 PM, Mudric, Dusan (Dusan) > >> <dmudric@avaya.com> > >>> wrote: > >>> > >>>>> They control the defaults for how Routers construct Router > >>>> Advertisements. > >>>> > >>>> And default 'O' flag set to TRUE should enabled stateless DHCPv6 to > >> obtain > >>>> configuration for hosts. > >>> > >>> > >>> Only if there is, in fact, a DHCPv6 server and it is configured with > >>> appropriate information. Maybe you wish to recommend net operators > >> deploy > >>> DHCPv6, but change the default for the O flag in RAs is more that. > >>> > >>> While I could be sympathetic to recommendations to provide DHCPv6 > >> servers > >>> on networks. However, changing the defaults for the M or O flags is n= ot > >>> something I can support. If I provide a DHCPv6 server then it is my = job to > >>> set the flags appropriately in the RA. If I don't provide a DHCPv6 I = should > >>> not have to do anything. This is how the defaults for the M and O fla= g are > >>> currently set. > >> > >> Exactly. Working out of the box on an unmanaged network has always > been > >> a goal for IPv6, even back when it was called IPng. The defaults are > >> set appropriately for that goal. > >> > >> Brian > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwIFAg&c=3DBFpWQw8bsuKpl > 1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3D7MH > tvme6nAWYF4uDMH3gO_auo_qxpA8VsctyigS3New&s=3DUAR1vCzZ7eYHUKdgl > xensNPphQb9IEool0hz1ozKIFs&e=3D From nobody Fri Aug 31 13:53:02 2018 Return-Path: <linux@thehobsons.co.uk> 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 8F3C8130E2A for <v6ops@ietfa.amsl.com>; Fri, 31 Aug 2018 13:53:00 -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] 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 dGhO8C7yT2QN for <v6ops@ietfa.amsl.com>; Fri, 31 Aug 2018 13:52:58 -0700 (PDT) Received: from patsy.thehobsons.co.uk (patsy.thehobsons.co.uk [80.229.10.150]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8A7B130E06 for <v6ops@ietf.org>; Fri, 31 Aug 2018 13:52:58 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from simons-macbookpro.thehobsons.co.uk (Simons-MacBookPro.thehobsons.co.uk [192.168.137.111]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 613B41BC37 for <v6ops@ietf.org>; Fri, 31 Aug 2018 20:52:53 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Simon Hobson <linux@thehobsons.co.uk> In-Reply-To: <8661280d-fc91-eb1b-2531-29bd6dbb23d8@asgard.org> Date: Fri, 31 Aug 2018 21:52:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <63AFCC0D-7183-4523-AF46-118D406E3899@thehobsons.co.uk> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> <CAD6AjGQ_OBFGJb_C+mP_87nu7q_oXPrTvxhaV_=RcubeHtMy2Q@mail.gmail.com> <E345387F-6C1D-49D4-8B03-52D04498DDA5@lists.zabbadoz.net> <a9eeba1b-76dc-a69f-aabe-04fa4ddc3a4f@gmail.com> <e560c82c-085e-60fe-2076-70e3624696c0@asgard.org> <9142206A0C5BF24CB22755C8EC422E459CB46310@AZ-US1EXMB03.global.avaya.com> <76055AE4-FF87-47E1-988A-CDB7E157C6AD@delong.com> <9142206A0C5BF24CB22755C8EC422E459CB4644F@AZ-US1EXMB03.global.avaya.com> <CAN-Dau26+uOpa9+CSf5QGmbqbmW5UisM3zxitLv12pLWRmZ8rQ@mail.gmail.com> <f2d934cb-5075-fc1c-49d5-71d4613b3b9c@gmail.com> <9142206A0C5BF24CB22755C8EC422E459CB47368@AZ-US1EXMB03.global.avaya.com> <8661280d-fc91-eb1b-2531-29bd6dbb23d8@asgard.org> To: "v6ops@ietf.org list" <v6ops@ietf.org> X-Mailer: Apple Mail (2.2104) Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/FOaWXvrY3neSC8HMTeGNQ2Pc5Wk> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 31 Aug 2018 20:53:00 -0000 Lee Howard <lee@asgard.org> wrote: > An "unmanaged network" that is "based on the network defaults" sounds = like it's in conflict with a server being "added to the network." Not really. If you add a SERVER (such as DHCP6) then you are implicitly = making it a managed network. At that point, you also take on = responsibility for configuring the network as such - ie setting the M = and/or O flags in the RAs. > The M bit means there are addresses available via DHCPv6. It doesn't = mean you have to use them. > The O bit means there is other configuration information available via = DHCPv6. It is redundant if the M bit is set. > Neither requires a device to pay attention to them. I may be wrong, but I was under the impression that if the M bit is set, = then the client is required to use DHCP to configure address(es) and not = auto-configure. Thus if the M bit is set and there is no DHCP server, = clients simply will not work. None of this is inconsistent. An unmanaged network means that someone = has thrown it together, accepting the default settings for RAs etc - and = with some expectation that the router will get a working config = (suitable prefix assignment) from upstream. Thus an unskilled person can = put together a basic network with some expectation of "it just works" - = much as happens when a user gets the ISP supplied router which uses = something like TR069 to automatically get the required config and within = a short time of plugging it in, give the user a working internet = connection and LAN. > How does a router (a thing sending RAs) know a DHCPv6 server has been = added to the network? Because the network administrator tells it. If there's a DHCP server, = then it's not a basic unmanaged network. If it's managed then there's an = admin responsible for it. It would be possible for a router manufacturer to obfuscate this by = providing a suitable GUI to configure and enable a DHCP server, and as a = side effect, turn on the M and/or O bits in the RAs issued by **that = router**. That would be OK for small routers (SOHO) where typically = there is only the one router and one internet connection. From nobody Fri Aug 31 15:08:51 2018 Return-Path: <brian.e.carpenter@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268FD12785F for <v6ops@ietfa.amsl.com>; Fri, 31 Aug 2018 15:08:49 -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 i69kzDe7ja16 for <v6ops@ietfa.amsl.com>; Fri, 31 Aug 2018 15:08:47 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 58D0C126CB6 for <v6ops@ietf.org>; Fri, 31 Aug 2018 15:08:47 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id b92-v6so1012296plb.0 for <v6ops@ietf.org>; Fri, 31 Aug 2018 15:08:47 -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=R5XwsNtIZWBlsxB56p8sdySBkAOTQVV+ngerSw6sWTE=; b=inTrVewh3w5S9WJvtMApg+7t+dHqh3U0YF13AinpkWYPLL3+Rj356fGAR+2oE3W+hG AwRln9c2dv54vVQRlSBJxFerP6ZNitxa3iCfuAqHBo/GdiXL7U60CobY9bQ57DmTHFIQ eFSmmPTtowva3nzl9dnvMmVlIVnjvafM0lUFgVxGn17VtOJTgZB42t4VmViS5cFgfkAh GA/2xU+/vdhLi+Mz28OLC8nPF+LTY5YcrNOXwfJaQYo+B/GRtJUedwOYGeU7X9CAHRfd uVcr4cAr6pl5m4m4JCBd9iJ0ms4Sl/FtYAsOpsZ8GsAbLNKtLegzKEWfWC5bapHDa2qK fyIQ== 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=R5XwsNtIZWBlsxB56p8sdySBkAOTQVV+ngerSw6sWTE=; b=aC0Dq73i8GeA9w8oer3salX3RWIjYENOqrEihLBQ6wDY9Y1RwNHw1/w70xQkpnNmKT T6c95nHA/J98y/JwUUnKDiKP8QAjkCSqcdehF+Bs+eg5XqpWHy+D0FG/FYzwsMSJcLTH nXB2vDfWGrIlYvwUdCVmITX49Hg0uOC8eCuMIkEcllTF5oatpMm4kQjQFICj5ROEEcuQ mS/eR3K0YboATBwoGF5yKn0hip7RrqdrNWkKMZXismtPr0jT3YmPcYnrqNBkRzaFkr/e 0ET9fL7N+l8/0uLwiPI+ZQ5uSq//eyqgBjOLOZnopRPdgW5E+M9Iyi994avJM9fBdiz1 +EZg== X-Gm-Message-State: APzg51DohAooARj2C338PveIOOBR2qKIhy58MGSHz+bB11GUWihE0tcz 9Htt4PYYQccXf2a6206/OTkQDI1p X-Google-Smtp-Source: ANB0VdazH/QRVmgIwxXTeBBpJCQqbiK/0jnbuhBm/9Bcsk5bbGXL+Sbyo5JlnLgeBaRGjVA3ytfNcw== X-Received: by 2002:a17:902:209:: with SMTP id 9-v6mr17255950plc.270.1535753326525; Fri, 31 Aug 2018 15:08:46 -0700 (PDT) Received: from [192.168.178.30] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id m21-v6sm15006295pgd.6.2018.08.31.15.08.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Aug 2018 15:08:45 -0700 (PDT) To: Simon Hobson <linux@thehobsons.co.uk>, "v6ops@ietf.org list" <v6ops@ietf.org> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> <CAD6AjGQ_OBFGJb_C+mP_87nu7q_oXPrTvxhaV_=RcubeHtMy2Q@mail.gmail.com> <E345387F-6C1D-49D4-8B03-52D04498DDA5@lists.zabbadoz.net> <a9eeba1b-76dc-a69f-aabe-04fa4ddc3a4f@gmail.com> <e560c82c-085e-60fe-2076-70e3624696c0@asgard.org> <9142206A0C5BF24CB22755C8EC422E459CB46310@AZ-US1EXMB03.global.avaya.com> <76055AE4-FF87-47E1-988A-CDB7E157C6AD@delong.com> <9142206A0C5BF24CB22755C8EC422E459CB4644F@AZ-US1EXMB03.global.avaya.com> <CAN-Dau26+uOpa9+CSf5QGmbqbmW5UisM3zxitLv12pLWRmZ8rQ@mail.gmail.com> <f2d934cb-5075-fc1c-49d5-71d4613b3b9c@gmail.com> <9142206A0C5BF24CB22755C8EC422E459CB47368@AZ-US1EXMB03.global.avaya.com> <8661280d-fc91-eb1b-2531-29bd6dbb23d8@asgard.org> <63AFCC0D-7183-4523-AF46-118D406E3899@thehobsons.co.uk> From: Brian E Carpenter <brian.e.carpenter@gmail.com> Message-ID: <01677f7d-3691-c871-e5a7-149c6cbca295@gmail.com> Date: Sat, 1 Sep 2018 10:08:40 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <63AFCC0D-7183-4523-AF46-118D406E3899@thehobsons.co.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/nVadQRM--so9O8ZSQ1wz8KZlHUA> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 31 Aug 2018 22:08:49 -0000 On 2018-09-01 08:52, Simon Hobson wrote: > Lee Howard <lee@asgard.org> wrote: > >> An "unmanaged network" that is "based on the network defaults" sounds like it's in conflict with a server being "added to the network." > > Not really. If you add a SERVER (such as DHCP6) then you are implicitly making it a managed network. At that point, you also take on responsibility for configuring the network as such - ie setting the M and/or O flags in the RAs. > >> The M bit means there are addresses available via DHCPv6. It doesn't mean you have to use them. >> The O bit means there is other configuration information available via DHCPv6. It is redundant if the M bit is set. >> Neither requires a device to pay attention to them. > > I may be wrong, but I was under the impression that if the M bit is set, then the client is required to use DHCP to configure address(es) and not auto-configure. Thus if the M bit is set and there is no DHCP server, clients simply will not work. > > None of this is inconsistent. An unmanaged network means that someone has thrown it together, accepting the default settings for RAs etc - and with some expectation that the router will get a working config (suitable prefix assignment) from upstream. Thus an unskilled person can put together a basic network with some expectation of "it just works" - much as happens when a user gets the ISP supplied router which uses something like TR069 to automatically get the required config and within a short time of plugging it in, give the user a working internet connection and LAN. > >> How does a router (a thing sending RAs) know a DHCPv6 server has been added to the network? > > Because the network administrator tells it. If there's a DHCP server, then it's not a basic unmanaged network. If it's managed then there's an admin responsible for it. > > It would be possible for a router manufacturer to obfuscate this by providing a suitable GUI to configure and enable a DHCP server, and as a side effect, turn on the M and/or O bits in the RAs issued by **that router**. That would be OK for small routers (SOHO) where typically there is only the one router and one internet connection. Maybe, but homenet renders this obsolete. For now, SLAAC is necessary and sufficient for single-router SOHOs. Brian From nobody Fri Aug 31 16:22:05 2018 Return-Path: <markzzzsmith@gmail.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF20127333 for <v6ops@ietfa.amsl.com>; Fri, 31 Aug 2018 16:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 DwTMz0zZqFHp for <v6ops@ietfa.amsl.com>; Fri, 31 Aug 2018 16:22:00 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 EE0FC1286E3 for <v6ops@ietf.org>; Fri, 31 Aug 2018 16:21:59 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id p84-v6so24537582oic.4 for <v6ops@ietf.org>; Fri, 31 Aug 2018 16:21:59 -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=KwyxjJIQT+m2+xN8fj04RJLIFaiWq0hB3ONQvu+Z1IM=; b=oFVoU33Qsx2XdjWtGaWDqX0eZSEqxmL0OY4vp1/9XMKOP0biL3abF/w91vWly8HbF/ QyUz+f/Z3CJA5mvT9FyHkfvVWkU9249sSQY6bfg2Ysw9BcuhYNWe8eC2p3s4MFK43nUv +iw5qpghNxgoSneo3nS1ojVICJiEznyz22J+L4ysTnVfu//8vWyYngHZaqNMlGMNOXaH hy47thNgK1fNptT2w2Iq/Q4+rtV4jwe6IQ1ilYLePWbURFhZOtml+ATHsWR5sNfqkpQr rxCrkj8l5Ao539ttwja5oLLucFOaiKdwR0n8TAd+NmDtaYmOs7SYYh+ZCvCO1W76nhAL EBcA== 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=KwyxjJIQT+m2+xN8fj04RJLIFaiWq0hB3ONQvu+Z1IM=; b=U0eW7n9S5nEYIc9/lukWGFqXvcFeOdGwI6sulGuFsuGYzgL3JbYAaiv7/V+kxU2Rdu ICzFYfgJpS83vnj7drRtfF0vl3gdm5iEu0OuPUpqRp+Rf1/SMniKV6xHu7CGTfKRa+dR bw1rdW0btOeJdgmMeCItUxF0WxnbNs2KTRPYJ+BONiMCjGSOWbmbw62RCL1dmxnSb8db RQAt2Z2eRaEU4uKwJC90SLk1lXTGIiTw48aZT6rQjr4MrXAS4IrGKB77XXGVKX2T/hg8 ed5VeCiduGWFbYJp4SBcXKzFZWN1Il61qYhwxvuVk9Ll+N3wJiAMsXr+oi0Rbnl4fcvE n5Gw== X-Gm-Message-State: APzg51DwjlMmetQiSGfg04Zju9frOu8SUbjUzhQymCwmy2f00m9BTYZU Ue4AHk1Npk2PRoWIUGikNEhja8C4HhG0JIUtZfcb3Q== X-Google-Smtp-Source: ANB0VdYZ8zn5WW84JG9UFDMc11Lsa6yUZDDhJC3okEDLbSU9l0RXMFFvbQ2HIZIUe3VYOXYd5Jnj7P3gAPdFMpcnOA4= X-Received: by 2002:aca:f2c3:: with SMTP id q186-v6mr9783011oih.193.1535757718026; Fri, 31 Aug 2018 16:21:58 -0700 (PDT) MIME-Version: 1.0 References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> <CAD6AjGQ_OBFGJb_C+mP_87nu7q_oXPrTvxhaV_=RcubeHtMy2Q@mail.gmail.com> <E345387F-6C1D-49D4-8B03-52D04498DDA5@lists.zabbadoz.net> <a9eeba1b-76dc-a69f-aabe-04fa4ddc3a4f@gmail.com> <e560c82c-085e-60fe-2076-70e3624696c0@asgard.org> <9142206A0C5BF24CB22755C8EC422E459CB46310@AZ-US1EXMB03.global.avaya.com> <76055AE4-FF87-47E1-988A-CDB7E157C6AD@delong.com> <9142206A0C5BF24CB22755C8EC422E459CB4644F@AZ-US1EXMB03.global.avaya.com> <CAN-Dau26+uOpa9+CSf5QGmbqbmW5UisM3zxitLv12pLWRmZ8rQ@mail.gmail.com> <f2d934cb-5075-fc1c-49d5-71d4613b3b9c@gmail.com> <9142206A0C5BF24CB22755C8EC422E459CB47368@AZ-US1EXMB03.global.avaya.com> <8661280d-fc91-eb1b-2531-29bd6dbb23d8@asgard.org> <63AFCC0D-7183-4523-AF46-118D406E3899@thehobsons.co.uk> In-Reply-To: <63AFCC0D-7183-4523-AF46-118D406E3899@thehobsons.co.uk> From: Mark Smith <markzzzsmith@gmail.com> Date: Sat, 1 Sep 2018 09:21:45 +1000 Message-ID: <CAO42Z2y5o9EkpXfZmbvmaGEkzKHGJBobQYodeapeTMON4++OTw@mail.gmail.com> To: Simon Hobson <linux@thehobsons.co.uk> Cc: v6ops list <v6ops@ietf.org> Content-Type: multipart/alternative; boundary="0000000000003e84910574c37527" Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/y8uhifnpFMHnr4MIw5uuUuWT8Y4> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Fri, 31 Aug 2018 23:22:03 -0000 --0000000000003e84910574c37527 Content-Type: text/plain; charset="UTF-8" On Sat., 1 Sep. 2018, 06:53 Simon Hobson, <linux@thehobsons.co.uk> wrote: > Lee Howard <lee@asgard.org> wrote: > > > An "unmanaged network" that is "based on the network defaults" sounds > like it's in conflict with a server being "added to the network." > > Not really. If you add a SERVER (such as DHCP6) then you are implicitly > making it a managed network. At that point, you also take on responsibility > for configuring the network as such - ie setting the M and/or O flags in > the RAs. > > > The M bit means there are addresses available via DHCPv6. It doesn't > mean you have to use them. > > The O bit means there is other configuration information available via > DHCPv6. It is redundant if the M bit is set. > > Neither requires a device to pay attention to them. > > I may be wrong, but I was under the impression that if the M bit is set, > then the client is required to use DHCP to configure address(es) and not > auto-configure. Thus if the M bit is set and there is no DHCP server, > clients simply will not work. > The signal to use SLAAC is one or more PIOs in the RA with the A bit set. SLAAC and stateful DHCPv6 can coexist, and they're optional, in the sense that the host can choose to use either or both. It is up to the host. The only way to enforce the use of one of them is to only provide that as the single method. (And even then if you think forcing stateful DHCPv6 means there is a database of all addresses, it won't contain statically assigned ones.) OpenWRT enables both by default, and a host that supports both SLAAC and DHCPv6 e.g. Fedora Linux, will get addresses using both. (And compromises SLAAC privacy addresses by limiting the stateful DHCPv6 address range to the same as the IPv4 pool range size.) So stateful DHCPv6 or not by itself is not a absolute statement of it being a managed network or not. > None of this is inconsistent. An unmanaged network means that someone has > thrown it together, accepting the default settings for RAs etc - and with > some expectation that the router will get a working config (suitable prefix > assignment) from upstream. Thus an unskilled person can put together a > basic network with some expectation of "it just works" - much as happens > when a user gets the ISP supplied router which uses something like TR069 to > automatically get the required config and within a short time of plugging > it in, give the user a working internet connection and LAN. > > > How does a router (a thing sending RAs) know a DHCPv6 server has been > added to the network? > > Because the network administrator tells it. If there's a DHCP server, then > it's not a basic unmanaged network. If it's managed then there's an admin > responsible for it. > > It would be possible for a router manufacturer to obfuscate this by > providing a suitable GUI to configure and enable a DHCP server, and as a > side effect, turn on the M and/or O bits in the RAs issued by **that > router**. That would be OK for small routers (SOHO) where typically there > is only the one router and one internet connection. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --0000000000003e84910574c37527 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">= On Sat., 1 Sep. 2018, 06:53 Simon Hobson, <<a href=3D"mailto:linux@theho= bsons.co.uk" target=3D"_blank" rel=3D"noreferrer">linux@thehobsons.co.uk</a= >> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0= 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Lee Howard <<a href= =3D"mailto:lee@asgard.org" rel=3D"noreferrer noreferrer" target=3D"_blank">= lee@asgard.org</a>> wrote:<br> <br> > An "unmanaged network" that is "based on the network de= faults" sounds like it's in conflict with a server being "add= ed to the network."<br> <br> Not really. If you add a SERVER (such as DHCP6) then you are implicitly mak= ing it a managed network. At that point, you also take on responsibility fo= r configuring the network as such - ie setting the M and/or O flags in the = RAs.<br> <br> > The M bit means there are addresses available via DHCPv6. It doesn'= ;t mean you have to use them.<br> > The O bit means there is other configuration information available via= DHCPv6. It is redundant if the M bit is set.<br> > Neither requires a device to pay attention to them.<br> <br> I may be wrong, but I was under the impression that if the M bit is set, th= en the client is required to use DHCP to configure address(es) and not auto= -configure. Thus if the M bit is set and there is no DHCP server, clients s= imply will not work.<br></blockquote></div></div><div dir=3D"auto"><br></di= v><div dir=3D"auto">The signal to use SLAAC is one or more PIOs in the RA w= ith the A bit set.</div><div dir=3D"auto"><br></div><div dir=3D"auto">SLAAC= and stateful DHCPv6 can coexist, and they're optional, in the sense th= at the host can choose to use either or both. It is up to the host.</div><d= iv dir=3D"auto"><br></div><div dir=3D"auto">The only way to enforce the use= of one of them is to only provide that as the single method. (And even the= n if you think forcing stateful DHCPv6 means there is a database of all add= resses, it won't contain statically assigned ones.)</div><div dir=3D"au= to"><br></div><div dir=3D"auto">OpenWRT enables both by default, and a host= that supports both SLAAC and DHCPv6 e.g. Fedora Linux, will get addresses = using both. (And compromises SLAAC privacy addresses by limiting the statef= ul DHCPv6 address range to the same as the IPv4 pool range size.)</div><div= dir=3D"auto"><br></div><div dir=3D"auto">So stateful DHCPv6 or not by itse= lf is not a absolute statement of it being a managed network or not.</div><= div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><bl= ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #= ccc solid;padding-left:1ex"> <br> None of this is inconsistent. An unmanaged network means that someone has t= hrown it together, accepting the default settings for RAs etc - and with so= me expectation that the router will get a working config (suitable prefix a= ssignment) from upstream. Thus an unskilled person can put together a basic= network with some expectation of "it just works" - much as happe= ns when a user gets the ISP supplied router which uses something like TR069= to automatically get the required config and within a short time of pluggi= ng it in, give the user a working internet connection and LAN.<br> <br> > How does a router (a thing sending RAs) know a DHCPv6 server has been = added to the network?<br> <br> Because the network administrator tells it. If there's a DHCP server, t= hen it's not a basic unmanaged network. If it's managed then there&= #39;s an admin responsible for it.<br> <br> It would be possible for a router manufacturer to obfuscate this by providi= ng a suitable GUI to configure and enable a DHCP server, and as a side effe= ct, turn on the M and/or O bits in the RAs issued by **that router**. That = would be OK for small routers (SOHO) where typically there is only the one = router and one internet connection.<br> <br> _______________________________________________<br> v6ops mailing list<br> <a href=3D"mailto:v6ops@ietf.org" rel=3D"noreferrer noreferrer" target=3D"_= blank">v6ops@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/v6ops" rel=3D"noreferrer n= oreferrer noreferrer" target=3D"_blank">https://www.ietf.org/mailman/listin= fo/v6ops</a><br> </blockquote></div></div></div> --0000000000003e84910574c37527-- From nobody Fri Aug 31 20:18:47 2018 Return-Path: <owen@delong.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F37130E99 for <v6ops@ietfa.amsl.com>; Fri, 31 Aug 2018 20:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 4Zg5bySrgacx for <v6ops@ietfa.amsl.com>; Fri, 31 Aug 2018 20:18:43 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id 96273130E0F for <v6ops@ietf.org>; Fri, 31 Aug 2018 20:18:42 -0700 (PDT) Received: from [IPv6:2620::930:0:421:64d6:306a:42b3] ([IPv6:2620:0:930:0:421:64d6:306a:42b3]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id w813HVQX024649 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 31 Aug 2018 20:17:32 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com w813HVQX024649 From: Owen DeLong <owen@delong.com> Message-Id: <C4CB8586-41A7-4CC5-86BD-550668DE8F45@delong.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_CF0C4C08-E993-4EE3-A705-E0E191F9BFEB" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 31 Aug 2018 20:17:31 -0700 In-Reply-To: <9142206A0C5BF24CB22755C8EC422E459CB483D1@AZ-US1EXMB03.global.avaya.com> Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, David Farmer <farmer@umn.edu>, "v6ops@ietf.org" <v6ops@ietf.org> To: "Mudric, Dusan (Dusan)" <dmudric@avaya.com> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> <CAD6AjGQ_OBFGJb_C+mP_87nu7q_oXPrTvxhaV_=RcubeHtMy2Q@mail.gmail.com> <E345387F-6C1D-49D4-8B03-52D04498DDA5@lists.zabbadoz.net> <a9eeba1b-76dc-a69f-aabe-04fa4ddc3a4f@gmail.com> <e560c82c-085e-60fe-2076-70e3624696c0@asgard.org> <9142206A0C5BF24CB22755C8EC422E459CB46310@AZ-US1EXMB03.global.avaya.com> <76055AE4-FF87-47E1-988A-CDB7E157C6AD@delong.com> <9142206A0C5BF24CB22755C8EC422E459CB4644F@AZ-US1EXMB03.global.avaya.com> <CAN-Dau26+uOpa9+CSf5QGmbqbmW5UisM3zxitLv12pLWRmZ8rQ@mail.gmail.com> <f2d934cb-5075-fc1c-49d5-71d4613b3b9c@gmail.com> <9142206A0C5BF24CB22755C8EC422E459CB47368@AZ-US1EXMB03.global.avaya.com> <5BECF927-9AD4-49A4-BBF7-4D590F0F557C@delong.com> <9142206A0C5BF24CB22755C8EC422E459CB483D1@AZ-US1EXMB03.global.avaya.com> X-Mailer: Apple Mail (2.3445.9.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Fri, 31 Aug 2018 20:17:38 -0700 (PDT) Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/PIG56ph_RDkmI6fpCL4l_URtG_k> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 01 Sep 2018 03:18:45 -0000 --Apple-Mail=_CF0C4C08-E993-4EE3-A705-E0E191F9BFEB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 31, 2018, at 13:21 , Mudric, Dusan (Dusan) <dmudric@avaya.com> = wrote: >=20 >> The O flag will cause hosts to seek information from a DHCPv6 server, >> hanging (possibly indefinitely) until that information is received. = If there is no >> DHCPv6 server available to provide that information, you have now = broken >> the network by changing the O flag without any reason to do so. >=20 > Possible but it is not required, by any standard that I know about, = that applications should wait indefinitely for DHCPv6 server response. Whether it=E2=80=99s required or not, it _IS_ the actual implementation = in a number of existing systems. SO=E2=80=A6 Changing the default value in this way breaks a lot of stuff = that already exists. I=E2=80=99m not saying we should never do that, but there certainly needs to be a compelling reason to do so or = we shouldn=E2=80=99t do it. So far, you have yet to provide anything remotely resembling a = compelling reason. Owen >=20 > Dusan >=20 >> -----Original Message----- >> From: Owen DeLong <owen@delong.com <mailto:owen@delong.com>> >> Sent: Thursday, August 30, 2018 8:17 PM >> To: Mudric, Dusan (Dusan) <dmudric@avaya.com = <mailto:dmudric@avaya.com>> >> Cc: Brian E Carpenter <brian.e.carpenter@gmail.com = <mailto:brian.e.carpenter@gmail.com>>; David Farmer >> <farmer@umn.edu <mailto:farmer@umn.edu>>; v6ops@ietf.org = <mailto:v6ops@ietf.org> >> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks >>=20 >>=20 >>=20 >> On Aug 30, 2018, at 12:26, Mudric, Dusan (Dusan) <dmudric@avaya.com> >> wrote: >>=20 >>>> Exactly. Working out of the box on an unmanaged network has always >> been >>>> a goal for IPv6, >>> I expected plug-and-play, or unmanaged network, means devices >> deployed to those networks should work based on the network defaults. = If >> DHCPv6 is added to the network, 'O' flag needs to be set. That means >> managing the network. >>>=20 >>>>> If I don't provide a DHCPv6 I should >>>>> not have to do anything. >>> Right. If nothing is added to the network, there is no need to = change the >> network configuration. But that is not the point. Plug-and-play is = used when >> something is added to the network. There should not be a need to = change >> 'O' bit when DHCPv6 server and DHCPv6 capable hosts are added to the >> network. And, if there are no DHCPv6 servers and DHCPv6 capable hosts = in >> that network, sending 'O'=3DTRUE will not impact the network. >>=20 >> You are badly mistaken. >>=20 >> The O flag will cause hosts to seek information from a DHCPv6 server, >> hanging (possibly indefinitely) until that information is received. = If there is no >> DHCPv6 server available to provide that information, you have now = broken >> the network by changing the O flag without any reason to do so. >>=20 >> Owen >>=20 >>>=20 >>> Dusan >>>=20 >>>> -----Original Message----- >>>> From: Brian E Carpenter <brian.e.carpenter@gmail.com> >>>> Sent: Wednesday, August 29, 2018 6:24 PM >>>> To: David Farmer <farmer@umn.edu>; Mudric, Dusan (Dusan) >>>> <dmudric@avaya.com> >>>> Cc: v6ops@ietf.org >>>> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks >>>>=20 >>>>> On 2018-08-30 08:52, David Farmer wrote: >>>>> On Wed, Aug 29, 2018 at 3:37 PM, Mudric, Dusan (Dusan) >>>> <dmudric@avaya.com> >>>>> wrote: >>>>>=20 >>>>>>> They control the defaults for how Routers construct Router >>>>>> Advertisements. >>>>>>=20 >>>>>> And default 'O' flag set to TRUE should enabled stateless DHCPv6 = to >>>> obtain >>>>>> configuration for hosts. >>>>>=20 >>>>>=20 >>>>> Only if there is, in fact, a DHCPv6 server and it is configured = with >>>>> appropriate information. Maybe you wish to recommend net = operators >>>> deploy >>>>> DHCPv6, but change the default for the O flag in RAs is more that. >>>>>=20 >>>>> While I could be sympathetic to recommendations to provide DHCPv6 >>>> servers >>>>> on networks. However, changing the defaults for the M or O flags = is not >>>>> something I can support. If I provide a DHCPv6 server then it is = my job to >>>>> set the flags appropriately in the RA. If I don't provide a DHCPv6 = I should >>>>> not have to do anything. This is how the defaults for the M and O = flag are >>>>> currently set. >>>>=20 >>>> Exactly. Working out of the box on an unmanaged network has always >> been >>>> a goal for IPv6, even back when it was called IPng. The defaults = are >>>> set appropriately for that goal. >>>>=20 >>>> Brian >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps- = <https://urldefense.proofpoint.com/v2/url?u=3Dhttps-> >> 3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDwIFAg&c=3DBFpWQw8bsuKpl >> 1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=3D7MH >> tvme6nAWYF4uDMH3gO_auo_qxpA8VsctyigS3New&s=3DUAR1vCzZ7eYHUKdgl >> xensNPphQb9IEool0hz1ozKIFs&e=3D --Apple-Mail=_CF0C4C08-E993-4EE3-A705-E0E191F9BFEB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><br = class=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div = class=3D"">On Aug 31, 2018, at 13:21 , Mudric, Dusan (Dusan) <<a = href=3D"mailto:dmudric@avaya.com" class=3D"">dmudric@avaya.com</a>> = wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div = style=3D"" class=3D""><blockquote type=3D"cite" style=3D"font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: normal; letter-spacing: normal; orphans: auto; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; = -webkit-text-stroke-width: 0px; text-decoration: none;" class=3D"">The O = flag will cause hosts to seek information from a DHCPv6 server,<br = class=3D"">hanging (possibly indefinitely) until that information is = received. If there is no<br class=3D"">DHCPv6 server available to = provide that information, you have now broken<br class=3D"">the network = by changing the O flag without any reason to do so.<br = class=3D""></blockquote><br style=3D"caret-color: rgb(0, 0, 0); = font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none;" class=3D""><span style=3D"caret-color: rgb(0, 0, = 0); font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; float: none; display: inline !important;" = class=3D"">Possible but it is not required, by any standard that I know = about, that applications should wait indefinitely for DHCPv6 server = response.</span><br style=3D"caret-color: rgb(0, 0, 0); font-family: = Helvetica; font-size: 12px; font-style: normal; font-variant-caps: = normal; font-weight: normal; letter-spacing: normal; text-align: start; = text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: = none;" class=3D""></div></div></blockquote><div><br = class=3D""></div>Whether it=E2=80=99s required or not, it _IS_ the = actual implementation in a number of existing systems.</div><div><br = class=3D""></div><div>SO=E2=80=A6 Changing the default value in this way = breaks a lot of stuff that already exists. I=E2=80=99m not saying we = should never</div><div>do that, but there certainly needs to be a = compelling reason to do so or we shouldn=E2=80=99t do it.</div><div><br = class=3D""></div><div>So far, you have yet to provide anything remotely = resembling a compelling reason.</div><div><br = class=3D""></div><div>Owen</div><div><br class=3D""><blockquote = type=3D"cite" class=3D""><div class=3D""><div style=3D"" class=3D""><br = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: = normal; letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><span = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: = normal; letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none; float: none; = display: inline !important;" class=3D"">Dusan</span><br = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: = normal; letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none;" class=3D""><br = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: = normal; letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none;" = class=3D""><blockquote type=3D"cite" style=3D"font-family: Helvetica; = font-size: 12px; font-style: normal; font-variant-caps: normal; = font-weight: normal; letter-spacing: normal; orphans: auto; text-align: = start; text-indent: 0px; text-transform: none; white-space: normal; = widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; = -webkit-text-stroke-width: 0px; text-decoration: none;" = class=3D"">-----Original Message-----<br class=3D"">From: Owen DeLong = <<a href=3D"mailto:owen@delong.com" = class=3D"">owen@delong.com</a>><br class=3D"">Sent: Thursday, August = 30, 2018 8:17 PM<br class=3D"">To: Mudric, Dusan (Dusan) <<a = href=3D"mailto:dmudric@avaya.com" class=3D"">dmudric@avaya.com</a>><br = class=3D"">Cc: Brian E Carpenter <<a = href=3D"mailto:brian.e.carpenter@gmail.com" = class=3D"">brian.e.carpenter@gmail.com</a>>; David Farmer<br = class=3D""><<a href=3D"mailto:farmer@umn.edu" = class=3D"">farmer@umn.edu</a>>;<span = class=3D"Apple-converted-space"> </span><a = href=3D"mailto:v6ops@ietf.org" class=3D"">v6ops@ietf.org</a><br = class=3D"">Subject: Re: [v6ops] Thinking about problems in IPv6-only = networks<br class=3D""><br class=3D""><br class=3D""><br class=3D"">On = Aug 30, 2018, at 12:26, Mudric, Dusan (Dusan) <<a = href=3D"mailto:dmudric@avaya.com" class=3D"">dmudric@avaya.com</a>><br = class=3D"">wrote:<br class=3D""><br class=3D""><blockquote type=3D"cite" = class=3D""><blockquote type=3D"cite" class=3D"">Exactly. Working out of = the box on an unmanaged network has always<br = class=3D""></blockquote></blockquote>been<br class=3D""><blockquote = type=3D"cite" class=3D""><blockquote type=3D"cite" class=3D"">a goal for = IPv6,<br class=3D""></blockquote>I expected plug-and-play, or unmanaged = network, means devices<br class=3D""></blockquote>deployed to those = networks should work based on the network defaults. If<br = class=3D"">DHCPv6 is added to the network, 'O' flag needs to be set. = That means<br class=3D"">managing the network.<br class=3D""><blockquote = type=3D"cite" class=3D""><br class=3D""><blockquote type=3D"cite" = class=3D""><blockquote type=3D"cite" class=3D"">If I don't provide a = DHCPv6 I should<br class=3D"">not have to do anything.<br = class=3D""></blockquote></blockquote>Right. If nothing is added to the = network, there is no need to change the<br class=3D""></blockquote>network= configuration. But that is not the point. Plug-and-play is used when<br = class=3D"">something is added to the network. There should not be a need = to change<br class=3D"">'O' bit when DHCPv6 server and DHCPv6 capable = hosts are added to the<br class=3D"">network. And, if there are no = DHCPv6 servers and DHCPv6 capable hosts in<br class=3D"">that network, = sending 'O'=3DTRUE will not impact  the network.<br class=3D""><br = class=3D"">You are badly mistaken.<br class=3D""><br class=3D"">The O = flag will cause hosts to seek information from a DHCPv6 server,<br = class=3D"">hanging (possibly indefinitely) until that information is = received. If there is no<br class=3D"">DHCPv6 server available to = provide that information, you have now broken<br class=3D"">the network = by changing the O flag without any reason to do so.<br class=3D""><br = class=3D"">Owen<br class=3D""><br class=3D""><blockquote type=3D"cite" = class=3D""><br class=3D"">Dusan<br class=3D""><br class=3D""><blockquote = type=3D"cite" class=3D"">-----Original Message-----<br class=3D"">From: = Brian E Carpenter <<a href=3D"mailto:brian.e.carpenter@gmail.com" = class=3D"">brian.e.carpenter@gmail.com</a>><br class=3D"">Sent: = Wednesday, August 29, 2018 6:24 PM<br class=3D"">To: David Farmer <<a = href=3D"mailto:farmer@umn.edu" class=3D"">farmer@umn.edu</a>>; = Mudric, Dusan (Dusan)<br class=3D""><<a = href=3D"mailto:dmudric@avaya.com" class=3D"">dmudric@avaya.com</a>><br = class=3D"">Cc: <a href=3D"mailto:v6ops@ietf.org" = class=3D"">v6ops@ietf.org</a><br class=3D"">Subject: Re: [v6ops] = Thinking about problems in IPv6-only networks<br class=3D""><br = class=3D""><blockquote type=3D"cite" class=3D"">On 2018-08-30 08:52, = David Farmer wrote:<br class=3D"">On Wed, Aug 29, 2018 at 3:37 PM, = Mudric, Dusan (Dusan)<br class=3D""></blockquote><<a = href=3D"mailto:dmudric@avaya.com" class=3D"">dmudric@avaya.com</a>><br = class=3D""><blockquote type=3D"cite" class=3D"">wrote:<br class=3D""><br = class=3D""><blockquote type=3D"cite" class=3D""><blockquote type=3D"cite" = class=3D"">They control the defaults for how Routers construct Router<br = class=3D""></blockquote>Advertisements.<br class=3D""><br class=3D"">And = default 'O' flag set to TRUE should enabled stateless DHCPv6 to<br = class=3D""></blockquote></blockquote>obtain<br class=3D""><blockquote = type=3D"cite" class=3D""><blockquote type=3D"cite" = class=3D"">configuration for hosts.<br class=3D""></blockquote><br = class=3D""><br class=3D"">Only if there is, in fact, a DHCPv6 server and = it is configured with<br class=3D"">appropriate information.  Maybe = you wish to recommend net operators<br class=3D""></blockquote>deploy<br = class=3D""><blockquote type=3D"cite" class=3D"">DHCPv6, but change the = default for the O flag in RAs is more that.<br class=3D""><br = class=3D"">While I could be sympathetic to recommendations to provide = DHCPv6<br class=3D""></blockquote>servers<br class=3D""><blockquote = type=3D"cite" class=3D"">on networks. However, changing the defaults for = the M or O flags is not<br class=3D"">something I can support.  If = I provide a DHCPv6 server then it is my job to<br class=3D"">set the = flags appropriately in the RA. If I don't provide a DHCPv6 I should<br = class=3D"">not have to do anything. This is how the defaults for the M = and O flag are<br class=3D"">currently set.<br class=3D""></blockquote><br= class=3D"">Exactly. Working out of the box on an unmanaged network has = always<br class=3D""></blockquote></blockquote>been<br = class=3D""><blockquote type=3D"cite" class=3D""><blockquote type=3D"cite" = class=3D"">a goal for IPv6, even back when it was called IPng. The = defaults are<br class=3D"">set appropriately for that goal.<br = class=3D""><br class=3D"">   Brian<br = class=3D""></blockquote>_______________________________________________<br= class=3D"">v6ops mailing list<br class=3D""><a = href=3D"mailto:v6ops@ietf.org" class=3D"">v6ops@ietf.org</a><br = class=3D""><a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttps-"= class=3D"">https://urldefense.proofpoint.com/v2/url?u=3Dhttps-</a><br = class=3D""></blockquote>3A__www.ietf.org_mailman_listinfo_v6ops&d=3DDw= IFAg&c=3DBFpWQw8bsuKpl<br = class=3D"">1SgiZH64Q&r=3DUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&a= mp;m=3D7MH<br = class=3D"">tvme6nAWYF4uDMH3gO_auo_qxpA8VsctyigS3New&s=3DUAR1vCzZ7eYHUK= dgl<br = class=3D"">xensNPphQb9IEool0hz1ozKIFs&e=3D</blockquote></div></div></b= lockquote></div><br class=3D""></body></html>= --Apple-Mail=_CF0C4C08-E993-4EE3-A705-E0E191F9BFEB-- From nobody Fri Aug 31 20:24:03 2018 Return-Path: <owen@delong.com> X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F18130E99 for <v6ops@ietfa.amsl.com>; Fri, 31 Aug 2018 20:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.1 X-Spam-Level: X-Spam-Status: No, score=-6.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RCVD_IN_DNSWL_HI=-5, 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 A5qA6FmPJPFd for <v6ops@ietfa.amsl.com>; Fri, 31 Aug 2018 20:24:00 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [192.159.10.2]) by ietfa.amsl.com (Postfix) with ESMTP id E6E32130E09 for <v6ops@ietf.org>; Fri, 31 Aug 2018 20:23:59 -0700 (PDT) Received: from kiev.delong.com (kiev.delong.com [192.159.10.5]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id w813MusC025291 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 31 Aug 2018 20:22:59 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com w813MusC025291 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Owen DeLong <owen@delong.com> In-Reply-To: <63AFCC0D-7183-4523-AF46-118D406E3899@thehobsons.co.uk> Date: Fri, 31 Aug 2018 20:22:55 -0700 Cc: "v6ops@ietf.org list" <v6ops@ietf.org> Content-Transfer-Encoding: quoted-printable Message-Id: <FC796BAC-F0A7-4461-8FE9-EEB16A962A37@delong.com> References: <9B8DB67F-DF22-4E5D-8EC5-90E79E3C86A2@gmail.com> <33af3d07-c1be-783a-e7a7-d1674c46b51d@asgard.org> <CAD6AjGQ_OBFGJb_C+mP_87nu7q_oXPrTvxhaV_=RcubeHtMy2Q@mail.gmail.com> <E345387F-6C1D-49D4-8B03-52D04498DDA5@lists.zabbadoz.net> <a9eeba1b-76dc-a69f-aabe-04fa4ddc3a4f@gmail.com> <e560c82c-085e-60fe-2076-70e3624696c0@asgard.org> <9142206A0C5BF24CB22755C8EC422E459CB46310@AZ-US1EXMB03.global.avaya.com> <76055AE4-FF87-47E1-988A-CDB7E157C6AD@delong.com> <9142206A0C5BF24CB22755C8EC422E459CB4644F@AZ-US1EXMB03.global.avaya.com> <CAN-Dau26+uOpa9+CSf5QGmbqbmW5UisM3zxitLv12pLWRmZ8rQ@mail.gmail.com> <f2d934cb-5075-fc1c-49d5-71d4613b3b9c@gmail.com> <9142206A0C5BF24CB22755C8EC422E459CB47368@AZ-US1EXMB03.global.avaya.com> <8661280d-fc91-eb1b-2531-29bd6dbb23d8@asgard.org> <63AFCC0D-7183-4523-AF46-118D406E3899@thehobsons.co.uk> To: Simon Hobson <linux@thehobsons.co.uk> X-Mailer: Apple Mail (2.3445.9.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [192.159.10.2]); Fri, 31 Aug 2018 20:22:59 -0700 (PDT) Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/H2eSbWxUetXoziL3jYeJvMUC7cU> Subject: Re: [v6ops] Thinking about problems in IPv6-only networks X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: v6ops discussion list <v6ops.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe> List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/> List-Post: <mailto:v6ops@ietf.org> List-Help: <mailto:v6ops-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe> X-List-Received-Date: Sat, 01 Sep 2018 03:24:02 -0000 > On Aug 31, 2018, at 13:52 , Simon Hobson <linux@thehobsons.co.uk> = wrote: >=20 > Lee Howard <lee@asgard.org> wrote: >=20 >> An "unmanaged network" that is "based on the network defaults" sounds = like it's in conflict with a server being "added to the network." >=20 > Not really. If you add a SERVER (such as DHCP6) then you are = implicitly making it a managed network. At that point, you also take on = responsibility for configuring the network as such - ie setting the M = and/or O flags in the RAs. >=20 >> The M bit means there are addresses available via DHCPv6. It doesn't = mean you have to use them. >> The O bit means there is other configuration information available = via DHCPv6. It is redundant if the M bit is set. >> Neither requires a device to pay attention to them. >=20 > I may be wrong, but I was under the impression that if the M bit is = set, then the client is required to use DHCP to configure address(es) = and not auto-configure. Thus if the M bit is set and there is no DHCP = server, clients simply will not work. My understanding was that there=E2=80=99s an exception for clients which = don=E2=80=99t support DHCPv6 (which is, after all, optional). > None of this is inconsistent. An unmanaged network means that someone = has thrown it together, accepting the default settings for RAs etc - and = with some expectation that the router will get a working config = (suitable prefix assignment) from upstream. Thus an unskilled person can = put together a basic network with some expectation of "it just works" - = much as happens when a user gets the ISP supplied router which uses = something like TR069 to automatically get the required config and within = a short time of plugging it in, give the user a working internet = connection and LAN. Well=E2=80=A6 Actually, an unmanaged network can still involve some = manual configuration of the router insofar as the M bit definition of = managed or not would mean it. Most of my unmanaged IPv6-only networks do have manually configured = router interfaces, and, in some cases, manually configured host = addresses as well. >=20 >> How does a router (a thing sending RAs) know a DHCPv6 server has been = added to the network? >=20 > Because the network administrator tells it. If there's a DHCP server, = then it's not a basic unmanaged network. If it's managed then there's an = admin responsible for it. You guys are seeming to disagree while actually agreeing. Lee's response = was aimed at Dusan=E2=80=99s desire to make O=3D1 the default for RAs = unless the administrator deliberately turns it off on the router. > It would be possible for a router manufacturer to obfuscate this by = providing a suitable GUI to configure and enable a DHCP server, and as a = side effect, turn on the M and/or O bits in the RAs issued by **that = router**. That would be OK for small routers (SOHO) where typically = there is only the one router and one internet connection. Sure, nothing at all wrong with that. However, I don=E2=80=99t think = anyone is disputing this. Owen