From nobody Tue Dec 1 08:31:11 2020 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 448093A1440 for ; Tue, 1 Dec 2020 08:31:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 u7G_EDWWQCnM for ; Tue, 1 Dec 2020 08:30:56 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5723A1479 for ; Tue, 1 Dec 2020 08:30:50 -0800 (PST) Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 81CA51B00062; Tue, 1 Dec 2020 16:30:44 +0000 (GMT) References: From: Gorry Fairhurst To: v6ops@ietf.org Cc: fernando@gont.com.ar, Gorry Fairhurst , fredbaker.ietf@gmail.com X-Forwarded-Message-Id: Message-ID: <0c121812-44cf-119e-fd09-bb138ff789de@erg.abdn.ac.uk> Date: Tue, 1 Dec 2020 16:30:43 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------D972FB92435BE6F001DD5AC6" Content-Language: en-GB Archived-At: Subject: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-packet-drops-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2020 16:31:10 -0000 This is a multi-part message in MIME format. --------------D972FB92435BE6F001DD5AC6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I promised a  careful read of this ID at the last v6OPS meeting, and this is it. * First, I think this is a useful document to help understand what is happening in operational networks and reasons for this. It's also a ueseful input for planning standards actions in 6man, etc. Thanks for doing this. * I have some concerns that some of the choices of words could (unintentionally) be taken as endorsing a best practice, which I don't think the IETF would generally promote. This is more about ensuring specific parts can not be quoted out of context. I did a careful read and hope I identified most of these and propose something that might be helpful (please see attached PDF - RTF is identical). I think it would be good to clarify in a few places this is the RFC8200 spec, since I have heard there could be new work to update that. * On the measurement evidence: I have  a slight concern that the results might not cover the wide variety of use cases and you may like to be more careful in the words you use to generalise these for the "internet".  I think we should be aware that in some scenarios an EH might still be effectively used, where path can safely support this. In some other uses, the fact that packets with these options might be expected to be dropped by many paths - for good reasons, does not mean that the option is useless to set in general - it might merely be that for these paths it is not possible to use the option and then care is needed in deciding which packets set the EH and how this is used. Hope this helps, Fernando. If you need any clarification or other help, just let me know, Gorry --- --------------D972FB92435BE6F001DD5AC6 Content-Type: text/rtf; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="draft-ietf-v6ops-ipv6-ehs-packet-drops.rtf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-v6ops-ipv6-ehs-packet-drops.rtf" {\rtf1\ansi\ansicpg1252\cocoartf1561\cocoasubrtf610 {\fonttbl\f0\fmodern\fcharset0 Courier;} {\colortbl;\red255\green255\blue255;\red0\green0\blue0;\red0\green0\blue0;\red255\green255\blue10; \red33\green255\blue6;\red253\green128\blue8;\red255\green255\blue10;\red255\green255\blue255;\red33\green255\blue6; \red251\green2\blue7;\red253\green128\blue8;} {\*\expandedcolortbl;;\cssrgb\c0\c0\c0;\csgray\c0\c0;\cssrgb\c99942\c98555\c0; \cssrgb\c0\c97680\c0;\cssrgb\c100000\c57637\c0;\cssrgb\c99942\c98555\c0;\csgray\c100000;\cssrgb\c0\c97680\c0; \cssrgb\c100000\c14913\c0;\cssrgb\c100000\c57637\c0;} \paperw11900\paperh16840\margl1440\margr1440\vieww15700\viewh14280\viewkind0 \deftab720 \pard\pardeftab720\sl280\partightenfactor0 \f0\fs24 \cf2 \expnd0\expndtw0\kerning0 \outl0\strokewidth0 \strokec2 \ \ \ IPv6 Operations Working Group (v6ops) F. Gont\ Internet-Draft SI6 Networks\ Intended status: Informational N. Hilliard\ Expires: April 17, 2021 INEX\ G. Doering\ SpaceNet AG\ W. Kumari\ Google\ G. Huston\ APNIC\ W. Liu\ Huawei Technologies\ October 14, 2020\ \ \ \cb3 Operational Implications of IPv\cb1 6 Packets with Extension Headers\ draft-ietf-v6ops-ipv6-ehs-packet-drops-01\ \ Abstract\ \ This document summarizes \cb3 the operational implications \cb1 of IPv6\ extension headers \cb4 specified in the IPv6\ Protocol Specification (RFC8200)\ \cb1 \ \cb5 >>> Suggest direct reference to the spec here, because there is proposed\ >>> work behind the scenes to update the spec, in light of the problems\ >>> described here, and the rFC-to-be should refer to what is currently\ >>> specified\ \cb1 \ , and attempts to analyze reasons why packets with\ IPv6 extension headers \cb6 have been\cb1 dropped in the public Internet.\ \ \cb5 >>> avoid any words that could be mis-read (by me and others?) \ >>> to infer permission to drop.\ \cb1 \ Status of This Memo\ \ This Internet-Draft is submitted in full conformance with the\ provisions of BCP 78 and BCP 79.\ \ Internet-Drafts are working documents of the Internet Engineering\ Task Force (IETF). Note that other groups may also distribute\ working documents as Internet-Drafts. The list of current Internet-\ Drafts is at https://datatracker.ietf.org/drafts/current/.\ \ Internet-Drafts are draft documents valid for a maximum of six months\ and may be updated, replaced, or obsoleted by other documents at any\ time. It is inappropriate to use Internet-Drafts as reference\ material or to cite them other than as "work in progress."\ \ This Internet-Draft will expire on April 17, 2021.\ \ Copyright Notice\ \ Copyright (c) 2020 IETF Trust and the persons identified as the\ document authors. All rights reserved.\ \ This document is subject to BCP 78 and the IETF Trust's Legal\ Provisions Relating to IETF Documents\ \ \ \ Gont, et al. Expires April 17, 2021 [Page 1]\ \page \ Internet-Draft IPv6 Extension Headers October 2020\ \ \ (https://trustee.ietf.org/license-info) in effect on the date of\ publication of this document. Please review these documents\ carefully, as they describe your rights and restrictions with respect\ to this document. Code Components extracted from this document must\ include Simplified BSD License text as described in Section 4.e of\ the Trust Legal Provisions and are provided without warranty as\ described in the Simplified BSD License.\ \ Table of Contents\ \ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2\ 2. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . 3\ 3. Background Information . . . . . . . . . . . . . . . . . . . 3\ 4. Previous Work on IPv6 Extension Headers . . . . . . . . . . . 5\ 5. Packet Forwarding Engine Constraints . . . . . . . . . . . . 7\ 5.1. Recirculation . . . . . . . . . . . . . . . . . . . . . . 8\ 6. Requirement to Process Layer-3/layer-4 information in\ Intermediate Systems . . . . . . . . . . . . . . . . . . . . 8\ 6.1. ECMP and Hash-based Load-Sharing . . . . . . . . . . . . 8\ 6.2. Enforcing infrastructure ACLs . . . . . . . . . . . . . . 9\ 6.3. DDoS Management and Customer Requests for Filtering . . . 9\ 6.4. Network Intrusion Detection and Prevention . . . . . . . 10\ 6.5. Firewalling . . . . . . . . . . . . . . . . . . . . . . . 10\ 7. Operational Implications . . . . . . . . . . . . . . . . . . 11\ 7.1. Inability to Find Layer-4 Information . . . . . . . . . . 11\ 7.2. Route-Processor Protection . . . . . . . . . . . . . . . 11\ 7.3. Inability to Perform Fine-grained Filtering . . . . . . . 12\ 7.4. Security Concerns Associated with IPv6 Extension Headers 12\ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13\ 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13\ 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13\ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14\ 11.1. Normative References . . . . . . . . . . . . . . . . . . 14\ 11.2. Informative References . . . . . . . . . . . . . . . . . 15\ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19\ \ 1. Introduction\ \ IPv6 Extension Headers (EHs) allow for the extension of the IPv6\ protocol, and provide support for core functionality such as IPv6\ fragmentation. However, common implementation limitations suggest\ that EHs present a challenge for IPv6 packet routing equipment and\ middle-boxes, and evidence exists that IPv6 packets with EHs \cb6 have been\cb1 \ \ \pard\pardeftab720\sl280\partightenfactor0 \cf2 \outl0\strokewidth0 >>> avoid any wors that could be mis-read (by me and others?) \ >>> to infer permission to drop.\cf2 \outl0\strokewidth0 \strokec2 \ \pard\pardeftab720\sl280\partightenfactor0 \cf2 \ intentionally dropped in the public Internet in some network\ deployments.\ \ The authors of this document have been involved in numerous\ discussions about IPv6 extension headers (both within the IETF and in\ \ \ \ Gont, et al. Expires April 17, 2021 [Page 2]\ \page \ Internet-Draft IPv6 Extension Headers October 2020\ \ \ other fora), and have noticed that the security and operational\ implications associated with IPv6 EHs were unknown to the larger\ audience participating in these discussions.\ \ This document has the following goals:\ \ o Raise awareness about the operational and security implications of\ \cb4 IPv6 Extension Headers \cf2 \cb7 \outl0\strokewidth0 specified in the IPv6\ \pard\pardeftab720\sl280\partightenfactor0 \cf2 Protocol Specification (RFC8200)\ \pard\pardeftab720\sl280\partightenfactor0 \cf2 \cb4 \outl0\strokewidth0 \strokec2 ,\cb1 and presents reasons why some networks \cb6 might\ \cb8 \ \pard\pardeftab720\sl280\partightenfactor0 \cf2 \cb5 \outl0\strokewidth0 >>> avoid any words that could be mis-read (by me and others?) \ >>> to infer permission to drop.\ \pard\pardeftab720\sl280\partightenfactor0 \cf2 \cb1 \outl0\strokewidth0 \strokec2 \ intentionally drop packets containing IPv6 Extension Headers.\ \ o Highlight areas where current IPv6 support by networking devices\ maybe sub-optimal, such that the aforementioned support is\ improved.\ \ o Highlight operational issues associated with IPv6 extension\ headers, such that those issues are considered in IETF\ standardization efforts.\ \ Section 3 provides background information about the IPv6 packet\ structure and associated implications. Section 4 of this document\ summarizes the previous work that has been carried out in the area of\ IPv6 extension headers. Section 5 discusses packet forwarding engine\ constraints in contemporary routers. Section 6 discusses why\ contemporary routers and middle-boxes may need to access Layer-4\ information to make a forwarding decision. Finally, Section 7\ discusses the operational implications of IPv6 EHs.\ \ 2. Disclaimer\ \ This document analyzes the operational challenges represented by\ packets that employ IPv6 Extension Headers, and documents some of the\ operational reasons why these packets \cb6 are being\cb1 dropped in the public\ \ \pard\pardeftab720\sl280\partightenfactor0 \cf2 \cb9 \outl0\strokewidth0 >>> /have been/ or /are being/? to avoid any words that could \ >>> be mis-read (by me and others?) to infer permission to drop.\ \pard\pardeftab720\sl280\partightenfactor0 \cf2 \cb1 \outl0\strokewidth0 \strokec2 \ \pard\pardeftab720\sl280\partightenfactor0 \cf2 Internet. This document is not a recommendation to drop such\ packets, but rather an analysis of why they are dropped.\ \ \cb5 >>> Looks good.\ \cb1 \ 3. Background Information\ \ It is useful to compare the basic structure of IPv6 packets against\ that of IPv4 packets, and analyze the implications of the two\ different packet structures.\ \ IPv4 packets have a variable-length header size, that allows for the\ use of IPv4 "options" -- optional information that may be of use by\ nodes processing IPv4 packets. The IPv4 header length is specified\ in the IHL header field of the mandatory IPv4 header, and must be in\ the range from 20 octets (the minimum IPv4 header size) to 60 octets\ (accommodating at most 40 octets of options). The upper-layer\ \ \ \ \ Gont, et al. Expires April 17, 2021 [Page 3]\ \page \ Internet-Draft IPv6 Extension Headers October 2020\ \ \ protocol type is specified via the "Protocol" field of the mandatory\ IPv4 header.\ \ Protocol, IHL\ +--------+\ | |\ | v\ +------//-----+------------------------+\ | | |\ | IPv4 | Upper-Layer |\ | Header | Protocol |\ | | |\ +-----//------+------------------------+\ \ variable length\ <------------->\ \ Figure 1: IPv4 Packet Structure\ \ IPv6 took a different approach to the IPv6 packet structure. Rather\ than employing a variable-length header as IPv4 does, IPv6 employs a\ linked-list-like packet structure, where a mandatory fixed-length\ IPv6 header is followed by an arbitrary number of optional extension\ headers, with the upper-layer header being the last header in the\ IPv6 header chain. Each extension header typically specifies its\ length (unless it is implicit from the extension header type), and\ the "next header" type that follows in the IPv6 IPv6 header chain.\ \ NH NH, EH-length NH, EH-length\ +-------+ +------+ +-------+\ | | | | | |\ | v | v | v\ +-------------+-------------+-//-+---------------+--------------+\ | | | | | |\ | IPv6 | Ext. | | Ext. | Upper-Layer |\ | header | Header | | Header | Protocol |\ | | | | | |\ +-------------+-------------+-//-+---------------+--------------+\ \ fixed length variable number of EHs & length\ <------------> <-------------------------------->\ \ Figure 2: IPv6 Packet Structure\ \ This packet structure has the following implications:\ \ \ \ \ \ \ Gont, et al. Expires April 17, 2021 [Page 4]\ \page \ Internet-Draft IPv6 Extension Headers October 2020\ \ \ o [RFC8200] requires the entire IPv6 header chain to be contained in\ the first fragment of a packet, therefore limiting the IPv6\ extension header chain to the size of t\cb3 he Path-MTU.\cb1 \ \ o Other than the Path-MTU constraints, there are no other limits to\ the number of IPv6 EHs that may be present in a packet.\ Therefore, there is no upper-limit regarding "how deep into the\ IPv6 packet" the upper-layer may be found.\ \ o The only way for a node to obtain the upper-layer protocol type or\ find the upper-layer protocol header is to parse and process the\ entire IPv6 header chain, in sequence, starting from the mandatory\ IPv6 header, until the last header in the IPv6 header chain is\ found.\ \ 4. Previous Work on IPv6 Extension Headers\ \ Some of the operational implications of IPv6 Extension Headers have\ been discussed in IETF circles:\ \ o [I-D.taylor-v6ops-fragdrop] discusses a rationale for which\ operators drop IPv6 fragments.\ \ o [I-D.wkumari-long-headers] discusses possible issues arising from\ "long" IPv6 header chains.\ \ o [I-D.kampanakis-6man-ipv6-eh-parsing] describes how\ inconsistencies in the way IPv6 packets with extension headers are\ parsed by different implementations may result in evasion of\ security controls, and presents guidelines for parsing IPv6\ extension headers with the goal of providing a common and\ consistent parsing methodology for IPv6 implementations.\ \ o [I-D.ietf-opsec-ipv6-eh-filtering] analyzes the security\ implications of IPv6 EHs, and the operational implications of\ dropping packets that employ IPv6 EHs and associated options.\ \ o [RFC7113] discusses how some popular RA-Guard implementations are\ subject to evasion by means of IPv6 extension headers.\ \ o [RFC8900] analyzes the fragility introduced by IP fragmentation.\ \ A number of recent RFCs have discussed issues related to IPv6\ extension headers, specifying updates to a previous revision of the\ IPv6 standard ([RFC2460]), many of which have now been incorporated\ into the current IPv6 core standard ([RFC8200]) or the IPv6 Node\ Requirements ([RFC8504]). Namely,\ \ \ \ \ Gont, et al. Expires April 17, 2021 [Page 5]\ \page \ Internet-Draft IPv6 Extension Headers October 2020\ \ \ o [RFC5095] discusses the security implications of Routing Header\ Type 0 (RTH0), and deprecates it.\ \ o [RFC5722] analyzes the security implications of overlapping\ fragments, and provides recommendations in this area.\ \ o [RFC7045] clarifies how intermediate nodes should deal with IPv6\ extension headers.\ \ o [RFC7112] discusses the issues arising in a specific fragmentation\ case where the IPv6 header chain is fragmented into two or more\ fragments (and formally forbids such fragmentation case).\ \ o [RFC6946] discusses a flawed (but common) processing of the so-\ called IPv6 "atomic fragments", and specified improved processing\ of such packets.\ \ o [RFC8021] deprecates the generation of IPv6 atomic fragments.\ \ o [RFC8504] clarifies processing rules for packets with extension\ headers, and also allows hosts to enforce limits on the number of\ options included in IPv6 EHs.\ \ o [RFC7739] discusses the security implications of predictable\ fragment Identification values, and provides recommendations for\ the generation of these values.\ \ o [RFC6980] analyzes the security implications of employing IPv6\ fragmentation with Neighbor Discovery for IPv6, and formally\ recommends against such usage.\ \ Additionally, [RFC8200] has relaxed the requirement that "all nodes\ examine and process the Hop-by-Hop Options header" from [RFC2460], by\ specifying that only nodes that have been explicitly configured to\ process the Hop-by-Hop Options header are required to do so.\ \ A number of studies have measured the extent to which packets\ employing IPv6 extension headers are dropped in the public Internet:\ \ o [PMTUD-Blackholes], [\cb10 Gont-IEPG88\cb1 ], [\cb10 Gont-Chown-IEPG89\cb1 ], and\ \cb8 [Linkova-Gont-IEPG90\cb1 ] presented some preliminary measurements\ regarding the extent to which packet containing IPv6 EHs are\ dropped in the public Internet.\ \ o [RFC7872] presents more comprehensive results and documents the\ methodology for obtaining the presented results.\ \ \ \ \ \ Gont, et al. Expires April 17, 2021 [Page 6]\ \page \ Internet-Draft IPv6 Extension Headers October 2020\ \ \ o [Huston-2017] and [Huston-2020] measured packet drops resulting\ from IPv6 fragmentation when communicating with DNS servers.\ \ 5. Packet Forwarding Engine Constraints\ \ Most contemporary routers use dedicated hardware (e.g. ASICs or\ NPUs) to determine how to forward packets across their internal\ fabrics (see [IEPG94-Scudder] and [APNIC-Scudder] for details). One\ of the common methods of handling next-hop lookup is to send a small\ portion of the ingress packet to a lookup engine with specialised\ hardware (e.g. ternary CAM or RLDRAM) to determine the packet's next-\ hop. Technical constraints mean that there is a trade-off between\ the amount of data sent to the lookup engine and the overall\ performance of the lookup engine. If more data is sent, the lookup\ engine can inspect further into the packet, but the overall\ performance of the system will be reduced. If less data is sent, the\ overall performance of the router will be increased but the packet\ lookup engine may not be able to inspect far enough into a packet to\ determine how it should be handled.\ \ NOTE:\ For example, contemporary high-end routers can use up to 192 bytes\ of header (Cisco ASR9000 Typhoon) or 384 bytes of header (Juniper\ MX Trio).\ \ If a hardware forwarding engine on a contemporary router cannot make\ a forwarding decision about a packet because critical information is\ not sent to the look-up engine, then the router will normally drop\ the packet.\ \ NOTE:\ Section 6 discusses some of the reasons for which a contemporary\ router might need to access layer-4 information to make a\ forwarding decision.\ \ Historically, some packet forwarding engines punted packets of this\ form to the control plane for more in-depth analysis, but this is\ unfeasible on most current router architectures as a result of the\ vast difference between the hardware forwarding capacity of the\ router and processing capacity of the control plane and the size of\ the management link which connects the control plane to the\ forwarding plane.\ \ If an IPv6 header chain is sufficiently long that its header exceeds\ the packet look-up capacity of the router, then it \cb6 would be dropped by\cb1 \ \cb6 hardware that is unable \cb1 to determine how it should be handled.\ \ \ \pard\pardeftab720\sl280\partightenfactor0 \cf2 \cb5 \outl0\strokewidth0 >>> might? .... In this case it would: \'93would be dropped by hardware that is unable...\ \pard\pardeftab720\sl280\partightenfactor0 \cf2 \cb1 \outl0\strokewidth0 \strokec2 \ \ \ Gont, et al. Expires April 17, 2021 [Page 7]\ \page \ Internet-Draft IPv6 Extension Headers October 2020\ \ \ 5.1. Recirculation\ \ Although TLV chains are amenable to iterative processing on\ architectures \cb6 that\cb1 have packet look-up engines with deep inspection\ \ \cb5 >>> is this /that/ ?\ \cb1 \ capabilities, some packet forwarding engines manage IPv6 Extension\ Header chains using recirculation. This approach processes Extension\ Headers one at a time: when processing on one Extension Header is\ completed, the packet is looped back through the processing engine\ again. This recirculation process continues repeatedly until there\ are no more Extension Headers left to be processed.\ \ Recirculation is typically used on packet forwarding engines with\ limited look-up capability, \cb6 because\cb1 it allows arbitrarily long header\ \ \cb5 >>> /as/because/\ \cb1 \ chains to be processed without the complexity and cost associated\ with packet forwarding engines which have deep look-up capabilities.\ However, recirculation can impact the forwarding capacity of\ hardware, as each packet will pass through the processing engine\ multiple times. Depending on configuration, the type of packets\ being processed, and the hardware capabilities of the packet\ forwarding engine, this may impact data-plane throughput performance\ on the router.\ \ 6. Requirement to Process Layer-3/layer-4 information in Intermediate\ Systems\ \ The following subsections discuss some \cb6 of the \cb1 reasons for which\ \ \cb5 >>> add the \ \cb1 \ contemporary routers and middle-boxes may need to process Layer-3/\ layer-4 information to make a forwarding decision.\ \ 6.1. ECMP and Hash-based Load-Sharing\ \ In the case of ECMP (equal cost multi path) load sharing, the router\ on the sending side of the link needs to make a decision regarding\ which of the links to use for a given packet. Since round-robin\ usage of the links is usually avoided \cb6 to\cb1 prevent packet\ \ \cb5 >> remove /in order/ which does not work when talking about order\ \cb1 \ reordering, forwarding engines need to use a mechanism \cb6 that\cb1 will\ consistently forward the same data streams down the same forwarding\ paths. Most forwarding engines achieve this by calculating a simple\ hash using an n-tuple gleaned from a combination of layer-2 through\ to layer-4 packet header information. This n-tuple will typically\ use the src/dst MAC address, src/dst IP address, and if possible\ further layer-4 src/dst port information. \cb4 As layer-4 port\ information increases the entropy of the hash, it is normally highly\ desirable to use it where possible.\ \cb1 \ \cb5 >>> I don\'92t agree with that actually, - but maybe others think so, please check\ >>> RFCs relating to ECMP or perhaps rephrase, something like: /\cf2 \cb11 \outl0\strokewidth0 Layer-4 port\ \pard\pardeftab720\sl280\partightenfactor0 \cf2 information can increase the entropy of the hash, and is often\ thought desirable to use it where it is available.\ \cf2 \cb5 \outl0\strokewidth0 \strokec2 /?\ \pard\pardeftab720\sl280\partightenfactor0 \cf2 \cb1 \ We note that in the IPv6 world, flows are expected to be identified\ by means of the IPv6 Flow Label [RFC6437]. Thus, ECMP and Hash-based\ Load-Sharing \cb6 is possible\cb1 without the need to process the entire\ \ \cb6 >>> why /would be possible/ ... some networks do this, and many RFCs encourage this?\ \cb1 \ Gont, et al. Expires April 17, 2021 [Page 8]\ \page \ Internet-Draft IPv6 Extension Headers October 2020\ \ \ IPv6 header chain to obtain upper-layer information to identify\ flows. However, we note that for \cb4 a long time\cb1 many IPv6\ implementations failed to set the Flow Label, \cb4 and ECMP and Hash-based\ Load-Sharing devices also did not employ the Flow Label for\ performing their task.\ \cb1 \ \ \cb5 >>> /also did not employ/\ >>> do you really need to claim that? I suggest we could write this\ >>> in more neutral language, since some implementations recently \ >>> changed this practice? Perhaps;\ >>> \cb6 /\cf2 \outl0\strokewidth0 When many IPv6\ \pard\pardeftab720\sl280\partightenfactor0 \cf2 >>> implementations failed to set the Flow Label, many ECMP and Hash-based\ >>> Load-Sharing devices also did not include the Flow Label [Cunha-2020],\ >>> possibly as a result of issues that have been found\ >>> in host implementations and middle-boxes [Jaeggli-2018].\cf2 \cb7 /\ \cf2 \cb5 >>> although it seems like you should somehow point to RFCs that say that\ >>> you should do this.\ \pard\pardeftab720\sl280\partightenfactor0 \cf2 \outl0\strokewidth0 \strokec2 \ \cb1 \ Clearly, widespread support of [RFC6437] would relieve middle-boxes\ from having to process the entire IPv6 header chain, making Flow\ Label-based ECMP and Hash-based Load-Sharing [RFC6438] feasible.\ \ \cb4 While support of [RFC6437] is currently widespread for current\ versions of all popular host implementations, there is still only\ marginal usage of the IPv6 Flow Label for ECMP and load balancing\ [Cunha-2020] -- possibly as a result of issues that have been found\ in host implementations and middle-boxes [Jaeggli-2018].\ \ \pard\pardeftab720\sl280\partightenfactor0 \cf2 \cb9 \outl0\strokewidth0 >>> The text in this para seems to be related to the para 2 before.\cf2 \cb4 \outl0\strokewidth0 \strokec2 \ \pard\pardeftab720\sl280\partightenfactor0 \cf2 \cb1 \ \ \pard\pardeftab720\sl280\partightenfactor0 \cf2 \cb9 \outl0\strokewidth0 >>> I suggest the section includes mention of the IETF recommendation,\ >>> and there the path with \'93clearly...\'94 should be at the end!\cf2 \cb7 \ \pard\pardeftab720\sl280\partightenfactor0 \cf2 \cb1 \outl0\strokewidth0 \strokec2 \ \ 6.2. Enforcing infrastructure ACLs\ \ Generally speaking, infrastructure ACLs (iACLs) drop unwanted packets\ destined to parts of a provider's infrastructure, because they are\ not operationally needed and can be used for attacks of different\ sorts against router control planes. Some traffic needs to be\ differentiated depending on layer-3 or layer-4 criteria to achieve a\ useful balance of protection and functionality, for example:\ \ o Permit some amount of ICMP echo (ping) traffic towards a router's\ addresses for troubleshooting.\ \ o Permit BGP sessions on the shared network of an exchange point\ (potentially differentiating between the amount of packets/seconds\ permitted for established sessions and connection establishment),\ but do not permit other traffic from the same peer IP addresses.\ \ 6.3. DDoS Management and Customer Requests for Filtering\ \ The case of customer DDoS protection and edge-to-core customer\ protection filters is similar in nature to the infrastructure ACL\ protection. Similar to infrastructure ACL protection, layer-4 ACLs\ generally need to be applied as close to the edge of the network as\ possible, even though the intent is usually to protect the customer\ edge rather than the provider core. Application of layer-4 DDoS\ protection to a network edge is often automated using Flowspec\ [RFC5575].\ \ For example, a web site \cb6 that\cb1 normally only handled traffic on TCP\ ports 80 and 443 could be subject to a volumetric DDoS attack using\ NTP and DNS packets with randomised source IP address, thereby\ rendering traditional [RFC5635] source-based real-time black hole\ \ \ \ Gont, et al. Expires April 17, 2021 [Page 9]\ \page \ Internet-Draft IPv6 Extension Headers October 2020\ \ \ mechanisms useless. In this situation, DDoS protection ACLs could be\ configured to block all UDP traffic at the network edge without\ impairing the web server functionality in any way. Thus, being able\ to block arbitrary protocols at the network edge can avoid DDoS-\ related problems both in the provider network and on the customer\ edge link.\ \ 6.4. Network Intrusion Detection and Prevention\ \ Network Intrusion Detection Systems (NIDS) examine network traffic\ and try to identify traffic patterns that can be correlated to\ network-based attacks. These systems generally inspect application-\ layer traffic (if possible), but at the bare minimum inspect layer-4\ flows. When attack activity is inferred, the operator is signaled of\ the potential intrusion attempt.\ \ Network Intrusion Prevention Systems (IPS) operate similarly to\ NIDS's, but they may also prevent intrusions by reacting to detected\ attack attempts by e.g.\cb6 ,\cb1 triggering packet filtering policies at\ firewalls and other devices.\ \ Use of extension headers \cb6 can\cb1 result problematic for NIDS/IPS, since:\ \ \cb5 >>/may/can/ ... not necessary, but might as well use /can/ in this case?\ \cb1 \ o Extension headers increase the complexity of resulting traffic,\ and the associated work and system requirements to process it.\ \ o Use of unknown extension headers \cb6 can\cb1 prevent an NIDS/IPS to\ process layer-4 information\ \ o Use of IPv6 fragmentation requires a stateful fragment-reassembly\ operation, even for decoy traffic employing forged source\ addresses (see e.g. [nmap]).\ \ As a result, in order to increase the efficiency or effectiveness of\ these systems, packets employing IPv6 extension headers \cb6 can\cb1 be\ \ \cb5 >>> /can/ or /have been/are being/ ... to follow the previous argument?\ \cb1 \ dropped at the network ingress point(s) of networks that deploy these\ systems.\ \ 6.5. Firewalling\ \ Firewalls enforce security policies by means of packet filtering.\ These systems generally inspect layer-3 and layer-4 traffic, and may\ also examine application-layer traffic flows.\ \ As with NIDS/IPS (Section 6.4), use of IPv6 extension headers may\ represent a challenge to network firewalls, since:\ \ \ \ \ \ Gont, et al. Expires April 17, 2021 [Page 10]\ \page \ Internet-Draft IPv6 Extension Headers October 2020\ \ \ o Extension headers increase the complexity of resulting traffic,\ and the associated work and system requirements to process it (see\ e.g. [Zack-FW-Benchmark]).\ \ o Use of unknown extension headers \cb6 can\cb1 prevent an NIDS/IPS to\ process layer-4 information\ \ o Use of IPv6 fragmentation requires a stateful fragment-reassembly\ operation, even for decoy traffic employing forged source\ addresses (see e.g. [nmap]).\ \ Additionally, a common firewall filtering policy is the so-called\ "default deny", where all traffic is blocked (by default), and only\ expected traffic is added to an "allow/accept list".\ \ As a result, whether because of the challenges represented by\ extension headers or because the use of IPv6 extension headers has\ not been explicitly allowed, packets employing IPv6 extension headers\ \cb6 can\cb1 be dropped by network firewalls.\ \ \pard\pardeftab720\sl280\partightenfactor0 \cf2 \cb9 \outl0\strokewidth0 >>> /can/ or /have been/are being/ ... to follow the previous argument?\ \pard\pardeftab720\sl280\partightenfactor0 \cf2 \cb1 \outl0\strokewidth0 \strokec2 \ \ 7. Operational Implications\ \ 7.1. Inability to Find Layer-4 Information\ \ As discussed in Section 6, contemporary routers and middle-boxes that\ need to find the layer-4 header must process the entire IPv6\ extension header chain. When such devices are unable to obtain the\ required information, they \cb6 might\cb1 simply resort to dropping the\ \ \cb5 >>> /may/might/ ?\ \cb1 \ corresponding packets.\ \ 7.2. Route-Processor Protection\ \ Most contemporary routers have a fast hardware-assisted forwarding\ plane and a loosely coupled control plane, connected together with a\ link that has much less capacity than the forwarding plane could\ handle. Traffic differentiation cannot be done by the control plane\ side, because this would overload the internal link connecting the\ forwarding plane to the control plane.\ \ The Hop-by-Hop Options header has been particularly challenging since\ in most circumstances, the corresponding packet is punted to the\ control plane for processing. As a result, operators usually drop\ IPv6 packets containing this extension header. Please see [RFC6192]\ for advice regarding protection of the router control plane.\ \ \ \ \ \ \ \ Gont, et al. Expires April 17, 2021 [Page 11]\ \page \ Internet-Draft IPv6 Extension Headers October 2020\ \ \ 7.3. Inability to Perform Fine-grained Filtering\ \ Some router implementations lack fine-grained filtering of IPv6\ extension headers. For example, an operator may want to drop packets\ containing Routing Header Type 0 (RHT0) but may only be able to\ filter on the extension header type (Routing Header). As a result,\ the operator \cb6 would\cb1 end up enforcing a more coarse filtering policy\ (e.g. "drop all packets containing a Routing Header" vs. "only drop\ packets that contain a Routing Header Type 0").\ \ 7.4. Security Concerns Associated with IPv6 Extension Headers\ \ The security implications of IPv6 Extension Headers generally fall\ into one or more of these categories:\ \ o Evasion of security controls\ \ o DoS due to processing requirements\ \ o DoS due to implementation errors\ \ o Extension Header-specific issues\ \ Unlike IPv4 packets where the upper-layer protocol can be trivially\ found by means of the "IHL" ("Internet Header Length") IPv4 header\ field, the structure of IPv6 packets is more flexible and complex,\ and may represent a challenge for devices that need to find this\ information, since locating upper-layer protocol information requires\ that all IPv6 extension headers be examined. This has presented\ implementation difficulties, and packet filtering mechanisms that\ require upper-layer information (even if just the upper layer\ protocol type) can be trivially circumvented by inserting IPv6\ Extension Headers between the main IPv6 header and the upper layer\ protocol. [RFC7113] describes this issue for the RA-Guard case, but\ the same techniques \cb6 could\cb1 be employed to circumvent other IPv6 firewall\ and packet filtering mechanisms. Additionally, implementation\ inconsistencies in packet forwarding engines \cb6 can\cb1 result in evasion of\ security controls [I-D.kampanakis-6man-ipv6-eh-parsing] [Atlasis2014]\ [BH-EU-2014].\ \ Packets with attached IPv6 Extension Headers \cb6 can\cb1 impact performance\ on routers that forward them. Unless appropriate mitigations are put\ in place (e.g., packet dropping and/or rate-limiting), an attacker\ could simply send a large amount of IPv6 traffic employing IPv6\ Extension Headers with the purpose of performing a Denial of Service\ (DoS) attack (see Section 7 for further details).\ \ NOTE:\ \ \ \ Gont, et al. Expires April 17, 2021 [Page 12]\ \page \ Internet-Draft IPv6 Extension Headers October 2020\ \ \ In the most trivial case, a packet that includes a Hop-by-Hop\ Options header might go through the slow forwarding path, and be\ processed by the router's CPU. Another possible case might be\ where a router that has been configured to enforce an ACL based on\ upper-layer information (e.g., upper layer protocol or TCP\ Destination Port), needs to process the entire IPv6 header chain\ (in order to find the required information), causing the packet to\ be processed in the slow path [Cisco-EH-Cons]. We note that, for\ obvious reasons, the aforementioned performance issues may affect\ other devices such as firewalls, Network Intrusion Detection\ Systems (NIDS), etc. [Zack-FW-Benchmark]. The extent to which\ these devices are affected is typically implementation-dependent.\ \ IPv6 implementations, like all other software, tend to mature with\ time and wide-scale deployment. While the IPv6 protocol itself has\ existed for over 20 years, serious bugs related to IPv6 Extension\ Header processing continue to be discovered (see e.g. [Cisco-Frag1],\ [Cisco-Frag2], and [FreeBSD-SA]). Because there is currently little\ operational reliance on IPv6 Extension headers, the corresponding\ code paths are rarely exercised, and there is the potential for bugs\ that still remain to be discovered in some implementations.\ \ IPv6 Fragment Headers are employed to allow fragmentation of IPv6\ packets. While many of the security implications of the\ fragmentation / reassembly mechanism are known from the IPv4 world,\ several related issues have crept into IPv6 implementations. These\ range from denial of service attacks to information leakage, as\ discussed in [RFC7739], [Bonica-NANOG58] and [Atlasis2012]).\ \ 8. IANA Considerations\ \ There are no IANA registries within this document. The RFC-Editor\ can remove this section before publication of this document as an\ RFC.\ \ 9. Security Considerations\ \ The security implications of IPv6 extension headers are discussed in\ Section 7.4. This document does not introduce any new security\ issues.\ \ 10. Acknowledgements\ \ The authors would like to thank (in alphabetical order) Mikael\ Abrahamsson, Fred Baker, Brian Carpenter, Tim Chown, Owen DeLong, Tom\ Herbert, Lee Howard, Tom Petch, Sander Steffann, Eduard Vasilenko,\ Eric Vyncke, Jingrong Xie, and Andrew Yourtchenko, for providing\ valuable comments on earlier versions of this document.\ \ \ \ Gont, et al. Expires April 17, 2021 [Page 13]\ \page \ Internet-Draft IPv6 Extension Headers October 2020\ \ \ Fernando Gont would like to thank Jan Zorz / Go6 Lab\ , Jared Mauch, and Sander Steffann\ , for providing access to systems and networks\ that were employed to perform experiments and measurements involving\ packets with IPv6 Extension Headers.\ \ 11. References\ \ 11.1. Normative References\ \ [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation\ of Type 0 Routing Headers in IPv6", RFC 5095,\ DOI 10.17487/RFC5095, December 2007,\ .\ \ [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments",\ RFC 5722, DOI 10.17487/RFC5722, December 2009,\ .\ \ [RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments",\ RFC 6946, DOI 10.17487/RFC6946, May 2013,\ .\ \ [RFC6980] Gont, F., "Security Implications of IPv6 Fragmentation\ with IPv6 Neighbor Discovery", RFC 6980,\ DOI 10.17487/RFC6980, August 2013,\ .\ \ [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of\ Oversized IPv6 Header Chains", RFC 7112,\ DOI 10.17487/RFC7112, January 2014,\ .\ \ [RFC8021] Gont, F., Liu, W., and T. Anderson, "Generation of IPv6\ Atomic Fragments Considered Harmful", RFC 8021,\ DOI 10.17487/RFC8021, January 2017,\ .\ \ [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6\ (IPv6) Specification", STD 86, RFC 8200,\ DOI 10.17487/RFC8200, July 2017,\ .\ \ [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node\ Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,\ January 2019, .\ \ \ \ \ \ Gont, et al. Expires April 17, 2021 [Page 14]\ \page \ Internet-Draft IPv6 Extension Headers October 2020\ \ \ 11.2. Informative References\ \ [APNIC-Scudder]\ Scudder, J., "Modern router architecture and IPv6", APNIC\ Blog, June 4, 2020, .\ \ [Atlasis2012]\ Atlasis, A., "Attacking IPv6 Implementation Using\ Fragmentation", BlackHat Europe 2012. Amsterdam,\ Netherlands. March 14-16, 2012,\ .\ \ [Atlasis2014]\ Atlasis, A., "A Novel Way of Abusing IPv6 Extension\ Headers to Evade IPv6 Security Devices", May 2014,\ .\ \ [BH-EU-2014]\ Atlasis, A., Rey, E., and R. Schaefer, "Evasion of High-\ End IDPS Devices at the IPv6 Era", BlackHat Europe 2014,\ 2014, .\ \ [Bonica-NANOG58]\ Bonica, R., "IPV6 FRAGMENTATION: The Case For\ Deprecation", NANOG 58. New Orleans, Louisiana, USA. June\ 3-5, 2013, .\ \ [Cisco-EH-Cons]\ Cisco, "IPv6 Extension Headers Review and Considerations",\ October 2006,\ .\ \ [Cisco-Frag1]\ Cisco, "Cisco IOS Software IPv6 Virtual Fragmentation\ Reassembly Denial of Service Vulnerability", September\ 2013, .\ \ \ \ \ \ \ \ \ Gont, et al. Expires April 17, 2021 [Page 15]\ \page \ Internet-Draft IPv6 Extension Headers October 2020\ \ \ [Cisco-Frag2]\ Cisco, "Cisco IOS XR Software Crafted IPv6 Packet Denial\ of Service Vulnerability", June 2015,\ .\ \ [Cunha-2020]\ Cunha, I., "IPv4 vs IPv6 load balancing in Internet\ routes", NPS/CAIDA 2020 Virtual IPv6 Workshop, 2020,\ .\ \ [FreeBSD-SA]\ FreeBSD, "FreeBSD Security Advisory FreeBSD-SA-20:24.ipv6:\ IPv6 Hop-by-Hop options use-after-free bug", September\ 2020, .\ \ \cb10 [Gont-Chown-IEPG89]\ Gont, F. and T. Chown, "A Small Update on the Use of IPv6\ Extension Headers", IEPG 89. London, UK. March 2, 2014,\ .\ \ [Gont-IEPG88]\ Gont, F., "Fragmentation and Extension header Support in\ the IPv6 Internet", IEPG 88. Vancouver, BC, Canada.\ November 13, 2013, .\ \cb1 \ \cb5 >>> These don\'92t seem great presentations, and seem like they were \ >>> mostly replaced by \cf2 \outl0\strokewidth0 iepg-ietf90-ipv6-ehs-in-the-real-world-v2.0?\ >>> I don\'92t know why these are useful as references? RC7872 also covers this?\cb1 \ \cf2 \outl0\strokewidth0 \strokec2 \ \pard\pardeftab720\sl280\partightenfactor0 \cf2 \cb5 \outl0\strokewidth0 >>> Is it worth also seeing whether Hendriks et al, http://dl.ifip.org/db/conf/tma/tma2017/tma2017_paper22.pdf\ >>> contains useful insight instead of these two?\ \cf2 \cb1 \outl0\strokewidth0 \strokec2 \ \pard\pardeftab720\sl280\partightenfactor0 \cf2 [Huston-2017]\ Huston, G., "Dealing with IPv6 fragmentation in the\ DNS", APNIC Blog, 2017,\ .\ \ [Huston-2020]\ Huston, G., "Measurement of IPv6 Extension Header\ Support", NPS/CAIDA 2020 Virtual IPv6 Workshop, 2020,\ .\ \ [I-D.ietf-opsec-ipv6-eh-filtering]\ Gont, F. and W. LIU, "Recommendations on the Filtering of\ IPv6 Packets Containing IPv6 Extension Headers", draft-\ ietf-opsec-ipv6-eh-filtering-06 (work in progress), July\ 2018.\ \ \ \ \ Gont, et al. Expires April 17, 2021 [Page 16]\ \page \ Internet-Draft IPv6 Extension Headers October 2020\ \ \ [I-D.kampanakis-6man-ipv6-eh-parsing]\ Kampanakis, P., "Implementation Guidelines for parsing\ IPv6 Extension Headers", draft-kampanakis-6man-ipv6-eh-\ parsing-01 (work in progress), August 2014.\ \ [I-D.taylor-v6ops-fragdrop]\ Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo,\ M., and T. Taylor, "Why Operators Filter Fragments and\ What It Implies", draft-taylor-v6ops-fragdrop-02 (work in\ progress), December 2013.\ \ [I-D.wkumari-long-headers]\ Kumari, W., Jaeggli, J., Bonica, R., and J. Linkova,\ "Operational Issues Associated With Long IPv6 Header\ Chains", draft-wkumari-long-headers-03 (work in progress),\ June 2015.\ \ [IEPG94-Scudder]\ Petersen, B. and J. Scudder, "Modern Router Architecture\ for Protocol Designers", IEPG 94. Yokohama, Japan.\ November 1, 2015, .\ \ [Jaeggli-2018]\ Jaeggli, G., "Dealing with IPv6 fragmentation in the\ DNS", APNIC Blog, 2018,\ .\ \ [Linkova-Gont-IEPG90]\ Linkova, J. and F. Gont, "IPv6 Extension Headers in the\ Real World v2.0", IEPG 90. Toronto, ON, Canada. July 20,\ 2014, .\ \ [nmap] Fyodor, "Dealing with IPv6 fragmentation in the\ DNS", Firewall/IDS Evasion and Spoofing,\ .\ \ [PMTUD-Blackholes]\ De Boer, M. and J. Bosma, "Discovering Path MTU black\ holes on the Internet using RIPE Atlas", July 2012,\ .\ \ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6\ (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,\ December 1998, .\ \ \ \ Gont, et al. Expires April 17, 2021 [Page 17]\ \page \ Internet-Draft IPv6 Extension Headers October 2020\ \ \ [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J.,\ and D. McPherson, "Dissemination of Flow Specification\ Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,\ .\ \ [RFC5635] Kumari, W. and D. McPherson, "Remote Triggered Black Hole\ Filtering with Unicast Reverse Path Forwarding (uRPF)",\ RFC 5635, DOI 10.17487/RFC5635, August 2009,\ .\ \ [RFC6192] Dugal, D., Pignataro, C., and R. Dunn, "Protecting the\ Router Control Plane", RFC 6192, DOI 10.17487/RFC6192,\ March 2011, .\ \ [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,\ "IPv6 Flow Label Specification", RFC 6437,\ DOI 10.17487/RFC6437, November 2011,\ .\ \ [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label\ for Equal Cost Multipath Routing and Link Aggregation in\ Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,\ .\ \ [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing\ of IPv6 Extension Headers", RFC 7045,\ DOI 10.17487/RFC7045, December 2013,\ .\ \ [RFC7113] Gont, F., "Implementation Advice for IPv6 Router\ Advertisement Guard (RA-Guard)", RFC 7113,\ DOI 10.17487/RFC7113, February 2014,\ .\ \ [RFC7739] Gont, F., "Security Implications of Predictable Fragment\ Identification Values", RFC 7739, DOI 10.17487/RFC7739,\ February 2016, .\ \ [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu,\ "Observations on the Dropping of Packets with IPv6\ Extension Headers in the Real World", RFC 7872,\ DOI 10.17487/RFC7872, June 2016,\ .\ \ [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,\ and F. Gont, "IP Fragmentation Considered Fragile",\ BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020,\ .\ \ \ \ Gont, et al. Expires April 17, 2021 [Page 18]\ \page \ Internet-Draft IPv6 Extension Headers October 2020\ \ \ [Zack-FW-Benchmark]\ Zack, E., "Firewall Security Assessment and Benchmarking\ IPv6 Firewall Load Tests", IPv6 Hackers Meeting #1,\ Berlin, Germany. June 30, 2013,\ .\ \ \ Authors' Addresses\ \ Fernando Gont\ SI6 Networks\ Segurola y Habana 4310, 7mo Piso\ Villa Devoto, Ciudad Autonoma de Buenos Aires\ Argentina\ \ Email: fgont@si6networks.com\ URI: https://www.si6networks.com\ \ \ Nick Hilliard\ INEX\ 4027 Kingswood Road\ Dublin 24\ IE\ \ Email: nick@inex.ie\ \ \ Gert Doering\ SpaceNet AG\ Joseph-Dollinger-Bogen 14\ Muenchen D-80807\ Germany\ \ Email: gert@space.net\ \ \ Warren Kumari\ Google\ 1600 Amphitheatre Parkway\ Mountain View, CA 94043\ US\ \ Email: warren@kumari.net\ \ \ \ \ \ \ Gont, et al. Expires April 17, 2021 [Page 19]\ \page \ Internet-Draft IPv6 Extension Headers October 2020\ \ \ Geoff Huston\ \ Email: gih@apnic.net\ URI: http://www.apnic.net\ \ \ Will (Shucheng) Liu\ Huawei Technologies\ Bantian, Longgang District\ Shenzhen 518129\ P.R. China\ \ Email: liushucheng@huawei.com\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ Gont, et al. Expires April 17, 2021 [Page 20]\ } --------------D972FB92435BE6F001DD5AC6 Content-Type: application/pdf; x-mac-type="0"; x-mac-creator="0"; name="draft-ietf-v6ops-ipv6-ehs-packet-drops.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-v6ops-ipv6-ehs-packet-drops.pdf" JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHFW9ty20YSfedXdOUlUpUIYXBnHrIl62Jr13EU i1XZqigPEDAkEYMAjYtk5ev39IAASRCSTWt216mKqBGIOeh7n2l8pt/oM5n4z524FDgWFZJ+ pwyLQi0LEgFZgqIlvZnSRK1NyDV9Y+L6Ln6dLul0OhUjQdMZ/UFHN+ExjU3DoqN5+0G2H+iY 1F9EfyFvF2bqitHR3pXmMf1J03/S5VQh3gIXCLeHjh+nDytudyg6fM1edFStUY2T9poOcPun Ftb4wWuv6SCv2pVyc4NubXP9uLvpovnC6Kgcd9d1oKJP3XXt5uMN9oFNcTPbF65liNERhNSI vhPwaV/iVntJ+5duofuydTxq7tKtnKzvsqeVTho/ra/o7uY2+hopfbGN+Rb5juFNbGGR4wry Jq5hm96kNbjTt6WgeUmn5/gZlVBhGREWLV4MhOH5vm2T51tG4EHjgWMI33FgioYQluuKEQx3 RsLxDUeYuD0+WJMgIN8zbMs2g+5C3nDG21hqG2MymTiWA5sxJoHrurY/are2eWthBcbEC5zN HZfkWoJ339ol3V6DLgLPorT77shzurUF+bYRWO6Ev71e3bljd+VmF9s3TN/2ccf2uyNvs7Z9 x3Z1qZ47sMSEtq5kWazXBB5KiN07dmsLCEgJxPcC0/EaXbRbE75nuMKckAMZ205gkWUajmuq 2AEVjEzD9bGrZTdfFPyYUJk78SA1KNGyDd9mkba6a1Ty/I5uYBqB7XqbHQXiiNUpHbrb2dHi HX0Yhwh8Q3gTIHx2y87QnBG0jVho2J4rAstiCbA7tb+yAfvmOtSYhmnCyqYRdNxciJ94RHsd eKwmHh5d3zx49OtKFmGV5FlJv+fFpySb09sir1d0d/Tg5avy7phe+Hdl0Ns8q45H07/a6LcB 9R0YPX/UBEcLIR4x++g6q2SRyWp8UYSz6gUkA3+6vfbog6we8VilNoSBGECYxTKmsgqruvyJ rrNZXiyVTMN0ANb20geD3iVpmoRFrA3hxO0hvPyySgoJZGerIoHj+ydwCqTNQ/5df7j8tzaE 8M8exEOg7F/71qCLXBawXX0QLVsnxNtVGEnYIp291QcR2WDXWfYlc9DK7wb9q16GRaIPIqKg Voh4nrd5Pk+lPohe310Oktn+xTDGd3VZ5Zk+iL5ed1GYz24+XJ/rgzjR6i4KIczxfVJrg2iZ WtzlXR0+yoSmMlpkeZrPE6kvt1iWLnf5Narye1mg5FSx3tQnRW9A0cf0fel/tFuiWJ7hmbaL gsjrSpV1GbApU5BSr5erNInWRUs+I9Qxmp7PclHMonQGgF7c8ugmRPtTlfSYVAu6/FLJrETV RO9kGMuiPEAEo6ZdfaZKs3y/LdPaZ9+NMTEXQuNEVjM0fCjQxsnqwRvLBRo2hXAcF7xqCk0y cck2+yHy7L6sijBCE6hF8dgClfdeopgukpLiPKqXMquorJecm/6WJTq9blvU820NfHC5aZkw ONsK1ruPQBW0ZWe1kJS3lTFMLtk2ua3tv1aRv6RrR7iG43nt9sxUtNs3Ro0GtnvO12wE8ToD RiU7G140NtzKdaRol++Xq3A9NEBozbBtz43KlYySWYJqOcmIhcw9iL7H9NA0KMqnFSRc56bI qzzKU7pt9m4CB9qbj1fngWWad8eHO8pOX2WDaup2HXHT0gqy4a++SZBbdxSWYZlC+IQb98T3 HTfuwsxoawtYRDDZgFad1s8//0y39Xwuy4pi9AtRhc53JguZRZKqXGmL1UcLrJ3QvYzCusRf +FeCo64QdvJS6utjHLMfhBkid3PYfJFkcQMpkhlCAgDWqzisFCBinCdsYmkyX1QEd2JbA8L7 VC715WtH9O2bEcayjIrkHjbeSCpcIy2uzsdVPr6XVC7yOo0b8TLyx0VYsQijuoC4q/TpcIvs 1Lzb8zt2v6JghJ0XHuB54BZGIFmf28ftmxM874T40cOqkssVEiceNMzC9OlviScPS2YcHhdP 1GStJq/qe26/bzvAo/iOZ6PetzjrS+FcTOC3SJXk+P1ctggfJGxWZlvyflXiWpcpzU7beYs4 +a824XVV36NUAiXRsCjGFoDXZRSXCaadUMuGFT7kCTSePbGbxlA5G3akjB1mv0zKMTQfI/be P9FSKvPIOYCU/wDNpE35rujHTcYG80syxDNCWgcSVbxhjQWmUSxOX/e3ihXiEKTKmV/kEjy5 SuuvTbNg9PxOCWtKD1autmkVvqbNEFvK+n6ZwBVV5p3VaQq9NEQVx3dV1EITDK2hxV9LNgac FHdMkzgAPyQs+JLl8eb8hvxAGYH6ONGnBk/01cDuv0MllhQib3E2YcqzrTIVMM4V7cV0mc2T TOollzyrnzdYb2H5ia7yAtq4O7q+nF7dHRtEH3KV0uBGylFoztxsScvwicK0hPkmqMST+7rS x4h4Tj9nAN2+oMKyE1JjZSXgTiG6FJBYv+tstrlKm4N7bt/BgVARxCWnUQhrUVWr8qfTU1QE IXcqn2RhcMtk5MX8VHVQ5eka36mhD1cwlHUGzE4h2DK6hzBF3ARtTCFU+yVZ1kuWYJl8oSXo 9YW+ksWbDJgep2m2KMTopoiKT5CiVyk4S3wCqvy+zFPJwQOBuzHEjcdA3Ij42oToiwHzq5Kl hHldqzIpycIVV5tFouo9VH6oQ1uHXdsiwTy78lUfNmvA8ED1IzygSYSgkFCipClCoUFObZwD M0bzg6pcUZMC+hx0fGn8oA+XO2B4Q4ngEYcNJNV5AIG82D0QaOPv6xOTH/QT03m+eipUMY6I lkQq0XzPiVGPMsJZK876dgsRxILNbndHEUoLHHeYxDGVpgW4WZVzOMqjFFB1aBKj7G76UmgK f9GmmWDoHKH1HQrrapEXHDjPoBclHzbbUhYPMm7V8drCFDLCkfaejHbZlaZC+Iu7PtjwVmpm MW0k92NJ7+U8TPXJZ4h+v9nUCR9lCqIPGRqoFIyLNR+kj3Gb4ChsVzp8pHlCOK0JU6hm69/6 JK3nN1sXNB//uAnnksSf2qQ02eMjd8PdFgLV5OzRk1sXELXkMHuFNojC3GMJsendUZuJK3Y8 KTdZGH0JKFQ5RlGew0URGOVsxvaHuMRGp5r5fKYRoBg4RmkaJMUlc8attilH6P4mRafK/epD Ih8ZFn5pvVdfUhamPRC/IxSoXKg/oY9WQempoxboKa+LNl5w9kbMQBkYNef4qpjHCkgQfSfz wtwj86BfeGVfZOd5LBGAl6s8Q1AtkW0UVYzaYVbky93LaQmj0Khhb6B0SLIorQHpVnG4int8 c3uBoyVlflQBH8t3w9rAEm8hOSb3HQM0sE4T3Gf0IEMYe5OWVGhlwrLtkhR/gjYFJcMDclSs +rS8rugxLIowq9AE6LTCYMBBduTCUIflqC9ZCaY+d+PxNARvx+55jsDMRtXRGKNXtqlCOB15 u2mhBZeaWVXkcd3YARkH/keEQbVvJu9fntvBeNKAXixgvEjKKA1RGhd0ID5+HiJbI8Yhws3G Jm/QfHHTiiC1NRjzrXj1YgwGeh8HGG84vud1MwHF+eeZJDpsBUSuPjmC+e9z/rg/Y1SHe0wQ wPdjrogaZoJ9gg/jEo61z1oBka8R4x6/psoLDMwB50cc8BRRzVUbBDksseFVokAjRmvAZzyF 73ON0w11pIjshWAboRej9+GTLMb2aap+OkwVtkNc+KwRlzOQ6Vl8qqBbylj1tLdPqJWWL+iz L0G9snMH/IQIA5KQ3+X5Lzeqf3oXlovxPaqjmN7nYTy+XeB0Fmb5rM71YvQH/IQxcly8ZOVF DAZqLEK4B+J4jTx6dv6+fBYfy5RoolHXwQBbwBg5Ll5c5Lf0Cw5E5o0tcqo/57khjuYf5eca FV2pKKGrJGWCAU/TaF0vxsmAnzBGjovr4UmVC2tFmF+ABGpSIuPluMmNMxy9J1USGjsLWwz6 jGdwXLyCMz+GGKHs5NP3jed+14txiNL1ga+br+0PrvQkNoyShL4xDmEPEbvIDMqvr7PwPkkT lJSIild8utqERGcnbQ+h1ItxiNpljOzXH1H6yvE6ZINtw6fWHL8iTb0YvUGfwbw5MO7I8UYW nEZYnnI85ySNaNn351amOLnVF3vsISqa5ch+jfamLljVqB0ijFeXdFaWecSpp2kxniuASC/G IS46YBmefThTdQ16nnY4vZXS13+S0FjXOkNs9KQnw/JgnHoxDrHSeAmBzqJPWf6YyrjJMQfU EyxlvRjtAZ/BuxpIdesZkwPRNXaAAUd9PuMMsegQA96ngTQ+NPUgTvK3IH/dGlmOOjHuvSGh am9g5ADZdViHoiShsYdx9t6RAMazhur+kc7imE8/MLPzlZjdly0JjbWZu/cKAut4u+nvOIav v3fz0liIC9Hi7ahdQoPrfX75Zp+nvTu6fMfv3KCiyR9V+cecCziq9bip4ijXY3PaCAZ+Q20P IDgnNTfXTPHgN2agMEawWuVFpZBFOUrqWZ2pghAnmEgoZR0tmE3jp9PnmO7QIQEK+zl3carR hO7e5Y+oRosTzDUscWiqRjZVad10ommC8Qf1kWch1JibRoBDE/pq+AXaBHsH2hgTrCFFC+hV ZjgcQFnQmEAz/kRgSNQxBwr/ZKWaUxTYGgEOzecvkzhO5fg+/yLLRsugQXAShgkE+QWH+Ov5 HWWp21NaxA+lCZvjuUaAAUpwXP0if2hq6mtDSztM2t5ZofD2jnr2ppb+X0NLwrP73eL/bGpJ eN7AvAwYpaa5g83i6OHFwTI+vinRuhJe1eNzbk3WAbvAq7X7sSnGcEL+xG5SHkI8vzzDKHwM 7+2FwSnC7/qYdu+AiDoTxfM/5CkObVkQGQbW4c8amXl/6OgKoz9RrebYMPJyz6cCylM3uaId 68a4HUYR1NkB0HE+USep3MHrpLb8vcMNPeeolr5zVBHsTewq3g1Wu/eC6TMJWpVb6//9dw5S gyG6v5klQdYI746bWK1sL1PDFDwJjSkc1mzZtnas3a03GPQ5ZDDE9O+8HxEONpPIGY88Kl5n 3JTADpuR8jQs5rLQCG+I5A/rOFF5bRUWmD5JVigEFDvIMuMj3Y0rbcWT3/4DfryBYgplbmRz dHJlYW0KZW5kb2JqCjUgMCBvYmoKMzgwNQplbmRvYmoKMiAwIG9iago8PCAvVHlwZSAvUGFn ZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgNiAwIFIgL0NvbnRlbnRzIDQgMCBSIC9NZWRp YUJveCBbMCAwIDU5NSA4NDJdCj4+CmVuZG9iago2IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BE RiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgOCAwIFIgL0NzMiA5IDAgUiA+PiAvRXh0 R1N0YXRlCjw8IC9HczIgMTEgMCBSIC9HczQgMTIgMCBSIC9HczMgMTMgMCBSIC9HczEgMTQg MCBSID4+IC9Gb250IDw8IC9UVDEgNyAwIFIKL1RUMiAxMCAwIFIgPj4gPj4KZW5kb2JqCjEx IDAgb2JqCjw8IC9UeXBlIC9FeHRHU3RhdGUgL2NhIDAgPj4KZW5kb2JqCjEyIDAgb2JqCjw8 IC9UeXBlIC9FeHRHU3RhdGUgL0FBUEw6QUEgdHJ1ZSA+PgplbmRvYmoKMTMgMCBvYmoKPDwg L1R5cGUgL0V4dEdTdGF0ZSAvY2EgMSA+PgplbmRvYmoKMTQgMCBvYmoKPDwgL1R5cGUgL0V4 dEdTdGF0ZSAvQUFQTDpBQSBmYWxzZSA+PgplbmRvYmoKMTUgMCBvYmoKPDwgL0xlbmd0aCAx NiAwIFIgL04gMSAvQWx0ZXJuYXRlIC9EZXZpY2VHcmF5IC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+CnN0cmVhbQp4AaVXB1iT1xo+/0jCSthTRtjIMqDsGZkBZA9BVGISSBghBoKAuCjFCtYt DhwVLYpStFoRKC7U4qBuUOu4UEsFpRaruLB6zwmg0Pa59z7Pzf8c/vd8Z3zrPd9/AEBdyJVI snEAQI44XxoSy06emZzCpN0DCkAXqAJHoMrl5UnY0dERcAoQ54oF6D3x97ILYEhywwHtNXHs v/YofEEeD846BVsRP4+XAwDmDQCtjyeR5gOgaAHl5gvyJQiHQqyVFR8bAHEqAAoqo2uhGJiE CMQCqYjHDJFyi5gh3JwcLtPZ0ZkZLc1NF2X/g9Vo0f/zy8mWIbvRzwQ2lbysuHD4doT2l/G5 gQi7Q3yYxw2KG8WPC0SJkRD7A4CbSfKnx0IcBvE8WVYCG2J7iOvTpcEJEPtCfFsoC0V4GgCE TrEwPgliY4jDxPMioyD2hFjIywtIgdgG4hqhgIPyBGNGXBTlc+IhhvqIp9LcWDTfFgDSmy8I DBqRk+lZueHIBjMo/y6vIA7J5TYXCwOQnVAX2ZXJDYuG2AriF4LsEDQf7kMxkORHoz1hnxIo zo5Eev0hrhLkyf2FfUpXvjAe5cwZAKpZvjQerYW2UePTRcEciIMhLhRKQ5Ec+ks9IcmW8wzG hPpOKotFvkMfacECcQKKIeLFUq40KARiGCtaK0jEuEAAcsE8+JcHxKAHMEEeEIECOcoAXJAD GxNaYA9bCJwlhk0KZ+SBLCjPgLj34zjqoxVojQSO5IJ0ODMbrhuTMgEfrh9Zh/bIhQ310L59 8n15o/ocob4A46+BDI4LwQAcF0I0A3TLJYXQvhzYD4BSGRzLgHi8FmfII2cQLbd1xAY0jrT0 j2rJhSv4cl0j65CXI7YFQJvFoBiOIdvknpO6JIucCpsXGUH6kCy5NimcUQQc5HJvuWxM6yfP kW/9H7XOh7aO9358vMZifBrGKx/unA09FI/GJw9a8w7anTW6+lM05RrXGMhsJJKqVTGcObVy i5HvzFLpXBHvyurB/5C1T9ka0+4wIW9R43khZwr/b7yAuijXKVcpDyg3ARO+f6F0Uvoguku5 B587H+2JHscHFHvEHBH8K4I+jjFghFk8uQTlIhs+KC9/t/NTzkb2+csOGCHXizjLlu+CGJYD G8qsQJ7XEKifC/ORB6MtgzxF3HCAjBmfuxEt405Ae0mrHmB2rTx1ATDr1ZrPy7XIo91JNqXe UGkvSRevMZBI5tSWDAskn0ZRHgTLI19GglJ71iHWAGsPq571nPXg0wzWLdZvrE7WLjjyhFhP HCWOE81EC9EBmLDXQpwmmuWonmiFz7cf101k+Mg5mshwxDfeKKORj/mjnBrP/XEeyuM1Fi00 fyxTmaMndTz3UHzHMwZl7H+zaHxGJ1aEkezITx3DnOHEoDFsGS4MNgNjmMLHmeEPkTnDjBHB 0IWjoQxrRiBj0sd4jJxxZAc674hhY3XhUxVLhqNjTED+CSEPpPKaxR31968+Mid4iSqaaPyp wujwZI5oGqkJYzrH4ipnyISTlQA1icACaIcUxhWddjGsJcwJc1AlRlUIMhKbJc/hP5wE0ph0 IjmwMkUBJskmXUj/UYyqlTd8UK0aqd4OpB8c9SUDSXdUx8Z7AHcfiReqaP9s/fiTIaB6Uq2p QVRr+d5y76iB1FBqMGBSnZCcOoUaBrEHmpUvKIR3DwACciVFUlGGMJ/JhrccAZMj5jnaM51Z TvDrhu5MaA4Az2PkdyFMp4MnkxaMyEj0ogAleJ/SAvrwq2oOv9YO0Cs34AW/mUHwDhAF4kEy mAP9EMJMSmFkS8AyUA4qwRqwEWwFO8EeUAcawGFwDLSC0+AHcAlcBZ3gLvye9IInYBC8BMMY htEwOqaJ6WMmmCVmhzlj7pgvFoRFYLFYMpaGZWBiTIaVYJ9hldg6bCu2C6vDvsWasdPYBewa dgfrwfqxP7C3OIGr4Fq4EW6FT8HdcTYejsfjs/EMfD5ejJfhq/DNeA1ejzfip/FLeCfejT/B hwhAKBM6hCnhQLgTAUQUkUKkE1JiMVFBVBE1RAOsAe3EDaKbGCDekFRSk2SSDjCLoWQCySPn k4vJleRWch/ZSJ4lb5A95CD5nkKnGFLsKJ4UDmUmJYOygFJOqaLUUo5SzsEK3Ut5SaVSdWB+ 3GDekqmZ1IXUldTt1IPUU9Rr1IfUIRqNpk+zo/nQomhcWj6tnLaFVk87SbtO66W9VlBWMFFw VghWSFEQK5QqVCnsVzihcF3hkcKwopqipaKnYpQiX7FIcbXiHsUWxSuKvYrDSupK1ko+SvFK mUrLlDYrNSidU7qn9FxZWdlM2UM5RlmkvFR5s/Ih5fPKPcpvVDRUbFUCVFJVZCqrVPaqnFK5 o/KcTqdb0f3pKfR8+ip6Hf0M/QH9NUOT4cjgMPiMJYxqRiPjOuOpqqKqpSpbdY5qsWqV6hHV K6oDaopqVmoBaly1xWrVas1qt9SG1DXVndSj1HPUV6rvV7+g3qdB07DSCNLga5Rp7NY4o/FQ k9A01wzQ5Gl+prlH85xmrxZVy1qLo5WpVan1jdZlrUFtDe1p2onahdrV2se1u3UIHSsdjk62 zmqdwzpdOm91jXTZugLdFboNutd1X+lN0vPXE+hV6B3U69R7q8/UD9LP0l+rf0z/vgFpYGsQ Y7DAYIfBOYOBSVqTvCbxJlVMOjzpJ0Pc0NYw1nCh4W7DDsMhI2OjECOJ0RajM0YDxjrG/saZ xhuMTxj3m2ia+JqITDaYnDR5zNRmspnZzM3Ms8xBU0PTUFOZ6S7Ty6bDZtZmCWalZgfN7psr mbubp5tvMG8zH7QwsZhhUWJxwOInS0VLd0uh5SbLdstXVtZWSVbLrY5Z9VnrWXOsi60PWN+z odv42cy3qbG5OZk62X1y1uTtk6/a4rYutkLbatsrdridq53IbrvdNXuKvYe92L7G/paDigPb ocDhgEOPo45jhGOp4zHHp1MspqRMWTulfcp7lgsrG37d7jppOIU5lTq1OP3hbOvMc652vjmV PjV46pKpTVOfTbObJpi2Y9ptF02XGS7LXdpc/nR1c5W6Nrj2u1m4pbltc7vlruUe7b7S/bwH xWO6xxKPVo83nq6e+Z6HPX/3cvDK8trv1edt7S3w3uP90MfMh+uzy6fbl+mb5vuVb7efqR/X r8bvZ39zf75/rf8j9mR2Jrue/XQ6a7p0+tHprwI8AxYFnAokAkMCKwIvB2kEJQRtDXoQbBac EXwgeDDEJWRhyKlQSmh46NrQWxwjDo9TxxkMcwtbFHY2XCU8Lnxr+M8RthHSiJYZ+IywGetn 3Iu0jBRHHosCUZyo9VH3o62j50d/H0ONiY6pjvk11im2JLY9TjNubtz+uJfx0+NXx99NsEmQ JbQlqiamJtYlvkoKTFqX1D1zysxFMy8lGySLkptSaCmJKbUpQ7OCZm2c1Zvqklqe2jXbenbh 7AtzDOZkzzk+V3Uud+6RNEpaUtr+tHfcKG4Nd2geZ962eYO8AN4m3hO+P38Dv1/gI1gneJTu k74uvS/DJ2N9Rr/QT1glHBAFiLaKnmWGZu7MfJUVlbU360N2UvbBHIWctJxmsYY4S3w21zi3 MPeaxE5SLume7zl/4/xBabi0Ng/Lm53XlK8F/8HskNnIPpf1FPgWVBe8XpC44EiheqG4sKPI tmhF0aPi4OKvF5ILeQvbSkxLlpX0LGIv2rUYWzxvcdsS8yVlS3qXhizdt0xpWdayH0tZpetK X3yW9FlLmVHZ0rKHn4d8fqCcUS4tv7Xca/nOL8gvRF9cXjF1xZYV7yv4FRcrWZVVle9W8lZe /NLpy81ffliVvuryatfVO9ZQ14jXdK31W7tvnfq64nUP189Y37iBuaFiw4uNczdeqJpWtXOT 0ibZpu7NEZubtlhsWbPl3Vbh1s7q6dUHtxluW7Ht1Xb+9us7/Hc07DTaWbnz7Veir27vCtnV WGNVU7Wburtg9697Eve0f+3+dV2tQW1l7Z97xXu798XuO1vnVle333D/6gP4AdmB/vrU+qvf BH7T1ODQsOugzsHKQ+CQ7NDjb9O+7TocfrjtiPuRhu8sv9t2VPNoRSPWWNQ4eEx4rLspuela c1hzW4tXy9HvHb/f22raWn1c+/jqE0onyk58OFl8cuiU5NTA6YzTD9vmtt09M/PMzbMxZy+f Cz93/ofgH860s9tPnvc533rB80LzRfeLxy65XmrscOk4+qPLj0cvu15uvOJ2pemqx9WWa97X Tlz3u376RuCNH25ybl7qjOy81pXQdftW6q3u2/zbfXey7zz7qeCn4btL4SW+4r7a/aoHhg9q /jX5Xwe7XbuP9wT2dPwc9/Pdh7yHT37J++Vdb9mv9F+rHpk8qutz7mvtD+6/+njW494nkifD A+W/qf+27anN0+9+9/+9Y3DmYO8z6bMPf6x8rv9874tpL9qGoocevMx5Ofyq4rX+631v3N+0 v016+2h4wTvau81/Tv6z5X34+3sfcj58+DctXfAcCmVuZHN0cmVhbQplbmRvYmoKMTYgMCBv YmoKMzM2NwplbmRvYmoKOCAwIG9iagpbIC9JQ0NCYXNlZCAxNSAwIFIgXQplbmRvYmoKMTcg MCBvYmoKPDwgL0xlbmd0aCAxOCAwIFIgL04gMyAvQWx0ZXJuYXRlIC9EZXZpY2VSR0IgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBnZZ3VFPZFofPvTe90BIiICX0GnoJINI7 SBUEUYlJgFAChoQmdkQFRhQRKVZkVMABR4ciY0UUC4OCYtcJ8hBQxsFRREXl3YxrCe+tNfPe mv3HWd/Z57fX2Wfvfde6AFD8ggTCdFgBgDShWBTu68FcEhPLxPcCGBABDlgBwOFmZgRH+EQC 1Py9PZmZqEjGs/buLoBku9ssv1Amc9b/f5EiN0MkBgAKRdU2PH4mF+UClFOzxRky/wTK9JUp MoYxMhahCaKsIuPEr2z2p+Yru8mYlybkoRpZzhm8NJ6Mu1DemiXho4wEoVyYJeBno3wHZb1U SZoA5fco09P4nEwAMBSZX8znJqFsiTJFFBnuifICAAiUxDm8cg6L+TlongB4pmfkigSJSWKm EdeYaeXoyGb68bNT+WIxK5TDTeGIeEzP9LQMjjAXgK9vlkUBJVltmWiR7a0c7e1Z1uZo+b/Z 3x5+U/09yHr7VfEm7M+eQYyeWd9s7KwvvRYA9iRamx2zvpVVALRtBkDl4axP7yAA8gUAtN6c 8x6GbF6SxOIMJwuL7OxscwGfay4r6Df7n4Jvyr+GOfeZy+77VjumFz+BI0kVM2VF5aanpktE zMwMDpfPZP33EP/jwDlpzcnDLJyfwBfxhehVUeiUCYSJaLuFPIFYkC5kCoR/1eF/GDYnBxl+ nWsUaHVfAH2FOVC4SQfIbz0AQyMDJG4/egJ961sQMQrIvrxorZGvc48yev7n+h8LXIpu4UxB IlPm9gyPZHIloiwZo9+EbMECEpAHdKAKNIEuMAIsYA0cgDNwA94gAISASBADlgMuSAJpQASy QT7YAApBMdgBdoNqcADUgXrQBE6CNnAGXARXwA1wCwyAR0AKhsFLMAHegWkIgvAQFaJBqpAW pA+ZQtYQG1oIeUNBUDgUA8VDiZAQkkD50CaoGCqDqqFDUD30I3Qaughdg/qgB9AgNAb9AX2E EZgC02EN2AC2gNmwOxwIR8LL4ER4FZwHF8Db4Uq4Fj4Ot8IX4RvwACyFX8KTCEDICAPRRlgI G/FEQpBYJAERIWuRIqQCqUWakA6kG7mNSJFx5AMGh6FhmBgWxhnjh1mM4WJWYdZiSjDVmGOY VkwX5jZmEDOB+YKlYtWxplgnrD92CTYRm40txFZgj2BbsJexA9hh7DscDsfAGeIccH64GFwy bjWuBLcP14y7gOvDDeEm8Xi8Kt4U74IPwXPwYnwhvgp/HH8e348fxr8nkAlaBGuCDyGWICRs JFQQGgjnCP2EEcI0UYGoT3QihhB5xFxiKbGO2EG8SRwmTpMUSYYkF1IkKZm0gVRJaiJdJj0m vSGTyTpkR3IYWUBeT64knyBfJQ+SP1CUKCYUT0ocRULZTjlKuUB5QHlDpVINqG7UWKqYup1a T71EfUp9L0eTM5fzl+PJrZOrkWuV65d7JU+U15d3l18unydfIX9K/qb8uAJRwUDBU4GjsFah RuG0wj2FSUWaopViiGKaYolig+I1xVElvJKBkrcST6lA6bDSJaUhGkLTpXnSuLRNtDraZdow HUc3pPvTk+nF9B/ovfQJZSVlW+Uo5RzlGuWzylIGwjBg+DNSGaWMk4y7jI/zNOa5z+PP2zav aV7/vCmV+SpuKnyVIpVmlQGVj6pMVW/VFNWdqm2qT9QwaiZqYWrZavvVLquNz6fPd57PnV80 /+T8h+qwuol6uPpq9cPqPeqTGpoavhoZGlUalzTGNRmabprJmuWa5zTHtGhaC7UEWuVa57Ve MJWZ7sxUZiWzizmhra7tpy3RPqTdqz2tY6izWGejTrPOE12SLls3Qbdct1N3Qk9LL1gvX69R 76E+UZ+tn6S/R79bf8rA0CDaYItBm8GooYqhv2GeYaPhYyOqkavRKqNaozvGOGO2cYrxPuNb JrCJnUmSSY3JTVPY1N5UYLrPtM8Ma+ZoJjSrNbvHorDcWVmsRtagOcM8yHyjeZv5Kws9i1iL nRbdFl8s7SxTLessH1kpWQVYbbTqsPrD2sSaa11jfceGauNjs86m3ea1rakt33a/7X07ml2w 3Ra7TrvP9g72Ivsm+zEHPYd4h70O99h0dii7hH3VEevo4bjO8YzjByd7J7HTSaffnVnOKc4N zqMLDBfwF9QtGHLRceG4HHKRLmQujF94cKHUVduV41rr+sxN143ndsRtxN3YPdn9uPsrD0sP kUeLx5Snk+cazwteiJevV5FXr7eS92Lvau+nPjo+iT6NPhO+dr6rfS/4Yf0C/Xb63fPX8Of6 1/tPBDgErAnoCqQERgRWBz4LMgkSBXUEw8EBwbuCHy/SXyRc1BYCQvxDdoU8CTUMXRX6cxgu LDSsJux5uFV4fnh3BC1iRURDxLtIj8jSyEeLjRZLFndGyUfFRdVHTUV7RZdFS5dYLFmz5EaM Wowgpj0WHxsVeyR2cqn30t1Lh+Ps4grj7i4zXJaz7NpyteWpy8+ukF/BWXEqHhsfHd8Q/4kT wqnlTK70X7l35QTXk7uH+5LnxivnjfFd+GX8kQSXhLKE0USXxF2JY0muSRVJ4wJPQbXgdbJf 8oHkqZSQlKMpM6nRqc1phLT4tNNCJWGKsCtdMz0nvS/DNKMwQ7rKadXuVROiQNGRTChzWWa7 mI7+TPVIjCSbJYNZC7Nqst5nR2WfylHMEeb05JrkbssdyfPJ+341ZjV3dWe+dv6G/ME17msO rYXWrlzbuU53XcG64fW+649tIG1I2fDLRsuNZRvfbore1FGgUbC+YGiz7+bGQrlCUeG9Lc5b DmzFbBVs7d1ms61q25ciXtH1YsviiuJPJdyS699ZfVf53cz2hO29pfal+3fgdgh33N3puvNY mWJZXtnQruBdreXM8qLyt7tX7L5WYVtxYA9pj2SPtDKosr1Kr2pH1afqpOqBGo+a5r3qe7ft ndrH29e/321/0wGNA8UHPh4UHLx/yPdQa61BbcVh3OGsw8/rouq6v2d/X39E7Ujxkc9HhUel x8KPddU71Nc3qDeUNsKNksax43HHb/3g9UN7E6vpUDOjufgEOCE58eLH+B/vngw82XmKfarp J/2f9rbQWopaodbc1om2pDZpe0x73+mA050dzh0tP5v/fPSM9pmas8pnS8+RzhWcmzmfd37y QsaF8YuJF4c6V3Q+urTk0p2usK7ey4GXr17xuXKp2737/FWXq2euOV07fZ19ve2G/Y3WHrue ll/sfmnpte9tvelws/2W462OvgV95/pd+y/e9rp95Y7/nRsDiwb67i6+e/9e3D3pfd790Qep D14/zHo4/Wj9Y+zjoicKTyqeqj+t/dX412apvfTsoNdgz7OIZ4+GuEMv/5X5r0/DBc+pzytG tEbqR61Hz4z5jN16sfTF8MuMl9Pjhb8p/rb3ldGrn353+71nYsnE8GvR65k/St6ovjn61vZt 52To5NN3ae+mp4req74/9oH9oftj9MeR6exP+E+Vn40/d3wJ/PJ4Jm1m5t/3hPP7CmVuZHN0 cmVhbQplbmRvYmoKMTggMCBvYmoKMjYxMgplbmRvYmoKOSAwIG9iagpbIC9JQ0NCYXNlZCAx NyAwIFIgXQplbmRvYmoKMjAgMCBvYmoKPDwgL0xlbmd0aCAyMSAwIFIgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4Kc3RyZWFtCngBzVtbc9s2Fn7XrziThx17YtG8Xzo76Wxbt85OtnVTd/ah 7gMlURY3oqCQlB13+uP3OwBBUSTcNC12p24nEiGQ+HBuOOcD+J6+p/fk4r8oiygNfaoL+jft 0OjJZo+8lHyPlhV9cUuZbMsochMni5IIl7cVXd7eejOPbtf0E53d5Oc0dx2fzu71l0J/oXOS v/jjBqEb1rLH7Ez39PQP7jn9TLf/pKtbiXgALvWiETqezhjWSj+o7vGpseis7VDNS92nB6x/ 0rDmD7Hu00Pe65bm+IC+7dh/3j90o26YnTXzvl8Pavmu76cHnx+xGwbFw4LEi3zHm51BSEr0 vdguu7n1Db3o9S99Q3+zfz5TT+lbLrqnTLTSS+Ozrkf/tEjpayb1xTaW+JSETpwFnk9h5FGc RU7gxpk2uMtvGo/uG7r8svFp2cBQsiwL/RDKdLI0iqIgmbnULCnNnMhPkxCPw7cwSyl2nTBI 4ogix/P8CA+HEa/1E/T9MArc7UWu44XZLIkAJvYDqijyPcdLQo/6tu2gTQ+y1bcex93ShpLA Sf0o82Y9muEDjzcfBwlDRuvTtr8XT+zbNrSeGaauwOvBcGfmBH6YwDmdMPSS0czhHU6UxBgl UDLzsgT9XExR3xj4gZME4ehGCB+u3sD3IarBaKHjewgCYZg4QZj6/V0zKeheZSzqJE7dMB7j xWhZmhwf4CEO+FpRU7ip50QRphdlMVQTBCTRxukYrzQOjDgaLkpdJw2ieDKewqvvmuKEmTl+ 4mfHG09NSsuHTWkGi/XZYr0MzheGGXkB5s/2HQB+mvpxLydlkAM5KcB4QoAn8JNCftJ7CDCI Iy/1fXRw2Zn1JQzGC2N2maSLdq7jutDoLWy6643PCGi8aKaiH27hoHxGRLebsqGVWB6qYtfS Jm+o3cBHxHYrHsvdPd2LfNvAiW//oyPscejnkczUqvAskjDo4vAAiSB6m5dNQfljXhe7omko X4hDKwGJfVHnbSl2+Zby3YqaYnmoy/aJymq/LZfyp4bE+nz2aUA/JrIomYoMUvtUeahh4L8G zYSp47uJG0BBUTISy+ubh5iuPrTFrsHc6brIV0XdkM1Z+h4CFfydRx/NtdkXy3JdFisqd1IL DOdTp/4xU0hgijJTGJjCTS1asRRb+kEhUPqlu7O3X3+Z+q57d25TAgjwHhaS0eQJa9ufsKXZ yP0iJ3R9KeY0Gk+YDXpfFw08sEFAyBuxa+hx80SNqAraFe2jqN/Z1XoQBoj7GWQ+nXlV3m+Q YvyRyZstPCLf9cYe/+rVK8ofRLmCPz8RZrji0JO3tBSH7YoWBVVlM4c0VtD74okgCZaTQHiq m8/vzq06ASP0x+bPCFsB218XNSH+AI/0QrStarF3PlVEv+0JvhtNDAORhjA+3F+Fvu2THJn2 ObJB2MpS7Nq83HGcNkcKx6afsJDSYOwmRAjc1zCZLZsNIXRjDXmEkgpCiEYgbxW25rDfi7ol qLKzaIa9Kh7KZdHYhpmNdSklSVX+BLtqDou52LdllW8vcLHcKLvjdS9fi7rglRDRFmFPYy5t A/Q8bypH1nW1r8VDsbJtW16QjYPOSG/DBRZ2fiiw+jaNWJZ5C0E8lu1GqbHQi5FllXmRwbIg kY1a8k4VJZAlaJBsZ4iXJRZGtVC9vrr92ja42GxPTYuQlNer8heZgFCxhv20jXXtoQKfrJE/ FEu2UgqwdIgHTL+hBcLCfS0OCJMIWqKuFKpjFiWDhAoeliXku9nUoJu2PizbAzTEkXtgTsOk zSHSUwmRwMEXBwmpbZQoeyaCbA5VldflLxAghwAsxA+lOCCGYdFVkYGz4kVR7GiZ1zWnQ5yV dikRxzvreafvo6adAJXa6/1Pe8ZAfhGtymZ5aBpMRWkZiXyNbHrFobbY3Ze7wrZEI0MgY39s ayxMWKIgJl6ligrBP6+fCObZYgEfoI4HqJH02AYYTxI7MiKSNlqVq9W2mC/EB4gQqwWWKqgb C36+xCrV0Jv8qajnoW2MicF5hh4MAFX+Dm401OcKyTnnIxDl1yXqou3TRe9JiW2EmcFxjsbG fnOygJwWZV1yct0HxpnkFvsS9vk68rfLMz/wx9bnQxpfwQm2eVkVteUMLUApP/HK0wI6hyKe dCgZimS5gYbggrCruuiSfZjWwra9B7FBUzpflPk1XHErnp5JGC+kG2g+oFEViIzKtiNHkBhC 3FBiw0IIBoYlX0/DploDF4RTCCYbeEbKRWhH2EfoHIyHAkcTL3/ManG340ZpLAccx3guK/Yq i5FL0WEBbmMw+u9igT5SZoTuOJngOudykz/wbIvdJYmaLvu5X34uw9/zhZrlSBN641jI8D5e Df5moWaVFPJBdo4VR/Qaa1yNwgbx5zQiIJvZCdRFcPulqFBbrFRW1lWRsgCxLcN4HBaRSHfO c0ELJC/g0lChwdfxPwJWA5BwcqYc0P7ERZwsNGGLtivIMDXp940QIDjuhbBe+UTgwE9jdgAV fXHMlF8fM2XLaohCQ+rxGpljQ4emWB+27FmwiT2Lm/19kTflko5ZM1QyyNhRkN0jp2pa2zCj sUZgLXKlUOOHR9ORabxa4STgYR6vcndM5FHYBpgYlrRVuQYtw+xCl+n2YuuzDLWD+Tvi9Uci Zsxk+piihGJ6wYA2R/DM6QFlRL5A/sgLPQpmVbtSg9riQkkUOYB4bDiLY/lZllNs4vdhaawZ CfcFsx7IzV/QfI58TXFKJ6WiVDvnvQi4uItvtp6hxL7B3naCC1hUspxmd3xWL18ZUws1h06m nYThSj1JbVuaocHqNA9+/UYrF/Q42ErIih24YjqgFShzpLwVVpVSVYcG3Bdoi51tnBPaXrpv gRiPbJPWtajA25FYtswY3p1JnOAMq0M1RCmtFKwqQlKse9tGmhiWpbszlFZYFwUvi6hSQQBX AqLC9m4HGbLt7PbuvLMEUIkow7ZcjFnGiN3e0dr+DarXCyqwgm8x+uDv6sO+BGlP/9jXJfaA kwvmkL1BB/X1p5scagh+tg10wsTqDGT+VZ2v2wEOuYZMN5EGPei7ZSsWSAgwA9cyUGyCjySK geHoaoOnfdozlXf0Ynooc+lLL266Pi/I7GO2cQaGsDRwY9ukXhqPE5OhQtR3LYILen39xvZ8 07GlT8eXLS/n3d9Ly5VIaqI1TSB+1Y2/WpZBZmIt9WDDzx7Bg2UZZDhoMskthiPje6eAy0up h14dWi3686Vt4Zg4yBG0Xi6y/fRq0NW63kys42A8/irBSP/tr/DlR7lySBqPm9HNttRMfKMa qv9XQruWGxuMoGvXzn7sZhuaiWbsR1NfNBjT1aCrdamZ+MXBePxVGX7nBfP/lxsEWNOn69cI mk78SaWldmNE4AZjxmY0PC7/rqOA/Hxl13JwGs+QC09BgIe+590e7zOVWd7IbWr6QW8DdXKx xP4GLg7XTWKnTHZa0Amox441Yr5HxpHzTq+QyYXsNS4ckd69lbyIZel5riEDQqW1I0XFyrT3 ueIRW08yiK1E0SAN4PNA6i7QAbZxTqg3qHhb7t4Vq/m2bFr8gz2IsdQuus3+fFD9rMsPfI+s gm2DDAymKMXSVYZIJtXpNcmuS4qrXpTYjkJVtjtUnOX2FQUOk/X7abZxmkhCBRF6lPvpXIkN KhldUUrKWVrpNkchpKclT2DZBmkiCofCxK5FyRtMV+w7vag0JiTvOHqHjac+fcd+X2v5rETg JQb36er/u7PDbssbc6Wk1RQfhe+y6mX5mjAXd+eyJrctzAmzCfdhDC92QNHJ7AXJikfyLMpM 5RYpd5NynwrfMkrfM5DXXSj/9voY07+9vqCra81kyfaTJsux3A8MsVyj0Wv9S9XQXXZXJ21z WaOos+U2zsziKLXB+DQunSx1n6cfqlPfheVlE5eJtB3jejjB0F2dtJGsZ2ziMnG1OnfTOYrW p7p+OUdOd9o0H19brm0CvCYwTR2OqfipjAZXWp2qaXyD7WIiCFyjV0gUMlIwDnl19YF3nvSV gtm3cZdh4WM5ew8CE/HcAeuWr+7q+qToUTD7NoY5LIKswzQRz2MdKkxSlKfS1E3jG+wr3UQ8 //VcCO8WmVwIZB1yv64QYpn1tdEx+bq6buhvp7WSrZogmJ7jZhAn5dGr00sdlYafrywvb6Fn yFoZ2OivK6B8WUDF9D8uoPCC0FSFcvd6nOQbXgwZ7v3J90MsriLRhIu1w8KHlln4IJqQqH9N Fj7AC21TVePg9k/dGxU/43jC+4Pcz5BpM05Ao5CfZKNcP2MTqzt3Lk+qWM5P8W7aFCi8hFGt yxoF0brO7+XLSijj8q4c5e1V7AZjX7VAxVqVcitJJ9W2ET5DPk5KDVk8acaBN4HlNmEXWaxs Tgd+hsNEfkJ8JmnEI0NeN2Az5v+6/VFvXdgKsrGJSIQxfcdKgCbAbLDs9fBsLvo8aKcoecJk J9TbHEpjOH1r+eBAgHdKn7Wl42okjZyXpOHmd3dCj4+vahuzfBImSFyzpd9qS9ayAqMBUXVM ARs3fPW+O9T7YiMe8RJFsQdSxW1ZtvbkGfpTSk0tE6hpoe0hk9GdIFjzUXRtfGzwf/r0XEQB XqeFpc/wavnghTEYH8RGYgcu4hHHF/iARQ6prXAeBVa24LdkJihBCQ42IYXlrWS8d2y2vnWJ w/BjifVYNN3D7oDgVuMEBp+6we/yADLus61g0zlMBFx+Cca0BFywTzRYLIrdEsda8ApELaNt T7n0hyBsAzXRvQA6WKQu6ADUWyndKXk27EkqONt+sSdITVwvQI5d4fv/Aj01dAwKZW5kc3Ry ZWFtCmVuZG9iagoyMSAwIG9iagozNTkyCmVuZG9iagoxOSAwIG9iago8PCAvVHlwZSAvUGFn ZSAvUGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgMjIgMCBSIC9Db250ZW50cyAyMCAwIFIgL01l ZGlhQm94ClswIDAgNTk1IDg0Ml0gPj4KZW5kb2JqCjIyIDAgb2JqCjw8IC9Qcm9jU2V0IFsg L1BERiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgOCAwIFIgL0NzMiA5IDAgUiA+PiAv RXh0R1N0YXRlCjw8IC9HczIgMTEgMCBSIC9HczQgMTIgMCBSIC9HczMgMTMgMCBSIC9HczEg MTQgMCBSID4+IC9Gb250IDw8IC9UVDEgNyAwIFIKL1RUMiAxMCAwIFIgPj4gPj4KZW5kb2Jq CjI0IDAgb2JqCjw8IC9MZW5ndGggMjUgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0 cmVhbQp4Ac1by3LbRhbd6yu6vBmpSqDxJpCdIsuWUrGsyExlqiwvmmCTRAygGTwka75+zu0G QIps2slUu2rohUwQJC7OfZ978Rf7jf3FXPyL0ogloc9qwf5gFQ566rDHvIT5HstK9vOMpepY yiJ3OkmjaYS3s5K9ns28E4/NluwTO73jZ8xxJz47XQ3/EcN/2BlTnwT7B+RwYKnOODkdzvSG D9wz9pnNfmFXMyXxjnCJF+1JR7ezL9Zi+KF6lE9fi522vVROPpwzCjx8NIjlPMbDOaPIm+FI s/2B8dj2fGf80bX+wslp44znjUJlX8bzhos7W9kNF8WPBVMv8ifeySlA0tCPsL3u72084A+n DJ+MB8Yv+2cn+lfGI+f9rxxoZUTjp/6M8dcira8TpS+ysanPpuEkTgPPZ2HksTiNJoEbp4PB vX7XeGzVsNeXjc+yhsxv4oWpF3gh1NlkJ14YTpIoSFgQRpM4SgLmJ5MkTAOY48Tz/Ag/CuNd wmDDiZ8G0fZEfHMahIk/nniiTsSlYNh0qSZjSTqJ/GQa4lvuJAqjKQOmURL7wfgt/fODgGRl SjBIHpLk8KNJEEde4vvqI4A4vMXN+17sTmLcjPYkd+K6LnwmY8CDfsjBX4icBMGJtl0fcsGl TsMJY3e1eMxl17A/ZP2FyYrd3D3G7OprK6omx9trwReibs7Y7M/BQ7YXV7++fbsjy8l3ZIkh gXLvQRbG2EdZCiaXrF3jz0bUvIUAvGB5uSnyTL1r6HOzhGzNH8XZyT8T83uQTaM9yCDmXIiK LfIm65pGLFgOyK5mb1mW11khGpjrPxPhO0ilbnCIlGTs043zZtLy50LWCB1y0zjLmq8Wtdx8 HoVrGGcDijBfWbOndZ6tLYOUetNDkICTVqGsG0ZSaa2RjKWo2mZiG6YwOg7T05eu5HXuFLJa OWtt0LsobWTT5PNCsLxpOgHU6rzJqxVb1rK0DVaUGsF6RbK90iBpCVm25nllH6hkehyoL7zc 8Ip/yRsnLnnl5JvH2BFrZ8NrAgSYiSar8zkwWssnu9CECFpGaPIqk4hFDSJSluPKcDiKEE/8 WcO14chsbcOe8nbNxBi4ej1DmZajQuh6hqgAgyeUEBDmz3DA5VLUsHMVuwRZfB++Skhdi6Yr 8FHFxCNXQVYubWPpm82sEVlX5+0zA6RtLYvmnPFqwTYQibySrbp8IYq8AswULnq9K5xtSxju ZyMgiNehApVeSeMriWSA+L+p5WO+IAfluI+yRJbCTdiWLzJHtdEW2xGdUrRruZCFXD0r1FR+ oqS1o/iJbfESgw0OaSEX7dJBShDZ6MHLvGhFrXwYDl48/wcaJkwHg7AtXmq2P3Mqv+7N8DuJ 37KMnme2QMpWG7KuIbC0a94yAX3KPuJcXSNHwG1408gs5y2cXm6oWEG0tlqAhF5oiImk5vu3 l1PcwG4WQ0RmDZVQG7npCl6z+wvnXcdrlCgvbfEHhEQvMpgjvLnp5n+KrGWtHGMdwmMpeLWt 5A483jqIiUHRPYhJ6rqfocwdl6AaJS8oSOYUIxddpoP6zR0KAl2+qGBuW0zfM+j6glVdORc1 xb1aZJRSoHqkXxS7Y50HDevCpRaFskbATUHIsjH6vkHJB9o7Z81GZPnymVyo2ywgEEKNRKxG ltGtBv3t8x4FIdtiBobYo2Jy08JrySEeTsmB/DB2Pz+cnTOUOs8EsKqONbQVnEkV+lR91BuJ MlrYTjF+ZLBL2JxUkRmJWlUQSnLIgFj9UvzEh+k+nDHkaQqc6rxbubAOZ2xIhPfiry6vVX5r ejSTyA0hDlrKW16K4hmdvc1GKAyC/cL1HWqYcyZaxgtcded19XUD4Rp2sanzgnnTc+a7IJr2 X5/u+Eqw6LNl+wum+/Z3UyH3VqJ13tR82e6IoXR2NZasfa+9cwJjH7JWkv/jDlzLgoa+IeD0 cTFy02g3uezWCgcN+b3sWvJ2Lb9tKQND1AFEs+eNALnxcHo/u3bJiykjLwSCDKgCKD9vLfeY YRgfacURS6Kp7+/lkaG0OoBLPoq64KrGsI3V1OCrwGrIW2O5TwU0MAJWqJ8FgqKqXnRrlVMD LLjt9Ba5Bj0OpYwbwtoyFC35klo8KmUQCEVdigXVV6xCXGtYs5ZdQUpGH6C6AvIfyxBG3r73 anc8yHO2rSsK9+MbLjzgAxJy3xv3uAp0k7zPvHk2Klzp1TZCsSFsQNaMN+jK1+h7t/lol8pA kTLKpXgzSnRPkvJXifRmW0oTdbfrCogcFDHQ5pa8KFTnNs8XMLIuW49yKvzUnSGzWZYwdg3p v1d4nIbxrsI5Wxb8Cag9nM67tu96kfvRCmcC5BWCL+oXFaSlY1vOI/xeBtggkcphr3gryx27 a17peKxLwZzUXVLbjv9sRbYtZ2C2SwCjdNq3c7b9No5SM6GGrJCg7IAat0mJNLQSVc9tk84U fPvoWTe1xJAXelNTddtO7N3qh9UdCO2eCDJxbJYVOD1CAPZMnrYoXjToJYpCPlGaaMBZIYyI Cm6cCVbkZY4jIIQI6LFzsi3nEf6v5wCQubKiW5DND9OUa9s0bjgNj9ci02mQ7gaPb9ZuqJcW edZy0N+2YTrCoA3FCLtZoJ1FwtejHfbIC5DvAyF5pEKBnm2LOTWHjUNXxRFkOC2m7SgyTY9H kThN9jmKo7WlpqkoH/yA2ig5wpgNGtXZUlVmtyJfredI7W8wKKOCd0uNag0PedeyNhPfEOmQ 9sdKF8XtiuYqrU4KXYMe0LYyk8gwjLpYLHI90ERvrAg81cCDbqA6vOBfETDI5upta433YB5f IdrpAtg2VrGh1BVfeQn+X3VTfSpQYl3LjTN/dvCHfdBcJ9Nx+RWKJVmqG1KEyjkGILYFNRF4 OyyTgklWKOJ0n6DeK4ZMUTjiK82P8xafg71f5qsOMQ9pw7aUqcH0/haE1G8NeifB2EKCybVd BKQm+m6XX2zabqG6L+IWwdE2GifYpGp+FIurKbK+lLIMIPYtDgeALwOaYTxE2CnKXidccqFN N4fC2UC7/GRbThMjRtXU3fvZ72+cnwsMJNcSpdNn+LlNFsxL00kYeDEL03i/WSQyzLm5unuX JP0lT9T+1bgocnxX41tLEP40mcQhhut0yT3t/C+39+JaJy93VAKsfoVhiiWeI7d3CV6g0jeZ 2sQ19NNJEqee6cK4SbSJNq9GWCaG9RdkKZuXCZOJ706xPWK42qdf8+qLfOTOaDWpVXLRS/2J H7j6TvethuYANG2Gv+pxFbIf6vaKo0boo45aEbEJBkmCLcSDlSNVGawwEqCKiUKHOdKpcTmq hqGuYmoCaJuziFzXEAAh4rfDm+XqJXIPiHaIMBBRyRREVK/ARvE2REbgwJr2xZA39HKDno8u ZNYpVRK0doMw2ERz2b4/jJfztlecygyj6fVyDuBZCZYRi7wDttrOlCK2PKWIvAOqeEiX/19T isg3EbJkjtdd08rK8V1vSsz7YueIj35pLGB0saKciCpt2r2BH1s2R/9guRJOg5eqjRXHs9ck wV8UjddVqv9F+FF905vbj9jJqNEw2d4liPwD3jai/U+1PcXeyvqpD4NX1YoagEusM7Q1fKe1 vPyJXVhDr/seXI4Ksyj4MG1FLqgxVQIMrEPTDTaFYELKWENKSCrAhIrJCjdw8fEG83DbtEAU mNjZ27vfG7CuVKELmk4QTjSrwAH0swTguDTCsxpbhRT48lrPMrBjYNnoAhMzu+TzOsfq8cNp IwTWRFESpqHzMesW2OPtHeXi7vbmcnsMstMN8bzA3QHSD5XtaB2YuNmese5XuHTgVmsha3gz ltBWrEI6dtZoOQspv3QbmiAAahQP2L1hDfH2thENDUMq2CM17gPDDsEQRZpe0yQQH+QT2nWU J6v+lBc5VgJtC2naId33C5o4kxddXrynCcv9r2/uL97v265KiSoA/KvRYNsWdWqYcUChMLKZ yNYU+wry+iHSqNUgOA1oD8gGL6dhJEMYWghHLpdYyWifsH5tW0oTPU7Y8FJ22LiBoWJCCouj 9Rvomz7qLbLXOKUfOkpMl32rxMbpXhGNzIIFecWhVeC9e096IRMgvlnqCk0JDyRJ/vMd6S3D GJp48R6gjFeIguQTLVt2NSmXoqLGUmdoEEcYbf1AFE07sQYUm2esGpdIx6Dd5lTQqg0wDSea eqyzky3swmkbR9NqbG9ZJrXrRDkKjPEDxvdqE7nHU+NrW0oTvf/CArFXRYxcSyjSfIFcZ7QB 7CeKSnartTYDbIfpQsQ2LYexusF5XqbvHGSwXi2ApCr5iMXQGOin2P4Gi/Lt5zgi9J+H7eft h9mV5QdG8KySYTKEeIEKD90tFvwLcf6y0FqDqncopw4VFzkrVV3IuFAZmnlQulipsWxA0RGq HsGsXxt4OL2k6QFKvHusaeLJu+fNWspK77wFSajFoug3fuEX1NPwaduimtZwgen7f7NZnUva DbC67BZFeHrtgKxAOOfb+rcvOKlM6mMs7cG/1GwfGaBPcsOS4wlAq/vJEZ6VO8xMWFbYdhML 7IKqXU8+Rz0PAXs/n2NNi2wMj5O0qgrIaYZb6hFSbt3WTNw8YbKf0h3YvIZTJUo9SN4NsNWw L0KkjGU0Y9MGMCVEjZltI4vxfOOBkf2IkBRH5pD0EdUAFdbxuMmMGmXnIUBKY6gN1QaCHjy8 tG/b8B8w3HBxvHr1lwiTLapkNTtiPKPFG1bwZ1E7IZLY1noRM8nVGLctX2LIZJDP4G22TWXq GkzlGs9kSfSaKHgx0dRcrk7iOxJpZ0K3hEIayGlLVl1eu95189/+C0CPnfYKZW5kc3RyZWFt CmVuZG9iagoyNSAwIG9iagozNjAzCmVuZG9iagoyMyAwIG9iago8PCAvVHlwZSAvUGFnZSAv UGFyZW50IDMgMCBSIC9SZXNvdXJjZXMgMjYgMCBSIC9Db250ZW50cyAyNCAwIFIgL01lZGlh Qm94ClswIDAgNTk1IDg0Ml0gPj4KZW5kb2JqCjI2IDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BE RiAvVGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczEgOCAwIFIgL0NzMiA5IDAgUiA+PiAvRXh0 R1N0YXRlCjw8IC9HczQgMTIgMCBSIC9HczEgMTQgMCBSID4+IC9Gb250IDw8IC9UVDEgNyAw IFIgL1RUMiAxMCAwIFIgPj4gPj4KZW5kb2JqCjI4IDAgb2JqCjw8IC9MZW5ndGggMjkgMCBS IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Ac1c25LbxhF951dM3qSqJUgM7k6V VIos23LJFdneih5kPYAgSCILAhQA7or5TKfyPzk9gwEGl11plbErvpRWQxDT6Ok+ffqC/ch+ Zh/ZGv96kcdCl7MqZe9YgUVbLNvMDhm3WXJkf7tmkViLmLcOrMgLPPz1+shW19f2wmbXO/ae PXkbP2XLtcXZk736IVU/sKdMfOKOF0q1sBNXLJ6oK231wfop+8Cuf2SvroXEmnCh7Y2ko8cZ i7VVN6o6+eRe7EnTSrXM1DWdwOojJdby1lfXdCKf1Erd36Bb669fdjc9yC8sntTL7rpOqOSm u05tvuxln9kUN3MC2+OWvXgCJUnVd2pbtc/WLXB1ifqkW+i+zJ8u5F26lav2LpNT6bTxTXtF dzdPntdCnBfZWMBZ4Fp+5NicuZ7N/MiznLUfKYNbfV/bbF+z1cuas6Qm87O8wHcC7uA462TB bc8KQ1gjVqwoDGCE1ppHkc88y7a5h3vCdncsiCyb22uPBXZohYHrMd+x7MD3eHfhQlwIM7Gi wA/Xri92YIFjhdyLbBasHctz/JC5bmA5bth/U26hybYg2ZiNrTx/HWCrwFoHTsBsSB+tedjt Kb95/54+963QDf3pnlJabU8pre15Fvdh/PBDCzohT7Vc14ZiBvrQtpTCdo/p+Z7lRl/ylO2O oWvxyPGYG+EEOA5mvOPnFOuGDkwApvDFig1ty/PcgLkOhzmIh+ORZwOo7n3K0WG6nOMM/S9X LMdJ8BBw6NrwKpjdvYdpRVHkcldoOPQ8zwlac4hcmKoTMif0IT5s9cg8bsMKXbtfy/U1G0fn c5Yzu/3uwsGjt2uH3jS71cEduyv7XQLb4ty2cUd13gvghFo7wFE0wxipzPF9y16H3kBstdaL vXB8eBAcsN+D9Uu60O11R8ZdqDRwI+06tbRwYNDQmju4Xb9GIndOIAVWX+3u1itFk63XSX+z /pv9mi6wWtVvqNZ6BTDH9SzfC52ByP3aZ7TsAiNcD7Y9Rpn7PJ4QkNtQHgf0RZ7HOBAOzoiA PHB5deLMWUeAwLV73xZ0fCMLlpq1YSo23I4DO0MK9PfsxNfcChyPL7oLe431X9Y0xr3QClwY QM7Ud5m21p/BolvV79h/uztV7gJ7bcCYZoXaGs4ATnkf0nMnBKThQfVN1Jouth1A06630Ddp 17BxLza4krwSdwRcuraP8+rWcn2NNMeHNxRL4n6arbcBUP9qt0WvhV5AbU3dT5NELQ1Elou6 DgB9UrrubnaEWBi5A1vX1rT7davwdwf4HSLAqjU8r7bGAbSI6JpS7ahbE94jDZTOjwC2dfv+ pu3FgGtsA8hWfvC5QAQ+YEUIlr1jwLccByyhjdNTxxgFTxs+GKx97Q7O2vIDzxkG+hGy2tjG oxBKAvA1PHMk8XTf9pkF2/ERctUduHTR+xjGWNw1ns8PXd3QQZLkmmbo9hoM3fPIPxWKLLQ1 /ZTVlXTK4C4BXFC7slsDz7Ndx6HY1t1RW3vglNubdhdzwT9ggUpnUPVCxDGpI1BIlyjkR5iL 43t2yDk+WBMnVn8F9eAwJLAXldIASddrJC/JAsRUXI0/iVTB7WQSwRF2kNs8YYztyurImpI1 h5QlZdFUZc5OeVyAd5YVO5bglVmx3Kan5sDiIs4vdVZfsc25wTeymmX108X1P1UO00v15UKy kZBgHBMhz8Uujetsk6esLCBU3bDkXFVp0bCqPDdpxeIqOWRNmjTnKq1ZjP+gyfqcN6zc0bOZ ltKzp1LexpBrm+12KSRLUrZJm7s0LYRqD3G1vYuJpJcV/txmxZ4l8SlOsubyB4noe1MRlbaK LTtVZZLW9YwgIzuIcTFZR539C+rfmdZkEE3FpO2OsLZ9eqQzzrPiht0dsuRAohU45VpINLRX acSmxYucqXjaGQpXsZ6yx/nAQtYeOkcd+QAY0dRRX+/gf+z121ufHdJ4C5tPDnFWwANZfd7t siSDqvILy0uYVnOIG5ZBTe2l6ackTbemfTV0ZkyMzg52fZPi3MryZnk+jQ299dkrOkPI3yAH F+pbiMJNB2xfByEOErnQd4CoU+nuynO+hVuybVWeTil+vJg+OdDAMXqZ3MKOLHfNkVCAgYx3 6iBGHn7NzkVMiGnSIwSXcVCJoP1HjgH/26bA4mOG4HEo7+hk64NS+QEwkqdb466C2sZQ4c+e PWPHbH9onjML/7DXBMBwkiSuEcoaJozgG/b7jDGwe1SI25hUIrQHfj7S3veIvVcMThPnFsJy /8+rT6eMYtqLU5Uhlw6uKMuw+8/bn96/BVqy4INpQcPxMb8ucMZF2iy/reJdo8khoOnVpyYt 6gxR+gcBUrV2AWN/T5pyA+TCE6zNCuqvnXFEBqWCJn9Jk6xKznncQCiTrogi3Bqkcmh8eNoX eQOj3x/Y9Zt/SIgGGUHgjxHKhD/CT8BUKgh0C6TsozDEM0qlULybiV1DomRSITYPkBxGEfQS jIkmQZLRvTzkGhxJ2Mxe8GJS7DAEpcUesFSzuww8dpumJ7Da+gQmQVZhVu32emyJBElAIAFD K1LFij03qQ2Yos1nTJEI5ibLsyZLwdnr8tipRWMwSjOSb0mC0XmxadW4MxYpgUK5ylkw0kr3 WnjxNSF4fIK3xCCBrdPgOP8wQb0xPsOzFaKViG+gVzFrsmP6DYgpWMzAj5GkpL1o7feMp0o+ KlqjIAIhk/J4yhGGt4JeKTeA9kDGBOWBX8ASkQgAogRX6xFImoLpMw9nSGK8B3VV5zo4bKVJ kYRkxRmHXKWnNMYTgdyeiwZBEGJXhjM61LTGgQ7KJNwuSpkFd6bW2UGeIv4BzUEolUV2/MYI l4Vfcz5jiIOYJpDlcsqSOCcF1aC1iL4t/M34OSGg4SPm7owh5tkRYW47SAIEGF2uFOGXndov IPwP5UscdVxUZhzoCsWvYTjepEkMjWhYu/hfSxQ8CC0fZVOx3dj9QC9xCuUdRfxN1lQxKFub kclETJPkiyo6Dz04iYBm4/CJKdSs4nrVPjlaom1muvi6EtIwM/V5FGDDBdrjWglJ5KEIb0NP EKEWxRkBMhKVPlGxg8oJCVVw4rouk4wc27A5OvaMOYrA/4BXiOqCYA6CHeipqwqhhpMA3+Ez yPhDeZfeptUVUE8jrshekCkfIb/Up+bXWhXJtB6dGUhUKdIVFdlSEY0l07rLclQOcah/anRx vBlGcUTdL0MUFAG6Rpj5FhGkEDU3QCOqRrtsfyYCXhYySjaXE5W2WtQ0XCbxHX8GwzcpVd66 uAF1tmU2pWBRNVGm15YIWwFNn3M44y+ahUlaQJoCjTjGF2WI27iJl7JW3BKKE9z9lFb4Lthk YjpEO9GMv+BAicXIwqbh6oLvTirmvkgpP56RkovSJEDvrSRQ7E18Sauls8rFny4SDKEHsjL8 jDoE1UbSLSGe4QN052rm7NdL3aTHuosAX9hE+EzIcdFPGoYc8KRrnMCupMhHRl2fN7XMrGqU w+vkDEwQyYfJx3Ywr4WmK2c+JBrFYVnyfzTLkDNXYAht+0SPfY6HBqUXuGK7kQIq9CbKohYN E1GlblVuigOiHT56QIry8VaW5Q2fL5qjo8cTSQWM93gqQWgurauB4gCwjtkWVb3lpvwEnk7Q UKDMTEygBbbOKUwePYiPN1d5nnM8iHKMb5Cv6Y2XLUIr1agUXJg6KM8fHxSGTgAYr17+9Fao 64e4Piw3KERu2Zsy3i5/BdjDY0wf4aQmiiMUZVC0+KgKCv8QIv32JP14jnNJx0TQRIBpDr89 BWmPtyjeCulkiJQAa/gYUUEbWTYkbRG9biN2nW2FxITyohFEJibYZnuw6jTBmPays2ZaSnuG B8l2VIs0JJcQCcmGgIGY7VHdU2kYTODXjDqCUGKxXVblJjNddELHY6rJc0014YGMiODnGmeO tCS+LaHa7aNh8qEA4VAH3Q2ZTx2YYZhoMOlprkvm2Ji89DBsMLMTwAcUGn1DSfdpWzm0aSQF 8v0xWwIYgw2UKDquEOfLCr25Vduu3JbAxaKkrkNFLUzqBsf5DUXJeEPJkbjatL1OavbwqioV W2HnKx0KVfVP4TYZcMyOKXK6IquPRptHNLboYwQV/48d6mvqw+2ItAzXi2uMrPbTDhjHtdyA Y3oVe40MEYlpnpu0RcQjjNeOd6FSHDoh4GCiLdvyaUFWa/QCGLFnVjcgD0fQpPJO8ljxUc+9 DVsGpk2nKEGQT0nST5SU91szZRrI8TL4k6T/mwtCSC77KWTEmAqgeqNpOSfNHFjwAcET4CV8 p2DFsjlTirfPUwyrbNmuKo8QB4UGgKtI7Qj4JCXgkF0UPE2Liem5IchBTDAORUTacoMs/ej5 ALQtKtrqIUTujCRUFvFMS+mNvQ1Skp9TRK2rZLXFuf/04iUxSjQaqVPQLr4Ga1FrxPYyZMgl RkbQVTYt41yraneuIGLVqVOJBR6K4YY+u4I2Tbqzg9Ev7mEC1Q8mfawXqKO36R1JYTi0BOGM e2oPiodOKNlATKGzA7BgjkGNDwn/uKION2J8QRk4BfkDOuH5xfBphZMOFyxqm9ZZpRqcZF7U a6dCfWczim4bKfsCdMNJz4vyotcA0+I/KC/uqzSV/T4xEIHSmeA9V2wpxteQraBwX5KFkTpp xKgurzD7RgpGNypNbkyrbdL9Inl/+e4ltTioQQ1ABXoIao7ZOxRSDvFJtD8OFWSSHTySdA8i fIPO08qkgEijMfFIap2I+WZk8o8Z93uILdJmGBafQKhu8qLw2Zr9/VYv0KkG4iPamlQKSTjX ZZMtfkz73Wv00g/j2zjLySmU7ZtKNcNJV2316JbyQwQKDx7ZM5zmHTXEGoodNGAmOYsY/ADB zdFz3LXdD6DTJ2qvy2oAHA2pBnp3u8x4tT+a65CBphzBC8gihNEIEb+DbChIbNKcvYfX+Sib fRCR+IyYN5OjGzakaK5LppcBjEYxGubmdgi2jX1HLoYA0cVxg6N3aKFarmNjKGPmUan/orpB KtlQRaI2mKGmajKOkwnP9sfuDhe26sa/lCZWNC4m65SYbqJ8jWg5RQZYh6h1xcVFojWme0v0 D5Bb06fPTdtJNGYBZmbDQsOzYch5xsTy/3M2LFjPNTimk7SIveWmwWACO2M6tFoKpqcTTYrO LY4ZplQB3n2aphICTIFQXU/wTkdfpGpGEYPevnBdzJaSMCPEiFERJHaCgZfWRY0EMgevgPge XhKce360kC5iHOmxoIC4tsCb3bN1fHqHdj2pCDBqaeWioyNSR9TyEbdl7Koxk0kA1UcPzC8Y nBjrOgsk2MgGCHbmApPBQhopZNLlAp0fBKZtepvhZQEMN9QY8s22oqSFhkBeXka6oQKCSe2Q eHPdrbbLKCjzIc0qlNXqG0WyDCUYqJaMLUWOV0y1YJSJ0zPPtnwQji7lGcmCSO1UFE3yOMMr PCBkz5H81Of9PkVCD6hAkMK4+12FMRwRqAyfC1+P4xRpB+gpXhoq0jPmX3Kky8X+jFCJ7EWU wEUjcOxtmHWQVTLTIvJprfYZTRoWe3Ju6mefKiSGMO7nsPm3MuP662MB5+EcB69djeGUFPWV m2hFTgdvOuBN/4h+fcB4h37wx0Db17XREvXwIv/MRu+opj2AanO19oBPXjIQJvYorBayzYGo QQyHx+Jt4RF4k6ifR1E4RX5Gh2sYYtj7l+fiEC9pUP7DlWmvCOYct+XB6AsB54Ex6uW5rK5p CFMkfGI+akPvtO2ok0UmbPK0ozlvBaAcqDI9xgxByfX28/sf43S/zzMozQ4/fO2wluZfyA/x my9Q2Q/4RLJH+9fDyXZA79QM6yBkPrF6lwDVhDrFMIco/Igg0L5ZQ3BK79qcygwNL/BTUU4S h1WjHU8/GLYeZ9INJUkpLrUitUmT6WDs4MXkoYaA2C9RratyTJTegZfX6PtR2xrsnSrESP27 NF++9UNlNtHK0McWTKsnmCPy1JyA87QVvmneO32v74rmFuh64p2mZZz034jwUWGkHU6Ygcsh lLWKDT8w9WLu1/rbfSwdv/VlhKeQ8d0BrHz+gBHK21eCUfXWrIGypPYDw1pEqWMqIUY3abJE FJ7A0uCXJ7x7VM1CmBisQH0cotcYa88x+WC6VI/fSzFjjse4wtswIGeDAYFxjYw01xmCGAjZ xGBzCYzStCbnOlR6BGTLpapYPSo+mQ3x7lyT6k8OT/e5izdpyRAqXyNvbdJPbaWW2G5coWUr IgliBcqyovEgE11iIOJzjg9w+KhZm9WfN2kskIx9ykICtIOD1OkiWoShMiobYyRIFXJfXX8H odHmxQdooeMj0/TIm7z7I0KxHM+Fu0o94TUyMVL+eyJDEIqH/1YREHpFdZyug4x/Ma3FyYsq aFeiSPSKGqLknFSxQr+oqc7ityGwFy/faEOgP/8Xim1GuAplbmRzdHJlYW0KZW5kb2JqCjI5 IDAgb2JqCjQ4MDgKZW5kb2JqCjI3IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAw IFIgL1Jlc291cmNlcyAzMCAwIFIgL0NvbnRlbnRzIDI4IDAgUiAvTWVkaWFCb3gKWzAgMCA1 OTUgODQyXSA+PgplbmRvYmoKMzAgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0g L0NvbG9yU3BhY2UgPDwgL0NzMiA5IDAgUiA+PiAvRXh0R1N0YXRlIDw8IC9HczQKMTIgMCBS IC9HczEgMTQgMCBSID4+IC9Gb250IDw8IC9UVDEgNyAwIFIgL1RUMiAxMCAwIFIgPj4gPj4K ZW5kb2JqCjMyIDAgb2JqCjw8IC9MZW5ndGggMzMgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl ID4+CnN0cmVhbQp4Ac1byZLbRhK98ysydHF3BInGvvgghyxZmp6w5bZFhyNGrUMRLJKwQBQF gL38/bwsLGSDUFuSSzOSD2aTIJHI9eXLrA/0G30gG/8FSUCx71Ip6U8q8Kaj33bIicl1KN3S j3NK9HsJBXZkJUEU4M/5li7mc2fi0HxFb+nsSpzTzLZcOlt3L2T3gs5JfxIM31DdGyt9xeSs u9LpPrDP6R3N/00/zbXER8LFTjCQjh9nKNay+6Gyl6+5F53VrVSzrLumF7j7qBNrdhN21/Qi 77p3qsMP9O8drp/1P7ppvjA5q2b9db1Q6fv+uu7ms4PsIzfFj3mRE7iWMzmDkhrV92q7aJ+t f8PtLuk+6d/ov+yeT5pf6d+Ztr9yYpVeG9+3V/S/BhOzvSbaXuxjkUuRb4WJ57jkBw6FSWB5 dph0DnfxqnJoXdHF88qltGL3s4Io9CLXgzmrdOL4vhUHXkyh51hJ6MAzcUViuzEFluO4AX4U zrsix4cy4BR+5Fl+BN91rSAIXXhrd92kvS6yfMd2IE5sOZ7vU4QbOL4T9Rc2Pwh/spIojG0/ 1KIQfjh2gwTf9BEHduLpF54fu/0321sMHoKcKLR8HzL5rmt5fhh+7J6um1h4NI+82ME3Qmhv KFxzi48LB7ewXBd6YikfCNfq6SDchDV8EM51Ywum+ahwECmMIs8jJ8DjJF7yd8IN1Ob4oeWG cfwJkpE9Ycng35EdeASncXzPc8nx8CIMwl7hf2eq2LcSJ3bhfENt9HpspIQj+uyISIuWFwb6 O5xREBPdn/BlD+4G7cZt6rEt27adyRyiurgWV+P/AUVwuzYVQWTOkGdE9EoWshR5fk/VTor3 WbGeUlasSlHV5T6t9/DOZ89/ruj6LOP/X5/TslQ72he3oqjlknYCWaKuzifzv7p8eJDtE0Wl U1F9yK+T+ZGoS1nVWYF71gq3LeuK1IoE7Up1ky1l+V01EHxKC5mKfSWp3sh7EqU0LWUQnEpZ qJrUDjqtM1VoxRZSLiG1KJaUigJCEWRa0kqVJOoa+tMPssxWK1nKojYtZJicClkpVp9Yi6yo airVvpYlpaqoS5XTLheFrCyiN2oL3ZVitcpS4qeoWPUL42qMvVMJe3Vkgt1sKXeyWMI7SRWU i3tZzjyCApuXPqVlhkfIBAso0k0mbyQJ05pMolM5YcrVPqeFgNJSyR4Jf6xlytbXJl/tC/2H yLP6fqqtLu/EdpfL7w3LF7kj7qiIrmS5zWqq2Jpiq/YFHHRFl89/uSKZbhRCewfFIrI7U9fq VpQwtmg94zvT4R15Iz6JZCSWy1JWlay0muCM+0Uuq41SiPu1dU6fl2MmDU5s0uFpjonCkXR4 UNePr64IklSwI+Kz4BxC1QZJZIlQqG9V+V6nn4LkXboRxVrSTmXGozeKRxIhNAWbwcuKOtMZ 5jhYOEYWEFDKRuaDxdtUfVFJRPrSuE2TEe+DpEiF8D6OYU54SOFikWfVBn/32tWZURVFGzX9 NVs84PX51HCYxPa48y32NS0Vcf5uZCYFm5d9VKxKtW28QCCQdhIfXV4dXNYyLaY3zDah5SEp v3ih3tAvohBryfrROeb5vqoR3SX9Lj/sob4mfl5mOefEAr3P/K8G/H4BjjgNnDgcsfQc4ZEK 1FqklrQTR8s6yIdyuZazWs1SBWjRXWlad9GIiY/kWGnNAC9UVGXbLBcloAMVQsMdVBCO9VMQ ZFrIZKTsHYTk+tvKBolOpTmqM9O+DDJEMyxmYg/9EEG97lEjw4IGFZDY7fIMf4mK0lwx7Go0 yRZnt2CtdqlTGBfTHUmUO4X8jRIyJeABTodqv9601uXsyQ6wr/Y6h0LYVvn6gq/kmYk3Ejta QQCMOtuglmgBIIyGtYBlpYQzPGPtphpVsjI74MMhZtri/uPRA02J3pBadqhRraBQEnvkIQ3Y 9hUXope5ukVfkZqWMBwJnbe/v3wegAd6ZxooJGiuT5qRl1zMGhw3hTpu5QKppJZk8kmdJLF8 z0HrCxEG0LPeCHAynweIHusPuc12vdDT9xo+bqHKrQ4SVaBRhIcuc476tjMAOJo/vzL54GD/ bHskUHa6bYltXfR830Ns7PMld1TVfvEX4IOG/3Sj8v1W1iW6Fl2Bmi4Lkc610GijGtvOSKy8 ngMXoNt78fpN1x/TbVZvqMS7aptx91epfYl+4YAgphz1pVzcm5bQG4kV9JnomDlCYcRl1rSq pCMo9IJ3rXSzBQr6EmSGyGd1BtCzyNGt0kblhlvA2I6HanyFZhRpG/gmR/I7+vfT3S5Dk4B8 WGY5aKIpuTY4rOG/t1cASJS8M6xNxxsG4iVokBJlbfYC4VAfiXF5dRPST3dIi9xD0L+kgMqr owuIfk1rtQBswxPYpgWNRsy+Rb8niqzactmTaK24y7/keqORUL3X5WXaRM0BijQMUBdrpgWN R/AFGpRVtgb51GCLXMHtkIDojxdXfdoRiPYjRKELEUcZyAzDIrrMpg3ZqGy7E1kTQpBC539Z 3sCYDxp+xpWiuKdbcQ9Vzzf7ilkpDjy0QaajyHVGciaq9aLRX7nIEO3lvcY5KlU5OvwRHTJH JW5UhvwFbDEzrUt3GOmIiFLmGjTA5aAVeOcCrRerjg3cA6EeOyK1tg3510FpseuPBI92sDwr 3hvGF7EbDfEFiGx4y+uWZkCGKVG78Mgv5DGzdFUyquXcbdpGyYiNHpPmzX1Vs9muz15fvngD JomREajaHiW2UMGwnJ4zYiYuvDWcHH4PVhjqWeF1i1R2QAJI1qAxgZ46Mhb4uvO/WpmW0B1J bq0ft9W1pYB1dpBomqpWl4cWCxwtIDQq4aEDMB2V3hjfrluMXncYAIDbbBsqsDLEfEmbPxag xQgGz7b7LcK2EbftUExrdIxzX3GbAQ3+ueEeRHPqYIHr7AaUK/d46J4ljLzUGKtl54HfddFb g6RHmVEr04KO8e46n3XEHcTqApv9crurTWcWLxmhOE8D+ZBI6BDJl1ccyM0kA17ZUBFA/8Zj xHdGqivnke+4VsLJoLR72gpMcPKKm3Sd9Q7KQ7W4Z4wKezOeVZgVcJaUS8MG9cfo9c7ZGvtp UaT1xVT10bzOSVz0Y7begwgG/RhG4J/X+D3GhPdNJhYuhjdC8GfrddMoNOwxNdQZa3qnwEdk QOJoRM02Vf7YeGAF1H8LDIj7cf2HU5Sw9E2WYlRlUh+s8bHJwB8Ntyl7QL9pAb3Jh3ft0Ao9 THJZhgHmBC773Of8pIZ/7HHRYO1z8OANHkNXkGr2nqPyAolhinyAaZfhAVbsn4wQnj69QOBf 4NEvyLIsTc5jTIDGBTi2yQ7bbL1BIaoAwdEgoK2h5nKNHpHhmZT+waSN4CCBOwI8MDo6dHud c0BNSE3MhQLJporHfndclMDgNTpue3AesRoedGA/ZehCTfOpERLEEVWl0ma8qsdZ/H6DPiDb hz3ijQcMeuYLR2ClU4YSZTbWg7FhAlTZhtu+eF+oWx6ydX10p9nPjYXHcqAbB1bsBxEsGw5z 4BeE3WO38rCt5vuJO3arvrahA+tCzXy9DcaGI/CMzsYdswzQxLSf7i8M1huET2iPwJKDzTVx gg2UNbtfQ3i3/sgjaQwQaz1y766YcYBVcrvITVNn4dhMAZrq1zvauQIPNpcYqh4aDYC5XN1z bOOzdU/3GY4dUHWDGtEGeD9Gvz6rpCRGJPS22Irdu+tz08UyBGd8Qo48Y0s1CY7XibCpAe5L t2TH+VBy1stkkSIfgk3H/gtjdoyWkGmM43EsiZ0qC1n50HJNe7L2YD7tiyPJx2AS9LFdF4eY McSnIn5B8nms5mPXkbcQkedwq6HVsNdjNsyxJDe4x9OnT9vqDHtfbASWdBbYU7jg9lGzYk2V B4ZfqRw9Xcv/AOWpPTyqXIPWL2rT1RzLg6eewVtuOwTugCFDSMOtq2bXA9HFLdKqozlaXgG7 Sgh+lr0yzfBF/ogTt4yB6cCOsKT6MLBDK0CT/bIF4lBF7zATE4sFcWxzKplghfto66+7XUWS CxJmJthf2WPdCzxm14GgAdxKwXs6oCj0QuKhTzENWGJnxATz4zxyNB1/yIV4unXp6mtLSmF6 CNwFlGu4OMQnkwoUB91Bd+TcMZ/0kOtp+JTeuvRh8s93OuM4SE6ti0KhJ2M93Lk+e8NVAGQn SFCmmRjRw6wfScRfQW9jg5NSgnaokHtQ1jBCyXPJC1/IUy2XB3dru9O+NWpy6UQfaeiXdb90 ITbGAYdBjvqHA7JmPubYpgdkyQl3/G0OyBJ7jPL81nq4xB6jOzmQmeX+0h4OPD1godl8k2BH f+ChDRjV4JPe/gdpefbyz9mPgHubrSjfm4eiOPxwAmoA1j+llzQI5/peksUZaMQwnOt7ybEn 73jSQS/ZQTwjFTtxcKLjpGLD7v+zXjJxcODjIUrB7Q82/1Z6ycQJRkAmi9odFfj/9pKJc8I3 NuF7WMn++r1k4uDc34kxny27BZUclB/qr9puAQ+6intAeg0e1AMfTo0Vdky5UhueAyTu2P7w k6VcCaZMMXK8fzKlW97l0SsL3ewRVKSew6OnuD4DYG2/wBCHkzlvVhnOyO4YSynveJYIIY7k go35Daz1FfQEKlO3FyJN5a4mbGrXT3RjYW5/OHGDkYHPA8YA2oMFS/SEzfkd4D+2aI+8KnAL LSCD4KZXphJ3jJM8JQHQw3YCsnSPA9WN6Y3XxB3j8Xh7nVtqEKa8LprVmNhpi/Lwsz0AQH9H b5j2w7FF56Pm4h+fbXMxNLG9wKXExfHHhwnkC0ruY/Stjy1JO0KfOnIrKF4fjmPaAAF+0hoY 7kQT74Se/Cb5lQRbpQMcFIFG+LUrfCKnS9Cl7W5z9bmO8Zi1AsJ50OFyTWQ5uP1lIRYZH8ni vPcyQwb+WZ8q8/HJgfc2iAshiz+2LIrEt8wqLDLxqiWo0r79naLSYbdwi6VXXtpqDumBBWO2 IFtiA3e2UHcYv+pNYMOCjjFi3ab/ipXFCa8jMpqJDG1x6qMHfvw52mV0xbpzN5xRcGx24FEA K8MEzeUiK7qtkGqfbrp5MR8FxQlW3sBj66tFjQv5kUyLGY4UunaUwbbu/UzvpdzjRLu5sT4O W1tNTvTDYQTokanRmwWRhX4aHn5yL94c2aEIgT7B8jarWzOreuxpXuEna8Q6I/IIWT/zBf1g 8rER0gEO6D8sOPBEvVFW7XDIjh+zrbpH2f+3/wJTZ66JCmVuZHN0cmVhbQplbmRvYmoKMzMg MCBvYmoKMzkxMAplbmRvYmoKMzEgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAg UiAvUmVzb3VyY2VzIDM0IDAgUiAvQ29udGVudHMgMzIgMCBSIC9NZWRpYUJveApbMCAwIDU5 NSA4NDJdID4+CmVuZG9iagozNCAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAv Q29sb3JTcGFjZSA8PCAvQ3MyIDkgMCBSID4+IC9FeHRHU3RhdGUgPDwgL0dzNAoxMiAwIFIg L0dzMSAxNCAwIFIgPj4gL0ZvbnQgPDwgL1RUMSA3IDAgUiAvVFQyIDEwIDAgUiA+PiA+Pgpl bmRvYmoKMzYgMCBvYmoKPDwgL0xlbmd0aCAzNyAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4Kc3RyZWFtCngBzVvbcttGEn3nV3T5ZaUqgiZAAiT2TTdHTjm2YjHJ7sp6GIJDEhEI0BhQ sv5+T88AEAnOOnEyrlq7yhcSIpo93adPn258pp/pMw3xO4xDmo4DKiX9Rjle9PXLPvlTCnxK NnQ+o1i/FlM4nAzicBLiv7MNvZ7N/J5PsyXd0cmNOCVvOAjoZNX8Qzb/oFPS70TdF4rmhaW+ onfSXOk3bwxP6Z5mP9LVTFu8Z9zUDzvW8dfpmrVoPqhs7TP3opOqtspLm2tag5u3GrO8x9b0 1uRt81Pq5QPa116u99oPXZsf6J0or72uNSp5aK9rbu692G65KT5sNPHDYOD3TuAk4/rWba/r 79a+EDSXNO+0L7Q/HJz2zKe0r/TrTzk6ldYb/6yvaD8tNOfV0+fFMTYJaDIeRPHID2gc+hTF 4WA0jOIm4F7/oHxaKXp9oQJKFIffIJxEo0kwwnGqpOf74WAa+Ai+2B8Mo+GE/NHAH0dhROHA 94MQH4rgXeLl8SCIRhGNx4jSYTw6vrBnLozjQRxHYxqPJoOIg38ymIb+2J90P7G90J8MgtH4 +DrzgRx4bCvhy4z5yyC1BqMo9KdBoN+CX5v/wh/jYBwNQnycSa7hYDgc+r1ZQnARf5CHv0OK w3FYh3MAryDLTmDEgOhjsaukd1MWiVSqKAn/qmRSpUV+SrPfkSk9ndvtHfVH/rEBdGzAZNQz +dQYQEQ/FaqipMgrudkWpSifqWR7SkVr8ShJ0FLggrUoF0+ilJ5QKlWVXNCyKPHCIs1Xpz1t pUEgB1ZOJ8dWbjORw5h8AYOyolAye4bRu20GS9j4sshIX9Pn/+ZwH96oipWs1rKkp7Rak3Bs Z8RnrEFzz5tZmj9QtRbsMUWbXbKmDKdKidiKJK2e+b0cfyC+W/8Zw/nrZAvXNvrhsY2wYJFJ BN6sFMtlmtAiXS5lKfMqFRx1MDbPi4rmkhYFvD5nq+Whm13bGcTHdqp0IfuwIhE7JWFCquiJ fUTFoyyzQuCAYVaKyC1zkZF2fX34iEp+07WVY0v+HJ1jVRy7a1Bn8p/Okd4+lBxncjQBgHRj bwZvXBdbb/7s4S/6sOXDRBpLsUAOcDzOpcxpK8oqTXaZKDmH1iLLZL5ih6k0T5y7bGoJwDSn jUadtEx2G1UJ3Ff1a6+VpVTbImdggakooxXh4Lc7HDNn9Pc41tgSfAegwslKWwPQsAupc6YA RLB0l1V9KrayFFUByNypHfz5TIuy2DoOvolvCb63N49R7SVgDHBQpLmJffhMfqlkrjihTQjA 7JtMCuSSkpLuPr65iPw4uHdtZ2CBb/afWDymiYTTVqZssEPrOkfFUp++qTyHSDNwbN901D3t H+C3PiHORAYX7f26+rJNccZ0ti3TjPxJn4IhKHTn192NWEnyfdeOnE679eWthjpZeZcA7mrP DB0GV+1xX+uMV3sXEH1IqmIOGMA3GDr2aBx0I3MyGMGTb3MxTzNd9Aq6kSWCYENv0lx6qxJx inR+k2YAbwTsHjz2XpjNXyY6MSjkbNNDP7NXmm+LDaJPcxtKN2AOG1Q8XfAUZQAaWu6btmxM 49hk/7p2WmQBxm7GKnjxDVJHfhFscB8EqAUb2ohnehJ5xaDIeNPggGtDJ918QVztQQ2zV4Yc E3Q0e95KUN5PJx+vZ8NPpzTfVdrSIgcsglGIeYZaXrg2Mu6GIIw0R0jAP+YJXd9SxZbCzgP7 P53C5fvg7tZQH52BBR7ZvqaIoDf7Njr9NargB+jT/emU9I07lEGTKad3C6NBgF7IejeSIO+7 Lf4CDiQcMQIsAP1bUogSNekl4bZFlibPzh0fdOEUIfLpRA5Qzl/p/EHlbnJoP8CFbtBeQvwV PSIvX+mAdl/ncVAjCzIYJqQQyWgt6uyDAw+Dt06+Vwji9lh7f6F1PeKbMCrqJthkMEaq3Mpk VzLEXxQgcSXo5hl62ASNBOBdt1322uT8dGPL6TIhVo2BDPlpUuN9jel0XDNXMgeZYw63xJ+u zfSHlrNFB1MApQABpckIw4aQEzBXrooylQq6jDtUCJGg/mjUgQOkQ0F09Sg0ZYQNres43tBg K+feiCyHBhsui1ta7LhM7JFuEMfPO9AxrtrKuTemsdUbe5YcUgaSZQnC79ojgW+pDnwqHW7n qa1MUu7dU6V20rk/giOpCtHxS56lD5LJ0LjFySfIK9ybS0A7uiAvE88gmczsiwSSDJQELvpV mT6mnFTO/RVayMmy2KHUQLXYSAFAMtlEr95ev3sFwH/VsOiGsbxD+1utAZrmm5leybmhNult mcpsYfpeVZW7pNrBlw00NYiPRk6XyWUmv6RMnlgESwrmg1/6zs20aW98QyabpdyiG0L6ofA0 uoHWsWghubWrq1MuTaMOOs0KTeo8SUY24S1lWrHR8N43SgZ0QoZ7EA1raO79QAMt7i21yW+6 hDPX0JWxS0tZpNF8nxskFNgZy16s3dS+l44lQn84smlvHbRjhZA1owqliLuQRQ0Ae6xtIxET eao2JgxcR+bIpr3VJeHggPfPFfTuEYpXuqTfdxCxW5hCvweYcm5iaAHvFgq53QDGdBGREi2C wUxmTACtNFcSAh3C1n3XicOeWEput7pwDFZPrBWyxzbo1U2sGmjUx/+9XWmTDRtXIitYvJr4 /uge0KOSMp1r8EGm6HKo5Tq28OOZ98MOahO8rlhK3lXOz9ymHfKtlYDaAHlrnaefUaDddnWT 4SAKMDcbjuIubzFTBIdkMRhGg2gUcAt5fDcNVihFxbPB/JdgpgJeKE3cLEHbnr4Dmx7bJNE/ ACdu7xeLlKVxJiT9jhTkOj7GNjUUOjuEeR6j5QkAFSnfwunLUEiL8oeB87elsVGIwAkjiGLD Y8OATN9Kq7828MTAdxCEMccN7tVl10Y6528u24ajvbujnnU8tmDdUVNDd2+9y8EDBDaRi4dU edFG5F66fYw8ufYwLMFYZHVPd2dVhs5IBUN/7FjphYNCS1t4d37tXf3i6Ru+9PN/chT9NVGI 27/x1NL+3ehxC6ZselxaVSJZI63tDTy5zJT9uJx2hYbvGJfHTgDvEUlFaGU0neSB2AuW/u38 056PORk62jQ0SqNM1xwaN+fhOtffDRALnRcPkcUWJRCzCKgCtAGErWo1A3N5DMic17bQt+QP YxXUclZOWTrrN8jFStiWWQvw9zWEDAzEpJelbGa++nSqpWvBIfXgnniFgSV9dCFEJ4Dq9Awp A5QVmwOixKhGbNAgVm2jVdVTcOw/oI59L+IVHo2d0FEfEy+deswftrtyizUHtrIORu1cupQ5 Oml++VaW3HW5zEOOzzDsJqDWSaGEgL2aE8TZ8wQR2p9eF5hovrXclbriLySGkJmqNUizN+RG gwyPBmKw7P2H2dU3i2OoWz1swZlFHYvaiW2lTsFyMyN0PWz1h9HRdKaRN/6/hoT+cGLT33GA b+sugxcCap2opuuiwRbdMYM0ZTuwfaTxy5KD6+Cf2LR3GNnZpdikq3VFK15GAGyv1rpPUlnx dLDVI6q16ZXnzpN0MrboXrAT9YGXyEwnyTBiqso/FF3c/MLUF3s9TMsBLUqLSdwYoZbw1/kO Vh4NDWAifhnREPsTZhirj7ddTwE1XqYrKGF628NMi1j0orOLdzSHudj/yZ2f+8TSusPSfeWo Iyzo4qffN2rCi+iJ6je7uHFuom3CARMvpUKJ1UyAboqy4lrLEhyYRCuf6/iEwoA+7KCTh2KT Ovfl1DbjgKGfTsAdipJ3kWBZrQ7yPoiW9RfoBVoFj78Db31xydPF0OwBuR4b+8Opb88jaHAv qQSz2Qid31skNd1dpCopvKtrD1MvdY+8+k0SMouFcIFVEnwP16c/HVmqMpxazB/TYqfgRaFg ixGTBQzQcxI0uUiXPTJbjwu0nIvdPxRw54aO7ZlkcKcRihUvRkLUbJQBGP4eklNRPqAeQArX I6hL2azBOl0wxanb5k5w5u0zWnLol59O3r+9BN3hpaAEp3v3H8Sf9+Y37xwN+3ojygc+8xli Qqu3egPjaZ0ma+fOnFiILQxFOAK2G2cy/TeHicOGBgalEYNOHmEeqrjeQm7Bg4EDjneq/GE8 tISnbhwPTcA56xkSy98mIlSxrHixGJHLHB3IABGf5yDMhF37M7aN16oUSh2rRk/YN/UUPMeu 5V6AR42c3OuUd1Zw3PobNTIkpRXWkJcszju3c2TpvDD+aRav9QYsVrnoWUKfwLwDS1SMAvMd dtVLmenpO1x52Lo7t3Jsic56DahGTwZwnh6nuRnnAlcXjJ1Y4EWsmjZCb2A0mPqmFCv/3vlc K7bNCWsY51sG94ap3b0ppTy/vfRuz+71KtB5u33Mc04kF9YdeFMayYXNtipzzuxi26DQ7AZp yZKPN+WFWd5rOjzfes2zLgJJsbdJ6/zobXPCpFigbKJAgqPDWXiWgLf05ReJdR/QNuNhpJFx JOfTFjWTt84z3UFy9Do2FIsrlkzShBOsCSCEOsnjDeTKYWjiNcX7gh34cg2c/tA2fNPHymHJ AFSPqY1PjUaB1IHBwFBuOOrLDAGsh8fOvWgbvtUD6hYgIZs+sy7BB9uqrOy//a0bvOncONvY 7dAtrzU/UnIzR0C2g0odpQ958ZTDi8WmQfgxnjIoMZd3bqdt9KYwoMS6UQvaZp0DNQWP3iQY uGP5nbeDdER0Y1FTEOXen7bZWylyKGfaTSAQtQKFsqNXuo0qpBuOPRKPB1/EA1ajkffu09o2 duPKstPNL7JXTwgnoxjAfnde5IhB7/3Z+w8/hNN7Xez39PyAod71aftHg58pMuXt2fszXpXj R1ugkALRXa/u4Om67lNmIIwzjbqMyjmCiY3AGj7oBK+WaaalexyUt0WBJzIM7cHPEMas3hWm Zc4bGt+PLJ0XD8eByKAHSEZYAxjRCuNcckcDTXTegIkBmj2DuZvAAMttp+D7R9MIOBNO+eZ5 jJmUYYDAjwYeK45+4Hcf6IkRLlBY2+3KTsg4FFb9wKZN8/H/TxjXeHS8usIBtp+Fro8jsGnT cJKRofVCqt6XaaIY4Yz45mfZgKJlsdiBNnGVyuVT+92c2xhZGmAD638lar6mU/sBnvU+fAzM HyJszhKuang0cnWwLenoMVKsXRw98GEghsSuWvNjUOYxPd3poXiBbuGhSC3/iGy7Flgu4f7U aEEYKvyUPgjpetUW+62Wczibl2ItNlhRzvsErr+gc4GBVJ/OMVXL6UKU6JDxSEqfZumGLtbg Bn368IRNmEv5rshXeL3YuI6YUWjhqNeyxOM6EJPeYdJyXfA0UN8cD9JUCXTlW3SsUNJuK7lc 4nHNPl0t9KbLrxhS44G+h8I5f8EDz8fPaF6V2EH99TnHWK9PP6LdK+El+lfKVR8t9Vm+wOoH /bvAcAjDZDZLU320h4+p+2eHEZpH8xCE5qPIdvq5E6xN6vVh7p3QOWcpPAj+xWpTvSe6V1H2 KMHP/wVXr42MCmVuZHN0cmVhbQplbmRvYmoKMzcgMCBvYmoKNDEwMwplbmRvYmoKMzUgMCBv YmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDM4IDAgUiAvQ29u dGVudHMgMzYgMCBSIC9NZWRpYUJveApbMCAwIDU5NSA4NDJdID4+CmVuZG9iagozOCAwIG9i ago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29sb3JTcGFjZSA8PCAvQ3MyIDkgMCBS ID4+IC9FeHRHU3RhdGUgPDwgL0dzNAoxMiAwIFIgL0dzMSAxNCAwIFIgPj4gL0ZvbnQgPDwg L1RUMSA3IDAgUiAvVFQyIDEwIDAgUiA+PiA+PgplbmRvYmoKNDAgMCBvYmoKPDwgL0xlbmd0 aCA0MSAwIFIgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBzVtrb9rYFv2eX7GV T4mE3+/qaiTyatKZJplA26ubqSpjDsFTYzO2gWZ+/V3n+IFDKKS3J7qTSo0xDl4+e+3X2oe/ 6Hf6i3T8cwKHfNuknNEnSnHSEKcNMnwyDYpmdDKkQJwLyNE9NXA8By+HM9KGQ+PAoOGE7uno NjwmRVdNOnpoDlhzQMck3vE2T2TNiYm44uCoudJo3tCP6TMN39H5UCDugPMNZwMdf5xNWOPm g/IWX3UvOiprVErcXNMCbt5qYClLt7mmhTxvzhTrD2jPra9X2g+dVn9wcFQo7XUtqOhre11z c2WNfctN8WGWZzimahwcYZGqpW+XTaufrT1hNpc077Qn2j82jw+qT2nP9OpPeWaVdjXe1Fe0 n+ZU9joQ9uIc80zybNUNLMMk2zHIDRzV0t2gIZx2WpgUFYJgOhURp6VquY7hm6Y4CUzNS3yW HdiG6tvGQUVMXdV1HRSMCB/P7a/gt0OGYVtOzQUTjAZFj95madkjVlKYqNT9Of82j3NWUH+e xwkZXo9MHczf+Lm/DR8YGdbn44Phnw0d19DEvdcvO0hrkn4fqecdVKxtkF6lJctTVipneTgp OziubpcunX8rWVrEWUqXLByzvOhcQHQTldmI5fwRdNlIHSPYQIpbXwBqmI4z4utLq2yRjCmJ vzIqMyqnYfqV3oUp/SfL/yYN17j0Wzg6puGfFUNeZux9S+hY1nNg/5qW5bx4o2kPmZuEI7WI tV96AJOzMb0PF9G0R8BNA/yH9RqUbDIJ01Q6NHvTulizFlpR31VNEw5ukuU0z7NlPI7TBwqj iBUFX8fiERfOCoEXvFhl+ddCunFd4/kawoCwKUNuYLN5kj1i6QBnznIgnRH7hqN4xtKygjZj YbHIWXUiTpdZssRzSAfqOc+BzkMEUMBYxeWUtruJyk37I467L8S4urURYgwDkeWOTbBgKWzX 3vBADs1da9NEuCG/5TWsEZbxkm27uaSA6jrBxtOCyPd3F6eOHjififqjhD3Cv9QeXAqmD3t0 i2PuYm9VumbLOEmYcs3ipEeHZ2yeswiQs1Q2PVxvSyzohMhsQsPHOUOquMsWJfezJozGqWDO YY/wVCh1AqcnHZy/JRp0wJ3dXJGhq4Zn+55Wr22PzljEZlVQ1z3k5JrGkljl6Zus6gDCYRus VquVmk8ihY3jMsvVLH/Q4nSSaTjHF+sX4WAyw7pnbsk3gnKeaYJyv+ZxMUXyAePAtMNLcC3h BoWJb5YsT8L5nL8U4eAiDx9EYDqUblTP3s04wSYghiE3zVud7Zg3kI/O2U25F5kXOF/BvP6W QM7N6wa2C/NWBdsFN+1tnvFcWBtXGPSwX2azODqk17RssIWAHe/gluVgn1u2Ovs+fEQhZljC Z2V6hm/sptxLjMohyjcqL82fVrNYr8qovv7UqAMWLfK4fKQr1BZxlQ0K7rxPHPZVkoTvbKFe x7DrMgIJ62E6Ql12FhdRhqjyWOcHN/D1JhYfiGa6bVP+917Ad3cTbjOACBDUXzwsinLNtLrI OVi3Iz+ByOdFzgFa/aY76SwTDl/GNF+vmAZk0tYqML7DNM8weHZYh4/3YZqHKDs+1vXInUon WQrGIbJscE92wg/M3UTjeaqI/0ZdLUhflSJ0Og3jtKiJxh9HOtEC68eIJkDwTm4R5iKm2Q0k LstIYVrg/DzTOMxXYJr/Hab50AmeMO23eNGjTzXNhir1eW9ZZCmI9palLBfBrAlx0rkW7OZa lTDX+ZJOM+gIAAj2XYb5bLJIasrx55JdiJi6/mOUEyC6lOuUvnIoB43k5ynHYUqnnKk736Mc 1hGUO2PovNMHXvmKFgsh7TIG2TjTGvmIUDWVWZTxyMejDBQjVzLnTN3dzbk/jnhc++OYBnMW xZM6y4Nmg+EZ+SiceAnl45lkl0im7v0g3TgIerdIRHh7wjUZgqSpB5tqwY8nUr5Q4JpcAdI0 zO9xzdFtcO10mq3AqyHC2m/Z4mGaNn0+7+0R5D7FXK8sOPO4PnmdjZl0iNZumt2xvxbQcOsG j05Ob8k0YU7BLjzF8wLd52elw7R3c66TP4Pei0onDlO+xc1neqkccdyWLY6b5jOxr4lu/zBx 3LSMzT4b4pwJce4KGsmry3OmZW/OOxBe7vu311enyiBajJHmP9fKkawK3LSc3XSv71uJgofv ERfylHKobtDbwzyaxiWLSgjGIoPx2IG8QAKybMe09oiCJ0mGXPpukTJCrOCzk457jvCmGs7R MKgQ3zX+rqa7mm5r0mHukQdnYgmVagmV7hIqiMVKPF+6mvxaxDa2BN/7fpmERVxA3jAbYlUz 5Re0wXuUddM2t2jNnXRZ37tHfeQkCEEl1P9W6eMdncgEVbH9gatGsg1l75H8Gk1KQOCsPkkA 8RLDlPNFnkF95suG9mCGuU4+DmfSM5G9R/W7ZuWUK6TpuFAxDYMzkmErBgoyjqzb20kpfmwP M1ixYWCPijCDuByqI75aGD2pUTbTRlOFLTDW1WqrtycU6VbdJkg+p53SEu4LD1rKIEETVajz 8aT1PVlNsekYWzqUju8h4zbjADlzHtMxvZ2m2vA9lHtLltAnKJ1Q7vqjhRBpRSHYDqpl28nZ pjF27NQMdDCqPF9iRF5pK63ceIZZFNRkuGWtz8ovBJ09+qJQzTCa5iMVKD0xZBU+UqnSi2Fr uqOFSspXVlmFj0o2UcJqZaVz3tmjOPKcorBmy4EyrbYcKGWmML60IucoRa3kKuNqaXkSktyk OMFmecXrm5NL5fyDgpAl3w9cY3fIeuIHd7wlOkcy4i0RevFBNA35GBjZCQwUrTe84xJSsnQD unsUxnMgujq7HUAyELQnJCHE/sonzvPwO9lJvk+4eyRHbsVO1cVdA/XiSh0zbYwGNMnCscYT gY34K0oPBasufzmd3ZOVxrLKKI/ZBKVFodQW5l7KLYwFV65uB0q93spqXqcGyR7hblUlK2Fb ue5f37x1fOnZAbu3dmaHRle/44XZ1e1Hly7u+m/fn18P+8Orm+s3NAT1TsOC0UWWy44R3j6F cb3rgLNerBE5Pt+dsKKbPGFhChUDGkdcxGGK6cCHQV8VXYF0pOZullmKIyoxa8MhMOxGL8In 7wWap0Ibs0m4SEptEid4JR2ltSXmdvLsLEvVByFrJ+qknq+LilcdifHKk5JIWtfpbZMc70/5 eE45v1S4qC2d9p63uyERd28EsLbuaXeW3CH0gmI8OTSau1gn1CDSbRbsZtZ6f6DuSi/zfX13 7dgteyJuMFHgs1T7MNCgBUzTDK12DCaXX13bx/++Z0pntb9N7uywugvky4qLFF/mITa66YGu hywa+7pjjy1v/DpR3d8mIdbs5l2lIZ3bvrtbmG64LX7T1c2ABtmkXGEfZVVDfIzzchEm7VxJ MFs2rf1nm2Q7FsPhHbYeFtgkBfX+jKUx4KDeGrCclzz0cZHw2dsoTrDbAJF/wObYTokNVdJR BluU9A5QlDhNREfxX2ZZUqhrP2iqaC3CjkqWaxE21OJIugME+hY9p4NSGLrplvrjZVxk+aMm cCpFyKttS8dcW5T+y0kuvda39Gf7HOXI045sedrSn+mK/1B52jK2injC1AqPK9JFPOz3f1nO FBhEXPn33Tq0nPKt7822iFuxu7f2bMlOa+GrAs93LHXcYUcgEYIx/AEbRRsVRs6mTMvYo981 mfT/FEMw7Ngd6fbHEEdHh63EWfHtFSKIsW3j3v3pIp3y+GXqspOoZQqdjn8jarvAKW7do6uq LVratCyq7MnbWhqFUGIjrmDzPcj1tz9k8xyztJ08F1MFrorR9e1AO+1fnfXFJISaBC9EvU/8 uwfTbF5PSaSD3CPtPdluFs1QUYtuSHwjAqgKMZ3RXXxfSyuELCs7e1rmHmkv4iR70vnIGotY ptiLt0Gy+4ucsZPBmTLor1ktKQqZ20S3Tmisb43Gpz5CaVXv6WzqBpSFDTx43hvTVrmi+EY2 b5DfdpJbcPcymyujRwW/KJvz7x4UtCiYwhNNrkyAk0aLh1esDy2QZyfKjcEjl8A4rFFRsbwt EMOqKOOd0nohf/8vwT9iIQplbmRzdHJlYW0KZW5kb2JqCjQxIDAgb2JqCjMwNTQKZW5kb2Jq CjM5IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyA0MiAw IFIgL0NvbnRlbnRzIDQwIDAgUiAvTWVkaWFCb3gKWzAgMCA1OTUgODQyXSA+PgplbmRvYmoK NDIgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0Nz MiA5IDAgUiA+PiAvRm9udCA8PCAvVFQxIDcgMCBSCi9UVDIgMTAgMCBSID4+ID4+CmVuZG9i ago0NCAwIG9iago8PCAvTGVuZ3RoIDQ1IDAgUiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+Pgpz dHJlYW0KeAHNW2tv21YS/a5fMfAnGxApvh/FIoVt2YnTOlFlpcHCCRa0SEmMKVIhKbve/7n/ Z89cPvSMlM3eYLdtGuqKIocz587jzPAr/UFfScO/tm+TZxmUR/SRUizqYlkn3SNDp/GcLkbk izWfbM1Vfdu18XE0p95opHd0Gk3onk4HwRkpmmrQ6bQ5iJoDOiPxjbe9kDULE3FG57Q5U2++ 0M7oM43e0tVISLwmnKfbW9Lx42yLFTYXylv5qnvRaVlLpcTNOa3AzVeNWMqT05zTirxoVorV Bdq11flKe9FZ9YPOaaG057VCjR/b85qbKyvZ99wUFzNd3TZUvXMKJVWqb9XWq5+tXTCaU5pv 2oX2x8ZZp7pKu9Ktr7JjlVYbv9RntFezK3t1hL0YY65BrqU6vqkbZNk6Ob6tmprjN4DrvS50 mhbUuywMGhcMP1W3fN3ULZizGHdcU/UM29fJ1UzVNh2PLMtVTcszyHZUw/Q0h681YYiqvut4 muWIX1L7S8f3VMuwzM6cbENXdddiOao1StbWPE/Vfd/A2uq3q7XZ7iquaLiOauq+Rc7qzLU1 U9U8x9m8Yrs2g9irOzmu6lr+6vF0bBrD1jvN01VPBYVZrDBsX9V0bN0zDH50RkDzETq3HdOF Hr16i2iqpml6ZzQmmEGcjb9t0k3T9Os9Y0D12MqntPHPdR5FF3d95e5cMbRfDEuNF0+OGhTj V+pZZ/Sl2Zere3+nKLRHFMftVNt3TZT711laKpez7DlVbq4Grz3/8xn9Z/ftVD6sUsG++3p4 cOHN1u67pgSWoEvXKgVpSCOVhDBdOjmnu3mQJPRhEQZlRFlK5SyiDwUOJ3QzgAuQrSDf3lXQ mqBXf5VRWsQQ5E0UhFFenHSJdUaer9LvWRpmaZc+/KbSbZCPZ2R0ydB0qytbTEvzD4r5t1lZ Ln7p9Z6fn9U4WkzVLJ/2WBJFMxXNUOKonHh+bzJly/MJ9YoiXVDDPChoNFOWwrbqIpwA75Jx x95wB3cV3gXSvRXSOz+w2fcg3XIOA6hBOsB9nQfTeZSWQcl4YuSv0DUT6KK75WKR5SXFqXTD uIcRxPuMNxjdpGWUp1EJoNdI91T6M0jH2fIpyrt0cdmlyyANwkC6t7L8w+B5lz1F84coh48V +wz//xbwTUXXK4x7PdmqRMZ2EOPbu8xT2MErE5hfgdWVaLYB/o5IG9tA8+PO3ja3ofjq1Ssa zSK4T/ipf5VURNGcpnkUlLTIsVxjsegKNIpvk/gxYqf7Qs8RgqR03VnbMGQZ51lRJi9IORZJ MI5CenhBeiQvIumupjqGC9jYyAU2/UPrDH2tMlM0Q/KZKlCBAkUlynOWJ6HyZKjar9KV4Wzj nZVxUxvrMc2e6Xn2wtaABQNYY1lEk2VCQQFVTWCedBwVv9Lw0vWQngRJkdEYWyQv8JO4kC+u j2xnI6gLcQuKS4KWylklAmAUp1NIHkHwHHEzDfP4saCoxPddqiNVmKjxJF6IQBU+9MZZOumV 84D/IG65zd//WASLKDcM3jGy1e9o+/YLJCmDOC0aZeMwns7YJRclnDQnIpVByufs1zWUdmTk a45pAp8dVIFredP9m2VRZimSRd1dxa/vTFaPZWqO5W7tiLXsB4fVvbv0WkUE62NDCNvGMLaI FuzUVjEtFvmadDs527jbFLH/7o6D1fng3c0lXSTZVAQHF5WWPBfCeb2DIn0T/5tyiFhUIAt7 gAxqsEjjsYpAynmY29O8nmH0wkqBlaeRridv27duyrdhKyVMi578BMzV98BpBWBDWwFYUgLm mofRsQHg2ygolnnEiG0qirUkrErxZZvFtbbdzKZZ6pyPIfxucNe7PL/pn6OKMDT6M87LZZBU O+1jlj8Ws2zB4DY06RWGax8GTwtuLjHGc+QxwnXD7wupCqDc0DQHrA7YkNGXiqyQk2K77naY 3FRgkcRhVAmgQALdUf4qU2UW5sVGnlXRc9+RZx1zmZ62r8i4UfoovcqJki2KaNzkEsokTpBP w2l+lo0rkHVb4XhTLU3lIXK7j6hWbz7AhQ+jcTYH/lFfowopmhL7uhET20K6oMZhaIlAMghA 15UFXVbhl6OMWF+VSKsCPMyDSSm9dPVAZh1y74eMC9zRp1PeDMgTkFtnSLKL4tNZl94ukxfp CrUPFyAIOJ700tpHAr2pngpgIq1TN6B39dcixvPT+SKPE9Jd4bL0jVPw4X4QTCPSHekbw3e2 8dbUtEqfkbMmyH6IrZ1A9H5cZlxzsn+TbEhL0/fErnv2JI/BfIEi+zEuFAfOtnUniyAvhDOR m9tYmnE4t/mtladLA04Fb+aLRMTRis14vYQPRm4Iq0+ynGoxpevL3LbshqmOeYxvKVW6mPZh T1JrR0Ec2e80zpdTpPyCSpRNslia9y3MlcFLkuWI4Ihggq0I82yxytfkFBxgMg8j7W0QTadJ DM8JmF1mSVyW+PA7Pvy2nAc5jj/i+M+XFPGiS1e8HkSZ7HzI0o8wrre4cU1ej4TesCc+olh/ j3I1KDPU4FVIpYb1K/h02UjTj9CtH2egem7wH3ZrHDF5XcXOvaYGUbzCo3RJzcMxaz1m9qNx xfMhkJmyA5mlO3sAKJzu86NAmJJk6VSpGNlCdnSy9CNE7DrKN/bCRYaCMujSsEbeW6R0cfqY PQXywX+EiD2pUI4EkquTolhysC+KbByjaxPSR6YH0BypU7ifUlZZxhEW9nLGLE6L+H22RXNk Bfj1rE02+A1jj89dC11vl2nE3t6WDnZjh/DEbe+5F+Jbyt14GaKn1bh4WUS0ZezwmmvPisNB hJII7DOaCVUHEFCuZYEXvc0gU0rDbImz6BxttbiMxiXKdulmcQ/7JM5kBnlWZuMsoX4EHjCt OoBVY8S3VPp79pjNgjm25dsACZv0aG3scK6bqly1RATpZX+7I2JzR0SrmiK+JbspYpk7ZOqm oAw5pbLpukmVL9OfU6VbaMNv1SsQ6L72qMyltr1Aabg3rcN4at35/45MtcwfIlM92WSqZf44 mer1NL2n672qq5Zkz0oSPESJMo8LNEhk8wKWeYRWnQXFDCWZfDLVQq6wB8J10Fe4/BbzGz5I VbljEZZ1hFRtEg8k6SILxiRHxQacfKOi/imdAcs6Qq0OQbcTiNMkJG7gMcUqhjd8TaVRlkOB WZfev2sb2oKtQSCWnlBZR9hVuCPr264bUxwuPJboZ/taT7QspVv8CMnK7NfxFmlNuEpGo81j VhuNR3bl6TxYfBZB5volCzOMJvxv+lOYOTlMxNb9qWtwYs8Yburd9O/o6ikQU0VcQt4tsmwC DyJ8rETi3LKPEK8tp8+qFHT+Q5Y99phvenhZBAVYgFpmtMTDQp2V80T6jJpl72Mz7we3ow99 5QLzAI+zLIlQh0lmvGx3D4u/lrP0I7rIeODlts1RL7KCM72TflyIPjuT1IMAtQ5kpQcWVfau tL3D0BKqaTj8huVE55olG94Mrui8TAIugpiG5grDkO7abP8wJ7c+oZMm6IciWBdqmvRCzB8m WRAWvcXyIUFpKxoSvcW8XEqP4Y5+mJETxlOENpV5MebpjyL+SYmpg0nZXW82vL40LEeDQ+tH ol/UpbsKeEOV3sRpyOXSSWvipiwBE4aShOfJZI9GYrDtMPY+nXKs/3QG/xWNMctRGRBYw6MQ P0uX+u9vCBO3GA723F79hNIB6OzQ/Wu7GIctm4QxZK8Ostyl50ZmPhkrURiDrxPuL04nWQ9r LL18R+ca2wqV00HBUIjkgOvujA03wPt/66B4+2jae0ANUcXGZsJY7lewU1XT4o5Hkrr0DgTa MCj+uXysyLTXmMdOwSVfYP02WI5xCrhn2Tr1jlC1nAn0MUc8HmBqquCxYo4zRTSP06rFgsGj axQ7m9tNupRHaNrhErG43uOs4t09Xq22HQzNl69JzO/vONC1Pd+mNQd2OEtZTb/ITLi8fdyu QKNjMhpX3K6omrbMPYzmGYbeR3k8nWK4L8QsE1IKeoP0R7qZjxC8q3GAZ+ZyPzDzjIbUMOLp wqhKeq6z/DnIQ041Pp0uh4PrT2cn0m3tH2F5OdbgvYx9OBSrPxOH/hFW97twCCnl49DfmbLF 9mAcOrpvcIqxnPIoZh8ObwBSMyiDHIXwJT6yF0LC0V+m7IA4ywD1yiZGRiQbhP4RmrhmgHki JAcBO0iCNKpdDz/HrusRq9KlPEIS1y9+oJX/fbkFCyk9t7C1ffSrsDiYNlj8HEVdiRh3Bxtf BvkCA3BimB8f38YBak/xDVsfjM4w+BLMgmQeyd7OKOQPFwsVfSTC3O/M6W0Gu8b4eCTZtbKt mYcrhO1U1mEhqKXfUVrpK45UzmijrR3hk7/HwbCc0h0M3oDYTmUbBwO6FHDbgJhwKihmGgye fBD1KTxKNbCxMrfkvWtrR6hbbvBcfeURy0u8gUC3y6SMF1zQs+thr8cbgrlOOp9iomtaJWLS X86xde0w+EZwx1HS5F0wKeqYPYDE6hYg5dYFtq4fbnB8JyA9+YDU9zHB7P9czeLMay8ga893 MsqDtED3oGXkEPfwZgWjVDYi9SNEcP2a485QcmN7fhzpfkY/wv1uQ00Isaqr4ftM+TJ5/z3U WE75UDP20b0CarpuAmpVUX+NyLo9JHcePsVjvFYNryPaJFWCIxtixhHWF1JEeRmjsuQp+NdL 5PBI4IfnijjkJF4wOC6eZi3+//Fv8TkLYQplbmRzdHJlYW0KZW5kb2JqCjQ1IDAgb2JqCjM1 MjkKZW5kb2JqCjQzIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291 cmNlcyA0NiAwIFIgL0NvbnRlbnRzIDQ0IDAgUiAvTWVkaWFCb3gKWzAgMCA1OTUgODQyXSA+ PgplbmRvYmoKNDYgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3Bh Y2UgPDwgL0NzMiA5IDAgUiA+PiAvRXh0R1N0YXRlIDw8IC9HczQKMTIgMCBSIC9HczEgMTQg MCBSID4+IC9Gb250IDw8IC9UVDEgNyAwIFIgL1RUMiAxMCAwIFIgPj4gPj4KZW5kb2JqCjQ5 IDAgb2JqCjw8IC9MZW5ndGggNTAgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVh bQp4Ac1a23LbNhB911fsuA+1Z0SK4J2ZTseW5YvSXBRbjTtN8wBLkISaIlSQsuJ+fRe8mZZo 2W3RmSaZiQxCxMHu2bOLhf+AT/AHWPjXizwIXRskgxtIcJDkwwRICDaByRL6Y4jysQg8KzAj L/Dwx/ESeuMx6RAYz+ALHI7oERiWacPhvPrAqg9wBPmTaHtAVAOzfEbnsJpJqgfWEXyF8Vs4 G+eIG+BC4m2hU9vZhjWtXiRrfMVacJiVqAxezakBV48qWMa9X82pIa+qkfTxBfXY43yjfumi +ELnMDXqeTWoyV09r1rceMTesii+zAmIZ5ukc4hGKkxfm61X7q0esKsp1ZN6oP6yfdQp3lKP dMu37Hiltsabckb9Nq/wVyf3l+JYYKt/rkfAj8KKZb3T1IZJmrPKgnSiuGg6vkdC284HEUj1 I37bdxzbdD2vU7DRMi3LQt5NgJSz8X8P0BiuUxLARhojLw/hyZ/BxyEQyySBGwa9q/PTgBCn C+fsVq6pfADbIm73qDP+vWLbIwhFrXZMJQefx+QFnYKU7Zh+WGTZKn3T6202G1POJgab8kxI U8h5jycz0cMxhfNH8wjGvxd2fZ21XkQWervIviizBE70FeBCJBlax+zCwTWbrCXPHmC4XMV8 QjMukhTEDEYS4U4yehszOJd0vmRJpt2CUbSLs+HX4RQX5bMSFnym8ZqlB13AnYDaShd2/K5G dcN0iLMXZpNmfhde5XfEiX7XzEjHJbtAc7+Hgf3E7+94cifuaRfeIglOF2KTdGGMH2kyhRsT 3vG1fitilO8Ll4OPtymT9xUDE8gWDAZSrFY8meeMpCilWQobni1gOEIh1m0+fz8dz75lLEkx QOCS0SmTKfAC5RWjMdwIGU8rcqK99Rsw3E/DnVhQIODtOmFK/3yU/L+nfy9pshMFezX5VXGA GPXHgWu3UE3FQRhZFsZBXySoKagjyPg+vWOyEMPLdZoJDIQLHL7kCYpPMWUsBcWPH03tLnWd /YxT4Xhulnp9MBzVSpxHCZyiVnMkIsNZKNE8Zgf6IXr7Wdc/HYHtWIUoK/vuinIxes1WGVve MolstC39OP1/n40VUP3Z2LO3LVjkX5YBjc1GugM4+7bikqVwspI8BhJ0la3Ikyn4w5cRnTOs 4r/qFkDP346bYZIxmbDMGEg6yxpAlP4i3G1BbMyAj5NMVO7WjdS3Wrz95VfMEMb5jdFnyWSx pPLuq27N89Eb+5KYQtCFMxSQg3P05IbGMdQl1kmasjRVhVSeZ2uUmN+028fZ9mTTM5CnT6gR vhN0CmOWZqq4Kp5dqmSLGe49Y5nKv98R7RHru/vFr89kzFF3L5hc0uTBLFKZkhpMZ472dOb7 +48YT9IZX937i8JEeT0/Q+1Ne8vCWGlPPTbK54Z23wYt3G+4l/T+VHHQgEiMWUlGIy3rfYPW ZDQwy+gHGbWUog2Qt1WIIrnM1XRWyO7fOZ69VJ4EzrY/T9bZQsj0eziZTlFlMRhLeejkLZP6 XPrPj4SB37Lrc1RQNLHI07huQQqwZbMjSNdDHz6wbCPkXbVF+NTRc7YMwpaovWbztRQxhQe4 pLc0oeA6BAM1WAoY8RSbHHpLz9Da9i1S6zOPEcGA3YtM4KGGr6eoauhzkYglhSmD/polApOr SrG6gzIkLUF5IufqAJtgL0jz/t0Wr58tKY/fwGyOp/vjlPuYtnMGmBOx1L5dr4UFP18N36Af mm2PbRia7RCpZlHermy0YD7wyR3W73HMqcRGW2l5TfSPSEtiHX44+6Ve6JUdr6KH03m2uxTZ 0e7WXMsO4CeUzHQjxBSuMG/X6+raoLtdraJLB+tbTMUAtlsv98ptvqTS2HPe3ebwTPsy4fMB g2fBu2OesG8mx06t1k6cj/7abXpgQZPBQDCpCr+Kn3rs6VtuS0Rcr+iEYUKAk4vGesi9qhP7 jzOeb3nKsB28MGhE4FuRstXCGAiMwWTOpNEXKIRAdLPHt/yWIHmPMj9Z4HowMEIrtALtTm1r xJRVasO+r2p8owx08BrmORnwCWnxZ6n0aFkUeuVbE7Ve9y5J28H/hkqJlv1pjacrvFzRmtV8 4rdowYUQ8ziPS43FoU/CFrMS37LgZLlaYIOR0QzvzUZ4htzQB83Z0ydRSxJ5L9ZJRlFlP3O2 wfrlBCByLdfRbWXbaomZn6+1L+O0OLMk7iZn0fFdzqKcu3o7uXirtG1gPS2XSHfLxXd2DnP/ 05aL75KWku+CidkMisapbga57vMMmvPFMV1h5v4v2OO2neIaxW15pfe4vmYd9NpONzdY0MJv h9eLtcpt89+O1CWNbmHy2k4xl2u6YRz7Q5NFImIx5/W5ufhVg1dUES9Ugb7ntMhxn+LZSTXe 34lkPqfYhBrwNJN4Kal92+62XGDNe41m/jMvI/Dymtj4Gw56s53ntejwyLwy8T7u6ZFRS6Hm hSqatgq1Uo9jvk5LXh0vcm/nZ0a9Gw7ITkNGiyjbVkOUP/0F8vvjCgplbmRzdHJlYW0KZW5k b2JqCjUwIDAgb2JqCjE4NzQKZW5kb2JqCjQ3IDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJl bnQgNDggMCBSIC9SZXNvdXJjZXMgNTEgMCBSIC9Db250ZW50cyA0OSAwIFIgL01lZGlhQm94 ClswIDAgNTk1IDg0Ml0gPj4KZW5kb2JqCjUxIDAgb2JqCjw8IC9Qcm9jU2V0IFsgL1BERiAv VGV4dCBdIC9Db2xvclNwYWNlIDw8IC9DczIgOSAwIFIgPj4gL0ZvbnQgPDwgL1RUMSA3IDAg UgovVFQyIDEwIDAgUiA+PiA+PgplbmRvYmoKNTMgMCBvYmoKPDwgL0xlbmd0aCA1NCAwIFIg L0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBdZHNasMwEITveoo5yhDZWqVq7RwD ueRUg6CH0kNJkyYE588hz19ha1fBUHRZZkc7n1ZXtLjCxuMbj/rF4bbFB05RpEEmUA1H2HRY BjSD1sBbVzY+yhahQxUCKULY4RP6/buAsaWD/uViywUKDB1iwXLBnfMoKL1LVm48X/lCWGMV BvQnypr8BDO+SyW++JyR74cjbwLKWfeUaQ7sEfKxlbHM45U9CRn6wkqfB4iW/SYNVXqfL4hP oDbHSTi0yezTUKX7OGz+Rt6VBC17lbVV09U7DudOElS+LBYZN/vvV2Qbi+SQab5A/q/2D41V dqgKZW5kc3RyZWFtCmVuZG9iago1NCAwIG9iagoyNDEKZW5kb2JqCjUyIDAgb2JqCjw8IC9U eXBlIC9QYWdlIC9QYXJlbnQgNDggMCBSIC9SZXNvdXJjZXMgNTUgMCBSIC9Db250ZW50cyA1 MyAwIFIgL01lZGlhQm94ClswIDAgNTk1IDg0Ml0gPj4KZW5kb2JqCjU1IDAgb2JqCjw8IC9Q cm9jU2V0IFsgL1BERiAvVGV4dCBdIC9Gb250IDw8IC9UVDEgNyAwIFIgPj4gPj4KZW5kb2Jq CjMgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9QYXJlbnQgNTYgMCBSIC9Db3VudCA4IC9LaWRz IFsgMiAwIFIgMTkgMCBSIDIzIDAgUiAyNyAwIFIKMzEgMCBSIDM1IDAgUiAzOSAwIFIgNDMg MCBSIF0gPj4KZW5kb2JqCjQ4IDAgb2JqCjw8IC9UeXBlIC9QYWdlcyAvUGFyZW50IDU2IDAg UiAvQ291bnQgMiAvS2lkcyBbIDQ3IDAgUiA1MiAwIFIgXSA+PgplbmRvYmoKNTYgMCBvYmoK PDwgL1R5cGUgL1BhZ2VzIC9NZWRpYUJveCBbMCAwIDU5NSA4NDJdIC9Db3VudCAxMCAvS2lk cyBbIDMgMCBSIDQ4IDAgUiBdID4+CmVuZG9iago1NyAwIG9iago8PCAvVHlwZSAvQ2F0YWxv ZyAvUGFnZXMgNTYgMCBSIC9WZXJzaW9uIC8xLjQgPj4KZW5kb2JqCjEwIDAgb2JqCjw8IC9U eXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL0JGV1FPSitDb3VyaWVy IC9Gb250RGVzY3JpcHRvcgo1OCAwIFIgL0VuY29kaW5nIC9NYWNSb21hbkVuY29kaW5nIC9G aXJzdENoYXIgMzIgL0xhc3RDaGFyIDIxMyAvV2lkdGhzIFsgNjAwCjYwMCA2MDAgNjAwIDAg MCA2MDAgNjAwIDYwMCA2MDAgMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMAo2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwCjYwMCAwIDYw MCAwIDYwMCAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAg NjAwIDYwMCA2MDAKNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYwMCA2MDAgNjAwIDYw MCA2MDAgMCA2MDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAKMCA2MDAgNjAwIDAgNjAwIF0gPj4KZW5kb2JqCjU4IDAgb2Jq Cjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvRm9udE5hbWUgL0JGV1FPSitDb3VyaWVyIC9G bGFncyAzMiAvRm9udEJCb3ggWy02NTUgLTQwOSAxMDYzIDEwOTBdCi9JdGFsaWNBbmdsZSAw IC9Bc2NlbnQgNzU0IC9EZXNjZW50IC0yNDYgL0NhcEhlaWdodCA1ODcgL1N0ZW1WIDc2IC9Y SGVpZ2h0CjQ1NyAvU3RlbUggNzAgL01heFdpZHRoIDgyMyAvRm9udEZpbGUyIDU5IDAgUiA+ PgplbmRvYmoKNTkgMCBvYmoKPDwgL0xlbmd0aCA2MCAwIFIgL0xlbmd0aDEgMzUwNDAgL0Zp bHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB1Z15nBx1mf/rW9XTc989R09PT9/XdM/0 3EcmGXJM7nAIMSThSiAk4b5DIiIgVxIIqCAEBESMIfBDDIENyQQVlCCsi8CuAlGQVQHFRZaf IgImnd/7qarunnR019ey//zg9UlXVfd8u+q5n+f7fL998YWXnK5ValdqhnbM0uXnr9TM/67a r2nON087Z/n51rnjTU1T15y25mK/da7e57Vt5fmrzrHO9Rrev2jV2evsvy9u1bR1764+ffkK 632N8bSB1VywzlUfr+HV51y81jo3ruHvl5193mn2+87VXN9xzvK19vdrr3HuP3f5Oadbn7/K PD//vIsuts9LeP3p+Reebn9eLeb8Nk3x72L1Za1U+5xWZJ5pWpmm6ZoR53mVeYXPrPUZd5xS PfnPyi3DaNo3r7Jef3bWue998sP94yVXlTzOZac9ArfKSUmGDzlv++SHn/yg5KrcO+bf88/i XZqW1Ma5bmh6Uo1rDuvg+xzM1yZpaS2oNfK5kuT3ubNTtHnaFC2Vu+LUph3yGe37DHQMH5r4 Z/phf2Zocw79s3GtmO8rTnIz/pmXn9E8xje2a5u0S7W7tdv592HOA5kLNM24S2tx3KcFNI2P pubv0pzHLH5EqZuW7FIHr92ljXl38/TGKSd37NJUyu+fecbYdrWMEz3FhfYAR0bKP2u7EZl1 7OLQEv9G/8a5Kzb6Z/lXL1+x3RExX3nj9I1L0v7t2nGLz+DfhYsD26cu8eQOT1+yZBLjOGQc /oSPb1zCCGfaI/BqXkof4ENFqfn+7Ub0mMWfWbz9yjHP9qljSzyBgH/m9iePWbz9yTFPYMkS PuXM3Sl3LE9v3XMx9+xs5/0Sa5TjFm+f6tmuLdm4UcY8bnEosP3KjRs9G3kO+3yX9mTBBaUV XphqX4ASjAElZu5SVx7DYLyEAh65EAqEAtznkjG+uzQ1/7jFM7nTwJIOzfG8thLwqh4Cizl2 gsccz+slnN8F7uT8VF7P4ZVjdR+vvwXPc+zgVc53gh2AMeS69oKN56zPm387xrXp4BPwuuP5 gxleF4KjAOOb753Iq3xOzr8H5DvngGFQAQJgHpD7HAE3A/mbKaAK6GARWAC4J/P+eYaD73F+ PZCxlwH5e3nuJ8C1YAXYCt4Bq8G4fX9yvBTIfct9yv3Ic8rfy30l+Ny7vB4L5B5/BN24pv0C fMT370TKLV3XtArNqdZw7td2cg1DgH7If0XId7Emal+KhSjnc5ValVat1Wi1Wp1Wr7m0BrSz SWvW3FoLn/JorZpXa9N8jBRAl0NaWItoUS2mxbUEOpZEmzv4XCcq26V1az1ar9an9WsD2iBX h8AwmKSNaJPR/FHtCG0qOj9dm6GNaTO1WdpsVHkuCj9fW6AdqR2lHY36f0Y7VjuOv1oI/n/5 77PaIm71ePN2J/G8Tyqn2qGv1m/SPzRONh42/t2hO8513FY0p+he59LinuJ/LVlfuqz0e2Xj 5TdWNFZcV/F0pV7586qXq/+5ZkvtfXXr669zLWz4fOP5ja81rW/+ktvlfq9lp+dLrT3emrb1 vsl+zf/LwM9DFeGy8M8jbZEVkbXRtbHPxc9PLExk2q9J3phakfrXjqWdSzsfTD/Z9WD3lT03 9t7X19b/pYGegQ8GXxz690n6pPdGdo78ZPKiyd+b/CH3rGsrM7c5VhZtQU6KtdmYjDTGB5TU YCdfBHJes5u3iz7gjCOHeWTwfulr2h5OdcZxJPfwqiNjjmRXd31toDYSqA2sdGj7LzI8+9/K 3FZc9dEfL3QmhEy6eujgO0bA8RbS59G2jyN2NZqRnFaEXNYgezWafsE0D+JTg4DUaEvAGWAd 2ADuAA+A3eA5sA+8Az4GlSdh3iu4ZW0m/smd9uxGmotHl+zS6l9jyEHkfDY4HqwCl4Lrwe3g fvA4+BF4BfwW/AVUnsSNOTloBPoFXd3KqFKhYDRm9PcN9PY0NijrxeXkov6LkOoMBTv14OjA 4GjmpVXHLVy1auFxqxwnH7g0kEwG9A1lk2bMmLQ/MGvx4lmzlyyFFouNc4xLipaihSGoMW5q qCH+DALXwQBhRMuLfK39lSOqp9Fr3kPgsCtGhbvR4WtqXN7Y5HM0ujPXu5sMX2PTsqbGNk6N c9xRdUGFu7nZXZG5Oeo+9ExkwXlwu+O5okth9nHQZ5cWgpJpUAzmp/dAAh2bIbxOmtx2cJ+N 3J8Iis5rE69JXtvs1wFe5foUXuVzR/Baxess+/VYea7ewZAyKQo9B+shotA1MMjTmQf1o0qo 7HIWG70Tj81rSVVsvRkKWFyxxlCvvLL0lcy+EnddIOHQb/2VLxBsU2VLMx/6AiGv6r2PN/xx Xf/KK1uKPbW+pGHc+lJbMNj2ydKP2oIBX+aN+4pb6vwJw/jyK7pr//4fNzYEWx0VTnWXt7XV t7+ttTWg9sq1kjJHZoXa29AYcjsrnJkVfk+rf7+vtdWbGcn9ialjjx18x6E5lmEB52l37MH8 OU1FmdaEtRRbOBMbMlNbCdaA68BtYCvYCZ4BL4NykcS3OPgz0E8aF1OvzaytGxaR342Rdnwg wY1I/ohI/ogl+eYFQy6g4qNL9qB1CrsuvBtBnfs0A8WeAyciOS50KiF9T2NTlvZwJRR0Nrga m+oHBgdEBIUhVaq4ySJ/UgVj0bRIJZ/p7Rkwasa+fPT1jyw7pyf1tQuix40UlZX5Qz2euss6 e6YHh/5S72rtG20MtEQqoi1T3PXNrU0Lm/1FxiW/Gpm0am7qMyePTHr8hmX3HDv7vN4zv9Li U8rXGpo0b7TTP29+5qH0ggtS/mhbSc/qwUVhXyTZUWzcpdKJZZOOOjuKF9RLjHP0vaY+lUMN MWda+m9pj75UdKW56ZSmZtEVWzma3e5mUzngm1J3Zc4zuh178YPn7DF51gDZTK454ZoTrjnh mhOuOeGaE6454ZoTrjnhmhOuObNcc8I1J1zLcsgjDPFolWKbTA5Vy4VqrXR0CXcLcZ26kLsN gophiUX1/r66QZMfRveM2rHhrm738fU1vgU9Z515/JJJp0Zr6h2bG25IfD3z0U1X//lz0x9t aHRPm3OHOmb3A6r3S6csc8vz3DnxeRq4HzHXCNXvOfjEvD0ebpiDuWAJOAOsAxvAHeABsBs8 B/aB8tzz2Leffx77Aa3nQbMH6vr7orGcZDXWNbh0JIhnU3eO1c2Y1N3TsshVE5jP8yxZMnpS tMaVuce1IXGvKt105V8+P/3RRpd72uzNmYd3P5D5ly+deiIhitJOJbo603E9McoRewhrHNBP xLoUEyMmqZrX5heheCtSUIH9khiJfIGPFPNWDR9RvDaJFQqYIh0K1Jrk7q/Nmp9ay7rr29VZ wY5UKPPVeLCtI3N7qKPLr85oDwTj+lME4fHMhnCKK5fG/W2dak04lQoLvc/JfM/oUAuIqaq5 iyruohYYIo+jKqtFlvFLK0gzWQ2q90tafL+ornM4Mn8obq4yiktm1dToqilYX1FaVFN84Onq Ot1oKa6rKC8tEhnV7iTq7dXTfEMl3rgYJRdvjA8ORqeIa+LBvMhTaK+rqcllTGlqaatX57gb z6xvbKw/s85ryvl9B/9oJNUiosKHxuEq2ZLljTUzErS9sYZUaEiFhlSQ+4IN4A7wANgNngP7 wDvgY2B6Y1O4S0W4Sy17ZFie2MATG3hiA09j4IkNPLGBJzbwxAae2MATG3hiA09s4ImNrCc2 cEOknHjiiMUbk2PqvnOOX3L2OYsXn73lqBWnHnPMqadCm98evNnhKNqM4xZbUGnTvihn5+CC 7VvUtY0xT2u7s0g/3x31tLUXFXl6wglvSUNF0bS+SLy1xFWKx3v+4BtEP1WM1qTKkC0GLAXN CFE1wlSNFTY05wemhTCwEAYWwsBCGFgIAwthYCEMLISBhTCwEAYWwshaCAMLwXOJkf89tPoE cCL6WArlS6F8KZQvhfKlUL4UypdC+VIoXwrlS6F8KUOJ9O8mlHdi1N2vZa1NhdC/wjL/dRBG RASV4JOk/HK/gxzMBseDVeBScD24HdwPHgc/Aq8A0w+9zcGHQD9JjCu2qq63Bw3XjaBeWyPH tTW6vvKiK6+86OIrr7z4iddff+KJX/7ScUXm/Y8+zvynqv34I1Xz12XqNNWv+tRpmbsyz/P/ 10RnyFaMT4pKcGdzxgmKWpFFFBgKO6GwE2rXctd+y9eVcSpcNWWsWZ6xWZ5xN3+neH4ff+EX 5c4xPGIxvDYbNJgxxoiqVZdWVhb5YkG/SpQ3lNc33rukKx4/8GA83rVkq6Nb10Pe5nDpMYYR avvrM954mP/iXuMlyKi0+7jf3yATvdqre7gvJ0GsbVPL4GFZlodl8LAMHpbBwzJ4WAYPy+Bh GTwsg4dl8LAMHpKawUM/z5vi7lM8nBynOZZATI77c1zV5Ik1i6tebqXS5KrE6BHTqctRgiOT vwn4m4C/CfibgL8J+JuAvwn4m4C/CfibgL+JLH8T8Ddh8te0hUeogUENE04cUMz/2G2JtWwF Us5qFcgqU4OYdVXW3/uk1zuoln5u+REXhZyVkc5wW1X91O+etvWNzEPHd16mnnPEAoEo/rqt Odkx7dHW1j4166tnXduXKqmfkRoNB+pH575819OZPZ/pXJPsSEWNauNIX4jH5UF3HnzD+Aia I3njpJ/urL2SzNWdzR7cUNwNxd1Q3A3F3VDcDcXdUNwNxd1Q3A3F3dgrN/bKjYEZZ3i3liam Gicpto4Iw9OmTtbBz7osP+sYvY7R6xi9jtHrGL2O0esYvY7R6xi9jtHrIKdlFeCgKbmimZI9 9eb46BQ+kp1LcJbi8UImH518ujrLvWq4Vw33quFeNdyrhnvVcK8a7lXDvWq4Vw33qrPcq4Z7 1ZZ2ZmMIK6YjOhNHzP/9fYPCQIunFj8tvTD0S676aO/mPyR9tT878dKvrlrqSS081t9w1LI1 Jyx8pLE18u/r73rhNH27/4HPfeeNS2a1xVauP3vJZbVFRtG0kTLDUbF63ilrV4c9U9Z9d+MZ 6yGoru1AR94rquBoSLttD8UCK/LYpXXzjNgiKFIORRRSrvFaxms3r37zfDc0EZrFOYujAyne 6RevLua3BYh3PyzI5Rsx02LlDL6j1LQHMnaAUeS7RKMkTujmtUdsRG2psq1BP/KO64Q4pn9o avQpSIjNMNM9F6JepZKqwbYh+njmWlXdFQzFLs50uFu9RYbaWlVX7ax2OFZW1fY2Nle7WnWj pNjjXRiailVRz+tbDyzN9PoS4cA2f9vMeKqkSP8Xd5WuVI3uaTxQEmprLK0uSYRbtvmiYcII BOIh/I7ueI+qy/skWDxuA8gmWm14HaGhKaMNyGhDVkYbkNEGZLQBGW1ARhuQ0QZktAEZbUBG G5DRBmS0wbQ5DdAJvkDpNuhi+TMsLsepnKTm/fgepNTAPkgyKIXmZo5Ee5o1w8xIxAvhaSzb U4f01iG9dUhvHdJbh/TWIb11SG8d0luH9NYhvaIsPMbbHHwITN9iWxVHTkAtAcYMyRUJz7Kh m7p2+vm933knk3lu22/aW8t/dsJ199+zdum369rciV71SVdXT2dmxKhqbvrTY9//6IRpLYkj v3HF57+1NDVJ/THgjcUiCe7e8vHGftPHh9XQLi0CpcXrRKBD84sidEJt28dr+HjNrP/IrIBU 3a4Dt4GtYCd4BrwM7NxNw8fzJZaP/x/H3JL5NWuaSWexEnUm14RTHu7Qw93WcRzNca1B7EuD ZV888ArvCdckDSRmRkOE8/DQ4tU/HpfZvDLglcQtclelWjV3hTaZWaBlWWJZvxCS0EAzuSUe RFc3f3HlssuuWLH8isaBa4665/WX79/7B3Wy8i0fXXNU+p696trLvvaVNZ/b/JXNs2a99/DO 36thVaQWqrtbY1N1VdqWOQgleYQXDr5nvItuBLWj94gHJNiTZ6qHAo1QozGdjYHyKbBtLoqE LEVZshjcvvyhB2JQjvrAzIeTuuXmVCAbQhwhNsGOqYv1S0qq6mtnu5oMQ23IOIxwKBhQqoww Qf+q11NW7mquqqkqqS5zJNMdwXBZmWNpa5vbE6yIBeTeDe79DSNjxZNaWp29S+sS3oEu7r6D u+9A2sjyhTMDHMwCi8BKsAZcB24DW8FO8Ax4GdjSVoG0YXSJJyQb0j6lF7OkyslIog91kCnG nY0jiR1azJTFDu46K4ExjsXWBtLjFI6zn5Cr3Tm5bBcGtFsMaIOVkl1PlMv2/yW5bLblUu7k b0lo/QRprc9mqFLgmOA51UXXnnvetevPPmt92dUrV1199apVXwwsP/WX337w18tOP/3s3/zT P/36bLX4zGuuPHP1VVeo9077whUrll1+eWZd1y2nfu1Hz37prFu7El8/61sv/uv9K7+OjXnO jl+atbBirkZsjNvijhv7TQRjxf3/eAQjMYbIiRW/VJjcEItlcWs3CbItQz5kyIcM+ZAhHzLk Q4Z8yJAPGfIhQz5kyIcM+bIy5EOGfKYMiUeoYMy8XbFzfjNuwcMSqwv/ghwx6WB6A0MLmvdS DSddWQvjwhu48AYuvIELb+DCG7jwBi68gQtv4MIbuPAGrqw3cGFhXNzDhEjeTDA0MzDFTw/U 1ZuBqV18mjfwRczJz7Y+/X7mG5mfnzTl0qM779lbdPXK5Wu/cNryK/UTZ4794ds7/yOzN7M/ 80BmVWt0qqGXeqkNvPZ5MTh33IJu6srMiY0rJNfTnv3fzYrRRehYAT3FZtdJLGPGL3k7PQ4F S83Mp4FPVFsZ8z8eA/4W4/4XYNeuq8mYiQWldj0hY7YrGwXZczaL1p+30+hMLJtP69QznjJi 0AS51c4aRy7+9yJvaGDVR8YRo6D56EFT/U1L/DerJVIunvA86p3SZu8LlbVUTjIl9VUlpcb0 6mplJHmic89dsvjsDwJ1FaUGJZTf1lQp1eysK3eUlRs7j1px2tFHn3aq6UvGtE2ORY6Tqfc1 cD9NqGUx5osMS2sy3VqpBIImwWIqG0BPqCHE9NdT0ZCvKujb/5bDeeLSEofh8USrfKFoSl+X ebgh0dIWLqtWFymjvacn7oCeleVBryfhEj82ne9emPtuqbg3md/dpBXb3521TE2qsYn6Kz5U 5fIw44IDkc5oqK060mp4HCVLF5c5uIe+5rZQtFNfp47iu73B8srMLboj3tNNUTyzSW8Kt7Uk GiTm+YT6z1vMx5STUfmzsr4H+255U2ZOBggNZ4FFYCVYA64Dt4GtYCd4BrwM3gYfAlP6ZO5E Ko36BRIfEDmZ9qDCsnb1WDsmVSxrV0+0Wk+0Wk+0Wk+0Wk+0Wk+0Wk+0Wk+0Wk+0Wk+0SjEH a9duZg3iT/J51MToNAxJG02HLpGokc2j/sfRzS4tzHd5Xzu06oT8ifk5JC02q25WgdySlX51 3unHLVy56rhjV54b6fD07/3imbPWVBpGyRGB2Ktfu/+lB59tJ3vYMH3hcTNmLPys+u7AaFOV +4TPnXhRpNHZtLQrfurggh/cedkD844JJKJBsU3a6wdvM54vWkwiNaqmSdHPYT7rHmpFRWRL YoWxxXzUrlYXw7tieFcM74rhXTG8K4Z3xfCuGN4Vw7tieFectfrFWP1i0+qLpep50Yw/hhll mFGGGWWYUYYZZZhRhhllmFGGGWWYUYazowwzyrA5itRvpub8vl23KM/VvtMSCKQ1LuyhAKLD YnkE/CAPIUeTOZJUY5eWYKDQi/bMFIwd0HRJfN7h4GM5EVEa4mAOWAxWg7VgPdgMtoFd4Fnw KigXp2Kyzypb2SmeGapSxWpsqM1pfDYC5Gp9bSeFa5kPkbmOwIkLv7Dpm9/oWFtb37L+9H2/ f/Xpu7/SWN3jrw01J+ZFT7v6sTudTc6SmuoTz5o7vbbH2NJ8w62Zn2R+n/lh5qmot7F7hrpS rVInqS+8tT+zurWtMtDb0FJf87V1X/22npmmFih19knzjxXV0Q9m4OgrjvugRpdilqcbIyEJ sOTK2WpRRHzFgBaBVxF4FYFXEXgVgVcReBWBVxF4FYFXEXgVQVsjaGskq60RtDViaittMloE bZ0m87It5v92JbgFTW1BU1vQ1BY0tQVNbUFTW9DUFjS1BU1tQVNb4EsLfGlhcO6Uu6x/TRqG WrR6xh3nMVL2kWF/1zgTU9l3A/Y15C8nOWUiKGUTZk0a5UKjhJC2D43LhbgVU0q532eKTZlp A6Qm2MgRmQ9HXsRIJiolSg2CNOgypwKohZthv8T5TXaFOGTGGkx9xQK5KUe7XqA2qzteufkr U7qTy5R3MFajrq8diEf7Mu8vSKannbQ841i0fHpXcm7m46nt7ZPrmSWvC8QSPm9sf7qNV18i 6nvvPV9UjmJtsBljRf+D4yL4XEIhs0eF9ogmQxdRhagYVo7gyu85+ATY9rMSrlTClUq4UglX KuFKJVyphCuVcKUSrlTClUqEXrq1KrWoaYsdli12MBZz+ZYtdjCWg7EcjOVgLAdjORjLwVgO xnIwloOxHIxlRTOlL46jorkxobJVtenL8S4onAlO4F2dXKizWCVab83MSGKBP4RB4v9rzCMx Qm7Y0wJqOJYko9X8wmKtjIfAKFtVgaTqzx7UZxlWa1cOrDKBFdObFcov//KJO2/Z/buXbtrw +Ys/ei4zNRRKHRcIHJkKB9W//fSXYzPOPmPpsd1rz910yrnnnXzZ0pOXnPLX98y677W+RCjy rbuPXhON3Xj2Cbd1tbrFfx918DeOYx1PoZkrZaLcyRS5bX0b0cVGdLERXWxEFxvRxUZ0sRFd bEQXG9HFRnSxMWs3G7GbTLXn5tbszDU/t9YplOucQMq81Fu1xYrXkI9SHK5bEkDpphjiYA5Y DFaDtWA92Ay2gV3gWfAq+B34CEg9lChUs/KJTthRLzG8mNt61Nr23EMczAGLwWqwFqwHm8E2 sAs8C14FIi1xxiFutKoNbnIBN7mAm1zATS7gJhdwkwu4yQXc5AJucgE3uYDbos3bHHwIJlaG GvslIqOgKTbZmojI1aVljjoUZMpAw2ob95WFg5E2hz8x3VXsqP/S8kde3rdj0tpJnpNdvmR6 6sIHT/5L5ntq1l+mb3Bc5WkMD536QHk6cHJr9fxTMgd+/vPMgUCgakairW0wPtiHua5RlWqF H1FFck89uN9xCfpaoaXUPNFWJ3It2hrm6NPPsYqGiZWTOqlUdkT8JRrpzOlWmwhE2wSB8MsF /4QLlXKhcoKhzCdvtuXMZ+NMqvB9lhIafJefM6mgmpwvhfP2zNQQB3PAYrAarAXrwWawDewC z4JXgXBeMh5pzpHqdwPHUsW0ajRc55q0j0jQbdXZUOo2jG82uKq1jTKzNZZCjxg9GrO19hzy pf4j2j586+0D6e6GezoikeTkuprJHZFY8p7XP1bxz35m/isPuE7ZZBiv/eG9fbohihxrM671 xyOhzPcz/3ntm4uOmi3xEno8HVs7DC+nqKVSqXZghIWTMSIrOiw4gg9mpmv5XdODcO+d3LtE OT28SqvLsP16RI5HNcIBWpRyrsq2f/kL+fmc3RhDMYE1NuUtvrstrXajAKiApdVuOOCGA244 4IYDbjjghgNuOOCGA2444IYDbrTajVa7TV9cyh1m/Z8Y16SVYSbRxiTamEQbk2hjEm1Moo1J tDGJNibRxiTamGRONkmGmbSiBrF1jUC/QGTO+EBiOZ1/wxxbU+1Wld2qWQ/gY3ttFuZ4KfPv 5jS1lN7pHLPmKv7OlfF0OJI8curU+R2RaIcxKRgSP3rgXeX0hkOe1nDYk/lEd4lfDQeyBjsS SsTe7Yunjrw5853+gfaOeePz27tmhjIz7zsylRjeH46avD8R3p8I74dU0R4sJlOdJsc74X3c PPLCe2t2ZgjO1Jga6XjNmlEQiR6ClhFe47z28+rldVJOAuwZyjzDi0Ukii0PGMPQ9vAlQrCs 8lUxhJRdpFOhmavWtKZMN/stUfDDT39WFPyIgh9R8CMKfkTBjyj4EQU/ouBHFPyIgh9R8CMK fkQB84BS1jJamPHltmN8h0TUu2GmmXfbcxy2K9UnulKrUeJvM0s/OdYeDQcz9cFwLB044ogF yXDQuCQYCgXb2w78SpW0hv1eTzDcmvloUyAcikRCEb9hetVELJPBDQuXWub2RNszPdGeud7M TPRy7OCvHLc4fqhNUlv30GbqpHlGakxxeCMzxOJVFPyw6mAWB4RsNdgT4Ya00jGPJ3XUfvxx P/64H3/cjz/uxx/344/78cf9+ON+/HE//rg/64/78cf9+BxrpMk5fh5mdcPCz/AEFc/PSUt/ iiLyFAZLX4rifsSGo3niqZMwUhTI9NRJGJmEkUkYmYSRSRiZhJFJGJmEkUkYmYSRSRiZhJGi hjJrsxsBsq10D1a6x4rmhjiYAxaD1WAtWA82g21gF3gWvArESougDck40hUwhEUYwiIMYRGG sAhDWIQhLMIQFmEIizCERRjCIgxl/fMQ/nnI9M+R/kMCr6SqlZIq/thv+2Oru8zS8UPdt7Hl ozZvS0Rtb3EH2isr6oZ/fn7mg8xONeOTsQ3zykKtaV+wva+ppCiyccmjL7/79PC6h97zB6Kt gUCkNfMfzZ6GsmCXWqTq+X+lz9fSNHT6+u7Y1PqyoxdlDrz2m8wHRNnSO6TRO3SfNkv1WR5b yv97aIdzmrpu+VzRcIl2ZVZMPJTouINXsZ1iNyV36INeYfNzXebnxPKLxE3lVTg8xmsfr3Ny cnOYHWgRuSFLyrmGpFyArbkLHXKhY8KFvOmw3Xe++GFfmCx/MtkyLiEeeGaBcTncsPi5U3mi rDnolTsHEnKLNRsAM8AYFpyAW3oA7QmSvFPWrcuKDmDbxueu2H9h5Vb8RUBdOmOkq332Lyb6 65eOSQ7M71BvjA13dyz+UUc40j7QXDM51b7ghc+k+uZ2ZwKb/JGEL+++fYm4P7NFnRgkgeJq YP9l2VRK3Wva9O/B5yr4HNQukdq01SOG0JsV1yahUdMEstotw3nC5+fm7T8pkT8psQIpmXyz wqSspW7iipWzWMSEUCZBWBlhZ4tZsqhAlh61xm1HJpNHHvhGOhxNHfnrX8/vjEY79FNwch3z f73JG5cHo90EAxkJhcMJ3/7LRH7PId+4hedKa3BE5o005opqTY/UVSPpkUyM7yZflKgxyFmQ z0R5J8FxgmMx/Pm5GFue8g9uy1P+Qr46TVyXe3CxY2Jna4HMI6akICOWI4XlSGE5UliOFJYj heVIYTlSWI4UliOF5UhhOVJZy5HCcvDXUpDJpm55EllF105lF9foi8RuSHukBIh6JvPH+alQ rEPvSIdDqXlX/eDVkx9cGGr0hpuDJQ6H09n4xRM3ft5RlyXggave+nGyoz7S/R+zQvV1Za3h ssCg5+gTvvYdoesc5EXoOkfNteyCxADjZFs4aGy3ROITrYL0EmStgtBcrIKf1DQgn8pWT2Io d8yy7sMczAVLwBlgHdgA7gAPgN3gObAPvAM+BpKHBXntNKsmvUQlckTMyXfN+/tWxQ7o8xw8 zGZMEVmeYsnyfxd1WM1U8mDFWrP59SJUUosTc2EFeON0QWXfFaMhBmMwbyyyNZRD4ghsCP1X EyouYlUUhfb6rH5I96u0R8aK1Z1iMEYyD1IvTfunTl3QHgqqRSPtYjG+UdHYnaKZNBYMpydX ZS4//r7/UzfK+8v83urSlbEjvjD7XExH3J8PNvxxTMcZ6nbGD0RCsUBmY90Tme+3xUKRKnfV d+decknZauRhGHk4D3mIa7dYeiN6RqkCrUrwiC4e0cUVauV2rNue40irkLd1gnU5LGAol0+U WwwwDVI+TbOSbUkqZO5ekgGJ0KKgnq+N8RqXYpU5AeJVEo39VyYmYLzR1h4OR4P7N6TD4eSC yy+fJ9mR+iE2p2PBNt2lbpmf4kLm8VDscGsjekEF0vEUdJim/XWXNh37Ie0307mVQW5lkGPx EP1ynRsuNz1hJVcqzUmMfq3SlF0vU0flpvAM8ql2PjWuRTAW7eY10aUZOeo5hDaUqXI+0JbW /AWXfMI1gXq2l6QaKLM2LlMBxWHLDQkFXRxVmkfZCpLX/pTcRvbzQmOhr7g+eSi5rawkK5Yg 2I27yayEZsValVuNhrFyrJI4x9wb9qoG+cMmffUrVd2dW/yBxGBNa9M0qk2Z305q75mdbHim OpVqT1U9V2cJ+e8IhKc1emsG24P+LZ3dlepd/cKwPxSIevdf6I0TMsdJYU888FQ7Q+lH7N8i wm2y7iZvNBDyywRI4OD7jg3wbER737JlUjkUJc3bMstjFJHD9EIcWUMg2ZvEO7089pQcNw5z jIcJ92HmJiXsSU1g4ETXaUq7Xc7NV28H5U8GLY6WcD8UQ7kTHSZkfYyog/QViSEa1FoPM0SS f/eKyclyyergyAUovV3m8oUmlasn5OITy8cotah33kBncu4nKEpipN69cKR3OO46uTPiVh/F Zg90t8/4z65wKDlc4enubvIceNcOSMRDU08I6A3J/XcajSEzSon799d6G8s7ja/yKLo27+Cv HFeTw0j/8GctDaq2qq/VVF+lXW+a9PtW4yGq8RDVeIhqPEQ1HqIaD1GNh6jGQ1TjIarxENLs JzQSbklS6OTZndgi6f5loAEOZoFFYCVYA64Dt4GtYCd4BrwM7I6RBjIdaR+z/Fi+f/iwYCDf TCMJl50sVODyK3D5Fbj8Clx+BS6/ApdfgcuvwOVX4PIrcPl2g8rbHHwI5Oty7WJSXKzD69mN lkMczAGLwWqwFqwHm8E2sAs8C14F5lxOjZat92nKbEg252nqHFdnXvzDf2ReUJ3v/UF1HfjN tqee2vbA95/Sj828l/mGWoYHcqmTMvceqFDq179W6uCbv7b6i3S+2aoJlOABnpd8s544QLrf nGSeks1JrK+9SBb3ey58AmwuFsHFIrhYBBeL4GIRXCyCi0VwsQguFsHFIrhYxI3LKBKIig+p QBfFxEs0EeI17098oh2+CQqVr+HJ6jslwR435DMVR+ydtF1I4c4qs0l5TcITKa+5xXdIS6PM fdUfaq0mZvmWd/7enrvvuvsu/Cu+tylIxn7VrMWk9OqFP+3/5M/fcdRlui6+5KKL918WCIt/ DQWtZP6Jxx8fz7wgcj8CDXdgh0q0qcopmbBTjC1UjOeoKBWpT09FESO3acMqTa1wMWob0ViS 74ubtkK4NT1n1QJC0cAEitpFurxFGpBPDIhFskh8hEniQI7E+QqdkNcirUVmmazwmN99hKab 3+3mu9NcNWeZssQ3DvUVE2Mja/UPMxZN+ViIRNnoJFxS179w46aNG342NqmrfVJmezAc7wxM mkQUHFJb77i9b8aRm77Qkqh/LjBECHRBd9ppPDly5BHXOjyZs09fcfrK/RfmQqGbWmPBoDfU cetnL/qWvzremvkXXzQUmeN0qNCSPmTq5oP/5uhlDdQMHd8+BqRqO8aTZDOMQehtWptBrM0g 1mYQazOItRnE2gxibQaxNoNYm0GszSDWZjBrbQaxNoOWtYEqstJ0kHElL7Wt4qfsZh3lziRy btVGTfrPFL4bfM00YDqgwzQqIuxmMlSCjmkw+dO3sEokMk2rM29gGo9XbpVay7GV5djKcmxl ObayHFtZjq0sx1aWYyvLsZXl2MpySq3llFrLs6XWckqt5eQSlp73Zee/+7CZnFjz333YzD4s Vx82sw+b2YfN7MNm9mEz+6BBHzazD5vZByeEQD6tz7y/CPfXYRWkOtCjjmxBqoPxOhivg/E6 GK+D8ToYr4PxOhivg/E6GK+DglQHBSkKFaRx1nrCtLWWsCmbrPWZsfzE9YU+q6fGLgHJrLrZ cG26YzW9KBxrTxiVVPRbKspDt59x1TdOO+XWF7534LuDnztSbw2mgo6qeLjfW1UV+PzR626/ 4OJ7H97+yUtzbgp1hLoHf1fXFV+UbJy14HOnHL2syuW998t3vOj1eRtbul8qC8XmtTf0DKxd vmBxjavp/pu2/Vh6K5QmNeALsFXd2j4qYwhKO/LYzmsa4qSxze3m6zRDW0agpE7iANHV1AUc nJK98u/Zg3uzB1eaB1h0RrA0R0aUSRux+TJmmz22pFIysy+2P9/bYicG+eA3KpIatUIlma5p Ne181BxSLL7UHzpAJxCjI5MTXbx2Y/nrZVYs2t810C8ramWWmxbIfiv+MQK1duiUDV/12sD7 uq8jFNLL9HDUOD0aVuV6NBpv08syv7rTrPQeeMGs9N6Z+ZVRNT8RCftq1LwI5bjMzjq/CocS 85VDvEO21Ct0nkJP+ybo3KP0PeTKzJKZHiHJkTVnL5YVXuQquknOW8xz6TulCsoD5WeX//v6 xWHzz4dVa+02FNP459NhsUcSfQq3mrKhThPq24T6NqG+TahvE+rbhPo2ob5NqG8T6tuE+jZZ tu5tDj4EEupIYmylH5ZsJYUhhbWyXG0jWy46NErt38nsFlWi56UolmxoDl2+4Oar+4/qb5/+ elc4kppUte/ne//DwSLnSEgKZAdeO+/09iljDz2pD/oSZjnJf+DRP/3pTz+BD1UHP3B8Dz7E 1VQrvxX7nuAeHTyzg2PTYNEpg3Uvx7qXY93Lse7lWPdyrHs51r0c616OdS/HupfTUVLOw9oG i+hGwkssyTjxKv0CGBpipTIutkioaa30/8dXKrzDH30MpOItvZGtdJRQaTEzAVkv1mDnBJK0 SRIX4wlE9PNR1GGSclg51haMAjmwSnzybWGzJc+qecm8QnadWW7xul0DLTW1LLdCAactC0eC aVab9bQTPqVHEqmuc+lpn39tuqN9kmImq72vIrPZF24dnp7QHfSJSJoXCe3fbKwOmbULCpzH zo+c6UQz4J2OfuyFd5PUfFnzbbVQjvC0ovCyXmzA6gYagHcD8G4A3g3AuwF4NwDvBuDdALwb gHcD8G4A3g3AuwHL2RRx0ACEd2LjBrK8q4J3VVneVRHnVhHnVhHnVhHnVhHnVhHnVhHnVhHn VhHnVhHnVhHZV8G7KpN3sg1AA7wr5byBccUNpc2jXVp+hqVWjFzthPisRy70TLjglQveCTWA vF2Um/ZqtaZnk0WDZaaFtEI0+brse0mIJe1TUrifJHGxneM3eQr5x/p2KVSR4NsHhqW39hIU GLziodKmtg6vu/SHp97dmUwMqRmNwWi04iajtn52U3PpvieLG93zXSzVrojF/E1qbDCR7NgE Ixf5a+s8B7YaHn8o2hbzBgP7m32uOre+/cBR7pr6oPF2MNAWbYsydyJ8XwTfL4Xv09T94/Bn ChnJOI+T4pUJpAH+nwUWgZVgDbgO3Aa2gp3gGfAyeBt8COxezSy/kRz4Y+CR5LUMwpRRx6nm m3IykEIGKNda+ptCBlLIQAoZSCEDKWQghQykkIEUMpBCBlLIQAoZSCEDVAXQ3xRjR0z9nWJ2 mon+pjSvyTB5r5HvbeR7u+yr4zjl7Cd77Hux5ljzVSO7Xp/3k4cVLib2yphB4LCI0LAlQvmK fiVfnld5EhVLjrgqKl8PxMNK2kbDO+5IVK6LcL9bkhrzs1YpQiaCMPBm826uJuHJFjyzrjbb WZytfKtD04JB9VQyEgruj8R6UvVlv3m3rKFroD28PxhKpDNPqRNT7fFg5oO+cGpq4qC2v2Nm F91nHwbj7Z3qWEedTnGTKdZgNPN9NY0ll7FIKBrMHJNJGkF/ICZVJLU88/W2WNwfCwSDSpGx iYwtQMYuQ8b61JnSku0yZayTiMOWsVZkrBUZa0XGWpGxVmSsFRlrRcZakbFWZKwVGWtFxlqR MeqgsuypiANsNIJj2WUhcRU89vMNVjVHKjx9ZuQe4HMSmJr+Ioq8RbPyFkXeoshbFHmLIm9R 5C2KvEWRtyjyFkXeoshbFHmLIm9RvlxUPjqhcj6QywL/+1mghIgI7W25WuRhE3T5eSKJWkQg sgKUnxLKl9CdZkO5NS8jJXSrfJ6fLMrOFdkGaCTr/bMWKXdB1RrTmTyalolMa0/P+3Lm0drJ lHE73hpJdE8L/PGvCaRkbss9C5LJyTWZh8y5JOIBr1qgD4tfMSvgR6kd/nh7mxkn7M78QHjP yjXWVDG3pKr3ELU4mP2QwkJTjeToVqYmx9kIQeYhLBthzUlYfT7kBaZ62UWKPO1iQsyYpW9S obDIJZPixVbuUUzuQfexNRleTO5RTO5RTO5RTO5RTO5RTO5RTO5RzHcUk3sUk3sUk3sUk3sU m6ZFOhkkWCMAYFyvlXN5Cdq8BG1egjYvQZuXoM1L0OYlaPMStHkJ2rwEbV5yLi85l9cSWScH jcBcQMEEtlR2pU3Fjp05LVaBwb5+s3e4y9kgO9FYejyo1OVlSkVikUAl/+qTRybX1x3YoV6o KJodCepVKhw7cGNyoNmtjzrqXqxsqggHYh0x5QoHO5KN3a37t/5eGRclOtiu56WIryfePCli TINa7EuyiX1J7uMJR/NzVFahWrpR6nMrSvK0l80vsi2WQnT6C1niVjSh+JBfSplU+pxt3nDQ m/mTr73dpyq9wbB320d+jzcUbS36cms0QPfGofcxfZwYz4FtkLvI1iQdkD5/L/m4S2RKl2iQ T1txttzLRGdrTmfYSqBfu60tFGhTFf72dn/mAy/tPttYOt7qZcb/k/NaoyFvq09TB9/LeB1v ZG6hi0b2wZCqE+0g7IOhGgL9jjf+Wp25Zc0auXr9wd86rjceo+7Yr1bj34iSpIda5Fp8nRj2 emqo5CMfTJMa6j++7sGuoWZ3erE6nsUKyBYFTsYWh+GX74NCCcan3pGzQXbYku+JP6wS1S1q 0y1qY23EJGusJJuQEp/dTVmKgJci4KUIeCkCXoqAlyLgpQh4KQJeioCXIuDSjodRfZuDD4Gs 3awkri013ZakkF5Uhw+8w8HHIvlWWcGLKnpRRS+q6EUVvaiiF1X0oopeVNGLKnpRRS/DS0k3 n98we5frl+9vsrJPc+aqyVo6YYdRxM321gxmmGWMDa7qvXPHeYuu2Fdy7FMrv/r4n16btGb0 3IuPetLnjb7+0PbHumezoPru1rBTjdfVrl48tvjaOS/MO2rrtfc8XF1TfNG5C9ORkWMf/U5m pI05raAfoYD/Y+zSd3URt6h1qTV7iC2c5tKCPZR6nAiP3VltUMk1N+OQeryBtzHwNgbexsDb GHgbA29j4G0MvI2BtzHwNrKVB0EAz10Kp0vxas2MbZV+JKPK8r8LCkdM/ks3Z7673dbWvAxM nHI3bak96WLKgOwUYBV8Zd5djCjyKnvvzQayH90qcCm4HtwO7gePgx+BV4AtAxoyAGG4c7EL 5n4gwnknnJftPRhUOuHmgMVgNVgL1oPNYBvYBZ4FrwIpKFWg2xICyfOzvsiUKik8W5PF4uXs pk5KPQYFiB6twUXZPhrDlArjKQ7l5mvMAEm/a9P2Rzfe8Mgj3x7aduZzqiLzh2fOuKunvvHx WLRzrKF+rCce29zmuWHHTTc89uiNNz6mXzVrXub/Prs38968+cd4mmVSzKH52bbDxd1AKG0Z NqADG5CSXm0Xd83srbWvk4uoxkVU4yKqcRHVuIhqXEQ1LqIaF37RRVTjIqqx1ya+xcGfgZ7r 1bZnLfM8tKfF8hcmZpeywrVWtFcoXgvFa7MUr4XitVC8ForXQvFaKF4LxWuheC0Ur4XitVC8 1qS4Yi7VSnTE5pKxS09ZOW60POtGyxmvnPHKGa+c8coZr5zxyhlPNscpZ7xyxivHjZbjRiV9 l/4lcaO2dfkf1zwwwof0c5qd2vbqGVk+ZTohFvizvYjZp31LlJ6XaNQTa+3asOSuH+65Zca6 gXr/tIgvlvnZtn2ZN5T/1QV3GMscAV/X/PFIxNf9meN2feWr341EKtz9Md/R31KNL76omuz1 /Ivh9Z3oexh9n7QHvbN2aJEVUk6kU2yoRJx062OPjRelQDyOJ8vWEZLQU6o/0kcoFahAdm7t H19hY/uFCJLCyhqoavYJ5yy/XdnLC4jtKM3yg6n1+b5gWRSl4HnWc3rhjdxtsZ01SSGwM2u7 O5Gnzqw8dcL/TvjfCf874X8n/O+E/53wvxP+d8L/TvjfacoTbcp2pCwdrNJoQEAzxZzeZh8y YVJTtjDFnHbWaIcmLvs3bmmonfzYGd89qGp+vGrLSP/xvYnY822eju5U1L9/+44NG3c8csOm hxvajp1/nKp89gVVP3e2uoJNMVDSv94RCNPJ8dTG7Y9vuuExglGx2yvh41JD8oqQ9roV9UiP PZ6bO5R+PG9upb9tNvMUtQ2raTZxbYwnfyjm7tNve2DdgBT0xAwHssQPQPxAlvjsZcTJYrAa rAXrwWawDewCz4JXgTmHKV1NYSsys9YvmCTHSGIdIwHTlSpXyaNfu0S5vG1keSt+dsabmfdU 8J1/U43p1dUHTtdvqH7gsmt3qvu+dPfl0VZvV1N3nyre97qqO6jtHIpefemXbxSaKu0JCDFS 5COquE4S1zIzfpM9WdjkEW0og7ISD0mtRma3pDe/m2OrrsZ9m9KZz3z20JNrSC8kM3sE33aE d3hKLVssBJBcK6OIM7IE/2mkLNssV+gDLPNhBd4EEt78dm3GnYlkInbgQvn3wS2Jjvb4PT95 +/yzOsN1G7ovOFWdmkimopmtN4fpnAvzj35alKOxf/pmT78v3nzKucMEBrEDdyNf12YucFxr 3IPhG1QXyp4mDrRVnqQXOyFrKs1o8H+8q5dV7bDiAjmWaXOhsdQ5ZIbSx7f1mp5S+i6Gc9bB rlbkZTktYaC5VtKmv72MgI32ZI9CVtybwi2FCTMmEM9ibcdm+3INYWT7brAarAWySc9msA0w KMKoIYwSIFDsYBy4asUWHmILD7GFh9jCQ2zhIbbwEFt4iC08xBYeYgsPsYWHP50m8aWH2MKD FsjzBe2YIEmBJB8T5BprssspCQhl+8MJMSKz1JbpMTcExfSY8YFdY9XnXb1169VfvP9+1dUa HPrnDRee0RvynO+99fNTbl2258/7x4+8Zb7He3s83jOzzii576orvvnNK67YcqDjxktS845M dfnS1eu/tW729I+//+SB4UlzGlyhUNzPkyO8K6T+gd8YVo2y3amTVECkQaIFa35CvAGfgYeS NxS9aO2bK/5C8l/pE5Q+GomsqZ2anJX2I1YPMKPRnJudHslx2g7485y2d1DM+wG7+GmasRJu keWxmLEe8z4k1ZVcgM4eK5qwWgdtnsfgeQyex+B5DJ7H4HkMnsfgeQyex+B5DJ7HTOsvuYC1 o4fYVulwawBBIBGcVS7t6h48xANIGJd3BNkyVq21LYMd1NtZce979WM4g82etrk3H3n7t9M9 qXg882E6kBgOnXn6qq+FJrcH0pkPY7H02CYrbGusz4yMTXtia2aE9Rxhs4Bx7yWXbVyZWSYL PyS8gxTsuOM4pmgZ+hvTVo3zDytRoI4UAqwOGTlizUBuj9SQKFJIFh3DLdk0tV4u1FsJFgvG iaCEvPX8mXS4WKsPxc6HuCKzbYQ1E7YfqGcaTQyU9ei92fZnszSsl8WmjsYj06bGdlOCi4TS +z+Kx9vbVfcPE0l2hIp4fI4nzh5KL16UiO6vDNDii6kK6lfRShFqZJWd9k7mEuNO89nata9Y O5HytNYaUI1MRcJ3zNMwB3PBEnAGWAc2gDvAA2A3eA7sAxKny2pTq1Qpe0jZ9ignj/mM1LLr 1oq2PGEkTyTxLiDD4bqb30sTAuk3xKdNiYWnTour6rbg8D+vv+BM9PVC71c+n1m3vDse12NC i7OGO5csjsX+On7FNahpp6jp9Vv1F1h3KfRQYrgcm9HNyeqYPaJLZkQku7sQD8Ey6YWSfL6W 1xJeZRNY6UqUJ8QslfGxFmDXrr3QzAvNvNDMC8280MwLzbzQzAvNvNDMC828uXRYaokyQNjM cYbsI1b/SC9XGelSiyyBsCrjQ4w+xOhDjD7E6EOMPsToQ4w+xOhDjD7E6EOMPkTMMGTG3d1U xUdy444KT1w8hCmm9tK+vNzaKUfeTvSJIPdZBbZs8+M4kaNDc5l3zCyqeZSdIJbvsq4g0pRe /mYOVhux9p8wxZy9J6pUtTJ1PifzVLu2B1p2x+LpI7sSi3oSse972lQg4Eu1q+pofHl9eeLU ni+ryxYlIyzz+b+peCyWeUVdkdkX77IyNAn+GusP9P6xKtjUxn7Mk8t0vag/dQUbK1PBbgt4 YhVqDJFV7JKtOabAf482T7JNMhS4LrtZch1FrYDvjpwcT1RrsZqiOYerNU9uFyHkAWsLlFkP Pbi8OxFT83iiSdFQMH0Ay4MCNzg2WXctIaulttyfuU7/t8SqR6sT9pCSO6kyiO+gaxj7Ikcz OMrfh9UtKz1fDdZOC5+ik2aQUcRISX+t5DSyIk9my6UqYcVt48ycYOVMjyReao75/gze/0yO Zr0iQTSa52zjJLkwacKFqXJh6oQLVXKhyhI6U05t+5oXy/nyifnWJ6r4YmuJozRDSPjeDsS1 SBsqpQ0c5yB3kDIFdop9ZE36j/GpmTJPd4hzEaGdomqtelLxoR7nkGqCtezI+jebuZgSb+zr HZ13fN2URDB0RdI3NtIx3xOZ3B7swhdF0mOuulm98fgdgQY9cfLIrBMa28+dfdWlNaPt4dC6 eFTv2HTalednlsneoPHpXrX1qPnH9/cd2Cf+iYlbr36VPx4KNUVS7VNGj5i87QmrJNUl/VVi y66gFjGiRmT3RycWQCRE9kzxm5IqsSKfgYeyujAbZ0jcKLVF4aCsOxqH9prWZXJVEhFrRZLb 5K3Mk+c7ee0u3Dxv7S7c/AV71jV/IV92sm2QLR953vYLb/uFt3Kz4i1ly4V4tjspjmXjxCom xRG5OMFInGePE4zECUbiBCNxgpE4li5OMBInGImbTqoKi2q17kkwIoGITAtapSTCZ447kIVc MMJMidfekmdCKdGqKB0qL1ZjcO8fCUba0+ll+WgkPfn1qeH2SQQjK+8iGAnP2jmQSBCMCBMj gcb6sWwsEgu0tTN7lotF2tuE1/jrpeSqFxk7iEVyfb6G1ef7KeqK4tVk6rEOX00HpVWdLqVe VUq9qpR6VSn1qlLqVaXUq0qJh0qpV5VSryqlXmVXfN/i4M9AqhCyL6bsGUYzaE7v/4vM2eIr UcYgDJ4NjgerwKXgenA7uB88Dn4EXgGHlRhFND99ifHQEqKS4qFVO9L0lXfufeaOO/Y+rd+f ee2d32VeU+Hf/U5FLvrh7bfv3Xv75h+opS9n3lc1L7+sqjPyC0+6Np2872ryvjgznVfvobfA SYwvGki+ks/7eqBzD3Tugc490LkHOvdA5x7o3AOde6BzD3SWJZQEAW9x8GcgdO6BbxKNSH+j xOqyekj8kyxHoO7GO/IJsdkeS0ZSRHSyEApaD3MwFywBZ4B1YAO4AzwAdoPnwD4g2VqQkQ6b 18zrsd3umL9gl5rIHW3FtvsfTcW2pmZEl615cEnX5fal5NSK060xjU2Eawk03pSM//Emw5K8 WCWAQ2OKQyy3pdjUQWQz0NjEKrJa8X40GklnZscTvTPr62f2JuIUhMe+dcpzquqg9qMzd0xW AzfseHTjxu3fOaixTNAfDsX9jioxyq6G5bNmZd5/fm9m/iz9Ozesf2T7ho3bkYujkIubzXpA n/qqVW8S3z1Ozb2beIPHHUB+ZoFFYCVYA64Dt4GtYCd4BrwMbKnI7v8pK/GyEbcTzjupOVYy btQkqcQvst2JRDSyRoYCEWcB5CfKO3n+2pvf5NlpN8PkL9gLYvL8zc8q/e/UvmQ7ndJsyvkp toboMMkhXt/N1KQ1ESUTSGEePMyDR3iVbRKFNFGOY9j8ids2qlopGITt2uTEAsGhkUDv/u03 MI9ww43f0S8a3XHW3sxBVf3PJ2+Z5Wm7PR7tnlEvcwnxzKx0JB5VP1r/8CMb1j+yY//D6uZZ 8zN7f6KqZ81a3uCi19r/1z8iO2E/80oSj/IbcY7z8OFJ7QvSdFRuxqPimZnjhHtmFo2+y6sn Nzdrdx3kmfX3tHOCUz1UEYVcrYRRPlNqpEobOSRu/RvKY6ao5o95FOsOtUBy0QMXxuKJ5MNj y7ti8Tc9raf85NIl5w4Gms5JHvXtMzZlo1r9Kkm+GlwPXnrxnOHI8JTz1spz7+B3TZp47ql6 v9VULVv4SZOzuGnpI8zaPTH7aWhhak0arUmjNWm0Jo3WpNGaNFqTRmvSaE0arUmjNRS5LFua xpayowT2zcrmMLC/J9z5BNhW8h/vQRMrKcEnOwjAmfxKALsJMM8Ne61e/sKQhDhDEwLcUbkw KhfEbRh2WX6Ux3dY/QYO/KQDP+nATzrwkw78pAM/6cBPOvCTDvykAz/poN/AQb8Bi93kgaUV VjYZkRaZIW6VORzLuv7jPeO237X6MIVwbdwVW4PJtFAEFZMdvugUG+JgDlgMVoO1YD3YDLaB XeBZ8Cr4HfgIyLSQJNN4KKvQZPVz2bFdivFSjJdivBTjpRgvxXgpxksxXorxUown7oqozazr TmgNtzNPSkkU/fj3kM0BzN+fOXQ7th2BSKK5prJ9y2lnXrnq8sF/efml7x55r6N8lJ/x8Yfa Uj5X/9rPnHzRmh+++ORPHxu+8cxQTy1LG3akokPB2oFpi2bNnnzT9dd8JRnr6bmkP90bqutO Hjf1iAFH0fWbrr+vwd3U1I2ML2a++FSHNKF9V35skF2vyR7FNVqd25JTCXETvBbzKm1gJbx2 5fT8sGVwtuKbPlbCeOdr2ZhZ/KusVDR96afgtpNRrWYjy+hEJVuyy1O15qZ1E2YXZOMkEicr +x3JrrDmJ6Yu7e5ob8+c9dlVJ2TaWmPdI6fePfOSr8dctQ+2R/s+e0EklgoaK4LUqDI7tqw+ M+4NdDfFwvPnhZat8Kmj4Evb8/3JRM+SH0PDOfx63UX8AmO39tc9/OPEq4knZcmWSU2pMVNT RR/FFwo1i3mVZUxNppbKjER+vjzfE2+nnHkVtd1d/oK9sYJJajMptZvATZP6v7EpZD6PNbht mSxxmcV8djA1jbKIRNZf2bNjOUpLncHig5W7WiXviW+rc8686JyvbYiFou0/i/o6u5njoGq6 bMOCb32rYawnlrg95FEXfOHijavV3YFQNByYeuBYf0SKKGPzBr/ziPqBxDetXXgkeJA4+Lrj XngQlT5v6YqWgpI0R1lzniRsVq9wGda5DOtchnUuwzqXYZ3LsM5lWOcyrHMZ1rkM61xGeb+M 8j678YnRslq62caNXuEqjKFsy8blMoLpFpkgt6phLqJZF9Gsi2jWRTTrIpp1Ec26iGZdRLMu olkX0ayLapiLnNFlmhuJkz1UxPg1BM3DuNKD7TKPrDkqIXCUp/HwuXgul7HnpfLCcJjDnVih KJylkm9jjZ/JRJn/rQVtwCeBhzk9lWv6LZ1YOZLqmb0M+K7pFDRV83C0Z0ZEOVRg8pED0WHV H493T6/L7HR3p5Npt2HGoL4YPfrr9OvZAdAnMxAHYoMB/5DJt4PvwreX4NskhTuQHm/Zu0F6 vK0uO5PGCWicyNI4AY0T0DgBjRPQOAGNE9A4AY0T0DgBjRPQOAGNE9CYtkZMuvSndEFj+QFJ q4ogoZb5q3kDlItmgUVgJVgDrgO3ga1gJ3gGvAzeBh8CWybqqWPIr+ZJvbTC3uvRkzsK8d3y XVK5tY6sOlW+//uwjhjbmOaZeljxc1C8srmEWB6G7T5MFspcL8U/TIwE1i3oKFMB5nvjMiVj f0qiTYk0RaBkEbH5M3ukGoe2eVP6TCqPVWSgRzzrs6zQq1i6//gTfdlVZfF4OF7zVml7JBZV 5QPRxtraDv+kh64qj8fCiZrLv9WcnNkV7lMVPl+451eVsVi4vUrtz0Ro8+7R9wXYx8AXaw45 ihwHtqnHaArvzizTFzP50cbcuF8/UC+X0OtjecgNyMcMdYO1Pm8U+ZD1edkYrNXS60/dryvk zHZFOCCQrA2RTgarO0I6eK13TYkcheGjWYkcRSJHkchRJHIUiRxFIkeRyFEkchSJHEUiR5HI USRyFIkcNSVSAqlBJDLI+aDJRLkiTdU9ZEvTc1el4mmu7DMN/GFxnN26m5eYw9or7Nqm6SQO z3kl1rH23cp61OxEWBe30g1k8rqX1z4wDUyXQNwy7PZs0IjK2ohsB7hqGpxQbhajUWonvrY4 sdGousHbM9Tdn3m3LT4w4lJjmR9UTeronfP8QPdgX8krzzcMDXQNKIcv1jPYmvmVOrks2t41 /1/6e7rah/ZvigTDwXhbJMj+sf0+swgZDP/bvwVCsVDMx553P8s8GOH9YDgQ/RAZGibX3YQM pdUCNBC+SqolFWOZ+3NZsxoROGqHjcMczAVLwBlgHdgA7gAPgN3gObAPvAM+BmJjIoyYMm2M yyzsMjZXPJZ8erAxHmyMBxvjwcZ4sDEebIwHG+PBxniwMR5sjCc3rWzbGA9yxxwzNsZnewWr m9wqHQf4bjnim/mu/H43hzmDwyba87WRbHg2MfuyRMLyCPJ9xXZHdwCKiYBIN0NhKaOeErVE vJalEJZngy4zNivWPcm5fcyN9KYjsdi++zJfNh1I05DpQKqVKzazLzr8l0QsNXRQIx0z0091 hP6CuHnThezTpZ8fF4KBEJ9PGc5RAV9jyoNnhKfKrB1KpBWHGtY6xHGo1mqm3Nk9Jv3cv/Sp Kj4jz5NNxOU1kfOvh81D5X9kLEswcSFFVi5URC5URC5URC5URC5URC5URC5URC5URC5UxM0W kQsVkQsVkQsVWS5EFtk3AsmF/Gii/IiAHEnRcppkM596M0RJms00xEo2rOnbQRWwmk3M/YZs y642qT9C9mDf9APfHJrk7tQnZ1hdFw7PmKM3zZrd0bGpbxEzBFs7Yp0pT1enPtJ7PLWEBxOx 3h7v3CTGU+mJTIl+nzNNGNMg/djyA34O2dBNSoO6/Cpgb21IT6xb50z/ZZ/UJn+hP2E8x9pr N/MfF/A5WbvsBaals6PffF+9XdvJXzhsg0lbxvOf+C/27OBurEVOEGdQWt17mhp77RXpf/8d Y1mxq3l7eZVDf62kpqSoxFDDFZVKZWq4/HBFtWH8orSmrKhE1wc50fXftlaXFRsVxWpvdZWu Nzhqy9i2P3PuYVcdZU6hx0f6nexTfx9Tvt0k8LJwhMAMSDgrS3RNuthbU+QfMr9TCc+U277F dtTm7y7yhH//jVOLXe6Hy2q4dX4yQC8uHqrgVtX7xfVcrTKMfc7aCt1ZMljJjwo4Lm2tLi/h eTIjlZXKcBVVlzrKi9Sth13lKZEHtVO/wYjxPG4UMP80BU/xd2+aJQd6pLjBvUPo+uuiuvJi p2O4it+duqS1trzEWV6U6ZCbanJUlzkrDGkXMf+jR36NdVTw72LOpe1JKhClRO7yG+F//xfC 878P/vd/HXzib4Nbvww+REk7/5vgU3HjY9p//WvgCzX5he3jqSks0ZZqJ7A++yTWWT+m/ZM5 0SBWjjX65pM4uVtt+qzjP3P0vOSM8y658IzTL7Tf4W3FPJu6GFwDbgVbwGPgafBT8Cb4ACFz ABcIgz4wBhaCFeBicA24FWwBj4GnwU/Bm+ADCOgALhAGfWAMLAQrwMXgGnAr2AIeA0+Dn4I3 wQfYAwdwgTDoA2NgIVgBLgbXgFvBFvAYeBr8FLwJPuBn3h3ABcKgD4yBhWAFuBhcA24FW8Bj 4GnwU/Am+IB+EAdwgTDoA2NgIVgBLgbXgFvBFvAYeBr89KD9n/Ahd6xwi4eeBwrOWURyyOdD BefRgvNYwTmNZIf8faLgXKzuxPtJFZzL79dPfL+z4DxdcG6m0hOer7vg/Z6C896C876C8/6C 84GC88GC86GC8+GC80kF5yMF55MLzkcLzo8oOJ9acD6t4Hx6wfmMgvOxgvOZBeezCs5nF5zP KTifW3A+r+B8fsE5axgP4e+RBedHFZwfXXB+TME5udYh4x1XcL6w4PyzBeeLCs6PLzgXCzxR HpcUnC8tOD+h4PykgvNTCs6XF5yfWnB+WsH5ioLz0wvOVxacryo4x+Ye8jxnFJyfWXB+VsH5 2QXnzLMcMt65BefnFZyfX3B+QcH5hQXnFxWcX1xwfknBuelHJ9iDSwveX1twvq7g/HMF558/ 9NzfWnAuv9Y8QT78bjn/fwklnuAKZW5kc3RyZWFtCmVuZG9iago2MCAwIG9iagoxOTU0MApl bmRvYmoKNyAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VG b250IC9aTVZEWEcrSGVsdmV0aWNhIC9Gb250RGVzY3JpcHRvcgo2MSAwIFIgL0VuY29kaW5n IC9NYWNSb21hbkVuY29kaW5nIC9GaXJzdENoYXIgMzIgL0xhc3RDaGFyIDExOCAvV2lkdGhz IFsgMjc4CjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAyNzggMzMzIDAgMjc4IDU1NiA1NTYgNTU2 IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NgoyNzggMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgNjY3IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAw IDAgNTU2IDAgNTAwIDU1NiA1NTYgMjc4IDU1NiA1NTYgMjIyIDAgNTAwIDAgMCAwIDU1NiA1 NTYgMCAzMzMgNTAwIDI3OAowIDUwMCBdID4+CmVuZG9iago2MSAwIG9iago8PCAvVHlwZSAv Rm9udERlc2NyaXB0b3IgL0ZvbnROYW1lIC9aTVZEWEcrSGVsdmV0aWNhIC9GbGFncyAzMiAv Rm9udEJCb3ggWy05NTEgLTQ4MSAxNDQ1IDExMjJdCi9JdGFsaWNBbmdsZSAwIC9Bc2NlbnQg NzcwIC9EZXNjZW50IC0yMzAgL0NhcEhlaWdodCA3MTcgL1N0ZW1WIDk4IC9YSGVpZ2h0CjUy MyAvU3RlbUggODUgL0F2Z1dpZHRoIDQ0MSAvTWF4V2lkdGggMTUwMCAvRm9udEZpbGUyIDYy IDAgUiA+PgplbmRvYmoKNjIgMCBvYmoKPDwgL0xlbmd0aCA2MyAwIFIgL0xlbmd0aDEgMTI4 MDQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBvXp5fJTF/f/Mc+zz7P3sfWQ3 u082e+S+2JCQSJaQEwhGIpAgkQQSCCCCGCJQwKCcUamKhAjWoypyiCwhyAaKpRpEq7V4V4qt rUipv6b22y9aD7L7/cyzIUJebX/+0Vf32Tk+M/PMM/OezzXzPO3LV7QiNepENKqd1bxsPpJ+ WZ0IURvmLWleFqcNYyB9dV5HuztOswGE6NvmL1uwJE7zjyCkcC64bdXw/cYQQvZIW2tzS7we XYE0vw0K4jQm/SW3LWlfGaf1fZB23rZ03nC9gbQvXdK8cvj56DzQ7tubl7TG22fNhjR52dI7 2+N05teQtixb3jrcHtfD+H6NMJS60cNIjhYjDlFIgKsRIe6SwokYqCX18Ht/QoJ6jrb4S6Tj JXpOzY/j5QuUf/269Ypf+RD/DRTIr7YnqSwlmoKQCkP9oPKhkRrpPojcEVSXFkHVEEogBCGk pU2wok68Bz0I4UkINFqI70OrIGyF8CgEZiS3D6h+fF8vw4eO41XIjieFlIzrZqPNZVUoXe9E sKzvcddH1k9PYBus3h+wrVeN5BMU+En8BGpBLvws8uLVqAoF8K4jKbe5mqBqH1oGoRMCLcUY 7+tNzHW9hNORl8Fwjw8lMvhF159yMlyf5UQo3Ot62R9hIPlFIlAhreuU83HXz50LXC9BOBCv 2p8CLV507XPe5tqeGMG7el0POyMY7nkonqxwwq0vupakdLtacqT6Kd0R6kCvqxDqZ4SUrvwC 0RV0XnBl+SM8BjrDOcWVmvMrVzLcCM3c0Kk3pHM5nNtd46Aq0VnuHwfhBN6Pd6NUvLvXO8l1 HLIw3SPVKQXdEfyjI1WBHG8Erw7lVwW6U6r83pQpLm9Khd8P+RmvcRu4W7gJXC6XxgU4Hydy CZyR1/MCr+FVvILneS6Cn+8tcclO4AOoBGA5cISX8WwEvwCFzAl8UCo8eIxneIpHvDES+wSY FyNjBB/oE0gOMi/KpJwsgg8eiRcdDLkYkmOkCoEieYggRhTmKTQJhfEDERnaaO4osZbox+sK K8r+VdQk1VyN0/71z4qd4e7JdfXh/c6GcC7JxJwNV5tbr2b+Zdq+AqpaS9PSJk9bdaRj2aL5 5a2e8iZPeSuEpvB9HW3WcOdct/vwomWkwh2mfU1z57WRtLk1vMzTWhZe5ClzH+6Q7htVPZ9U d3jKDqP55TfXH54fai3r7Qh1lHuayxqOzC1d3njds7aOPGt56T95VinpbDl51lzpvlHPaiTV c8mzGsmzGsmz5obmSs8iky9fWFd6Zztwp7t84WR3OFAXrr5pVn3Y3dxQFsF7oLBsBWJPIYE9 iQJsJ7IzWciFUOwjCOdIGp0eu8ieQUJ0Sex/6CJY1H4SqGhJMTqFHkC70SEkQ3shH0C3oh70 Ol4Esj0b9aEPcCLKBN3LoAiagt7EsdjbaD56Btq3o5fRDnQYqeCeJcgEtduwN7Ya6BDk56IN sZ+iZFSANqGTqBB63YYGY/tiR6B2GpqO9qMDcP8b2EMdZgyxF2IXEI9ugj43QM3bsSmxQ0iP 0lEpqoXSDegl7KXPxdqQFRXB6B5DT6Cn0C/QX/A9uC/WFuuInY39AVjVihyoDq61uA//gT7E bIo9Fvs8FgUkAigVntqEtqOnof9DcJ0C1VqOF+N2vB3voELUPVQfs5G1RIcAhxRUCVcVWoq2 AAL9aAD9HX2Dv6CstEC306djwdj/IiWaDLMkM2lFHXBthmsbzOkEluFsPBHX4rX4EbwDv0ul UtOpeuouaiV1kZ5Kz6ZX0e8ydzK97P1sj0wZ/TJ2InYm9j6yICe6BS1H62B2L6Oz6DL6FtPQ lwN7cREuxbfC1Yl3U/34KdxP1eJT+Cy1H/8ef4q/wN9RLKWiTFQa1U5tpw5QL1Nv0QvpHfSj 9O/pL5nxLMU+xX4m83K/jc6Nbo2+FSuK/SH2NahYHomwMqVoKpqDmmG2y9AYdDfM4iBch2DV BtBp9Lp0fYodaBB9DSggrMd2nItr4JqKb8Tz8UL8OD4O10vSWL6iYCEoOaWjLJSDqqPmUkuo Tup9qpNOoFPpSfQs+hBcr9Ef0N/R3zEsY2BMTCVTje5nljC74NrD7GV6mV+zhex4dio7g+1k t7L30/PYt9kPZOtk22S9si9kfwO1OIVbyt0Pq/M68OwvgJe//zE4GUafi25H83AZnou6YTWe ws2oC7irBW8BvJahQKyRXkdXUtnADS+hHwG37kJr0VZ6Nnoq9ht6P/oQOOU26LITPceUIie7 E1bnHpQNXDR8hVJSUwJ+nzfZkyS6QeU7Euw2q8VsMhr0OkGtUirkPCdjGZrCKL3cU9HkDvua wozPU1WVQWhPMxQ0X1PQBKLsDldc3ybsJvc1Q9V1LUPQcv6olqF4y9BISyy4i1FxRrq73OMO /6rM447gWTfVQ/6BMk+DOzwo5Wuk/INSXg15UYQb3OXWtjJ3GDe5y8MVHW1d5U1lGem4PwRw KDLSieIIISXpOIwmNq8FBYsmkhblYbunrDxs80Ae6mhveXNLuPam+vKyBFFsgDIomlYPz8hI XxiGcaL7VC2elvsiITS3ieSaZ9eH6eaGMNVE+tKlhS2esrBl9WfW78mrufL7r6kMU96K5tau inCo6T4Al5BNhGq+H6jJdW7oltrYUB/GG4cHQca4CEZKhhu3Cd6mRe6w3FPqaeta1ATgomn1 vfaQXVK+YVRb32sL2SQiI73fuq5IhNn3Z0zImEDSItG6Lp7+6d54+TunSGpdN/AJpJOnjQCA CQKeahhn2D1PeogHBltAotYC1DWvAHCCXwOGaS6E8UwMU8AztDfMequbw511V4fRVhYfXNOi sl65zS4ZodIGaN/UJYyDlYL2gsfd9SVY6ybP4F+uL2keLpF5hS8RqSQLPcIrYdx8Nd9BjKUX Zt1m9bSR9e2Q1hRoj7X8mgKgCTRkzGEjGPDaejHsboAC8CbTJ0eQvLb+MMbbGiI4tjGCypz9 4KPSc26F6nTCagvL4PlAZKRDQaoIucx0dwU8uYLwirvL3VXd0uWucLcBMzFeKYWK1q6GLECw rh5wQjfDE0MNCSPZ1oaGcdBPFukHboHmXQ3Qw6LhHiCVirKGoFF2OhhT2ldbf1N9uLMsIRwq a4BVAPY9VVsfPgWc29AArXJGRgojXrvQOjzmXBhzTirU58V7Ad+lE7po6OoifdbVe8Twqa6u hC4ib3E6gtHogtBwQQSRJgTyCO6shXsh8YgJ0hqIHhGG1UAwHQMsfZWjwGf/9wjnj4wb7hwL o82XEC74DyFc+EMQHveDEC4aGel1CBfDmIsIwjf89xAefx3CJf8e4dDIuGGQE2C0IQnh0v8Q whN/CMJlPwjh8pGRXodwBYy5nCBc+d9DuOo6hKv/PcKTRsYNg5wMo50kITzlP4RwzQ9BeOoP QvjGkZFeh3AtjPlGgvBN/z2Ep12HcN2/R/jmkXHDIKfDaG+WEJ7xH0J45g9BuP4HIdwwMtLr EJ4FY24gCN8ygnAoIYyu1cOdo9Qu+o8r5tnXQA6eEqtHpVQhbJwL0X5qP5pO8sydKARhYDjN gXQMhFIINRAmD+eroe2n7Ax0COhpsCEvgrQAQhWUOyC9AcIGfAZtgLpOyJP6DnjGVqDJMy2Q KmEIV8+OVLCjiQDtRjPJVv6f/ijYDcAAEQttOdgXyJEC+lDBuY0Gaf/pHf+8EE4O/j8/HdTr kQEZYcdohl2PFWjb8D12lAA5B/jaiZDC/lX65aN81Aa7yP3YisfjX1Id1ABdT/+VKWA+h93B 8zJK9iY3lTvOb+DPylfKX5N/pZiv+J2yVtmt6lC9qiancBTscRBzFvbGNMxuYvzci8+KIAYC LwA4ZyEQGvL0echDykFKQyo/j47DXQjNSDsOPbGQZufk6USdH0Ipsy1y5Y/syW8nRpia7+Ac BRDeHz2LO9E5QC4jZEYejaKFVwgWi50bo2hBvE07r9WaNlW4XFM8NDi1vLXsIiqpGXxvMCfb kj82PzjG5/cE80xGGbe/3KHF1JIPmjreVk3PSOWU3Llf3tVnIpBgNB3/jppM7YT5uEMKlEVj O4tsDJwAlR4Rj1fBscnUC8JFlFUD3RpEkzgdfxVVUDvBdY9zALVIwiItZOGwBe+EjSZFOfQ0 jShaQc58aFuW9T1UUlxSzG7OTFsrDOBGnIc9+J2eaGYPmS3BNBT7iHGwPcAfDnRHyLKZxRW8 KahlHUFOrS+gl1oLlImVTqFjwPre4NAgKhksgdFMXBUagxLUPuy1++Re1mfWWAPAC/oATuAh J8ggZ1GZAthAQWRTOAJIx0BEzkAwiaTfejgitZh1AkeJbr9PN2asXtTn68ZQniRKZ7SY8+jQ mqaZ66J/jEbXLSzpwMGuPSsPPrE9q+oFtuezw9E3o+d/Hv3rJydw0eVDuOLbz77G0y7jouj7 0Y9/u/GNOL4DMMH32YdBEjyHeRzBeSEVw3AqhutmkaJSTiY18P5QISopufwrgDg4Ho/N03l0 A6/s8m07RX/VZWjY8+3t9FcS3iHgvUT2JygJ7QlNzWcqmJnsYuftiasTN+DNFJ/Kz7Ittq2x rXEctbEoCWsZh8Ymcg4bnHeyLq02yaAIGli3a4WYpBLv5grMS5M0fu16V0FScqUnDu7lQeHL wQuwXEPFJYM6fWGW3lKIIdUXFuogQo0S7A7GpvLqfEq9JoDkRg7AZdSCIoB5E0SAryBI+AK0 +foSHOdFTxIn4zyQF3P1JiMn02IZFABDTdr4i1Prx0zrXttf6WOO0aUrcOCrT1dVHN06t6DF TmuupPRj/bKlk4N1i9duv3/yxhMdZ6NfPf386srWKfk5Mxftl3DJAf6xs7tQDhoIuapVdRmt KfMyVqSsyJB1+/BkPk1hTTOq6W9yjEE1bF49IaMuKNytVuckBJNZLpijtnb7y3QROHXWKgoy l1KuFPd62k/lVeZeg8rg5TjjASiXhy4KgwLBh2AjQZKflW3zITnrc3qTfDJEBxBD89kAh8Pj CiC71xrADOYAriyIEsUEwMwH0QgzCsWEG9evB8xwI0MF88zAe7lEiD1JMi6YiPNyJZGOwziG wAgnBIBgIjYZkQebP/uZKlBxbNvzR5/Sew0On7l1wvKe1r5yH9sbuh2bfvu3yvSKO+6O/v1r P7a8dl/JHT0rH+nA+Amachc8uLh9ZenqJ5e99kr/hml5Ttfhzl9Fo4R3KTjDAb3GPgY5NZod SpJTCl4N8v2SXibjKBlmOR7OlTgFtULJfkGrOIaOYMtR3K3mn1dEcP0RVlupkRD88nLxEHBV CSTFukIJNQCuEBQCs1Y4rc3Jxjo51olBnKfLM3l01LPRIH5r6H7qwZ5334Ujqa1Dd0VZfGuY 3nZlzk+iPyVjw6g0dh50RifYohOhtCr9FhdVqKowzDQsMDDjeJWaQyqFVqNZoTcY9BqtW2/g kMGisARhYEkhu/pujcapH6dlmKD7jFOt4wrsS1GBO6lSjK/4l4MDoGUGS4ZgtS9cvrrSRAwk JXYaxZce1t4KaihgdWE55aMT4XAQXi24WQfIhNwKEXYxASRLgIi3xWWDqB6hmCw3WetGw3Xr 7CcalgYhyctlTEZKTEr2D+nXhm5+ctexzsaNWY8toS4NPXFDbkbtwtNY/1108FD0fwW8ZFdR 4ptrup+pCslp+oXocp9BjL7yRvSXp9+U1rAm9lvGwz4O9tCP9oUK77JjC+/l/bZ62ya0GW+R c5W8QvSLQY3GSJ/hggmsPwiykkKtTyzQLbUoqGJFco4lpTIgATNUuGbytJWrs6ygJoblYRAg IgDFFbLX53BrzUjG+tzaxAD2mZIDyGGAHJEJzNAuQQxgr9kfQE49REQmJF2B4wJAJGA9bgSd bDZ5fH5gfup7ODxJSCdI+jkuFiYjqOfKk72CZ8KGnb2K8bfOWNSHVdH/93r0/IS1eMr6B9bt aT/0xAPs499smJ49K/rn6JVbMgIXL7wSfRfnwFGj8jhu+fbjn99z+5ldu7fE7dlkid87wQ7V hfJZpY0qUI5TFaonqadTM5i51DFOsUbdpz6tpik5VmvGIS0jV1FqeI22VMMXyJ/X6CoFCSZQ o58RBgeWB44HtsGgOBuxSUaBxIIa1Bvyx4pBJqv8s/qZGc7MM2WXtu68cont/MnEaN+pE7vm nce7cPdfDx6F13rA5x+CbnsMfCgLnES+EaqcgWfKZ2kbDC24Vb5Yu9Bwl1deLfzI1uFZ7r3T vyZnTe4W22b3Zv+WzC05PTZ1JZ/LezWUN1cZ1OnS2WAiawmmq6kCOBTYdExTkLI0iy9IgPxR Y0HWmMq8OPtLZuB7fTcYF9nhNQ6mZjrcejOtNmcYA0iVpglghZ4HNndCxLioADZlWgJInQoR 52ADmHZDNKLpJC0XX+Nh9UbWUX9NHvl9wTEgAnEFBwICouBJSoaysdQzmzrvvae9e/6WZ/dv XP/0jseiR1NvvPT+W5+X+Wob8uZEL70d/f2a1XRo4+zaTZtmtS4fKtq86b4Ht9+z7GnqybTa zicvfvTQprqsjJRgy5Mno998+pu7+3OInquO/YbRgf0gMnIglGlj09iAuUpWz7axW21b7D12 eQXPiX5/UKGwikGBZYIJZ6xqjirmEnPgTdj0kFKNUhLWJxeorwoKSIfw5VDh2ri0SLrkekFx +Wx2pQHTei/lS9KClLh1ICW0DVSITwmkRwOC4jJAhO2gPrwqkBZiIoY9l7ic4Lj2MGgwCEpw jD7PbTCbiCuT5AuiaxDFAr94bPn6F33Fh+f/+n/+egkX3lV6473RM++co3IPP/GjDbu37MCz dhQmfoir59Rg6o1XcCB6cfefo9+8EX3h/B7seyD8+O7Dj9z/LMHqU1C+fYwo+b+5ITubytGp CIyAHPxSFrcwyMbLW8SVa4jnSDzT4mHPFFxTgfiQRMFD+PRt+DHiuaHt8FKJ9HsIZO9r8CUV 4MM1h4ILVQv1q1Sr9UyVsd7YZlxtZDg+UScICqzRJoJjqeApmV7FyI3GHMZu1sq9yGYyR7Dy iLhja/zR8GThq5ohHbgwcTkUQFPBeCRZNEj2U+YRdR5gN0hEMLaHqB0Df/vgd9HcM3TnytI7 o+34/k3PsSc/fu352NB2pn+cK0ovf5DI5DSwPeRNgxbeIRWjj0MFqdlYISgTVA5/XpWwUL5I 4Ap5vUpOJ+RyyXKnoHIWpVGZKUXHiqii3FSvXuBY3uFPsjgiuCvksThdnN+ZqaScQWUxV1zs MHIpqXuT7eMTUhyTtP4C2w3jf4Z3wguWftyN4nMD9iKTuzA0AHOC2YFDDOZKX0gm2wiaJ3Mw c5D4JjpLXC8H8seakhC2eXG+VkTWxAQRmd1GEYtJaCwlIrvTImKTCBHhsWFdPOyMJIMfMjb/ BqzBkstmus6fGw9+CcinDiQ4Fx5B+NDv85OEiPBYA9YsnzqnoVtsy10yN6cO9403qe5d/UCR qNjL/uPpkx0rLF5Voi413deYapaPfWvNjpPHd3b9elZ69Z6HTA6ZRu3IWoBv49OtGbPrpqTW vbq7qqpnaKcjiaY3qmSlnlDVoqNbdjxjwBcI/8CbKPosMxWRnd9zoaznbLjHupffb6Un8brd Rpo2ypx2Tu00KhO4hASL4NdjcPF0dqfCb7E54PU8d0RcvnYYXcC2uAa0HhHZOLqQIdwLxn4M MLhXZVL4kMYg+LBepxU4G1AsokWMKYZWmtU+pNVDJLfKfOD2ycSrJo4YubjxT5McPWS2eDIB LE5GdCAgmBeXZAHlcdQHn1oOCcvXPT8pe8vDy+61HUr824l3vsX69xzM1PCH8+7du+TJp85v vev90zjvIrxGG8cCBgWxc/Qg+zLYCie6K5Q7VlOpmal5jtmXwHp5I6V1Coh3OjmDgnJalGym IVNI0entLqXfbkt0bRaXl147/aEL4LENEtbSge8vTd1udcgVCGOrEubmgAjZKB9SJPA+mCD8 JY7Rk4kMG2jYWVl0sJsJkmkhoqC+eviptU/tWb1lH+6qy77h4E9Lnl96JPrtF7/Dcy59+Pob r5z9JTV2TOJkyvnt+B3z6nHGt5/jmSBvVbFzjB3kzQFvgb1YFVq1k3/U/pyLZjWUljWaNHqt yRhShYx8ih1PVr5In8Gv0mcSfsN/JP/A9RvPJcslj/KM7oyems2zYrJ2l9mZXCjjOLPodHAK p1np5XY6nnMcc3zoYLxmrdfB2hQqTgd7I6eftfuTMzm/zebzvyfuaRzWLBeI8A2+NyTti8DO A3c0jvAJqBhpbyBBVoE8DEvDa1PMMjKXTyfoBYNgFBiZypuUkOwD79Xpw4lOuYXzIaVJ4wO3 wmMXoYiFiLcCX8HOCoCWVH+cfSCbmpa6Ht/RiO5oBEcJMDabxPgOgTAQcTEkVwnlYcmFknGY 6vugIF8vXPmCfXDnAzdnGw9zN+ZMWzVh2mvRz7H1j9ilDEw6uGYviz1M5eLpN9026adPn27M ryx6KLPWIcBmXYYpXBr1rai450gXJh8ngZvrAKGzsO+AV1ITSuOcMoWTxlpjoVkt0ytsYAs0 al2KRc/ptRqXhtJcMdqstivignXDCDYWDhBdLFw1DsU1ZMdJzi70xPs1W0xELmQmYi3gCuYF j3pK+nTJFodNOc3d29e7YwdbOmY2RT1D4ekvbLvSQj+2bS+Mi0Y3RIvoS8ArLpQBXxscC9Xk G6v5ank93yDfotqXsNe5z78nrT9BGeJpc1KKZkCRBOqXkaU4bQq9U6HN5DIzWQedac7MSGHt 2SqNXz3e53fYsrKvEZDLg4WSbbnwJejYq/q3JL4ljItKuidgT1Tqkr2Cz5Po86GAHSKdUiMi rUal9jqTfNifkAJ6QqUXpdUFpfu9CyydSViCeTrY4YEt98d3g2PzJc2arAP1gMA1HtYasC/E 1Jpb84J7ipdFXz/4F80xtf+Ge38d8tH5PWtfiH6HueO47Jm7X6rwbl/z8o3p0beZ0vGeiZuv 5L7ZcW73s1X+4odnfDyt9h/YidU4M/rUqd45u46ePDRvA5UhrfMGAJXoFDP4xOkgNbyFs/B+ xm9Ywa3geYOaMsBBks4p40wqhTpFYbdiUwoy2yxW+GrriDg3rlPI8koyQ06CiEYpxMSbRI2G PJ203SFGxKMbQzx+GeQ29IXyZt7z57qM/sSczcte7GNfHjp/k1j4dMPjQzdRT3eMrd/1wdBr hA8p+KID4aLh87j8kIP7jAHmlNGSPwJ8m8LRxCPZ//1IBoaKB0bYDrwS4pPAs4HTNhyDH5P6 3QfsSbJ3wqgT5k58EiVYlJYGCo/jsY0CAbPIZrIL2FWyldxmtp9+nT5HK1hWBh9TyWlqA/UI MCVNFerlcoaFF/eyJXpAjefgFT4rk/MsmAgF+Dq0TMHJFDK7GnbVKUhpU6l7xbn92By38ASw YttU4aIVEIPDsxJi2TGEzTWZafxa4RfM5kxrWiO7Vjgl8MV8MWyhiTpYDlPBeXIQWU7n6TyI 37oYnY8PX4z27jzInrxyAJ+JLh2aSzm6orfD/GiwmR8xIthMFZyd2tCDobwevlt41Pwss5ff I+wzR/jX+A+ZzzR/NqrG8TKnlVM59UobZ7OZKL/WniD3m2x22DvIwXIOa0bJK/neakoqMB2O kX1Kgxy0mI7yYc4COVYNOYVR5UNYgIg3g6GkNRBJeo5ExEAm64PDHEF2CLD5A8cWBSXj+MnG 7CnHn+3ufho+KroS/cfH0StY/ydZO9bu6b71kSu9By7Q56J/iV6ODkVfwGlXwHkJEfvYEZ3O eEE3aOAErT2Uvo9/zkIFeLdDp5E5TZxWpnE6lEkaym+1JysyhUwxJUlr8yRvFk/GpweLciGu +iVlDydkoPmlOTrMCYi1+xgfSoCJsWaIsE3jQ7RFmpM0LbLfTwbLSHiciC4c8OA8k8T98KEH 0dngOuk81KvPeSuOnyj3QhzNPJQfuuVHL0aPte9aNS27qG/Vu+90zj58omXXmpl76MPbqgPF sK0div60e04wsXroY8KzW0EoHmYqkQ7dGPL5aZ96LF3JMBpeoDRynVzl51kOyXQK3m7AxP4j m94QweUgqXHVTOYIbAcTrCkZGBogu9j4IReRVRPx90Z0s86z9YDpmcWs1SkkCFse7mOy+vN3 U/RLNHVo+VAPkU3Yu9IvMpNBD2fhzNCPC+Q9bLf+UWOPqSdVFkj2+vPFCrEyudI/I3mmf37y At8q1Sr1Kk2Hpz253dvu25O4N91Ag1lkM5hMA7KbEiwOqynDmBnQKhfyPm++l/ImqRVMmsH6 qsNp4Bhn5q40ZRYn1wgUh7LELLvLarb6LeMDPs4fsOdoXH5hPPJn2rJzekds+eDlobguLxQg R6ZbmEUcZ2nzDidAg3C2YSm8Q1rlKTiD8pnguFnUuEQkh88pMZ0OfjnsgUTs1ENZgtEqYrc2 SURikkbN+xUi9nnlCpwBGyZZCkSJOoeIbWaIJJMuKX0pkljkKuPDGeDIwZDfl0XMuLQjtpi5 +KmIxD4usv2D831wtv34C95btrel5wb/nT/eOqH9t/1/XzyR2s/6xj86f2F5YOpdL5cu/Oh3 X5zh8DFcOyt75sxbypPBC0pKrV7f87Nts9puyK2cGqpItRmcWenlj/z47EdPUt8AL1liX1By dhZoh2lH1ZmKUxo4vy4JeRlzoYWWaRQ6O9h5OAFMQSaNSUu7aIq+YrbZ7GDnhz3poevtfBac h4BiGxSGLkhal1h3IgdX9w6+IDH1e188cMBnylEnGl0T/etmPfQQOyv6/vah8gKDElPb5Pz6 BdTp7ZJ+hndT9OdMFgI9H8osxacxhRagNqqNXiDbzGxhn0N7KR6+vqPKmUnsJmYre4Z5jeWr A3cGOF5SW5I7Ap97RmLL+sBBczMRfO8xml6ipzAFb0DuDSXKQHuDVLEyhsaYpWgZDWdbjIIn Ez9EHcfE+mw4gg/JbLapl601Q598MmSTjAvR2yWW4vg5ob6QA7UtTL1Qw8WTtMk3rQp5qRR4 UcKgFDhOBf/wus7BSBxi0ff9FhYOFRaO6pnlhDT4g+oHV7DxDoNcerFyHifitNPR205FVzBZ V3rotu/eBoQowAt+sVb4xvCf/dxQSMN+Vhj1Rs0m7afIe7Q8VIYqpG8Zq+HzXfLF4lT4ZrEO vlqcAW8DG6ROMdyNpZwMekKzamaU1VemVbXe1tHavnBeM9TEa0mTLRAegfAMBPikGL4QROg9 CBcgXIaGDAQjhGQIYyCUQbgZQguEdggbIDwC4RkIfRAGILwH4QKEy6B8GAhGCMkQxkAog3Az hBYI7bHhHzwLjeQxco+i00fRxCO6tn3WKDp7FA2HS9e1zx1F542iYZzXtQ+OovNH0WNH0QWj 6MJR9LhRdO0omqzQtfObN4oG7K6rl3jpGvzmj6pfMIpuG0UvHEUvHkUvHUUvG0UvH0XfOYpu H0V3EPr/AD6GFYwKZW5kc3RyZWFtCmVuZG9iago2MyAwIG9iago4NTYzCmVuZG9iago2NCAw IG9iagooZHJhZnQtaWV0Zi12Nm9wcy1pcHY2LWVocy1wYWNrZXQtZHJvcHMpCmVuZG9iago2 NSAwIG9iagooTWFjIE9TIFggMTAuMTMuNiBRdWFydHogUERGQ29udGV4dCkKZW5kb2JqCjY2 IDAgb2JqCihHRikKZW5kb2JqCjY3IDAgb2JqCigpCmVuZG9iago2OCAwIG9iagooVGV4dEVk aXQpCmVuZG9iago2OSAwIG9iagooRDoyMDIwMTIwMTE2MjUyNFowMCcwMCcpCmVuZG9iago3 MCAwIG9iagooKQplbmRvYmoKNzEgMCBvYmoKWyAoKSBdCmVuZG9iagoxIDAgb2JqCjw8IC9U aXRsZSA2NCAwIFIgL0F1dGhvciA2NiAwIFIgL1N1YmplY3QgNjcgMCBSIC9Qcm9kdWNlciA2 NSAwIFIgL0NyZWF0b3IKNjggMCBSIC9DcmVhdGlvbkRhdGUgNjkgMCBSIC9Nb2REYXRlIDY5 IDAgUiAvS2V5d29yZHMgNzAgMCBSIC9BQVBMOktleXdvcmRzCjcxIDAgUiA+PgplbmRvYmoK eHJlZgowIDcyCjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAwMDA3MzA0OSAwMDAwMCBuIAowMDAw MDAzOTIxIDAwMDAwIG4gCjAwMDAwNDI0OTkgMDAwMDAgbiAKMDAwMDAwMDAyMiAwMDAwMCBu IAowMDAwMDAzOTAxIDAwMDAwIG4gCjAwMDAwMDQwMjUgMDAwMDAgbiAKMDAwMDA2MzQ1NiAw MDAwMCBuIAowMDAwMDA3ODk5IDAwMDAwIG4gCjAwMDAwMTA2NzEgMDAwMDAgbiAKMDAwMDA0 Mjg2MiAwMDAwMCBuIAowMDAwMDA0MjEwIDAwMDAwIG4gCjAwMDAwMDQyNTUgMDAwMDAgbiAK MDAwMDAwNDMwOCAwMDAwMCBuIAowMDAwMDA0MzUzIDAwMDAwIG4gCjAwMDAwMDQ0MDcgMDAw MDAgbiAKMDAwMDAwNzg3OCAwMDAwMCBuIAowMDAwMDA3OTM1IDAwMDAwIG4gCjAwMDAwMTA2 NTAgMDAwMDAgbiAKMDAwMDAxNDM5NiAwMDAwMCBuIAowMDAwMDEwNzA3IDAwMDAwIG4gCjAw MDAwMTQzNzUgMDAwMDAgbiAKMDAwMDAxNDUwMyAwMDAwMCBuIAowMDAwMDE4Mzg5IDAwMDAw IG4gCjAwMDAwMTQ2ODkgMDAwMDAgbiAKMDAwMDAxODM2OCAwMDAwMCBuIAowMDAwMDE4NDk2 IDAwMDAwIG4gCjAwMDAwMjM1NjMgMDAwMDAgbiAKMDAwMDAxODY1OCAwMDAwMCBuIAowMDAw MDIzNTQyIDAwMDAwIG4gCjAwMDAwMjM2NzAgMDAwMDAgbiAKMDAwMDAyNzgyOCAwMDAwMCBu IAowMDAwMDIzODIxIDAwMDAwIG4gCjAwMDAwMjc4MDcgMDAwMDAgbiAKMDAwMDAyNzkzNSAw MDAwMCBuIAowMDAwMDMyMjg2IDAwMDAwIG4gCjAwMDAwMjgwODYgMDAwMDAgbiAKMDAwMDAz MjI2NSAwMDAwMCBuIAowMDAwMDMyMzkzIDAwMDAwIG4gCjAwMDAwMzU2OTUgMDAwMDAgbiAK MDAwMDAzMjU0NCAwMDAwMCBuIAowMDAwMDM1Njc0IDAwMDAwIG4gCjAwMDAwMzU4MDIgMDAw MDAgbiAKMDAwMDAzOTUzOCAwMDAwMCBuIAowMDAwMDM1OTEyIDAwMDAwIG4gCjAwMDAwMzk1 MTcgMDAwMDAgbiAKMDAwMDAzOTY0NSAwMDAwMCBuIAowMDAwMDQxNzY3IDAwMDAwIG4gCjAw MDAwNDI2MjIgMDAwMDAgbiAKMDAwMDAzOTc5NiAwMDAwMCBuIAowMDAwMDQxNzQ2IDAwMDAw IG4gCjAwMDAwNDE4NzUgMDAwMDAgbiAKMDAwMDA0MjMyMiAwMDAwMCBuIAowMDAwMDQxOTg1 IDAwMDAwIG4gCjAwMDAwNDIzMDIgMDAwMDAgbiAKMDAwMDA0MjQzMCAwMDAwMCBuIAowMDAw MDQyNzA1IDAwMDAwIG4gCjAwMDAwNDI3OTcgMDAwMDAgbiAKMDAwMDA0MzU3MCAwMDAwMCBu IAowMDAwMDQzODAzIDAwMDAwIG4gCjAwMDAwNjM0MzQgMDAwMDAgbiAKMDAwMDA2Mzg2MyAw MDAwMCBuIAowMDAwMDY0MTEzIDAwMDAwIG4gCjAwMDAwNzI3NjcgMDAwMDAgbiAKMDAwMDA3 Mjc4OCAwMDAwMCBuIAowMDAwMDcyODQ1IDAwMDAwIG4gCjAwMDAwNzI4OTggMDAwMDAgbiAK MDAwMDA3MjkxOSAwMDAwMCBuIAowMDAwMDcyOTM4IDAwMDAwIG4gCjAwMDAwNzI5NjUgMDAw MDAgbiAKMDAwMDA3MzAwNyAwMDAwMCBuIAowMDAwMDczMDI2IDAwMDAwIG4gCnRyYWlsZXIK PDwgL1NpemUgNzIgL1Jvb3QgNTcgMCBSIC9JbmZvIDEgMCBSIC9JRCBbIDw0MmI4ZDFkZjc1 NDI5YzhiZWYwOTgzODcwNDMzODFiOT4KPDQyYjhkMWRmNzU0MjljOGJlZjA5ODM4NzA0MzM4 MWI5PiBdID4+CnN0YXJ0eHJlZgo3MzIyNAolJUVPRgo= --------------D972FB92435BE6F001DD5AC6-- From nobody Wed Dec 2 10:23:42 2020 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 DCABA3A18DA; Wed, 2 Dec 2020 10:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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 DMYlVfG6Qe6n; Wed, 2 Dec 2020 10:23:25 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 196803A18D1; Wed, 2 Dec 2020 10:22:18 -0800 (PST) Received: from [IPv6:2800:810:464:8164:e592:5e1:9fe6:cf05] (unknown [IPv6:2800:810:464:8164:e592:5e1:9fe6:cf05]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 4E1F92806F0; Wed, 2 Dec 2020 18:22:14 +0000 (UTC) To: Gorry Fairhurst , v6ops@ietf.org Cc: fernando@gont.com.ar, Brian E Carpenter , draft-ietf-v6ops-ipv6-ehs-packet-drops.authors@ietf.org References: <0c121812-44cf-119e-fd09-bb138ff789de@erg.abdn.ac.uk> From: Fernando Gont Message-ID: Date: Wed, 2 Dec 2020 14:52:33 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <0c121812-44cf-119e-fd09-bb138ff789de@erg.abdn.ac.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-packet-drops-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 18:23:37 -0000 Hello, Gorry, Thanks a lot for your feedback! -- We really appreciate it! In-line... On 1/12/20 13:30, Gorry Fairhurst wrote: [...] > > * I have some concerns that some of the choices of words could > (unintentionally) be taken as endorsing a best practice, which I don't > think the IETF would generally promote. This is more about ensuring > specific parts can not be quoted out of context. I did a careful read > and hope I identified most of these and propose something that might be > helpful (please see attached PDF - RTF is identical). I think it would > be good to clarify in a few places this is the RFC8200 spec, since I > have heard there could be new work to update that. I don't mind doing that. However, isn't it implicit in all RFCs that they are referring to the current specifications (unless otherwise noted)? i.e., regardless of whether there is ongoing work, and whether one is aware about it, a spec refers to the IETF status at the time the spec is published (*). (*) Well, modulo RFC Ed processing times. In any case, IIRC, RFC8200 is the current state of affairs when it comes to EH processing, so I guess explicitly referencing RFC8200 wouldn't hurt. -- I'm CC'ing Brian, who may correct me if my "of the top o my head" assessment is not correct :-) > * On the measurement evidence: I have  a slight concern that the results > might not cover the wide variety of use cases and you may like to be > more careful in the words you use to generalise these for the > "internet".  I think we should be aware that in some scenarios an EH > might still be effectively used, where path can safely support this. We're targeting the general case here. As they say, "with sufficient thrust, pigs fly just fine". You can, of course, build a network where EHs can be used just fine. -- but what we're discussing is the general case. > In > some other uses, the fact that packets with these options might be > expected to be dropped by many paths - for good reasons, does not mean > that the option is useless to set in general - it might merely be that > for these paths it is not possible to use the option and then care is > needed in deciding which packets set the EH and how this is used. We certainly don't mean that. We mean "if you EHs, the chances of your packets being dropped increase, for the general case". As noted, you may employ them within environments where everything is under your control ("your network, your rules"), or, I guess, might try to use them and have a fall-back mechanism (ala TCP ECN during 3WHS). Some additional comments/questions based on the PDF you've attached: > However, common implementation limitations suggest > that EHs present a challenge for IPv6 packet routing equipment and > middle-boxes, and evidence exists that IPv6 packets with EHs have been Doesn't this imply that this is no longer the case? (i.e. your proposed change is "have been") > If an IPv6 header chain is sufficiently long that its header exceeds > the packet look-up capacity of the router, then it would be dropped by > hardware that is unable to determine how it should be handled. This seems rather confusing. It's the router that drops the packet. > 5.1. > Recirculation > Although TLV chains are amenable to iterative processing on > architectures that have packet look-up engines with deep inspection >>>> is this /that/ ? Not sure what you mean.... > As layer-4 port > information increases the entropy of the hash, it is normally highly > desirable to use it where possible. >>>> I don’t agree with that actually, - but maybe others think so, please check >>>> RFCs relating to ECMP or perhaps rephrase, something like: /Layer-4 port > information can increase the entropy of the hash, and is often > thought desirable to use it where it is available. > /? Your suggested change seems fine to me. That said, what would you employ for the hash if not the ports? > We note that in the IPv6 world, flows are expected to be identified > by means of the IPv6 Flow Label [RFC6437]. Thus, ECMP and Hash-based > Load-Sharing is possible without the need to process the entire >>>> why /would be possible/ ... some networks do this, and many RFCs encourage this? Support for the FL is not widely deployed and implemented (see [Cunha-2020]) >>>> > /also did not employ/ > do you really need to claim that? I suggest we could write this > in more neutral language, since some implementations recently > changed this practice? > Perhaps; > /When many IPv6 > implementations failed to set the Flow Label, many ECMP and Hash-based > Load-Sharing devices also did not include the Flow Label [Cunha-2020], > possibly as a result of issues that have been found > in host implementations and middle-boxes [Jaeggli-2018]./ > although it seems like The suggested change seems to imply that the situation has changed, but I believe it hasn't. [Cunha-2020] provides evidence in this respect. SO assuming that this is something from the past would be inaccurate. >>>> I suggest the section includes mention of the IETF recommendation, >>>> and there the path with “clearly...” should be at the end! Ok with moving the para "Clearly.." to the end. That said, could you elaborate on what IETF recommendation you're referring to? > Use of extension headers can result problematic for NIDS/IPS, since: >>>/may/can/ ... not necessary, but might as well use /can/ in this case? Doesn't "may" imply possibility here? > As a result, in order to increase the efficiency or effectiveness of > these systems, packets employing IPv6 extension headers can be >>>> /can/ or /have been/are being/ ... to follow the previous argument? > dropped at the network ingress point(s) of networks that deploy these > systems. (Must admit that since you're a native English speaker, I have a high probability of being wrong :-), but, anyway): Packets can be drop, whether with EHs or anything else (i.e., the contents of a packet does not affect the ability of a device dropping them -- at the end of the day, a device can drop *all* packets if it feels like). What we are meaning here is that dropping packets with EHs is indeed one option to increase the efficiency and effectiveness of these systems. We don't mean to "give permission" to operators, because, at the end of the day, they don't need to ask :-) (they don't, and they shouldn't, IMO!). That's why we use "may" -- it's an actual possible operational policy to deal with the problem at hand. > o Use of unknown extension headers can prevent an NIDS/IPS to > process layer-4 information I this case, I think both are fine: -- "can" as in ability, and "may" as in possibility > As a result, whether because of the challenges represented by > extension headers or because the use of IPv6 extension headers has > not been explicitly allowed, packets employing IPv6 extension headers > can be dropped by network firewalls. >>>> /can/ or /have been/are being/ ... to follow the previous argument? Same as before: I don't think you need reasons for an "ability". What we mean is that firewalls may (as in "possibility of intended behaviour") drop such packets. > When such devices are unable to obtain the > required information, they might simply resort to dropping the >>>> /may/might/ ? "might" reads as a possibly imaginary situation. What we are meaning is that some devices *do* this. > Some router implementations lack fine-grained filtering of IPv6 > extension headers. For example, an operator may want to drop packets > containing Routing Header Type 0 (RHT0) but may only be able to > filter on the extension header type (Routing Header). As a result, > the operator would end up enforcing a more coarse filtering policy > (e.g. "drop all packets containing a Routing Header" vs. "only drop > packets that contain a Routing Header Type 0"). The proposed change seems to change the meaning of the paragraph. i.e., these things *do* happen. > Additionally, implementation > inconsistencies in packet forwarding engines can result in evasion of > security controls [I-D.kampanakis-6man-ipv6-eh-parsing] [Atlasis2014] > [BH-EU-2014]. The original text said "...may result in evasion". It would seem to me that both are correct ("can" = ability, "may" = possibility)? Actually, the later implies the former? Same for this one: > Packets with attached IPv6 Extension Headers can impact performance > on routers that forward them. > [Gont-Chown-IEPG89] > Gont, F. and T. Chown, "A Small Update on the Use of IPv6 > Extension Headers", IEPG 89. London, UK. March 2, 2014, > eh-update.pdf>. > [Gont-IEPG88] > Gont, F., "Fragmentation and Extension header Support in > the IPv6 Internet", IEPG 88. Vancouver, BC, Canada. > November 13, 2013, fgont-iepg-ietf88-ipv6-frag-and-eh.pdf>. >>>> These don’t seem great presentations, and seem like they were >>>> mostly replaced by iepg-ietf90-ipv6-ehs-in-the-real-world-v2.0? >>>> I don’t know why these are useful as references? RC7872 also covers this? They are listed as they were part of the work that eventually resulted in RFC7872, and as an indication of for how long the problem has been looked into. At the time, we didn't even have tools to do the measurements. For example, the path6 tool I implemented, and the support in RIPE Atlas were triggered by these efforts. >>>> Is it worth also seeing whether Hendriks et al, http://dl.ifip.org/db/conf/tma/tma2017/tma2017_paper22.pdf >>>> contains useful insight instead of these two? I will read it. Thanks for the pointer! -- I wasn't aware about this paper. Thanks! Regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Dec 2 11:33:19 2020 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 136A03A1538; Wed, 2 Dec 2020 11:33:17 -0800 (PST) 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 RuIIv443X-wq; Wed, 2 Dec 2020 11:33:14 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 44A363A1536; Wed, 2 Dec 2020 11:33:13 -0800 (PST) Received: from Gs-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 1D0F51B00062; Wed, 2 Dec 2020 19:33:06 +0000 (GMT) To: Fernando Gont , v6ops@ietf.org Cc: fernando@gont.com.ar, Brian E Carpenter , draft-ietf-v6ops-ipv6-ehs-packet-drops.authors@ietf.org References: <0c121812-44cf-119e-fd09-bb138ff789de@erg.abdn.ac.uk> From: Gorry Fairhurst Message-ID: Date: Wed, 2 Dec 2020 19:33:05 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-packet-drops-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 19:33:17 -0000 On 02/12/2020 17:52, Fernando Gont wrote: > Hello, Gorry, > Hi! > Thanks a lot for your feedback! -- We really appreciate it! > > In-line... > > On 1/12/20 13:30, Gorry Fairhurst wrote: > [...] >> >> * I have some concerns that some of the choices of words could >> (unintentionally) be taken as endorsing a best practice, which I >> don't think the IETF would generally promote. This is more about >> ensuring specific parts can not be quoted out of context. I did a >> careful read and hope I identified most of these and propose >> something that might be helpful (please see attached PDF - RTF is >> identical). I think it would be good to clarify in a few places this >> is the RFC8200 spec, since I have heard there could be new work to >> update that. > > I don't mind doing that. However, isn't it implicit in all RFCs that > they are referring to the current specifications (unless otherwise > noted)? > > i.e., regardless of whether there is ongoing work, and whether one is > aware about it, a spec refers to the IETF status at the time the spec > is published (*). > > (*) Well, modulo RFC Ed processing times. > > > In any case, IIRC, RFC8200 is the current state of affairs when it > comes to EH processing, so I guess explicitly referencing RFC8200 > wouldn't hurt.  -- I'm CC'ing Brian, who may correct me if my "of the > top o my head" assessment is not correct :-) > The above is all true - and I think it is simple to add the REF! > >> * On the measurement evidence: I have  a slight concern that the >> results might not cover the wide variety of use cases and you may >> like to be more careful in the words you use to generalise these for >> the "internet".  I think we should be aware that in some scenarios an >> EH might still be effectively used, where path can safely support this. > > We're targeting the general case here. As they say, "with sufficient > thrust, pigs fly just fine". You can, of course, build a network where > EHs can be used just fine. -- but what we're discussing is the general > case. > Why? - as a transport guy, the only thing that matters is whether a specific path supports them, the average case just tells me whether I need a fallback mechanism to cope with a particular path not supporting;-) > >> In some other uses, the fact that packets with these options might be >> expected to be dropped by many paths - for good reasons, does not >> mean that the option is useless to set in general - it might merely >> be that for these paths it is not possible to use the option and then >> care is needed in deciding which packets set the EH and how this is >> used. > > We certainly don't mean that. We mean "if you EHs, the chances of your > packets being dropped increase, for the general case". Yes, the chance that you encounter a path the drops packets with EHs. > As noted, you may employ them within environments where everything is > under your control ("your network, your rules"), or, I guess, might > try to use them and have a fall-back mechanism (ala TCP ECN during 3WHS). > > > > Some additional comments/questions based on the PDF you've attached: > >> However, common implementation limitations suggest >> that EHs present a challenge for IPv6 packet routing equipment and >> middle-boxes, and evidence exists that IPv6 packets with EHs have been > > Doesn't this imply that this is no longer the case? (i.e. your > proposed change is "have been") > > /have been/are/ ... if that makes better sense to you, they're equivalent to me - you observe what has happens and you can predict what is happening, you might now know the future. >> If an IPv6 header chain is sufficiently long that its header exceeds >> the packet look-up capacity of the router, then it would be dropped by >> hardware that is unable to determine how it should be handled. > > This seems rather confusing. It's the router that drops the packet. > /hardware/router hardware/ >> 5.1. >> Recirculation >> Although TLV chains are amenable to iterative processing on >> architectures that have packet look-up engines with deep inspection >>>>> is this /that/ ? > > Not sure what you mean.... > I was suggesting using that in place of /which/... minor nit. > >> As layer-4 port >> information increases the entropy of the hash, it is normally highly >> desirable to use it where possible. >>>>> I don’t agree with that actually, - but maybe others think so, >>>>> please check >>>>> RFCs relating to ECMP or perhaps rephrase, something like: >>>>> /Layer-4 port >> information can increase the entropy of the hash, and is often >> thought desirable to use it where it is available. >> /? > > Your suggested change seems fine to me. That said, what would you > employ for the hash if not the ports? > flow label? > >> We note that in the IPv6 world, flows are expected to be identified >> by means of the IPv6 Flow Label [RFC6437]. Thus, ECMP and Hash-based >> Load-Sharing is possible without the need to process the entire >>>>> why /would be possible/ ... some networks do this, and many RFCs >>>>> encourage this? > > Support for the FL is not widely deployed and implemented (see > [Cunha-2020]) > Yes I looked at Cunha - it's just a slide deck - is there a paper that can be read to check the measurement methodology and results? I hear others saying that it is now more often being set, ... so I'm just urging caution here, because I am not sure v6OPS need to comment on the results of this on-going work at this stage. For instance... what is the chance that a router now observes a flow label set to non-zero? ... > >>>>> >> /also did not employ/ >> do you really need to claim that? I suggest we could write this >> in more neutral language, since some implementations recently >> changed this practice? >> Perhaps; >> /When many IPv6 >> implementations failed to set the Flow Label, many ECMP and Hash-based >> Load-Sharing devices also did not include the Flow Label [Cunha-2020], >> possibly as a result of issues that have been found >> in host implementations and middle-boxes [Jaeggli-2018]./ >> although it seems like > > The suggested change seems to imply that the situation has changed, > but I believe it hasn't. [Cunha-2020] provides evidence in this > respect. SO assuming that this is something from the past would be > inaccurate. > Well.... we can debate this, if we need to, however:  - i.e., I think the existence of techniques that utilise ports is sufficient to justify why the router wishes to traverse the header chain, and why extension headers are problematic - that does not need to present anything about what is good practice for ECMP without predjudice to deployment of FL-based methods. >>>>> I suggest the section includes mention of the IETF recommendation, >>>>> and there the path with “clearly...” should be at the end! > > Ok with moving the para "Clearly.." to the end. That said, could you > elaborate on what IETF recommendation you're referring to? > > > >> Use of extension headers can result problematic for NIDS/IPS, since: >>>> /may/can/ ... not necessary, but might as well use /can/ in this case? > > Doesn't "may" imply possibility here? > No. In many reader's eyes this is permissive ... do it would read are permitted to. > >> As a result, in order to increase the efficiency or effectiveness of >> these systems, packets employing IPv6 extension headers can be >>>>> /can/ or /have been/are being/ ... to follow the previous argument? >> dropped at the network ingress point(s) of networks that deploy these >> systems. > > (Must admit that since you're a native English speaker, I have a high > probability of being wrong :-), but, anyway): > > Packets can be drop, whether with EHs or anything else (i.e., the > contents of a packet does not affect the ability of a device dropping > them -- at the end of the day, a device can drop *all* packets if it > feels like). > :-) > What we are meaning here is that dropping packets with EHs is indeed > one option to increase the efficiency and effectiveness of these systems. That sounds correct. > We don't mean to "give permission" to operators, because, at the end > of the day, they don't need to ask :-)  (they don't, and they > shouldn't, IMO!).  That's why we use "may" -- it's an actual possible > operational policy to deal with the problem at hand. > > >> o Use of unknown extension headers can prevent an NIDS/IPS to >> process layer-4 information > > I this case, I think both are fine: -- "can" as in ability, and "may" > as in possibility > - but not may as in "are permitted to"... > > >> As a result, whether because of the challenges represented by >> extension headers or because the use of IPv6 extension headers has >> not been explicitly allowed, packets employing IPv6 extension headers >> can be dropped by network firewalls. >>>>> /can/ or /have been/are being/ ... to follow the previous argument? > > Same as before: I don't think you need reasons for an "ability". What > we mean is that firewalls may (as in "possibility of intended > behaviour") drop such packets. > > >> When such devices are unable to obtain the >> required information, they might simply resort to dropping the >>>>> /may/might/ ? > > "might" reads as a possibly imaginary situation. What we are meaning > is that some devices *do* this. > OK : then say that devices do this,... rather than they are permitted to. > >> Some router implementations lack fine-grained filtering of IPv6 >> extension headers. For example, an operator may want to drop packets >> containing Routing Header Type 0 (RHT0) but may only be able to >> filter on the extension header type (Routing Header). As a result, >> the operator would end up enforcing a more coarse filtering policy >> (e.g. "drop all packets containing a Routing Header" vs. "only drop >> packets that contain a Routing Header Type 0"). > > The proposed change seems to change the meaning of the paragraph. > i.e., these things *do* happen. > How about something like: Some router implementations do not have fine-grained filtering of IPv6 extension headers. For example, an operator that wishes to drop packets containing Routing Header Type 0 (RHT0), may only be able to filter on the extension header type (Routing Header). This would result in an operator  enforcing a more coarse filtering policy (e.g. "drop all packets containing a Routing Header" vs. "only drop packets that contain a Routing Header Type 0"). ??? > > >>  Additionally, implementation >>    inconsistencies in packet forwarding engines can result in evasion of >>    security controls [I-D.kampanakis-6man-ipv6-eh-parsing] [Atlasis2014] >>    [BH-EU-2014]. > > The original text said "...may result in evasion". It would seem to me > that both are correct ("can" = ability, "may" = possibility)?  > Actually, the later implies the former? > > /can/will/ or whatever or just /result in/ ? > Same for this one: > >> Packets with attached IPv6 Extension Headers can impact performance >> on routers that forward them. > Except in this case, I think the performance of some designs of router are impacted when forwarding packets with IPv6 EH. > > >> [Gont-Chown-IEPG89] >> Gont, F. and T. Chown, "A Small Update on the Use of IPv6 >> Extension Headers", IEPG 89. London, UK. March 2, 2014, >> > eh-update.pdf>. >> [Gont-IEPG88] >> Gont, F., "Fragmentation and Extension header Support in >> the IPv6 Internet", IEPG 88. Vancouver, BC, Canada. >> November 13, 2013, > fgont-iepg-ietf88-ipv6-frag-and-eh.pdf>. >>>>> These don’t seem great presentations, and seem like they were >>>>> mostly replaced by iepg-ietf90-ipv6-ehs-in-the-real-world-v2.0? >>>>> I don’t know why these are useful as references? RC7872 also >>>>> covers this? > > They are listed as they were part of the work that eventually resulted > in RFC7872, and as an indication of for how long the problem has been > looked into. At the time, we didn't even have tools to do the > measurements. For example, the path6 tool I implemented, and the > support in RIPE Atlas were triggered by these efforts. I don't agree with that. They are actually cited in RFC7872 if taht is your reason, so that is already clear! >>>>> Is it worth also seeing whether Hendriks et al, >>>>> http://dl.ifip.org/db/conf/tma/tma2017/tma2017_paper22.pdf >>>>> contains useful insight instead of these two? > > I will read it. Thanks for the pointer! -- I wasn't aware about this > paper. > > Thanks! > > Regards, -- G. Fairhurst, School of Engineering Gorry From nobody Wed Dec 2 12:07:01 2020 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 928403A1476 for ; Wed, 2 Dec 2020 12:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=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 AJjhwET1an6t for ; Wed, 2 Dec 2020 12:06:56 -0800 (PST) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 EAB6D3A1544 for ; Wed, 2 Dec 2020 12:06:55 -0800 (PST) Received: by mail-ej1-x636.google.com with SMTP id jx16so6254221ejb.10 for ; Wed, 02 Dec 2020 12:06:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=pV5rQUXwOrtuUPU2Gj2ylM5U7U9IA7wnIWjg4vLe+GM=; b=iGuLm7DNboJKCntjZBgCMAt6k6wiNzypdYItZ6hbG4lrXmUS/t8JgkbKdEPYQ0ff9C /M1q0lNcF7Bc9IyQyB0+fZsXcRJcZdjABI5tCLOsxYyyPclsjKaseHXkZlvLEN7Lsy1Q zCk4KTvbTzf+agBkvQ6v9WN56rvObU0Yhq8aYcopV8AWo7mgJAcIwlFg2hEllI0qPdx1 vYsL+HRd6gtQSlEphuHO9WKrUZIcrs2w9oS4fquthoBfgqyI7IEwM2Py3LkBJJUq1FbL 8X33e8t8tpAJdgQzswGsJeBbln+9uRuUseneYxVMPKsAQVCjXU4lOrzIfU9+U5HxRl1w f+UQ== 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=pV5rQUXwOrtuUPU2Gj2ylM5U7U9IA7wnIWjg4vLe+GM=; b=KXnqj6aqRp8Wm+CrLR0zbMkGCGhdKgswTQbt1+mmbcA8S0DaSePfqUp83OkeX1tblr jAV3Mbr1tR6nNNi5nv5V0wFkrrkRDxfMLnhIurIz6pGQ5OaD4tZaa3kfk3/9Ib+15wnD pJM+KkTMN5qVMbooW4I4lgkKpU5XNoRMxFv1EP/Sb1mukp7eXxBQ5cpUk2uMiep1vMAr A2jrxSoGGawWVo0xvsQO0Fz8ODwjdYVZqfzNSQN0PqWiYZ7aCb8uCGXAQu9ygYEGWTGW YVpZm7T3JGzDrmKou/Q8G4urUYS8XQkHXYj32NvUVyffy/vooEFokR+tnAgfLxxIlBnG aJAQ== X-Gm-Message-State: AOAM533QkjWZu5KZDnjIEK1IwJC58FHOU/qsUPTG05qpVVKRPvS1Z5nH xqoL6nQVtK43sJL8FSfPRn+/tqr+M1K4q56uusuA9w== X-Google-Smtp-Source: ABdhPJz0i3jt0E9YRfF+zIDFJIadPOB4DrZLclzv7QVF88zKF4KHeAy6j7uZdEZfkMKUxu+L3Q7CpLthJ8lUrzLRRBY= X-Received: by 2002:a17:906:f153:: with SMTP id gw19mr1470059ejb.272.1606939613450; Wed, 02 Dec 2020 12:06:53 -0800 (PST) MIME-Version: 1.0 References: <0c121812-44cf-119e-fd09-bb138ff789de@erg.abdn.ac.uk> In-Reply-To: From: Tom Herbert Date: Wed, 2 Dec 2020 13:06:42 -0700 Message-ID: To: Fernando Gont Cc: Gorry Fairhurst , IPv6 Operations , draft-ietf-v6ops-ipv6-ehs-packet-drops.authors@ietf.org, Fernando Gont Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-packet-drops-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 20:07:00 -0000 On Wed, Dec 2, 2020 at 11:48 AM Fernando Gont wrote= : > > Hello, Gorry, > > Thanks a lot for your feedback! -- We really appreciate it! > > In-line... > > On 1/12/20 13:30, Gorry Fairhurst wrote: > [...] > > > > * I have some concerns that some of the choices of words could > > (unintentionally) be taken as endorsing a best practice, which I don't > > think the IETF would generally promote. This is more about ensuring > > specific parts can not be quoted out of context. I did a careful read > > and hope I identified most of these and propose something that might be > > helpful (please see attached PDF - RTF is identical). I think it would > > be good to clarify in a few places this is the RFC8200 spec, since I > > have heard there could be new work to update that. > > I don't mind doing that. However, isn't it implicit in all RFCs that > they are referring to the current specifications (unless otherwise noted)= ? > > i.e., regardless of whether there is ongoing work, and whether one is > aware about it, a spec refers to the IETF status at the time the spec is > published (*). > > (*) Well, modulo RFC Ed processing times. > > > In any case, IIRC, RFC8200 is the current state of affairs when it comes > to EH processing, so I guess explicitly referencing RFC8200 wouldn't > hurt. -- I'm CC'ing Brian, who may correct me if my "of the top o my > head" assessment is not correct :-) > > > > > > * On the measurement evidence: I have a slight concern that the result= s > > might not cover the wide variety of use cases and you may like to be > > more careful in the words you use to generalise these for the > > "internet". I think we should be aware that in some scenarios an EH > > might still be effectively used, where path can safely support this. > > We're targeting the general case here. As they say, "with sufficient > thrust, pigs fly just fine". You can, of course, build a network where > EHs can be used just fine. -- but what we're discussing is the general ca= se. > > > > > In > > some other uses, the fact that packets with these options might be > > expected to be dropped by many paths - for good reasons, does not mean > > that the option is useless to set in general - it might merely be that > > for these paths it is not possible to use the option and then care is > > needed in deciding which packets set the EH and how this is used. > > We certainly don't mean that. We mean "if you EHs, the chances of your > packets being dropped increase, for the general case". Fernando, That's true of a lot protocols. If you use fragmentation, any protocol other than TCP or UDP, encryption, encapsulation, or even IPv6 your chances of packets being dropped increase in the general case. In fact many of the reason noted in this draft for drops are the same those other cases. So it's generally true that any deviation from a narrow set of protocols and options that are known to be commonly supported by routers risks increased chance of packet drop. I view this draft is another case of trying to document and explain the status quo for how routers and middleboxes implement the protocol (we saw the similar discussion in RFC8900 and draft-ietf-tsvwg-transport-encrypt-18). Documenting current real world behavior is good, however it needs to been in context (similar to concerns raised for other like drafts): 1) Some of the behaviors being documented are either contrary with the Internet architecture or downright non-conformant with the standards. IMO this needs to be clarified and called when discussing some particualar mechanism a vendor has chosen to implement. This may be describing current practice, but as Gorry this in no way should be construed as IETF best practice 2) We need to realize there are potentially conflicting rrequirements. For instance, in this draft there is a statement "contemporary routers and middle-boxes that need to find the layer-4 header must process the entire IPv6 extension header chain.". I do not believe there is any core IETF standard that requires routers to access the transport layer, that's more a design choice vendors have made. In fact, from a host perspective, we are trying to obsolete that by encrypting transport headers like in QUIC for instance (there are both security and protocol evolution motivations for doing that). 3) We need to very careful about making conclusions or even those that are inferred by the reader. It should be very clear that this documenting is not advocating obsoleting extension headers nor that arbitrary dropping of packets with extension headers is acceptable. 4) It would be nice to have some guidance on a way forward. Assuming that the consensus is that extension headers are still useful, what can we do to increase their viablitiy? We already have a couple of examples of this: RFC8200 relaxed the requirements that all nodes must process HBH EH, RFC8883 describes ICMP errors to send when an intermeidate does drop a packet with EH. 5) Specific to this draft, almost all the references are at least five years old. For instance, RFC7872 which is considered the reference for measurement of EH drops on the Internet dates back to 2016. So these aren't really fresh and in the case of RFC7872 that was publsihed before RFC8200 so it doesn't reflect the impact of the updated EH related requirements in RFC8200. More recent data and analysis would strengthen the discussion. Tom > As noted, you may > employ them within environments where everything is under your control > ("your network, your rules"), or, I guess, might try to use them and > have a fall-back mechanism (ala TCP ECN during 3WHS). > > > > Some additional comments/questions based on the PDF you've attached: > > > However, common implementation limitations suggest > > that EHs present a challenge for IPv6 packet routing equipment and > > middle-boxes, and evidence exists that IPv6 packets with EHs have been > > Doesn't this imply that this is no longer the case? (i.e. your proposed > change is "have been") > > > > > If an IPv6 header chain is sufficiently long that its header exceeds > > the packet look-up capacity of the router, then it would be dropped by > > hardware that is unable to determine how it should be handled. > > This seems rather confusing. It's the router that drops the packet. > > > > > > 5.1. > > Recirculation > > Although TLV chains are amenable to iterative processing on > > architectures that have packet look-up engines with deep inspection > >>>> is this /that/ ? > > Not sure what you mean.... > > > > As layer-4 port > > information increases the entropy of the hash, it is normally highly > > desirable to use it where possible. > >>>> I don=E2=80=99t agree with that actually, - but maybe others think s= o, please check > >>>> RFCs relating to ECMP or perhaps rephrase, something like: /Layer-4 = port > > information can increase the entropy of the hash, and is often > > thought desirable to use it where it is available. > > /? > > Your suggested change seems fine to me. That said, what would you employ > for the hash if not the ports? > > > > We note that in the IPv6 world, flows are expected to be identified > > by means of the IPv6 Flow Label [RFC6437]. Thus, ECMP and Hash-based > > Load-Sharing is possible without the need to process the entire > >>>> why /would be possible/ ... some networks do this, and many RFCs enc= ourage this? > > Support for the FL is not widely deployed and implemented (see [Cunha-202= 0]) > > > > >>>> > > /also did not employ/ > > do you really need to claim that? I suggest we could write this > > in more neutral language, since some implementations recently > > changed this practice? > > Perhaps; > > /When many IPv6 > > implementations failed to set the Flow Label, many ECMP and Hash-based > > Load-Sharing devices also did not include the Flow Label [Cunha-2020], > > possibly as a result of issues that have been found > > in host implementations and middle-boxes [Jaeggli-2018]./ > > although it seems like > > The suggested change seems to imply that the situation has changed, but > I believe it hasn't. [Cunha-2020] provides evidence in this respect. SO > assuming that this is something from the past would be inaccurate. > > > > >>>> I suggest the section includes mention of the IETF recommendation, > >>>> and there the path with =E2=80=9Cclearly...=E2=80=9D should be at th= e end! > > Ok with moving the para "Clearly.." to the end. That said, could you > elaborate on what IETF recommendation you're referring to? > > > > > Use of extension headers can result problematic for NIDS/IPS, since: > >>>/may/can/ ... not necessary, but might as well use /can/ in this case? > > Doesn't "may" imply possibility here? > > > > As a result, in order to increase the efficiency or effectiveness of > > these systems, packets employing IPv6 extension headers can be > >>>> /can/ or /have been/are being/ ... to follow the previous argument? > > dropped at the network ingress point(s) of networks that deploy these > > systems. > > (Must admit that since you're a native English speaker, I have a high > probability of being wrong :-), but, anyway): > > Packets can be drop, whether with EHs or anything else (i.e., the > contents of a packet does not affect the ability of a device dropping > them -- at the end of the day, a device can drop *all* packets if it > feels like). > > What we are meaning here is that dropping packets with EHs is indeed one > option to increase the efficiency and effectiveness of these systems. > We don't mean to "give permission" to operators, because, at the end of > the day, they don't need to ask :-) (they don't, and they shouldn't, > IMO!). That's why we use "may" -- it's an actual possible operational > policy to deal with the problem at hand. > > > > o Use of unknown extension headers can prevent an NIDS/IPS to > > process layer-4 information > > I this case, I think both are fine: -- "can" as in ability, and "may" as > in possibility > > > > > As a result, whether because of the challenges represented by > > extension headers or because the use of IPv6 extension headers has > > not been explicitly allowed, packets employing IPv6 extension headers > > can be dropped by network firewalls. > >>>> /can/ or /have been/are being/ ... to follow the previous argument? > > Same as before: I don't think you need reasons for an "ability". What we > mean is that firewalls may (as in "possibility of intended behaviour") > drop such packets. > > > > When such devices are unable to obtain the > > required information, they might simply resort to dropping the > >>>> /may/might/ ? > > "might" reads as a possibly imaginary situation. What we are meaning is > that some devices *do* this. > > > > Some router implementations lack fine-grained filtering of IPv6 > > extension headers. For example, an operator may want to drop packets > > containing Routing Header Type 0 (RHT0) but may only be able to > > filter on the extension header type (Routing Header). As a result, > > the operator would end up enforcing a more coarse filtering policy > > (e.g. "drop all packets containing a Routing Header" vs. "only drop > > packets that contain a Routing Header Type 0"). > > The proposed change seems to change the meaning of the paragraph. i.e., > these things *do* happen. > > > > > Additionally, implementation > > inconsistencies in packet forwarding engines can result in evasion o= f > > security controls [I-D.kampanakis-6man-ipv6-eh-parsing] [Atlasis2014= ] > > [BH-EU-2014]. > > The original text said "...may result in evasion". It would seem to me > that both are correct ("can" =3D ability, "may" =3D possibility)? Actual= ly, > the later implies the former? > > > Same for this one: > > > Packets with attached IPv6 Extension Headers can impact performance > > on routers that forward them. > > > > > [Gont-Chown-IEPG89] > > Gont, F. and T. Chown, "A Small Update on the Use of IPv6 > > Extension Headers", IEPG 89. London, UK. March 2, 2014, > > > eh-update.pdf>. > > [Gont-IEPG88] > > Gont, F., "Fragmentation and Extension header Support in > > the IPv6 Internet", IEPG 88. Vancouver, BC, Canada. > > November 13, 2013, > fgont-iepg-ietf88-ipv6-frag-and-eh.pdf>. > >>>> These don=E2=80=99t seem great presentations, and seem like they wer= e > >>>> mostly replaced by iepg-ietf90-ipv6-ehs-in-the-real-world-v2.0? > >>>> I don=E2=80=99t know why these are useful as references? RC7872 also= covers this? > > They are listed as they were part of the work that eventually resulted > in RFC7872, and as an indication of for how long the problem has been > looked into. At the time, we didn't even have tools to do the > measurements. For example, the path6 tool I implemented, and the support > in RIPE Atlas were triggered by these efforts. > > > >>>> Is it worth also seeing whether Hendriks et al, http://dl.ifip.org/d= b/conf/tma/tma2017/tma2017_paper22.pdf > >>>> contains useful insight instead of these two? > > I will read it. Thanks for the pointer! -- I wasn't aware about this pape= r. > > Thanks! > > Regards, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Dec 2 15:04:44 2020 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 1EC9D3A15C7; Wed, 2 Dec 2020 15:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=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=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 1Hm7LJDFU3Vp; Wed, 2 Dec 2020 15:04:41 -0800 (PST) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (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 D9DF33A15BC; Wed, 2 Dec 2020 15:04:40 -0800 (PST) Received: by mail-pj1-x1036.google.com with SMTP id j13so20977pjz.3; Wed, 02 Dec 2020 15:04:40 -0800 (PST) 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=O7pjGyN9bxW6+cJjaIok0+VDVMvS1/ESAqZCwpI9Ufc=; b=sF3U9ZGPWSy54KP2a8F+cUllPhm/b0zeuQHgMoEUzpOm4Hsz2WQ9WmjVbgIj0LPJYq k0XWMiQ5+H0I11BUGD9NtpyNiCNT95GIZiKHncur6QbUXsaGvv9VRRuCivjZ690qnLIg 4tFKJANXzPNNBvH0v9zPEUavXgygO0LnLZpxnQJGnN6ZKLFDiLerkzWkWu1rQx9e30F+ iR8B4TrmaT+DUbygvL1ct4uLbNeRmYZONjCPEmVQWIHKMIQ4/7WBv7AYYyylsAF4LmUN NOPHBwMmUDq5ygYHMYbSPnyJsPDqKmc7SBr5TgO2Pp/jcRuDFusMgOSQjkfoTNpospG0 Uc2w== 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=O7pjGyN9bxW6+cJjaIok0+VDVMvS1/ESAqZCwpI9Ufc=; b=nMZy4ikInanws997LemUD8Edk9Rgyb5/tsNFqng5BcrAy3OzzFVbDGIwIMklGruRMu qmpcDAMISKSNQ7BfZayypet3ASO0F572ugZ+BI/LZiP8RmDq/t1PBHa/oRM255cdzoN3 qRyg0lpopk27NP8fh8TtOLvKDw//Vq6ykV2riGhJrmnq3qiMqnBhkyKm1w0zlasqdxgy 7EVIKem5GLr4zNH+jC2C6JFcH26kPCSZdcL7QMunpHMKs5cT1Mrxaypsxud72ExM3CEp KHf6BIHxHseTw9OOhyTzhQEXjApawva/PaIQOpZVfq50z0/YP+ZQQSf1LsFVlurh7wGr LuaQ== X-Gm-Message-State: AOAM533Uo80qeAOzpySqJo/4NUmzRnmtE4eroWwfhxMzVbfh0ZjRlozo LHY8htbc1Pd2OxqQGFHyl4XpWcT5g2okQw== X-Google-Smtp-Source: ABdhPJxycl71aOwITimofVzAb2gOhZ5CjhwCLLRly6m+cVlGe5KpFD3wNEd1PfeJR/zQ4LHt0gOPKQ== X-Received: by 2002:a17:90b:243:: with SMTP id fz3mr214861pjb.41.1606950279561; Wed, 02 Dec 2020 15:04:39 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id q5sm13557pjg.4.2020.12.02.15.04.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Dec 2020 15:04:38 -0800 (PST) To: Fernando Gont , Gorry Fairhurst , v6ops@ietf.org Cc: fernando@gont.com.ar, draft-ietf-v6ops-ipv6-ehs-packet-drops.authors@ietf.org References: <0c121812-44cf-119e-fd09-bb138ff789de@erg.abdn.ac.uk> From: Brian E Carpenter Message-ID: <25389c41-2f2a-19a3-5106-f64a8d81cdd3@gmail.com> Date: Thu, 3 Dec 2020 12:04:34 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-packet-drops-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Dec 2020 23:04:43 -0000 On 03-Dec-20 06:52, Fernando Gont wrote: > Hello, Gorry, >=20 > Thanks a lot for your feedback! -- We really appreciate it! >=20 > In-line... >=20 > On 1/12/20 13:30, Gorry Fairhurst wrote: > [...] >> >> * I have some concerns that some of the choices of words could=20 >> (unintentionally) be taken as endorsing a best practice, which I don't= =20 >> think the IETF would generally promote. This is more about ensuring=20 >> specific parts can not be quoted out of context. I did a careful read = >> and hope I identified most of these and propose something that might b= e=20 >> helpful (please see attached PDF - RTF is identical). I think it would= =20 >> be good to clarify in a few places this is the RFC8200 spec, since I=20 >> have heard there could be new work to update that. >=20 > I don't mind doing that. However, isn't it implicit in all RFCs that=20 > they are referring to the current specifications (unless otherwise note= d)? >=20 > i.e., regardless of whether there is ongoing work, and whether one is=20 > aware about it, a spec refers to the IETF status at the time the spec i= s=20 > published (*). >=20 > (*) Well, modulo RFC Ed processing times. >=20 >=20 > In any case, IIRC, RFC8200 is the current state of affairs when it come= s=20 > to EH processing, so I guess explicitly referencing RFC8200 wouldn't=20 > hurt. -- I'm CC'ing Brian, who may correct me if my "of the top o my=20 > head" assessment is not correct :-) Yes, although 8200 does give a polite nod to 7045 and does *not* obsolete it. Brian >=20 >=20 >=20 >=20 >> * On the measurement evidence: I have=C2=A0 a slight concern that the = results=20 >> might not cover the wide variety of use cases and you may like to be=20 >> more careful in the words you use to generalise these for the=20 >> "internet".=C2=A0 I think we should be aware that in some scenarios an= EH=20 >> might still be effectively used, where path can safely support this. >=20 > We're targeting the general case here. As they say, "with sufficient=20 > thrust, pigs fly just fine". You can, of course, build a network where = > EHs can be used just fine. -- but what we're discussing is the general = case. >=20 >=20 >=20 >> In=20 >> some other uses, the fact that packets with these options might be=20 >> expected to be dropped by many paths - for good reasons, does not mean= =20 >> that the option is useless to set in general - it might merely be that= =20 >> for these paths it is not possible to use the option and then care is = >> needed in deciding which packets set the EH and how this is used. >=20 > We certainly don't mean that. We mean "if you EHs, the chances of your = > packets being dropped increase, for the general case". As noted, you ma= y=20 > employ them within environments where everything is under your control = > ("your network, your rules"), or, I guess, might try to use them and=20 > have a fall-back mechanism (ala TCP ECN during 3WHS). >=20 >=20 >=20 > Some additional comments/questions based on the PDF you've attached: >=20 >> However, common implementation limitations suggest >> that EHs present a challenge for IPv6 packet routing equipment and >> middle-boxes, and evidence exists that IPv6 packets with EHs have been= >=20 > Doesn't this imply that this is no longer the case? (i.e. your proposed= =20 > change is "have been") >=20 >=20 >=20 >> If an IPv6 header chain is sufficiently long that its header exceeds >> the packet look-up capacity of the router, then it would be dropped by= >> hardware that is unable to determine how it should be handled. >=20 > This seems rather confusing. It's the router that drops the packet. >=20 >=20 >=20 >=20 >> 5.1. >> Recirculation >> Although TLV chains are amenable to iterative processing on >> architectures that have packet look-up engines with deep inspection >>>>> is this /that/ ? >=20 > Not sure what you mean.... >=20 >=20 >> As layer-4 port >> information increases the entropy of the hash, it is normally highly >> desirable to use it where possible. >>>>> I don=E2=80=99t agree with that actually, - but maybe others think = so, please check >>>>> RFCs relating to ECMP or perhaps rephrase, something like: /Layer-4= port >> information can increase the entropy of the hash, and is often >> thought desirable to use it where it is available. >> /? >=20 > Your suggested change seems fine to me. That said, what would you emplo= y=20 > for the hash if not the ports? >=20 >=20 >> We note that in the IPv6 world, flows are expected to be identified >> by means of the IPv6 Flow Label [RFC6437]. Thus, ECMP and Hash-based >> Load-Sharing is possible without the need to process the entire >>>>> why /would be possible/ ... some networks do this, and many RFCs en= courage this? >=20 > Support for the FL is not widely deployed and implemented (see [Cunha-2= 020]) >=20 >=20 >=20 >>>>> >> /also did not employ/ >> do you really need to claim that? I suggest we could write this >> in more neutral language, since some implementations recently >> changed this practice? >> Perhaps; >> /When many IPv6 >> implementations failed to set the Flow Label, many ECMP and Hash-based= >> Load-Sharing devices also did not include the Flow Label [Cunha-2020],= >> possibly as a result of issues that have been found >> in host implementations and middle-boxes [Jaeggli-2018]./ >> although it seems like >=20 > The suggested change seems to imply that the situation has changed, but= =20 > I believe it hasn't. [Cunha-2020] provides evidence in this respect. SO= =20 > assuming that this is something from the past would be inaccurate. >=20 >=20 >=20 >>>>> I suggest the section includes mention of the IETF recommendation, >>>>> and there the path with =E2=80=9Cclearly...=E2=80=9D should be at t= he end! >=20 > Ok with moving the para "Clearly.." to the end. That said, could you=20 > elaborate on what IETF recommendation you're referring to? >=20 >=20 >=20 >> Use of extension headers can result problematic for NIDS/IPS, since: >>>> /may/can/ ... not necessary, but might as well use /can/ in this cas= e? >=20 > Doesn't "may" imply possibility here? >=20 >=20 >> As a result, in order to increase the efficiency or effectiveness of >> these systems, packets employing IPv6 extension headers can be >>>>> /can/ or /have been/are being/ ... to follow the previous argument?= >> dropped at the network ingress point(s) of networks that deploy these >> systems. >=20 > (Must admit that since you're a native English speaker, I have a high=20 > probability of being wrong :-), but, anyway): >=20 > Packets can be drop, whether with EHs or anything else (i.e., the=20 > contents of a packet does not affect the ability of a device dropping=20 > them -- at the end of the day, a device can drop *all* packets if it=20 > feels like). >=20 > What we are meaning here is that dropping packets with EHs is indeed on= e=20 > option to increase the efficiency and effectiveness of these systems. > We don't mean to "give permission" to operators, because, at the end of= =20 > the day, they don't need to ask :-) (they don't, and they shouldn't,=20 > IMO!). That's why we use "may" -- it's an actual possible operational = > policy to deal with the problem at hand. >=20 >=20 >> o Use of unknown extension headers can prevent an NIDS/IPS to >> process layer-4 information >=20 > I this case, I think both are fine: -- "can" as in ability, and "may" a= s=20 > in possibility >=20 >=20 >=20 >> As a result, whether because of the challenges represented by >> extension headers or because the use of IPv6 extension headers has >> not been explicitly allowed, packets employing IPv6 extension headers >> can be dropped by network firewalls. >>>>> /can/ or /have been/are being/ ... to follow the previous argument?= >=20 > Same as before: I don't think you need reasons for an "ability". What w= e=20 > mean is that firewalls may (as in "possibility of intended behaviour") = > drop such packets. >=20 >=20 >> When such devices are unable to obtain the >> required information, they might simply resort to dropping the >>>>> /may/might/ ? >=20 > "might" reads as a possibly imaginary situation. What we are meaning is= =20 > that some devices *do* this. >=20 >=20 >> Some router implementations lack fine-grained filtering of IPv6 >> extension headers. For example, an operator may want to drop packets >> containing Routing Header Type 0 (RHT0) but may only be able to >> filter on the extension header type (Routing Header). As a result, >> the operator would end up enforcing a more coarse filtering policy >> (e.g. "drop all packets containing a Routing Header" vs. "only drop >> packets that contain a Routing Header Type 0"). >=20 > The proposed change seems to change the meaning of the paragraph. i.e.,= =20 > these things *do* happen. >=20 >=20 >=20 >> Additionally, implementation >> inconsistencies in packet forwarding engines can result in evasion = of >> security controls [I-D.kampanakis-6man-ipv6-eh-parsing] [Atlasis201= 4] >> [BH-EU-2014]. >=20 > The original text said "...may result in evasion". It would seem to me = > that both are correct ("can" =3D ability, "may" =3D possibility)? Actu= ally,=20 > the later implies the former? >=20 >=20 > Same for this one: >=20 >> Packets with attached IPv6 Extension Headers can impact performance >> on routers that forward them. >=20 >=20 >=20 >> [Gont-Chown-IEPG89] >> Gont, F. and T. Chown, "A Small Update on the Use of IPv6 >> Extension Headers", IEPG 89. London, UK. March 2, 2014, >> > eh-update.pdf>. >> [Gont-IEPG88] >> Gont, F., "Fragmentation and Extension header Support in >> the IPv6 Internet", IEPG 88. Vancouver, BC, Canada. >> November 13, 2013, > fgont-iepg-ietf88-ipv6-frag-and-eh.pdf>. >>>>> These don=E2=80=99t seem great presentations, and seem like they we= re >>>>> mostly replaced by iepg-ietf90-ipv6-ehs-in-the-real-world-v2.0? >>>>> I don=E2=80=99t know why these are useful as references? RC7872 als= o covers this? >=20 > They are listed as they were part of the work that eventually resulted = > in RFC7872, and as an indication of for how long the problem has been=20 > looked into. At the time, we didn't even have tools to do the=20 > measurements. For example, the path6 tool I implemented, and the suppor= t=20 > in RIPE Atlas were triggered by these efforts. >=20 >=20 >>>>> Is it worth also seeing whether Hendriks et al, http://dl.ifip.org/= db/conf/tma/tma2017/tma2017_paper22.pdf >>>>> contains useful insight instead of these two? >=20 > I will read it. Thanks for the pointer! -- I wasn't aware about this pa= per. >=20 > Thanks! >=20 > Regards, >=20 From nobody Wed Dec 2 16:38:10 2020 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 1A01B3A02BB; Wed, 2 Dec 2020 16:38:09 -0800 (PST) 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 bWubQfGeA-jk; Wed, 2 Dec 2020 16:38:05 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD5833A00F7; Wed, 2 Dec 2020 16:38:03 -0800 (PST) Received: from [IPv6:2800:810:464:8164:9c91:27c0:253d:5241] (unknown [IPv6:2800:810:464:8164:9c91:27c0:253d:5241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id E3DE7283C03; Thu, 3 Dec 2020 00:37:58 +0000 (UTC) To: Gorry Fairhurst , v6ops@ietf.org Cc: fernando@gont.com.ar, Brian E Carpenter , draft-ietf-v6ops-ipv6-ehs-packet-drops.authors@ietf.org References: <0c121812-44cf-119e-fd09-bb138ff789de@erg.abdn.ac.uk> From: Fernando Gont Message-ID: <676f329d-658b-4398-3b2e-4e8b835686de@si6networks.com> Date: Wed, 2 Dec 2020 21:17:24 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-packet-drops-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 00:38:09 -0000 Hi, Gorry, Thanks for your timely response! In-line.... On 2/12/20 16:33, Gorry Fairhurst wrote: [....|] >> >> In-line... >> >> On 1/12/20 13:30, Gorry Fairhurst wrote: >> [...] >>> >>> * I have some concerns that some of the choices of words could >>> (unintentionally) be taken as endorsing a best practice, which I >>> don't think the IETF would generally promote. This is more about >>> ensuring specific parts can not be quoted out of context. I did a >>> careful read and hope I identified most of these and propose >>> something that might be helpful (please see attached PDF - RTF is >>> identical). I think it would be good to clarify in a few places this >>> is the RFC8200 spec, since I have heard there could be new work to >>> update that. >> >> I don't mind doing that. However, isn't it implicit in all RFCs that >> they are referring to the current specifications (unless otherwise >> noted)? >> >> i.e., regardless of whether there is ongoing work, and whether one is >> aware about it, a spec refers to the IETF status at the time the spec >> is published (*). >> >> (*) Well, modulo RFC Ed processing times. >> >> >> In any case, IIRC, RFC8200 is the current state of affairs when it >> comes to EH processing, so I guess explicitly referencing RFC8200 >> wouldn't hurt.  -- I'm CC'ing Brian, who may correct me if my "of the >> top o my head" assessment is not correct :-) >> > The above is all true - and I think it is simple to add the REF! I will apply the proposed ref. I just want to double-check that we're not leaving outside e.g. things like RFC7045, which I should double-check whether it's fully incorporated into RFC8200. Otherwise, just mentioning RFC8200 would be imprecise. >>> * On the measurement evidence: I have  a slight concern that the >>> results might not cover the wide variety of use cases and you may >>> like to be more careful in the words you use to generalise these for >>> the "internet".  I think we should be aware that in some scenarios an >>> EH might still be effectively used, where path can safely support this. >> >> We're targeting the general case here. As they say, "with sufficient >> thrust, pigs fly just fine". You can, of course, build a network where >> EHs can be used just fine. -- but what we're discussing is the general >> case. >> > Why? - as a transport guy, the only thing that matters is whether a > specific path supports them, the average case just tells me whether I > need a fallback mechanism to cope with a particular path not supporting;-) The evil comment would be that, as a transport guy, you don't control the path. Or, furthermore, there's no concept of "path" for a transport guy ;-) >> >> Some additional comments/questions based on the PDF you've attached: >> >>> However, common implementation limitations suggest >>> that EHs present a challenge for IPv6 packet routing equipment and >>> middle-boxes, and evidence exists that IPv6 packets with EHs have been >> >> Doesn't this imply that this is no longer the case? (i.e. your >> proposed change is "have been") >> >> > /have been/are/ ... if that makes better sense to you, they're > equivalent to me - you observe what has happens and you can predict what > is happening, you might now know the future. WHat I mean is that we're not referring to the occurence of some event in the past, but rather about something that is still the case. >>> If an IPv6 header chain is sufficiently long that its header exceeds >>> the packet look-up capacity of the router, then it would be dropped by >>> hardware that is unable to determine how it should be handled. >> >> This seems rather confusing. It's the router that drops the packet. >> > /hardware/router hardware/ Would the meaning be hanged if we just say "router"? > >>> 5.1. >>> Recirculation >>> Although TLV chains are amenable to iterative processing on >>> architectures that have packet look-up engines with deep inspection >>>>>> is this /that/ ? >> >> Not sure what you mean.... >> > I was suggesting using that in place of /which/... minor nit. Oops -- my bad! (And thanks for it, btw! For English-as-second language I remember studying "that vs. which"... and it seems I should recheck, as the RFC-Ed frequently corrects these for me :-( ) >>> As layer-4 port >>> information increases the entropy of the hash, it is normally highly >>> desirable to use it where possible. >>>>>> I don’t agree with that actually, - but maybe others think so, >>>>>> please check >>>>>> RFCs relating to ECMP or perhaps rephrase, something like: >>>>>> /Layer-4 port >>> information can increase the entropy of the hash, and is often >>> thought desirable to use it where it is available. >>> /? >> >> Your suggested change seems fine to me. That said, what would you >> employ for the hash if not the ports? >> > flow label? The thing is that you cannot rely on it. So, if you want entropy, your safe bet is to use the port numbers.... >>> We note that in the IPv6 world, flows are expected to be identified >>> by means of the IPv6 Flow Label [RFC6437]. Thus, ECMP and Hash-based >>> Load-Sharing is possible without the need to process the entire >>>>>> why /would be possible/ ... some networks do this, and many RFCs >>>>>> encourage this? >> >> Support for the FL is not widely deployed and implemented (see >> [Cunha-2020]) >> > Yes I looked at Cunha - it's just a slide deck - is there a paper that > can be read to check the measurement methodology and results? There's also a paper -- my apologies for not referencing it. I will check if it's online, and otherwise ask the author for permission to share it. > I hear others saying that it is now more often being set, ... so I'm > just urging caution here, because I am not sure v6OPS need to comment on > the results of this on-going work at this stage. For instance... what is > the chance that a router now observes a flow label set to non-zero? ... It's not only to have a non-zero FL, but also that the FL is set correctly -- e.g., some implementations used to employ one FL value during 3WHS, and another during the life of a connection. Thus, if you were using the FL for load-sharing, it would actually break things. FWIW, I wish the FL was widely and correctly implemented and deployed -- I'm just the messenger here. >>> Perhaps; >>> /When many IPv6 >>> implementations failed to set the Flow Label, many ECMP and Hash-based >>> Load-Sharing devices also did not include the Flow Label [Cunha-2020], >>> possibly as a result of issues that have been found >>> in host implementations and middle-boxes [Jaeggli-2018]./ >>> although it seems like >> >> The suggested change seems to imply that the situation has changed, >> but I believe it hasn't. [Cunha-2020] provides evidence in this >> respect. SO assuming that this is something from the past would be >> inaccurate. >> > Well.... we can debate this, if we need to, however:  - i.e., I think > the existence of techniques that utilise ports is sufficient to justify > why the router wishes to traverse the header chain, and why extension > headers are problematic - that does not need to present anything about > what is good practice for ECMP without predjudice to deployment of > FL-based methods. What we mean here is: the reader might wonder "why don't you just use the FL? -- Because we can't". More of empirical evidence than prejudice. >>>>>> I suggest the section includes mention of the IETF recommendation, >>>>>> and there the path with “clearly...” should be at the end! >> >> Ok with moving the para "Clearly.." to the end. That said, could you >> elaborate on what IETF recommendation you're referring to? >> >>> Use of extension headers can result problematic for NIDS/IPS, since: >>>>> /may/can/ ... not necessary, but might as well use /can/ in this case? >> >> Doesn't "may" imply possibility here? >> > No. In many reader's eyes this is permissive ... do it would read are > permitted to. Any alternative wording that would convey "possibility" rather than "ability" or "permission"? >>> As a result, in order to increase the efficiency or effectiveness of >>> these systems, packets employing IPv6 extension headers can be >>>>>> /can/ or /have been/are being/ ... to follow the previous argument? >>> dropped at the network ingress point(s) of networks that deploy these >>> systems. >> >> (Must admit that since you're a native English speaker, I have a high >> probability of being wrong :-), but, anyway): >> >> Packets can be drop, whether with EHs or anything else (i.e., the >> contents of a packet does not affect the ability of a device dropping >> them -- at the end of the day, a device can drop *all* packets if it >> feels like). >> > :-) >> What we are meaning here is that dropping packets with EHs is indeed >> one option to increase the efficiency and effectiveness of these systems. > That sounds correct. Would modifying the text as phrased address your comment? >>> o Use of unknown extension headers can prevent an NIDS/IPS to >>> process layer-4 information >> >> I this case, I think both are fine: -- "can" as in ability, and "may" >> as in possibility >> > - but not may as in "are permitted to"... Would "could" be better to convey "posibility" rather than ability or permission? >>> When such devices are unable to obtain the >>> required information, they might simply resort to dropping the >>>>>> /may/might/ ? >> >> "might" reads as a possibly imaginary situation. What we are meaning >> is that some devices *do* this. >> > OK : then say that devices do this,... rather than they are permitted to. I'll tweak to: "Some of such devices, when unable to obtain the required information, simply resort to...". OK? >> >>> Some router implementations lack fine-grained filtering of IPv6 >>> extension headers. For example, an operator may want to drop packets >>> containing Routing Header Type 0 (RHT0) but may only be able to >>> filter on the extension header type (Routing Header). As a result, >>> the operator would end up enforcing a more coarse filtering policy >>> (e.g. "drop all packets containing a Routing Header" vs. "only drop >>> packets that contain a Routing Header Type 0"). >> >> The proposed change seems to change the meaning of the paragraph. >> i.e., these things *do* happen. >> > How about something like: > > Some router implementations do not have fine-grained filtering of IPv6 > extension headers. For example, an operator that wishes to drop packets > containing Routing Header Type 0 (RHT0), may only be able to > filter on the extension header type (Routing Header). This would > > result in an operator  enforcing a more coarse filtering policy > (e.g. "drop all packets containing a Routing Header" vs. "only drop > packets that contain a Routing Header Type 0"). > > ??? Looks good to me! Thanks! >>>  Additionally, implementation >>>    inconsistencies in packet forwarding engines can result in evasion of >>>    security controls [I-D.kampanakis-6man-ipv6-eh-parsing] [Atlasis2014] >>>    [BH-EU-2014]. >> >> The original text said "...may result in evasion". It would seem to me >> that both are correct ("can" = ability, "may" = possibility)? >> Actually, the later implies the former? >> >> > /can/will/ or whatever or just /result in/ ? "often results in"? >> Same for this one: >> >>> Packets with attached IPv6 Extension Headers can impact performance >>> on routers that forward them. >> > Except in this case, I think the performance of some designs of router > are impacted when forwarding packets with IPv6 EH. Other than HbH, the performance impact generally results from looking up the L4 header. That said, upon re-read of your suggestion, it looks good to me. >>> [Gont-Chown-IEPG89] >>> Gont, F. and T. Chown, "A Small Update on the Use of IPv6 >>> Extension Headers", IEPG 89. London, UK. March 2, 2014, >>> >> eh-update.pdf>. >>> [Gont-IEPG88] >>> Gont, F., "Fragmentation and Extension header Support in >>> the IPv6 Internet", IEPG 88. Vancouver, BC, Canada. >>> November 13, 2013, >> fgont-iepg-ietf88-ipv6-frag-and-eh.pdf>. >>>>>> These don’t seem great presentations, and seem like they were >>>>>> mostly replaced by iepg-ietf90-ipv6-ehs-in-the-real-world-v2.0? >>>>>> I don’t know why these are useful as references? RC7872 also >>>>>> covers this? >> >> They are listed as they were part of the work that eventually resulted >> in RFC7872, and as an indication of for how long the problem has been >> looked into. At the time, we didn't even have tools to do the >> measurements. For example, the path6 tool I implemented, and the >> support in RIPE Atlas were triggered by these efforts. > I don't agree with that. Which part, specifically? :-) Well, I don't think there were tools available at the time. But if you know of any, I'd like to know! > They are actually cited in RFC7872 if taht is your reason, so that is already clear! That said, I don't mind removing these two references. They were including in this document at a time RFC7872 didn't exist -- i.e. we don't have any special motivation for including them. Thanks! Regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Dec 2 16:38:23 2020 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 7E5443A045E; Wed, 2 Dec 2020 16:38:14 -0800 (PST) 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 cMUWrpLAkOof; Wed, 2 Dec 2020 16:38:09 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0A9A3A0115; Wed, 2 Dec 2020 16:38:07 -0800 (PST) Received: from [IPv6:2800:810:464:8164:9c91:27c0:253d:5241] (unknown [IPv6:2800:810:464:8164:9c91:27c0:253d:5241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 2B64E283C27; Thu, 3 Dec 2020 00:38:03 +0000 (UTC) To: Brian E Carpenter , Gorry Fairhurst , v6ops@ietf.org Cc: fernando@gont.com.ar, draft-ietf-v6ops-ipv6-ehs-packet-drops.authors@ietf.org References: <0c121812-44cf-119e-fd09-bb138ff789de@erg.abdn.ac.uk> <25389c41-2f2a-19a3-5106-f64a8d81cdd3@gmail.com> From: Fernando Gont Message-ID: <0330da67-57e1-7d8c-282d-aeba379987d4@si6networks.com> Date: Wed, 2 Dec 2020 21:19:36 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <25389c41-2f2a-19a3-5106-f64a8d81cdd3@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-packet-drops-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 00:38:22 -0000 On 2/12/20 20:04, Brian E Carpenter wrote: > On 03-Dec-20 06:52, Fernando Gont wrote: >> Hello, Gorry, >> >> Thanks a lot for your feedback! -- We really appreciate it! >> >> In-line... >> >> On 1/12/20 13:30, Gorry Fairhurst wrote: >> [...] >>> >>> * I have some concerns that some of the choices of words could >>> (unintentionally) be taken as endorsing a best practice, which I don't >>> think the IETF would generally promote. This is more about ensuring >>> specific parts can not be quoted out of context. I did a careful read >>> and hope I identified most of these and propose something that might be >>> helpful (please see attached PDF - RTF is identical). I think it would >>> be good to clarify in a few places this is the RFC8200 spec, since I >>> have heard there could be new work to update that. >> >> I don't mind doing that. However, isn't it implicit in all RFCs that >> they are referring to the current specifications (unless otherwise noted)? >> >> i.e., regardless of whether there is ongoing work, and whether one is >> aware about it, a spec refers to the IETF status at the time the spec is >> published (*). >> >> (*) Well, modulo RFC Ed processing times. >> >> >> In any case, IIRC, RFC8200 is the current state of affairs when it comes >> to EH processing, so I guess explicitly referencing RFC8200 wouldn't >> hurt. -- I'm CC'ing Brian, who may correct me if my "of the top o my >> head" assessment is not correct :-) > > Yes, although 8200 does give a polite nod to 7045 and does *not* > obsolete it. So, my question is: would it be correct to say "Extension Headers as specified in RFC8200"? -- or would that be imprecise because it fails to note that EHs are partially specified in RFC7045? FWIW, I don't mind applying the change Gorry suggested, as long as the text is still correct/precise. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Dec 2 16:38:27 2020 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 A1F433A074E; Wed, 2 Dec 2020 16:38:17 -0800 (PST) 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 TCim9GqQTDO8; Wed, 2 Dec 2020 16:38:13 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4F8D3A044E; Wed, 2 Dec 2020 16:38:12 -0800 (PST) Received: from [IPv6:2800:810:464:8164:9c91:27c0:253d:5241] (unknown [IPv6:2800:810:464:8164:9c91:27c0:253d:5241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id C196E283CCD; Thu, 3 Dec 2020 00:38:08 +0000 (UTC) To: Tom Herbert Cc: Gorry Fairhurst , IPv6 Operations , draft-ietf-v6ops-ipv6-ehs-packet-drops.authors@ietf.org, Fernando Gont References: <0c121812-44cf-119e-fd09-bb138ff789de@erg.abdn.ac.uk> From: Fernando Gont Message-ID: <74b592f9-3bb5-840b-c544-921b9d3bed0f@si6networks.com> Date: Wed, 2 Dec 2020 21:37:44 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-packet-drops-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 00:38:25 -0000 Hi, Tom, On 2/12/20 17:06, Tom Herbert wrote: [....] >>> In >>> some other uses, the fact that packets with these options might be >>> expected to be dropped by many paths - for good reasons, does not mean >>> that the option is useless to set in general - it might merely be that >>> for these paths it is not possible to use the option and then care is >>> needed in deciding which packets set the EH and how this is used. >> >> We certainly don't mean that. We mean "if you EHs, the chances of your >> packets being dropped increase, for the general case". > > Fernando, > > That's true of a lot protocols. If you use fragmentation, any protocol > other than TCP or UDP, encryption, encapsulation, or even IPv6 your > chances of packets being dropped increase in the general case. I haven't seen measurements in that respect. > In fact > many of the reason noted in this draft for drops are the same those > other cases. So it's generally true that any deviation from a narrow > set of protocols and options that are known to be commonly supported > by routers risks increased chance of packet drop I don't think this is necessarily the case. > I view this draft is another case of trying to document and explain > the status quo for how routers and middleboxes implement the protocol > (we saw the similar discussion in RFC8900 and > draft-ietf-tsvwg-transport-encrypt-18). Documenting current real world > behavior is good, however it needs to been in context (similar to > concerns raised for other like drafts): > 1) Some of the behaviors being documented are either contrary with the > Internet architecture or downright non-conformant with the standards. > IMO this needs to be clarified and called when discussing some > particualar mechanism a vendor has chosen to implement. This may be > describing current practice, but as Gorry this in no way should be > construed as IETF best practice This document doesn't pretend to be a BCP. For instance, we have a Disclaimer in that respect: https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-01#section-2 > 2) We need to realize there are potentially conflicting rrequirements. > For instance, in this draft there is a statement "contemporary routers > and middle-boxes that need to find the layer-4 header must process the > entire IPv6 extension header chain.". I do not believe there is any > core IETF standard that requires routers to access the transport > layer, that's more a design choice vendors have made. That depends a lot whether you're referring to the conceptual role of router, or to the concept of "router" as deployed in the real operational world. > In fact, from a > host perspective, we are trying to obsolete that by encrypting > transport headers like in QUIC for instance (there are both security > and protocol evolution motivations for doing that). > 3) We need to very careful about making conclusions or even those that > are inferred by the reader. I don't think we are driving to a lot of conclusions here. Actually, we're elaborating on the empirical results. > It should be very clear that this > documenting is not advocating obsoleting extension headers nor that > arbitrary dropping of packets with extension headers is acceptable. That's why we have: https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-01#section-2 . At the end of the day, I don't think one can do a lot better than that (and tweaking the document as suggested by Gorry, of course). > 4) It would be nice to have some guidance on a way forward. It *would* be nice. However, most of the ways forward are unrealistic. To name a few: 1) You can't claim you support IPv6 if you can't handle EHs of arbitrary length. 2) You can't claim you support IPv6 if long EH chains result in a performance impact. 3) You can't claim you support IPv6 if you peek at the EH chain -- whether you are a router, NIDS, firewall, or load-balancer 4) Dropping packets with EHs is being a bad Internet neighbor. Re: #1-3: I guess IETF/6man would be unhappy to realize that, then, IPv6 is not as widely implemented. Re: #4: I guess operators will note that they ave a network to run. > Assuming > that the consensus is that extension headers are still useful, FWIW, we're not making statements in that respect. We're elaborating on the problem at hand, and the considerations when relying on EHs. I would assume that, at the very lest, you can leverage EHs in the so-called "limited domains" -- and that's what spring et al are doing. > what can we do to increase their viablitiy? Improved support in network devices. But that normally implies $ than needs to be invested by some, and payed by others. > 5) Specific to this draft, almost all the references are at least five > years old. For instance, RFC7872 which is considered the reference for > measurement of EH drops on the Internet dates back to 2016. So these > aren't really fresh and in the case of RFC7872 that was publsihed > before RFC8200 so it doesn't reflect the impact of the updated EH > related requirements in RFC8200. More recent data and analysis would > strengthen the discussion. The only EH that was relaxed is HbH. And the numbers for other EHs are already bad enough. I'm not sure how that would change the reality and assessment. Thanks! Regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Dec 2 16:50:22 2020 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 D4A923A02BB; Wed, 2 Dec 2020 16:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 m0iTEJyXj6Um; Wed, 2 Dec 2020 16:50:19 -0800 (PST) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 865653A02BC; Wed, 2 Dec 2020 16:50:19 -0800 (PST) Received: by mail-pj1-x102f.google.com with SMTP id r9so137234pjl.5; Wed, 02 Dec 2020 16:50:19 -0800 (PST) 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=CT9JqstVNlrEaV6nbroEhA/0gIDSVbkpYGZCV+Hd7qE=; b=iZFlriuClptjOiKWjZQZ/EE3Vvsfz9a0dFEx0rg8heefJTnJaWoosKZC76+8dH6xzF VIUEF5JGN5sGj6HsYsarDnD0jXD0g6N41TdbIHKGu5AHRRlApxpWsn2VcHswRO7l7bzR 97oMa+RO/AP2E0TWQHAt/hPjylxm1HBFk4gQB4nS7T+ljskFn9a4MeV3tjUB7T/KQgQp UGFZ2OlgoS4649ML2+4E8TUfortz5lapFArKQD6O9aj9NjkT/ILdkJRelqwXF/2FbTXA Bu5Lx6c/SnamPokVbLMnMVS/fi4v1QWjmzaomKfe0iDp6M/SC23rRaSTL2wG8GHTeXxM Oovg== 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=CT9JqstVNlrEaV6nbroEhA/0gIDSVbkpYGZCV+Hd7qE=; b=n9g6V8ZwB0VeVVUUzRa+/WdaHFmxlsrZUnoOPExjGPvSmLMamRmBZ2QaykqzNkVx8Y HM0RubvivGznA3DlxZOxA3+SwxoG7GMsyaaz/NsiFnVFJTDBPRb9yytzWkY3HcrcQCTE KzKh9S1YgxAbI2uiKM7mkOvx35dd9+4kOR7iUnE1Yzvi+lYjbPCxVC83r/S1P+EHR4jl zdlxY3l0qyqiTOWmAy0M42N0K1VAo9mOg7UsKGHZbUSoFf7cDfQVdZ/EFG6NHkl7HVv8 lkF6MlF/UVJbCd9dHpx+MiROFq73nwXP/9E1jCeP9PsxaeHec+eimD1sV6WqHA4RbYcc a75g== X-Gm-Message-State: AOAM533mEvZgxhoAH1kI5R8uhOyuC9Th+HABBpAiteE3pXJ6wv27O5/U sMWCb1GpfLc5hrCWYah6A6odTGJ25XDeew== X-Google-Smtp-Source: ABdhPJyJGna7Ux83E9Wt2YdODibG2J26Lmz0tXHd4r4LjFlcmHD8+OtNyqpdYp85vjRpqSDgvm8jLg== X-Received: by 2002:a17:90b:128a:: with SMTP id fw10mr544422pjb.113.1606956618616; Wed, 02 Dec 2020 16:50:18 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id c205sm229710pfc.160.2020.12.02.16.50.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Dec 2020 16:50:17 -0800 (PST) To: Fernando Gont , Gorry Fairhurst , v6ops@ietf.org Cc: fernando@gont.com.ar, draft-ietf-v6ops-ipv6-ehs-packet-drops.authors@ietf.org References: <0c121812-44cf-119e-fd09-bb138ff789de@erg.abdn.ac.uk> <25389c41-2f2a-19a3-5106-f64a8d81cdd3@gmail.com> <0330da67-57e1-7d8c-282d-aeba379987d4@si6networks.com> From: Brian E Carpenter Message-ID: Date: Thu, 3 Dec 2020 13:50:13 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <0330da67-57e1-7d8c-282d-aeba379987d4@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-packet-drops-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 00:50:21 -0000 On 03-Dec-20 13:19, Fernando Gont wrote: > On 2/12/20 20:04, Brian E Carpenter wrote: >> On 03-Dec-20 06:52, Fernando Gont wrote: >>> Hello, Gorry, >>> >>> Thanks a lot for your feedback! -- We really appreciate it! >>> >>> In-line... >>> >>> On 1/12/20 13:30, Gorry Fairhurst wrote: >>> [...] >>>> >>>> * I have some concerns that some of the choices of words could >>>> (unintentionally) be taken as endorsing a best practice, which I don't >>>> think the IETF would generally promote. This is more about ensuring >>>> specific parts can not be quoted out of context. I did a careful read >>>> and hope I identified most of these and propose something that might be >>>> helpful (please see attached PDF - RTF is identical). I think it would >>>> be good to clarify in a few places this is the RFC8200 spec, since I >>>> have heard there could be new work to update that. >>> >>> I don't mind doing that. However, isn't it implicit in all RFCs that >>> they are referring to the current specifications (unless otherwise noted)? >>> >>> i.e., regardless of whether there is ongoing work, and whether one is >>> aware about it, a spec refers to the IETF status at the time the spec is >>> published (*). >>> >>> (*) Well, modulo RFC Ed processing times. >>> >>> >>> In any case, IIRC, RFC8200 is the current state of affairs when it comes >>> to EH processing, so I guess explicitly referencing RFC8200 wouldn't >>> hurt. -- I'm CC'ing Brian, who may correct me if my "of the top o my >>> head" assessment is not correct :-) >> >> Yes, although 8200 does give a polite nod to 7045 and does *not* >> obsolete it. > > So, my question is: would it be correct to say "Extension Headers as > specified in RFC8200"? -- or would that be imprecise because it fails to > note that EHs are partially specified in RFC7045? Maybe you should ask the authors of 8200 why they didn't obsolete 7045? It's my belief that 8200 simply codifies in slightly different words what 7045 says, as far as normative requirements go, but the informative text in 7045 remains valid, and is therefore not obsoleted. Brian > > FWIW, I don't mind applying the change Gorry suggested, as long as the > text is still correct/precise. > > Thanks, > From nobody Wed Dec 2 17:31:28 2020 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 CA6B53A0621 for ; Wed, 2 Dec 2020 17:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=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 xJB1A4mj_LUz for ; Wed, 2 Dec 2020 17:31:24 -0800 (PST) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 F392F3A064A for ; Wed, 2 Dec 2020 17:31:23 -0800 (PST) Received: by mail-ej1-x636.google.com with SMTP id qw4so931107ejb.12 for ; Wed, 02 Dec 2020 17:31:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2BBP50fKkRhJLPrFSOYbvj8d1ywtpyrTcRufc+fscYY=; b=HKU1j05rgAUpen56FcAEfpjSL6fAAhCvW/7JbcWylZ/Nps18keNdH7kYbV6TDRnB03 Y24XCxNIlaX4zZFsbJ927IkHb0/wXJKVrJTA55C/6dyAOyV9iIYWYysxDcMIZCDj0lAQ JdsxCo0E5Pag08UiuZJm6jJYgsY9pLxkAg3hlCAOrajsSiVt+sswqd5TdeJgmV8j8oBK 92cELedr73vfaOFsvsRn9ywuwN+00K6JXsA731bxMgVEbGX9vVYFv2eWLLgO7I8Mn/v8 HwB0JBFQflcxGgcKPFCOj8lTE3I6ZjuwS3B1dnEV0frTT9PFDEJFKuiQu1UYR/ORhHOw GQMA== 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=2BBP50fKkRhJLPrFSOYbvj8d1ywtpyrTcRufc+fscYY=; b=dTEd7+4DaI3rTW/4nk6/ebR4MrnnNYBcMDOEW9SfPbydpG4PTUeZ0Kth/9Z7AEMDOg uIVYLyRDwodfRk8JoZsjRg//8PTb5HsUykvxEs1sYyqlpHSR7nMXjxfRTgeKA5w23kZT pDqduaxs9t96JIz4+tzSO1Cv2VrAvNJWS+GsYwa57nMQiVUZ4dWYfVX6kZwE/7WdLsVR /FEs+lUQcRWdEAT1mZCbwad7T2XQqR43cClq+KVCMxn13eK1qiOL1X4EWWl7owFzd0p1 wpm/daSVmLPYW5jz9rhEqycPrARRhJ2PKGEnVdx4y86xJpda67x88MWhinv6U/lMuchO k/Kw== X-Gm-Message-State: AOAM533vRxmD/IzfHhS6YPDhxmVOGVY6kUFvDJ0oI7IeXWvKYMJNQLxc JbthIhumLzXuFwFMuUsatb8etN9savWanRBp+milnw== X-Google-Smtp-Source: ABdhPJy9EsNU5/RJ+IOwJ1Rb72r48/WnX5+0VUbj9B/Xx50zGzBsoBHU1jNyTTKHlNZPdz4gfbSV4Ssb1lg8HXBWGio= X-Received: by 2002:a17:907:210b:: with SMTP id qn11mr526707ejb.41.1606959081805; Wed, 02 Dec 2020 17:31:21 -0800 (PST) MIME-Version: 1.0 References: <0c121812-44cf-119e-fd09-bb138ff789de@erg.abdn.ac.uk> <676f329d-658b-4398-3b2e-4e8b835686de@si6networks.com> In-Reply-To: <676f329d-658b-4398-3b2e-4e8b835686de@si6networks.com> From: Tom Herbert Date: Wed, 2 Dec 2020 18:31:08 -0700 Message-ID: To: Fernando Gont Cc: Gorry Fairhurst , IPv6 Operations , draft-ietf-v6ops-ipv6-ehs-packet-drops.authors@ietf.org, Fernando Gont Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-packet-drops-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 01:31:28 -0000 On Wed, Dec 2, 2020 at 5:38 PM Fernando Gont wrote: > > Hi, Gorry, > > Thanks for your timely response! In-line.... > > > On 2/12/20 16:33, Gorry Fairhurst wrote: > [....|] > >> > >> In-line... > >> > >> On 1/12/20 13:30, Gorry Fairhurst wrote: > >> [...] > >>> > >>> * I have some concerns that some of the choices of words could > >>> (unintentionally) be taken as endorsing a best practice, which I > >>> don't think the IETF would generally promote. This is more about > >>> ensuring specific parts can not be quoted out of context. I did a > >>> careful read and hope I identified most of these and propose > >>> something that might be helpful (please see attached PDF - RTF is > >>> identical). I think it would be good to clarify in a few places this > >>> is the RFC8200 spec, since I have heard there could be new work to > >>> update that. > >> > >> I don't mind doing that. However, isn't it implicit in all RFCs that > >> they are referring to the current specifications (unless otherwise > >> noted)? > >> > >> i.e., regardless of whether there is ongoing work, and whether one is > >> aware about it, a spec refers to the IETF status at the time the spec > >> is published (*). > >> > >> (*) Well, modulo RFC Ed processing times. > >> > >> > >> In any case, IIRC, RFC8200 is the current state of affairs when it > >> comes to EH processing, so I guess explicitly referencing RFC8200 > >> wouldn't hurt. -- I'm CC'ing Brian, who may correct me if my "of the > >> top o my head" assessment is not correct :-) > >> > > The above is all true - and I think it is simple to add the REF! > > I will apply the proposed ref. I just want to double-check that we're > not leaving outside e.g. things like RFC7045, which I should > double-check whether it's fully incorporated into RFC8200. Otherwise, > just mentioning RFC8200 would be imprecise. > > > > >>> * On the measurement evidence: I have a slight concern that the > >>> results might not cover the wide variety of use cases and you may > >>> like to be more careful in the words you use to generalise these for > >>> the "internet". I think we should be aware that in some scenarios an > >>> EH might still be effectively used, where path can safely support thi= s. > >> > >> We're targeting the general case here. As they say, "with sufficient > >> thrust, pigs fly just fine". You can, of course, build a network where > >> EHs can be used just fine. -- but what we're discussing is the general > >> case. > >> > > Why? - as a transport guy, the only thing that matters is whether a > > specific path supports them, the average case just tells me whether I > > need a fallback mechanism to cope with a particular path not supporting= ;-) > > The evil comment would be that, as a transport guy, you don't control > the path. Or, furthermore, there's no concept of "path" for a transport > guy ;-) Fernando, The analogue evil comment would be that, as a network guy, you shouldn't have any interest in the transport layer. Or furthermore, there's no concept of a "transport layer" for a network guy ;-) The fact is that hosts, including the transport layer, do have a vested interest in the network path to a destination and what its characteristics are as part of ensuring viable end to end communications. As Gorry alludes to, if the host can get information apriori about the capabilities that a particular network path supports then we're able to apply fallbacks when the path doesn't support the requested functionality or possibly influence the routing to get a better path. For instance, if my host has information that EH headers are supported to some destination on the Internet then why not use them to that destination if they offer better service for the user? Tom > > > > >> > >> Some additional comments/questions based on the PDF you've attached: > >> > >>> However, common implementation limitations suggest > >>> that EHs present a challenge for IPv6 packet routing equipment and > >>> middle-boxes, and evidence exists that IPv6 packets with EHs have bee= n > >> > >> Doesn't this imply that this is no longer the case? (i.e. your > >> proposed change is "have been") > >> > >> > > /have been/are/ ... if that makes better sense to you, they're > > equivalent to me - you observe what has happens and you can predict wha= t > > is happening, you might now know the future. > > WHat I mean is that we're not referring to the occurence of some event > in the past, but rather about something that is still the case. > > > > >>> If an IPv6 header chain is sufficiently long that its header exceeds > >>> the packet look-up capacity of the router, then it would be dropped b= y > >>> hardware that is unable to determine how it should be handled. > >> > >> This seems rather confusing. It's the router that drops the packet. > >> > > /hardware/router hardware/ > > Would the meaning be hanged if we just say "router"? > > > > > > >>> 5.1. > >>> Recirculation > >>> Although TLV chains are amenable to iterative processing on > >>> architectures that have packet look-up engines with deep inspection > >>>>>> is this /that/ ? > >> > >> Not sure what you mean.... > >> > > I was suggesting using that in place of /which/... minor nit. > > Oops -- my bad! (And thanks for it, btw! For English-as-second language > I remember studying "that vs. which"... and it seems I should recheck, > as the RFC-Ed frequently corrects these for me :-( ) > > > > > >>> As layer-4 port > >>> information increases the entropy of the hash, it is normally highly > >>> desirable to use it where possible. > >>>>>> I don=E2=80=99t agree with that actually, - but maybe others think= so, > >>>>>> please check > >>>>>> RFCs relating to ECMP or perhaps rephrase, something like: > >>>>>> /Layer-4 port > >>> information can increase the entropy of the hash, and is often > >>> thought desirable to use it where it is available. > >>> /? > >> > >> Your suggested change seems fine to me. That said, what would you > >> employ for the hash if not the ports? > >> > > flow label? > > The thing is that you cannot rely on it. So, if you want entropy, your > safe bet is to use the port numbers.... > > > >>> We note that in the IPv6 world, flows are expected to be identified > >>> by means of the IPv6 Flow Label [RFC6437]. Thus, ECMP and Hash-based > >>> Load-Sharing is possible without the need to process the entire > >>>>>> why /would be possible/ ... some networks do this, and many RFCs > >>>>>> encourage this? > >> > >> Support for the FL is not widely deployed and implemented (see > >> [Cunha-2020]) > >> > > Yes I looked at Cunha - it's just a slide deck - is there a paper that > > can be read to check the measurement methodology and results? > > There's also a paper -- my apologies for not referencing it. I will > check if it's online, and otherwise ask the author for permission to > share it. > > > > > I hear others saying that it is now more often being set, ... so I'm > > just urging caution here, because I am not sure v6OPS need to comment o= n > > the results of this on-going work at this stage. For instance... what i= s > > the chance that a router now observes a flow label set to non-zero? ... > > It's not only to have a non-zero FL, but also that the FL is set > correctly -- e.g., some implementations used to employ one FL value > during 3WHS, and another during the life of a connection. Thus, if you > were using the FL for load-sharing, it would actually break things. > > FWIW, I wish the FL was widely and correctly implemented and deployed -- > I'm just the messenger here. > > > > >>> Perhaps; > >>> /When many IPv6 > >>> implementations failed to set the Flow Label, many ECMP and Hash-base= d > >>> Load-Sharing devices also did not include the Flow Label [Cunha-2020]= , > >>> possibly as a result of issues that have been found > >>> in host implementations and middle-boxes [Jaeggli-2018]./ > >>> although it seems like > >> > >> The suggested change seems to imply that the situation has changed, > >> but I believe it hasn't. [Cunha-2020] provides evidence in this > >> respect. SO assuming that this is something from the past would be > >> inaccurate. > >> > > Well.... we can debate this, if we need to, however: - i.e., I think > > the existence of techniques that utilise ports is sufficient to justify > > why the router wishes to traverse the header chain, and why extension > > headers are problematic - that does not need to present anything about > > what is good practice for ECMP without predjudice to deployment of > > FL-based methods. > > What we mean here is: the reader might wonder "why don't you just use > the FL? -- Because we can't". > > More of empirical evidence than prejudice. > > > > >>>>>> I suggest the section includes mention of the IETF recommendation, > >>>>>> and there the path with =E2=80=9Cclearly...=E2=80=9D should be at = the end! > >> > >> Ok with moving the para "Clearly.." to the end. That said, could you > >> elaborate on what IETF recommendation you're referring to? > >> > >>> Use of extension headers can result problematic for NIDS/IPS, since: > >>>>> /may/can/ ... not necessary, but might as well use /can/ in this ca= se? > >> > >> Doesn't "may" imply possibility here? > >> > > No. In many reader's eyes this is permissive ... do it would read are > > permitted to. > > Any alternative wording that would convey "possibility" rather than > "ability" or "permission"? > > > > >>> As a result, in order to increase the efficiency or effectiveness of > >>> these systems, packets employing IPv6 extension headers can be > >>>>>> /can/ or /have been/are being/ ... to follow the previous argument= ? > >>> dropped at the network ingress point(s) of networks that deploy these > >>> systems. > >> > >> (Must admit that since you're a native English speaker, I have a high > >> probability of being wrong :-), but, anyway): > >> > >> Packets can be drop, whether with EHs or anything else (i.e., the > >> contents of a packet does not affect the ability of a device dropping > >> them -- at the end of the day, a device can drop *all* packets if it > >> feels like). > >> > > :-) > >> What we are meaning here is that dropping packets with EHs is indeed > >> one option to increase the efficiency and effectiveness of these syste= ms. > > That sounds correct. > > Would modifying the text as phrased address your comment? > > > > >>> o Use of unknown extension headers can prevent an NIDS/IPS to > >>> process layer-4 information > >> > >> I this case, I think both are fine: -- "can" as in ability, and "may" > >> as in possibility > >> > > - but not may as in "are permitted to"... > > Would "could" be better to convey "posibility" rather than ability or > permission? > > > > >>> When such devices are unable to obtain the > >>> required information, they might simply resort to dropping the > >>>>>> /may/might/ ? > >> > >> "might" reads as a possibly imaginary situation. What we are meaning > >> is that some devices *do* this. > >> > > OK : then say that devices do this,... rather than they are permitted t= o. > > I'll tweak to: > > "Some of such devices, when unable to obtain the required information, > simply resort to...". OK? > > > > >> > >>> Some router implementations lack fine-grained filtering of IPv6 > >>> extension headers. For example, an operator may want to drop packets > >>> containing Routing Header Type 0 (RHT0) but may only be able to > >>> filter on the extension header type (Routing Header). As a result, > >>> the operator would end up enforcing a more coarse filtering policy > >>> (e.g. "drop all packets containing a Routing Header" vs. "only drop > >>> packets that contain a Routing Header Type 0"). > >> > >> The proposed change seems to change the meaning of the paragraph. > >> i.e., these things *do* happen. > >> > > How about something like: > > > > Some router implementations do not have fine-grained filtering of IPv6 > > extension headers. For example, an operator that wishes to drop packets > > containing Routing Header Type 0 (RHT0), may only be able to > > filter on the extension header type (Routing Header). This would > > > > result in an operator enforcing a more coarse filtering policy > > (e.g. "drop all packets containing a Routing Header" vs. "only drop > > packets that contain a Routing Header Type 0"). > > > > ??? > > Looks good to me! Thanks! > > > > >>> Additionally, implementation > >>> inconsistencies in packet forwarding engines can result in evasion= of > >>> security controls [I-D.kampanakis-6man-ipv6-eh-parsing] [Atlasis20= 14] > >>> [BH-EU-2014]. > >> > >> The original text said "...may result in evasion". It would seem to me > >> that both are correct ("can" =3D ability, "may" =3D possibility)? > >> Actually, the later implies the former? > >> > >> > > /can/will/ or whatever or just /result in/ ? > > "often results in"? > > > >> Same for this one: > >> > >>> Packets with attached IPv6 Extension Headers can impact performance > >>> on routers that forward them. > >> > > Except in this case, I think the performance of some designs of router > > are impacted when forwarding packets with IPv6 EH. > > Other than HbH, the performance impact generally results from looking up > the L4 header. > > That said, upon re-read of your suggestion, it looks good to me. > > > > >>> [Gont-Chown-IEPG89] > >>> Gont, F. and T. Chown, "A Small Update on the Use of IPv6 > >>> Extension Headers", IEPG 89. London, UK. March 2, 2014, > >>> >>> eh-update.pdf>. > >>> [Gont-IEPG88] > >>> Gont, F., "Fragmentation and Extension header Support in > >>> the IPv6 Internet", IEPG 88. Vancouver, BC, Canada. > >>> November 13, 2013, >>> fgont-iepg-ietf88-ipv6-frag-and-eh.pdf>. > >>>>>> These don=E2=80=99t seem great presentations, and seem like they w= ere > >>>>>> mostly replaced by iepg-ietf90-ipv6-ehs-in-the-real-world-v2.0? > >>>>>> I don=E2=80=99t know why these are useful as references? RC7872 al= so > >>>>>> covers this? > >> > >> They are listed as they were part of the work that eventually resulted > >> in RFC7872, and as an indication of for how long the problem has been > >> looked into. At the time, we didn't even have tools to do the > >> measurements. For example, the path6 tool I implemented, and the > >> support in RIPE Atlas were triggered by these efforts. > > I don't agree with that. > > Which part, specifically? :-) > > Well, I don't think there were tools available at the time. But if you > know of any, I'd like to know! > > > > They are actually cited in RFC7872 if taht is your reason, so that is a= lready clear! > > That said, I don't mind removing these two references. They were > including in this document at a time RFC7872 didn't exist -- i.e. we > don't have any special motivation for including them. > > Thanks! > > Regards, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Wed Dec 2 17:32:39 2020 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 55F443A064B; Wed, 2 Dec 2020 17:32:38 -0800 (PST) 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 A303dwJ-_RA8; Wed, 2 Dec 2020 17:32:35 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 558083A09CF; Wed, 2 Dec 2020 17:32:18 -0800 (PST) Received: from [IPv6:2800:810:464:8164:9c91:27c0:253d:5241] (unknown [IPv6:2800:810:464:8164:9c91:27c0:253d:5241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 16E102839F5; Thu, 3 Dec 2020 01:32:14 +0000 (UTC) To: Brian E Carpenter , Gorry Fairhurst , v6ops@ietf.org Cc: fernando@gont.com.ar, draft-ietf-v6ops-ipv6-ehs-packet-drops.authors@ietf.org References: <0c121812-44cf-119e-fd09-bb138ff789de@erg.abdn.ac.uk> <25389c41-2f2a-19a3-5106-f64a8d81cdd3@gmail.com> <0330da67-57e1-7d8c-282d-aeba379987d4@si6networks.com> From: Fernando Gont Message-ID: <0b8b837a-8ef0-4112-0580-8a1d6f153f4d@si6networks.com> Date: Wed, 2 Dec 2020 22:31:52 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-packet-drops-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 01:32:38 -0000 On 2/12/20 21:50, Brian E Carpenter wrote: > On 03-Dec-20 13:19, Fernando Gont wrote: >> On 2/12/20 20:04, Brian E Carpenter wrote: >>> On 03-Dec-20 06:52, Fernando Gont wrote: >>>> Hello, Gorry, >>>> >>>> Thanks a lot for your feedback! -- We really appreciate it! >>>> >>>> In-line... >>>> >>>> On 1/12/20 13:30, Gorry Fairhurst wrote: >>>> [...] >>>>> >>>>> * I have some concerns that some of the choices of words could >>>>> (unintentionally) be taken as endorsing a best practice, which I don't >>>>> think the IETF would generally promote. This is more about ensuring >>>>> specific parts can not be quoted out of context. I did a careful read >>>>> and hope I identified most of these and propose something that might be >>>>> helpful (please see attached PDF - RTF is identical). I think it would >>>>> be good to clarify in a few places this is the RFC8200 spec, since I >>>>> have heard there could be new work to update that. >>>> >>>> I don't mind doing that. However, isn't it implicit in all RFCs that >>>> they are referring to the current specifications (unless otherwise noted)? >>>> >>>> i.e., regardless of whether there is ongoing work, and whether one is >>>> aware about it, a spec refers to the IETF status at the time the spec is >>>> published (*). >>>> >>>> (*) Well, modulo RFC Ed processing times. >>>> >>>> >>>> In any case, IIRC, RFC8200 is the current state of affairs when it comes >>>> to EH processing, so I guess explicitly referencing RFC8200 wouldn't >>>> hurt. -- I'm CC'ing Brian, who may correct me if my "of the top o my >>>> head" assessment is not correct :-) >>> >>> Yes, although 8200 does give a polite nod to 7045 and does *not* >>> obsolete it. >> >> So, my question is: would it be correct to say "Extension Headers as >> specified in RFC8200"? -- or would that be imprecise because it fails to >> note that EHs are partially specified in RFC7045? > > Maybe you should ask the authors of 8200 why they didn't obsolete 7045? > > It's my belief that 8200 simply codifies in slightly different words > what 7045 says, as far as normative requirements go, but the informative > text in 7045 remains valid, and is therefore not obsoleted. Ok. Then it would be safe to reference RFC8200 as *the* specification for EHs. I'm CC'ing Bob since he might correct me in case I'm missing something. Thanks! Regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Dec 2 23:53:29 2020 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 66F383A0A73 for ; Wed, 2 Dec 2020 23:53:22 -0800 (PST) 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 UJOnOcWcr5sQ for ; Wed, 2 Dec 2020 23:53:19 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0173D3A09C0 for ; Wed, 2 Dec 2020 23:53:15 -0800 (PST) Received: from [IPv6:2800:810:464:8164:9c91:27c0:253d:5241] (unknown [IPv6:2800:810:464:8164:9c91:27c0:253d:5241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 3BCAB28462B; Thu, 3 Dec 2020 07:53:07 +0000 (UTC) To: Gorry Fairhurst , v6ops@ietf.org Cc: fernando@gont.com.ar References: <0c121812-44cf-119e-fd09-bb138ff789de@erg.abdn.ac.uk> From: Fernando Gont Message-ID: Date: Thu, 3 Dec 2020 04:50:19 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <0c121812-44cf-119e-fd09-bb138ff789de@erg.abdn.ac.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-packet-drops-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 07:53:29 -0000 Hi, Gorry, On 1/12/20 13:30, Gorry Fairhurst wrote: [----] > > Hope this helps, Fernando. If you need any clarification or other help, > just let me know, I had promised to read "Threats and Surprises behind IPv6 Extension Headers" (http://dl.ifip.org/db/conf/tma/tma2017/tma2017_paper22.pdf) My read of the paper is essentially that EHs are largely unused. And when it comes to actual use of EHs, they seem to boil down to fragmented UDP (already considered fragile, per RFC8900), local-link traffic (e.g. MLD), some IPsec, and what seem to be bogus traffic (e.g., ICMPv6 errors being fragmented or employing HbH headers). No surprises here. Then, in the "Conclusions" section, the authors note: "Dropping all packets that contain Extension Headers is a bad practice" -- with which I disagree. Not that I think it is great to have to resort to dropping packets with EHs, but rather because folks that a network to run, and if allowing such packets will prevent them from doing what they need to do, or open their network to DoS, then, given the options they have on the table, dropping such packets might be the most acceptable one. They also note: "The share of traffic containing more than one EH however, is very small. For the design of hardware able to handle the dynamic nature of EHs, we therefore recommend to support at least one EH: the exceptional packets containing more EHs can be handled in the slow-path, i.e. a slower CPU in the network device, without substantial performance loss, while still offering flexibility to drop packets with e.g. more than three EHs to prevent the possible Denial of Service attack" This doesn't seem to make a lot of sense. A key design choice is the EH-chain length to be supported, rather than EH # count. And no, I don't think you want to process packets in the slower path -- unless you rate limit them to such a small number, that it wouldn't make sense, anyway. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Dec 3 00:02:59 2020 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 810AE3A07B3; Thu, 3 Dec 2020 00:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=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 cWWDoNBm4FvH; Thu, 3 Dec 2020 00:02:51 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62EA03A0D1C; Thu, 3 Dec 2020 00:02:43 -0800 (PST) Received: from [IPv6:2800:810:464:8164:9c91:27c0:253d:5241] (unknown [IPv6:2800:810:464:8164:9c91:27c0:253d:5241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id D0C1D280498; Thu, 3 Dec 2020 08:02:38 +0000 (UTC) To: Tom Herbert , Fernando Gont Cc: IPv6 Operations , tcpm , Mark Smith , Brian E Carpenter References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> <0d38980a-f1c5-fac5-a9b1-0711d61353d1@gont.com.ar> From: Fernando Gont Message-ID: <42b6e327-08b5-292b-be65-28f1a8508a69@si6networks.com> Date: Thu, 3 Dec 2020 05:02:33 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] [tcpm] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 08:02:58 -0000 Hi, Tom, On 29/11/20 13:25, Tom Herbert wrote: >> Modulo the comments I've already made, I'm afraid we might be in the >> path of making the FL unusable... >> > > Fernanda,, > > I really don't understand how this makes the flow label "unusable", to > the contrary this is a useful case with good effect and justifies the > work in the host to set the field. In any case, it would be great if > you could provide the draft with the normative requirements that would > make the flow label "usable". Have the FL identify a flow. packets RTO'ing does not imply that the retransmissions belong to a different flow. FL changing for established sessions will break load-balancers. OTOH, one would still need to anylize what would happen if a SYN RTO-es, gets retransmitted, but both the original and the retransmitted SYN is delivered. > Please include requirements for both hosts and network nodes. If there > is going to the be a requirement that hosts MUST make a 1:1 mapping to > a transport connection and the flow label MUST be consistent for the > life of connection, then I would expect there to also be a requirement > that the flow label MUST be immutable by all devices in the path-- in > particular the requirement of RFC6437 would need to be updated: "A > forwarding node MUST either leave a non-zero flow label value > unchanged or change it only for compelling operational security > reasons..."-- if hosts are not allowed to change a field they are > primarily responsible for setting, then the network should not be > allowed to modify it either. I don't recall _(of the top of my head) why we ended up making the field mutable ("SHOULD NOT be modified" rather than "MUST NOT.."). IIRC, it had to do with allowing middle-boxes to mitigate FL-based covert channels. If that's the case (Brian CC'ed) then, in retrospective, that seems to have been a bad idea. -- I was part of the discussion, so I take my share of blame. :-) > Additionally, if the underlying design principle is that flow > identification in a packet is immutable and persistent, then I'd like > to see the discussion on how that rectifies with NAT where > intermediate nodes routinely change IP addresses and transport port > numbers without the host endpoints' knowledge-- unlike the flow label, > port numbers are formally part of the transport connection > identification, so changing them in flight is far more invasive and > potentially harmful than changing the flow label (we've seen far more > problems caused by NAT than flow label due to NAT state evictions, > packets of a flow being re-routed to not hit the same NAT device, > etc.). You seem to be referring to IPv4 NAT, since IPv6 NPT does not modify the ports. That said, even if IPv6 NAT did, then as long as the FL is consistent from the outside, that's fine. (i.e., the FL remains constant from both the "external realm" pov, and also from the "internal realm" pov). Thanks! Regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Dec 3 00:32:16 2020 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 178E03A0B12; Thu, 3 Dec 2020 00:32:15 -0800 (PST) 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 pqua-G-nxagY; Thu, 3 Dec 2020 00:32:12 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 981983A0B0E; Thu, 3 Dec 2020 00:32:11 -0800 (PST) Received: from Gs-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id A5F1F1B00196; Thu, 3 Dec 2020 08:32:03 +0000 (GMT) To: Fernando Gont , v6ops@ietf.org Cc: fernando@gont.com.ar, Brian E Carpenter , draft-ietf-v6ops-ipv6-ehs-packet-drops.authors@ietf.org References: <0c121812-44cf-119e-fd09-bb138ff789de@erg.abdn.ac.uk> <676f329d-658b-4398-3b2e-4e8b835686de@si6networks.com> From: Gorry Fairhurst Message-ID: <7b483c43-288b-dc4b-3df8-79d529c7e163@erg.abdn.ac.uk> Date: Thu, 3 Dec 2020 08:32:02 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <676f329d-658b-4398-3b2e-4e8b835686de@si6networks.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-packet-drops-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 08:32:15 -0000 HI, I think we are converging... On 03/12/2020 00:17, Fernando Gont wrote: > Hi, Gorry, > > Thanks for your timely response! In-line.... > > > On 2/12/20 16:33, Gorry Fairhurst wrote: > [....|] >>> >>> In-line... >>> >>> On 1/12/20 13:30, Gorry Fairhurst wrote: >>> [...] >>>> >>>> * I have some concerns that some of the choices of words could >>>> (unintentionally) be taken as endorsing a best practice, which I >>>> don't think the IETF would generally promote. This is more about >>>> ensuring specific parts can not be quoted out of context. I did a >>>> careful read and hope I identified most of these and propose >>>> something that might be helpful (please see attached PDF - RTF is >>>> identical). I think it would be good to clarify in a few places >>>> this is the RFC8200 spec, since I have heard there could be new >>>> work to update that. >>> >>> I don't mind doing that. However, isn't it implicit in all RFCs that >>> they are referring to the current specifications (unless otherwise >>> noted)? >>> >>> i.e., regardless of whether there is ongoing work, and whether one >>> is aware about it, a spec refers to the IETF status at the time the >>> spec is published (*). >>> >>> (*) Well, modulo RFC Ed processing times. >>> >>> >>> In any case, IIRC, RFC8200 is the current state of affairs when it >>> comes to EH processing, so I guess explicitly referencing RFC8200 >>> wouldn't hurt.  -- I'm CC'ing Brian, who may correct me if my "of >>> the top o my head" assessment is not correct :-) >>> >> The above is all true - and I think it is simple to add the REF! > > I will apply the proposed ref. I just want to double-check that we're > not leaving outside e.g. things like RFC7045, which I should > double-check whether it's fully incorporated into RFC8200. Otherwise, > just mentioning RFC8200 would be imprecise. > > > >>>> * On the measurement evidence: I have a slight concern that the >>>> results might not cover the wide variety of use cases and you may >>>> like to be more careful in the words you use to generalise these >>>> for the "internet".  I think we should be aware that in some >>>> scenarios an EH might still be effectively used, where path can >>>> safely support this. >>> >>> We're targeting the general case here. As they say, "with sufficient >>> thrust, pigs fly just fine". You can, of course, build a network >>> where EHs can be used just fine. -- but what we're discussing is the >>> general case. >>> >> Why? - as a transport guy, the only thing that matters is whether a >> specific path supports them, the average case just tells me whether I >> need a fallback mechanism to cope with a particular path not >> supporting;-) > > The evil comment would be that, as a transport guy, you don't control > the path. Or, furthermore, there's no concept of "path" for a > transport guy ;-) > We do have the notion of a path... but it may be that is different to your notion. > > >>> >>> Some additional comments/questions based on the PDF you've attached: >>> >>>> However, common implementation limitations suggest >>>> that EHs present a challenge for IPv6 packet routing equipment and >>>> middle-boxes, and evidence exists that IPv6 packets with EHs have been >>> >>> Doesn't this imply that this is no longer the case? (i.e. your >>> proposed change is "have been") >>> >>> >> /have been/are/ ... if that makes better sense to you, they're >> equivalent to me - you observe what has happens and you can predict >> what is happening, you might now know the future. > > What I mean is that we're not referring to the occurence of some event > in the past, but rather about something that is still the case. > > Sure, why not write this is still the case? > >>>> If an IPv6 header chain is sufficiently long that its header exceeds >>>> the packet look-up capacity of the router, then it would be dropped by >>>> hardware that is unable to determine how it should be handled. >>> >>> This seems rather confusing. It's the router that drops the packet. >>> >> /hardware/router hardware/ > > Would the meaning be  hanged if we just say "router"? > > Router is OK for me. > >> >>>> 5.1. >>>> Recirculation >>>> Although TLV chains are amenable to iterative processing on >>>> architectures that have packet look-up engines with deep inspection >>>>>>> is this /that/ ? >>> >>> Not sure what you mean.... >>> >> I was suggesting using that in place of /which/... minor nit. > > Oops -- my bad! (And thanks for it, btw!  For English-as-second > language I remember studying "that vs. which"... and it seems I should > recheck, as the RFC-Ed frequently corrects these for me :-(  ) > > > > >>>> As layer-4 port >>>> information increases the entropy of the hash, it is normally highly >>>> desirable to use it where possible. >>>>>>> I don’t agree with that actually, - but maybe others think so, >>>>>>> please check >>>>>>> RFCs relating to ECMP or perhaps rephrase, something like: >>>>>>> /Layer-4 port >>>> information can increase the entropy of the hash, and is often >>>> thought desirable to use it where it is available. >>>> /? >>> >>> Your suggested change seems fine to me. That said, what would you >>> employ for the hash if not the ports? >>> >> flow label? > > The thing is that you cannot rely on it. So, if you want entropy, your > safe bet is to use the port numbers.... > OK, but I still do not understand why this particular RFC-to-be would make a judgment on this issue, it is not related to EH, the desire of some devices to look for transport headers is irrefutable. This happens for various reasons of which this is one. There are other things that happen also - but in the context of this document, the text can be entirely neutral as to whether this is good or bad practice. > >>>> We note that in the IPv6 world, flows are expected to be identified >>>> by means of the IPv6 Flow Label [RFC6437]. Thus, ECMP and Hash-based >>>> Load-Sharing is possible without the need to process the entire >>>>>>> why /would be possible/ ... some networks do this, and many RFCs >>>>>>> encourage this? >>> >>> Support for the FL is not widely deployed and implemented (see >>> [Cunha-2020]) >>> >> Yes I looked at Cunha - it's just a slide deck - is there a paper >> that can be read to check the measurement methodology and results? > > There's also a paper -- my apologies for not referencing it. I will > check if it's online, and otherwise ask the author for permission to > share it. > That would help a lot to read that. > >> I hear others saying that it is now more often being set, ... so I'm >> just urging caution here, because I am not sure v6OPS need to comment >> on the results of this on-going work at this stage. For instance... >> what is the chance that a router now observes a flow label set to >> non-zero? ... > > It's not only to have a non-zero FL, but also that the FL is set > correctly -- e.g., some implementations used to employ one FL value > during 3WHS, and another during the life of a connection. Thus, if you > were using the FL for load-sharing, it would actually break things. > > FWIW, I wish the FL was widely and correctly implemented and deployed > -- I'm just the messenger here. > So, I'm urging that the message is represented as saying that at the time of publication, load-sharing and other techniques utilise the transport header information [REF]. To access this information, a router need to process the EH chain, and this leads to issues ... as you decribe. > > >>>> Perhaps; >>>> /When many IPv6 >>>> implementations failed to set the Flow Label, many ECMP and Hash-based >>>> Load-Sharing devices also did not include the Flow Label [Cunha-2020], >>>> possibly as a result of issues that have been found >>>> in host implementations and middle-boxes [Jaeggli-2018]./ >>>> although it seems like >>> >>> The suggested change seems to imply that the situation has changed, >>> but I believe it hasn't. [Cunha-2020] provides evidence in this >>> respect. SO assuming that this is something from the past would be >>> inaccurate. >>> >> Well.... we can debate this, if we need to, however:  - i.e., I think >> the existence of techniques that utilise ports is sufficient to >> justify why the router wishes to traverse the header chain, and why >> extension headers are problematic - that does not need to present >> anything about what is good practice for ECMP without predjudice to >> deployment of FL-based methods. > > What we mean here is: the reader might wonder "why don't you just use > the FL?  -- Because we can't". > > More of empirical evidence than prejudice. Observing this happens is helfpul - with more clarity of recent trends in setting and using. However, I will objec interpretation of this to how to use (or not) the FL. This document is not the correct place to offer this advice. One: because this document is not about ECMP and FL, it is about EH. Two: because this is an informational document from an OPS WG trying to change something that is being used by PS in Transport and Internet areas. > >>>>>>> I suggest the section includes mention of the IETF recommendation, >>>>>>> and there the path with “clearly...” should be at the end! >>> >>> Ok with moving the para "Clearly.." to the end. That said, could you >>> elaborate on what IETF recommendation you're referring to? >>> >>>> Use of extension headers can result problematic for NIDS/IPS, since: >>>>>> /may/can/ ... not necessary, but might as well use /can/ in this >>>>>> case? >>> >>> Doesn't "may" imply possibility here? >>> >> No. In many reader's eyes this is permissive ... do it would read are >> permitted to. > > Any alternative wording that would convey "possibility" rather than > "ability" or "permission"? > Trying to be close to your original wording: Problems can arise when EH are used for NIDS/IPS, since: (The meaning here is clear to me, in that the problems can arise). > >>>> As a result, in order to increase the efficiency or effectiveness of >>>> these systems, packets employing IPv6 extension headers can be >>>>>>> /can/ or /have been/are being/ ... to follow the previous argument? >>>> dropped at the network ingress point(s) of networks that deploy these >>>> systems. >>> >>> (Must admit that since you're a native English speaker, I have a >>> high probability of being wrong :-), but, anyway): >>> >>> Packets can be drop, whether with EHs or anything else (i.e., the >>> contents of a packet does not affect the ability of a device >>> dropping them -- at the end of the day, a device can drop *all* >>> packets if it feels like). >>> >> :-) >>> What we are meaning here is that dropping packets with EHs is indeed >>> one option to increase the efficiency and effectiveness of these >>> systems. >> That sounds correct. > > Would modifying the text as phrased address your comment? > Pehaps, you could try something. I'd suggest just being neutral and saying: As a result, IPS systems have been observed to drop packets employing IPv6 extension headers at the network ingress point(s). > >>>> o Use of unknown extension headers can prevent an NIDS/IPS to >>>> process layer-4 information >>> >>> I this case, I think both are fine: -- "can" as in ability, and >>> "may" as in possibility >>> >> - but not may as in "are permitted to"... > > Would "could" be better to convey "posibility" rather than ability or > permission? > > Could is fine. > >>>> When such devices are unable to obtain the >>>> required information, they might simply resort to dropping the >>>>>>> /may/might/ ? >>> >>> "might" reads as a possibly imaginary situation. What we are meaning >>> is that some devices *do* this. >>> >> OK : then say that devices do this,... rather than they are permitted >> to. > > I'll tweak to: > > "Some of such devices, when unable to obtain the required information, > simply resort to...". OK? > > /such/these/ ... seems like a reasonable statement to me:-). > >>> >>>> Some router implementations lack fine-grained filtering of IPv6 >>>> extension headers. For example, an operator may want to drop packets >>>> containing Routing Header Type 0 (RHT0) but may only be able to >>>> filter on the extension header type (Routing Header). As a result, >>>> the operator would end up enforcing a more coarse filtering policy >>>> (e.g. "drop all packets containing a Routing Header" vs. "only drop >>>> packets that contain a Routing Header Type 0"). >>> >>> The proposed change seems to change the meaning of the paragraph. >>> i.e., these things *do* happen. >>> >> How about something like: >> >> Some router implementations do not have fine-grained filtering of IPv6 >> extension headers. For example, an operator that wishes to drop packets >> containing Routing Header Type 0 (RHT0), may only be able to >> filter on the extension header type (Routing Header). This would >> >> result in an operator  enforcing a more coarse filtering policy >> (e.g. "drop all packets containing a Routing Header" vs. "only drop >> packets that contain a Routing Header Type 0"). >> >> ??? > > Looks good to me! Thanks! > > > >>>>  Additionally, implementation >>>>    inconsistencies in packet forwarding engines can result in >>>> evasion of >>>>    security controls [I-D.kampanakis-6man-ipv6-eh-parsing] >>>> [Atlasis2014] >>>>    [BH-EU-2014]. >>> >>> The original text said "...may result in evasion". It would seem to >>> me that both are correct ("can" = ability, "may" = possibility)? >>> Actually, the later implies the former? >>> >>> >> /can/will/ or whatever or just /result in/ ? > > "often results in"? > > That is also good - since there is a reference to clarify often! >>> Same for this one: >>> >>>> Packets with attached IPv6 Extension Headers can impact performance >>>> on routers that forward them. >>> >> Except in this case, I think the performance of some designs of >> router are impacted when forwarding packets with IPv6 EH. > > Other than HbH, the performance impact generally results from looking > up the L4 header. > > That said, upon re-read of your suggestion, it looks good to me. > > > >>>> [Gont-Chown-IEPG89] >>>> Gont, F. and T. Chown, "A Small Update on the Use of IPv6 >>>> Extension Headers", IEPG 89. London, UK. March 2, 2014, >>>> >>> eh-update.pdf>. >>>> [Gont-IEPG88] >>>> Gont, F., "Fragmentation and Extension header Support in >>>> the IPv6 Internet", IEPG 88. Vancouver, BC, Canada. >>>> November 13, 2013, >>> fgont-iepg-ietf88-ipv6-frag-and-eh.pdf>. >>>>>>> These don’t seem great presentations, and seem like they were >>>>>>> mostly replaced by iepg-ietf90-ipv6-ehs-in-the-real-world-v2.0? >>>>>>> I don’t know why these are useful as references? RC7872 also >>>>>>> covers this? >>> >>> They are listed as they were part of the work that eventually >>> resulted in RFC7872, and as an indication of for how long the >>> problem has been looked into. At the time, we didn't even have tools >>> to do the measurements. For example, the path6 tool I implemented, >>> and the support in RIPE Atlas were triggered by these efforts. >> I don't agree with that. > > Which part, specifically? :-) > > Well, I don't think there were tools available at the time. But if you > know of any, I'd like to know! > >> They are actually cited in RFC7872 if taht is your reason, so that is >> already clear! > > That said, I don't mind removing these two references. They were > including in this document at a time RFC7872 didn't exist -- i.e. we > don't have any special motivation for including them. > Aha - that now make sense, if RFC7872 hadn't been finalised. So removing them would be good for me. > Thanks! > > Regards, -- G. Fairhurst, School of Engineering Gorry From nobody Thu Dec 3 02:57:53 2020 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 002783A0E94; Thu, 3 Dec 2020 02:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=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 oEhLinJ_K5OP; Thu, 3 Dec 2020 02:57:47 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 196D93A0E93; Thu, 3 Dec 2020 02:57:44 -0800 (PST) Received: from [IPv6:2800:810:464:8164:9c91:27c0:253d:5241] (unknown [IPv6:2800:810:464:8164:9c91:27c0:253d:5241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 7CE1D283B84; Thu, 3 Dec 2020 10:57:35 +0000 (UTC) To: Gorry Fairhurst , v6ops@ietf.org Cc: fernando@gont.com.ar, Brian E Carpenter , draft-ietf-v6ops-ipv6-ehs-packet-drops.authors@ietf.org References: <0c121812-44cf-119e-fd09-bb138ff789de@erg.abdn.ac.uk> <676f329d-658b-4398-3b2e-4e8b835686de@si6networks.com> <7b483c43-288b-dc4b-3df8-79d529c7e163@erg.abdn.ac.uk> From: Fernando Gont Message-ID: <59b0ae50-079d-ddca-1cc5-dc478e502d8c@si6networks.com> Date: Thu, 3 Dec 2020 07:57:23 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <7b483c43-288b-dc4b-3df8-79d529c7e163@erg.abdn.ac.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-packet-drops-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 10:57:52 -0000 Hi, Gorry! On 3/12/20 05:32, Gorry Fairhurst wrote: > HI, I think we are converging... Indeed! [....] >>>>> * On the measurement evidence: I have a slight concern that the >>>>> results might not cover the wide variety of use cases and you may >>>>> like to be more careful in the words you use to generalise these >>>>> for the "internet".  I think we should be aware that in some >>>>> scenarios an EH might still be effectively used, where path can >>>>> safely support this. >>>> >>>> We're targeting the general case here. As they say, "with sufficient >>>> thrust, pigs fly just fine". You can, of course, build a network >>>> where EHs can be used just fine. -- but what we're discussing is the >>>> general case. >>>> >>> Why? - as a transport guy, the only thing that matters is whether a >>> specific path supports them, the average case just tells me whether I >>> need a fallback mechanism to cope with a particular path not >>> supporting;-) >> >> The evil comment would be that, as a transport guy, you don't control >> the path. Or, furthermore, there's no concept of "path" for a >> transport guy ;-) >> > We do have the notion of a path... but it may be that is different to > your notion. For curiosity sake: what would be that notion? It would seem to me that, if anything, the transport view of a path is kind of single-hop with varying properties. As opposed to e.g. multiple ways to get to the same destination. i.e., internet-layer could find a working path, where transport cannot. >>>> Some additional comments/questions based on the PDF you've attached: >>>> >>>>> However, common implementation limitations suggest >>>>> that EHs present a challenge for IPv6 packet routing equipment and >>>>> middle-boxes, and evidence exists that IPv6 packets with EHs have been >>>> >>>> Doesn't this imply that this is no longer the case? (i.e. your >>>> proposed change is "have been") >>>> >>>> >>> /have been/are/ ... if that makes better sense to you, they're >>> equivalent to me - you observe what has happens and you can predict >>> what is happening, you might now know the future. >> >> What I mean is that we're not referring to the occurence of some event >> in the past, but rather about something that is still the case. >> > Sure, why not write this is still the case? s/may be/are/? >>>>> As layer-4 port >>>>> information increases the entropy of the hash, it is normally highly >>>>> desirable to use it where possible. >>>>>>>> I don’t agree with that actually, - but maybe others think so, >>>>>>>> please check >>>>>>>> RFCs relating to ECMP or perhaps rephrase, something like: >>>>>>>> /Layer-4 port >>>>> information can increase the entropy of the hash, and is often >>>>> thought desirable to use it where it is available. >>>>> /? >>>> >>>> Your suggested change seems fine to me. That said, what would you >>>> employ for the hash if not the ports? >>>> >>> flow label? >> >> The thing is that you cannot rely on it. So, if you want entropy, your >> safe bet is to use the port numbers.... >> > OK, but I still do not understand why this particular RFC-to-be would > make a judgment on this issue, it is not related to EH, the desire of > some devices to look for transport headers is irrefutable. This happens > for various reasons of which this is one. There are other things that > happen also - but in the context of this document, the text can be > entirely neutral as to whether this is good or bad practice. I'll apply the suggested edit unless I hear otherwise from the group/co-authors. FWIW, the only thing that were meaning was "Yes, we know folks are supposed to use the FL for that... but that's not feasible... hence the *need* to look up the port numbers" >>>>> We note that in the IPv6 world, flows are expected to be identified >>>>> by means of the IPv6 Flow Label [RFC6437]. Thus, ECMP and Hash-based >>>>> Load-Sharing is possible without the need to process the entire >>>>>>>> why /would be possible/ ... some networks do this, and many RFCs >>>>>>>> encourage this? >>>> >>>> Support for the FL is not widely deployed and implemented (see >>>> [Cunha-2020]) >>>> >>> Yes I looked at Cunha - it's just a slide deck - is there a paper >>> that can be read to check the measurement methodology and results? >> >> There's also a paper -- my apologies for not referencing it. I will >> check if it's online, and otherwise ask the author for permission to >> share it. >> > That would help a lot to read that. I've asked for permission to share. Worst-case scenario, I'll send it unicast. >>> I hear others saying that it is now more often being set, ... so I'm >>> just urging caution here, because I am not sure v6OPS need to comment >>> on the results of this on-going work at this stage. For instance... >>> what is the chance that a router now observes a flow label set to >>> non-zero? ... >> >> It's not only to have a non-zero FL, but also that the FL is set >> correctly -- e.g., some implementations used to employ one FL value >> during 3WHS, and another during the life of a connection. Thus, if you >> were using the FL for load-sharing, it would actually break things. >> >> FWIW, I wish the FL was widely and correctly implemented and deployed >> -- I'm just the messenger here. >> > So, I'm urging that the message is represented as saying that at the > time of publication, load-sharing and other techniques utilise the > transport header information [REF]. To access this information, a router > need to process the EH chain, and this leads to issues ... as you decribe. Would this be addressed by: OLD: As layer-4 port information increases the entropy of the hash, it is normally highly desirable to use it where possible. NEW: Most forwarding engines employ layer-4 port information to increase the entropy of the hash, and this implies the need to process the IPv6 header chain, thus leading to the issues discussed in this document. ? >>>>> Perhaps; >>>>> /When many IPv6 >>>>> implementations failed to set the Flow Label, many ECMP and Hash-based >>>>> Load-Sharing devices also did not include the Flow Label [Cunha-2020], >>>>> possibly as a result of issues that have been found >>>>> in host implementations and middle-boxes [Jaeggli-2018]./ >>>>> although it seems like >>>> >>>> The suggested change seems to imply that the situation has changed, >>>> but I believe it hasn't. [Cunha-2020] provides evidence in this >>>> respect. SO assuming that this is something from the past would be >>>> inaccurate. >>>> >>> Well.... we can debate this, if we need to, however:  - i.e., I think >>> the existence of techniques that utilise ports is sufficient to >>> justify why the router wishes to traverse the header chain, and why >>> extension headers are problematic - that does not need to present >>> anything about what is good practice for ECMP without predjudice to >>> deployment of FL-based methods. >> >> What we mean here is: the reader might wonder "why don't you just use >> the FL?  -- Because we can't". >> >> More of empirical evidence than prejudice. > > Observing this happens is helfpul - with more clarity of recent trends > in setting and using. > > However, I will objec interpretation of this to how to use (or not) the > FL. This document is not the correct place to offer this advice. > > One: because this document is not about ECMP and FL, it is about EH. Not sure what you mean. THis section is discussing why some boxes may need to access the layer-4 information. For load-sharing, the reader might wonder "why aren't you using the FL in the first place?" -- that¡s the only reason why we're mentioning the FL here... We're not advising whether to use or not the FL. We're simmply explaining why boxes actually need to access the layer-4 info... > Two: because this is an informational document from an OPS WG trying to > change something that is being used by PS in Transport and Internet areas. I'm a bit lost here. This document is not trying to provide any sort of advice. We essentially elaborate on why boxes need to access layer-4 information, and what are the options they have on the table (if any) if they can't. >>>>>>>> I suggest the section includes mention of the IETF recommendation, >>>>>>>> and there the path with “clearly...” should be at the end! >>>> >>>> Ok with moving the para "Clearly.." to the end. That said, could you >>>> elaborate on what IETF recommendation you're referring to? >>>> >>>>> Use of extension headers can result problematic for NIDS/IPS, since: >>>>>>> /may/can/ ... not necessary, but might as well use /can/ in this >>>>>>> case? >>>> >>>> Doesn't "may" imply possibility here? >>>> >>> No. In many reader's eyes this is permissive ... do it would read are >>> permitted to. >> >> Any alternative wording that would convey "possibility" rather than >> "ability" or "permission"? >> > Trying to be close to your original wording: > > Problems can arise when EH are used for NIDS/IPS, since: Maybe /used for/processed by/ ? >>>>> As a result, in order to increase the efficiency or effectiveness of >>>>> these systems, packets employing IPv6 extension headers can be >>>>>>>> /can/ or /have been/are being/ ... to follow the previous argument? >>>>> dropped at the network ingress point(s) of networks that deploy these >>>>> systems. >>>> >>>> (Must admit that since you're a native English speaker, I have a >>>> high probability of being wrong :-), but, anyway): >>>> >>>> Packets can be drop, whether with EHs or anything else (i.e., the >>>> contents of a packet does not affect the ability of a device >>>> dropping them -- at the end of the day, a device can drop *all* >>>> packets if it feels like). >>>> >>> :-) >>>> What we are meaning here is that dropping packets with EHs is indeed >>>> one option to increase the efficiency and effectiveness of these >>>> systems. >>> That sounds correct. >> >> Would modifying the text as phrased address your comment? >> > Pehaps, you could try something. > > I'd suggest just being neutral and saying: > > As a result, IPS systems have been observed to drop packets employing > IPv6 extension headers at the network ingress point(s). Looks good to me. >>>>> o Use of unknown extension headers can prevent an NIDS/IPS to >>>>> process layer-4 information >>>> >>>> I this case, I think both are fine: -- "can" as in ability, and >>>> "may" as in possibility >>>> >>> - but not may as in "are permitted to"... >> >> Would "could" be better to convey "posibility" rather than ability or >> permission? >> >> > Could is fine. Done ;-) >> >>>>> When such devices are unable to obtain the >>>>> required information, they might simply resort to dropping the >>>>>>>> /may/might/ ? >>>> >>>> "might" reads as a possibly imaginary situation. What we are meaning >>>> is that some devices *do* this. >>>> >>> OK : then say that devices do this,... rather than they are permitted >>> to. >> >> I'll tweak to: >> >> "Some of such devices, when unable to obtain the required information, >> simply resort to...". OK? >> >> > /such/these/ ... seems like a reasonable statement to me:-). Will do. [....] >>> They are actually cited in RFC7872 if taht is your reason, so that is >>> already clear! >> >> That said, I don't mind removing these two references. They were >> including in this document at a time RFC7872 didn't exist -- i.e. we >> don't have any special motivation for including them. >> > Aha - that now make sense, if RFC7872 hadn't been finalised. Indeed, this text (with these references) had been crafted before RFC7872 got published. > So removing them would be good for me. I don't mind, and thus will do unless I hear otherwise from the group. Thanks! Regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Dec 3 03:37:06 2020 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 A96DE3A0657; Thu, 3 Dec 2020 03:37:04 -0800 (PST) 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=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 H_gfN71n2YVc; Thu, 3 Dec 2020 03:37:02 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5649A3A0656; Thu, 3 Dec 2020 03:37:00 -0800 (PST) Received: from Gs-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 7F38F1B00179; Thu, 3 Dec 2020 11:36:53 +0000 (GMT) To: Fernando Gont , v6ops@ietf.org Cc: fernando@gont.com.ar, Brian E Carpenter , draft-ietf-v6ops-ipv6-ehs-packet-drops.authors@ietf.org References: <0c121812-44cf-119e-fd09-bb138ff789de@erg.abdn.ac.uk> <676f329d-658b-4398-3b2e-4e8b835686de@si6networks.com> <7b483c43-288b-dc4b-3df8-79d529c7e163@erg.abdn.ac.uk> <59b0ae50-079d-ddca-1cc5-dc478e502d8c@si6networks.com> From: Gorry Fairhurst Message-ID: <7fade404-4f91-571c-a88e-dc9551cba41a@erg.abdn.ac.uk> Date: Thu, 3 Dec 2020 11:36:52 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <59b0ae50-079d-ddca-1cc5-dc478e502d8c@si6networks.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-packet-drops-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 11:37:05 -0000 See below On 03/12/2020 10:57, Fernando Gont wrote: > Hi, Gorry! > > On 3/12/20 05:32, Gorry Fairhurst wrote: >> HI, I think we are converging... > > Indeed! > > > [....] >>>>>> * On the measurement evidence: I have a slight concern that the >>>>>> results might not cover the wide variety of use cases and you may >>>>>> like to be more careful in the words you use to generalise these >>>>>> for the "internet".  I think we should be aware that in some >>>>>> scenarios an EH might still be effectively used, where path can >>>>>> safely support this. >>>>> >>>>> We're targeting the general case here. As they say, "with >>>>> sufficient thrust, pigs fly just fine". You can, of course, build >>>>> a network where EHs can be used just fine. -- but what we're >>>>> discussing is the general case. >>>>> >>>> Why? - as a transport guy, the only thing that matters is whether a >>>> specific path supports them, the average case just tells me whether >>>> I need a fallback mechanism to cope with a particular path not >>>> supporting;-) >>> >>> The evil comment would be that, as a transport guy, you don't >>> control the path. Or, furthermore, there's no concept of "path" for >>> a transport guy ;-) >>> >> We do have the notion of a path... but it may be that is different to >> your notion. > > For curiosity sake: what would be that notion?  It would seem to me > that, if anything, the transport view of a path is kind of single-hop > with varying properties.  As opposed to e.g. multiple ways to get to > the same destination. > > i.e., internet-layer could find a working path, where transport cannot. > The transport can sometimes choose between paths it sees available. Most of the concern of the transport is to characterise the current actual path(s) - discovering the PMTU - i.e. the largest size of packet are not forwarded, discovering if certain headers are not forwarded, often trying to determine the current capacity, rtt, jitter, reordering, etc. Possibly trying to associate QoS or other information with packets in a flow to influence the network path. etc. > >>>>> Some additional comments/questions based on the PDF you've attached: >>>>> >>>>>> However, common implementation limitations suggest >>>>>> that EHs present a challenge for IPv6 packet routing equipment and >>>>>> middle-boxes, and evidence exists that IPv6 packets with EHs have >>>>>> been >>>>> >>>>> Doesn't this imply that this is no longer the case? (i.e. your >>>>> proposed change is "have been") >>>>> >>>>> >>>> /have been/are/ ... if that makes better sense to you, they're >>>> equivalent to me - you observe what has happens and you can predict >>>> what is happening, you might now know the future. >>> >>> What I mean is that we're not referring to the occurence of some >>> event in the past, but rather about something that is still the case. >>> >> Sure, why not write this is still the case? > > s/may be/are/? > > Fine with me. > >>>>>> As layer-4 port >>>>>> information increases the entropy of the hash, it is normally highly >>>>>> desirable to use it where possible. >>>>>>>>> I don’t agree with that actually, - but maybe others think so, >>>>>>>>> please check >>>>>>>>> RFCs relating to ECMP or perhaps rephrase, something like: >>>>>>>>> /Layer-4 port >>>>>> information can increase the entropy of the hash, and is often >>>>>> thought desirable to use it where it is available. >>>>>> /? >>>>> >>>>> Your suggested change seems fine to me. That said, what would you >>>>> employ for the hash if not the ports? >>>>> >>>> flow label? >>> >>> The thing is that you cannot rely on it. So, if you want entropy, >>> your safe bet is to use the port numbers.... >>> >> OK, but I still do not understand why this particular RFC-to-be would >> make a judgment on this issue, it is not related to EH, the desire of >> some devices to look for transport headers is irrefutable. This >> happens for various reasons of which this is one. There are other >> things that happen also - but in the context of this document, the >> text can be entirely neutral as to whether this is good or bad practice. > > I'll apply the suggested edit unless I hear otherwise from the > group/co-authors. > > FWIW, the only thing that were meaning was "Yes, we know folks are > supposed to use the FL for that... but that's not feasible... hence > the *need* to look up the port numbers" > > > > >>>>>> We note that in the IPv6 world, flows are expected to be identified >>>>>> by means of the IPv6 Flow Label [RFC6437]. Thus, ECMP and Hash-based >>>>>> Load-Sharing is possible without the need to process the entire >>>>>>>>> why /would be possible/ ... some networks do this, and many >>>>>>>>> RFCs encourage this? >>>>> >>>>> Support for the FL is not widely deployed and implemented (see >>>>> [Cunha-2020]) >>>>> >>>> Yes I looked at Cunha - it's just a slide deck - is there a paper >>>> that can be read to check the measurement methodology and results? >>> >>> There's also a paper -- my apologies for not referencing it. I will >>> check if it's online, and otherwise ask the author for permission to >>> share it. >>> >> That would help a lot to read that. > > I've asked for permission to share. Worst-case scenario, I'll send it > unicast. > > Look foward to learning more. > > >>>> I hear others saying that it is now more often being set, ... so >>>> I'm just urging caution here, because I am not sure v6OPS need to >>>> comment on the results of this on-going work at this stage. For >>>> instance... what is the chance that a router now observes a flow >>>> label set to non-zero? ... >>> >>> It's not only to have a non-zero FL, but also that the FL is set >>> correctly -- e.g., some implementations used to employ one FL value >>> during 3WHS, and another during the life of a connection. Thus, if >>> you were using the FL for load-sharing, it would actually break things. >>> >>> FWIW, I wish the FL was widely and correctly implemented and >>> deployed -- I'm just the messenger here. >>> >> So, I'm urging that the message is represented as saying that at the >> time of publication, load-sharing and other techniques utilise the >> transport header information [REF]. To access this information, a >> router need to process the EH chain, and this leads to issues ... as >> you decribe. > > Would this be addressed by: > > OLD: > As layer-4 port >    information increases the entropy of the hash, it is normally highly >    desirable to use it where possible. > > NEW: >    Most forwarding engines employ layer-4 port information to increase >    the entropy of the hash, and this implies the need to process the >    IPv6 header chain, thus leading to the issues discussed in this >    document. > > ? > Hmmm... can we more neutral: "Forwarding engines that employ layer-4 port information to increase    the entropy of the hash have a need to process the    IPv6 header chain, thus leading to the issues discussed in this    document." > >>>>>> Perhaps; >>>>>> /When many IPv6 >>>>>> implementations failed to set the Flow Label, many ECMP and >>>>>> Hash-based >>>>>> Load-Sharing devices also did not include the Flow Label >>>>>> [Cunha-2020], >>>>>> possibly as a result of issues that have been found >>>>>> in host implementations and middle-boxes [Jaeggli-2018]./ >>>>>> although it seems like >>>>> >>>>> The suggested change seems to imply that the situation has >>>>> changed, but I believe it hasn't. [Cunha-2020] provides evidence >>>>> in this respect. SO assuming that this is something from the past >>>>> would be inaccurate. >>>>> >>>> Well.... we can debate this, if we need to, however:  - i.e., I >>>> think the existence of techniques that utilise ports is sufficient >>>> to justify why the router wishes to traverse the header chain, and >>>> why extension headers are problematic - that does not need to >>>> present anything about what is good practice for ECMP without >>>> predjudice to deployment of FL-based methods. >>> >>> What we mean here is: the reader might wonder "why don't you just >>> use the FL?  -- Because we can't". >>> >>> More of empirical evidence than prejudice. >> >> Observing this happens is helfpul - with more clarity of recent >> trends in setting and using. >> >> However, I will objec interpretation of this to how to use (or not) >> the FL. This document is not the correct place to offer this advice. >> >> One: because this document is not about ECMP and FL, it is about EH. > > Not sure what you mean. THis section is discussing why some boxes may > need to access the layer-4 information. For load-sharing, the reader > might wonder "why aren't you using the FL in the first place?" -- > that¡s the only reason why we're mentioning the FL here... > > We're not advising whether to use or not the FL. We're simmply > explaining why boxes actually need to access the layer-4 info... > >> Two: because this is an informational document from an OPS WG trying >> to change something that is being used by PS in Transport and >> Internet areas. > > I'm a bit lost here. This document is not trying to provide any sort > of advice. We essentially elaborate on why boxes need to access > layer-4 information, and what are the options they have on the table > (if any) if they can't. > See above suggestion about how you might take a more neutral position? > >>>>>>>>> I suggest the section includes mention of the IETF >>>>>>>>> recommendation, >>>>>>>>> and there the path with “clearly...” should be at the end! >>>>> >>>>> Ok with moving the para "Clearly.." to the end. That said, could >>>>> you elaborate on what IETF recommendation you're referring to? >>>>> >>>>>> Use of extension headers can result problematic for NIDS/IPS, since: >>>>>>>> /may/can/ ... not necessary, but might as well use /can/ in >>>>>>>> this case? >>>>> >>>>> Doesn't "may" imply possibility here? >>>>> >>>> No. In many reader's eyes this is permissive ... do it would read >>>> are permitted to. >>> >>> Any alternative wording that would convey "possibility" rather than >>> "ability" or "permission"? >>> >> Trying to be close to your original wording: >> >> Problems can arise when EH are used for NIDS/IPS, since: > > Maybe /used for/processed by/ ? > > Much better. > >>>>>> As a result, in order to increase the efficiency or effectiveness of >>>>>> these systems, packets employing IPv6 extension headers can be >>>>>>>>> /can/ or /have been/are being/ ... to follow the previous >>>>>>>>> argument? >>>>>> dropped at the network ingress point(s) of networks that deploy >>>>>> these >>>>>> systems. >>>>> >>>>> (Must admit that since you're a native English speaker, I have a >>>>> high probability of being wrong :-), but, anyway): >>>>> >>>>> Packets can be drop, whether with EHs or anything else (i.e., the >>>>> contents of a packet does not affect the ability of a device >>>>> dropping them -- at the end of the day, a device can drop *all* >>>>> packets if it feels like). >>>>> >>>> :-) >>>>> What we are meaning here is that dropping packets with EHs is >>>>> indeed one option to increase the efficiency and effectiveness of >>>>> these systems. >>>> That sounds correct. >>> >>> Would modifying the text as phrased address your comment? >>> >> Pehaps, you could try something. >> >> I'd suggest just being neutral and saying: >> >> As a result, IPS systems have been observed to drop packets employing >> IPv6 extension headers at the network ingress point(s). > > Looks good to me. > > > >>>>>> o Use of unknown extension headers can prevent an NIDS/IPS to >>>>>> process layer-4 information >>>>> >>>>> I this case, I think both are fine: -- "can" as in ability, and >>>>> "may" as in possibility >>>>> >>>> - but not may as in "are permitted to"... >>> >>> Would "could" be better to convey "posibility" rather than ability >>> or permission? >>> >>> >> Could is fine. > > Done ;-) > > >>> >>>>>> When such devices are unable to obtain the >>>>>> required information, they might simply resort to dropping the >>>>>>>>> /may/might/ ? >>>>> >>>>> "might" reads as a possibly imaginary situation. What we are >>>>> meaning is that some devices *do* this. >>>>> >>>> OK : then say that devices do this,... rather than they are >>>> permitted to. >>> >>> I'll tweak to: >>> >>> "Some of such devices, when unable to obtain the required >>> information, simply resort to...". OK? >>> >>> >> /such/these/ ... seems like a reasonable statement to me:-). > > Will do. > > > [....] >>>> They are actually cited in RFC7872 if taht is your reason, so that >>>> is already clear! >>> >>> That said, I don't mind removing these two references. They were >>> including in this document at a time RFC7872 didn't exist -- i.e. we >>> don't have any special motivation for including them. >>> >> Aha - that now make sense, if RFC7872 hadn't been finalised. > > Indeed, this text (with these references) had been crafted before > RFC7872 got published. > > >> So removing  them would be good for me. > > I don't mind, and thus will do unless I hear otherwise from the group. > > Thanks! > > Regards, -- G. Fairhurst, School of Engineering Gorry From nobody Thu Dec 3 07:37:46 2020 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 7EE093A0E94; Thu, 3 Dec 2020 07:37:44 -0800 (PST) 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 6CjTJwOafV1b; Thu, 3 Dec 2020 07:37:36 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62E983A0EA4; Thu, 3 Dec 2020 07:37:35 -0800 (PST) Received: from [IPv6:2800:810:464:8164:9c91:27c0:253d:5241] (unknown [IPv6:2800:810:464:8164:9c91:27c0:253d:5241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 17F7C283833; Thu, 3 Dec 2020 15:37:30 +0000 (UTC) To: Gorry Fairhurst , v6ops@ietf.org Cc: fernando@gont.com.ar, Brian E Carpenter , draft-ietf-v6ops-ipv6-ehs-packet-drops.authors@ietf.org References: <0c121812-44cf-119e-fd09-bb138ff789de@erg.abdn.ac.uk> <676f329d-658b-4398-3b2e-4e8b835686de@si6networks.com> <7b483c43-288b-dc4b-3df8-79d529c7e163@erg.abdn.ac.uk> <59b0ae50-079d-ddca-1cc5-dc478e502d8c@si6networks.com> <7fade404-4f91-571c-a88e-dc9551cba41a@erg.abdn.ac.uk> From: Fernando Gont Message-ID: <50597c7d-32ac-6df0-0a6f-ea1f02a4497c@si6networks.com> Date: Thu, 3 Dec 2020 12:29:36 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <7fade404-4f91-571c-a88e-dc9551cba41a@erg.abdn.ac.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-packet-drops-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 15:37:45 -0000 Hi, Gorry, BTW, Italo noted that he has posted the paper on his site, so it's available here [CUnha-2020]: https://homepages.dcc.ufmg.br/~cunha/papers/almeida20infocom-mca.pdf In-line... On 3/12/20 08:36, Gorry Fairhurst wrote: [....] >>>> >>> We do have the notion of a path... but it may be that is different to >>> your notion. >> >> For curiosity sake: what would be that notion?  It would seem to me >> that, if anything, the transport view of a path is kind of single-hop >> with varying properties.  As opposed to e.g. multiple ways to get to >> the same destination. >> >> i.e., internet-layer could find a working path, where transport cannot. >> > The transport can sometimes choose between paths it sees available. How would it? -- It'd seem to me that it could at most pick pairs of {Src, Dst} (but actually, probably it wouldn't/shouldn't, if node identifiers (as opposed to interface identifiers) were used for the connection-id). [....] [...] >>>> >>>> There's also a paper -- my apologies for not referencing it. I will >>>> check if it's online, and otherwise ask the author for permission to >>>> share it. >>>> >>> That would help a lot to read that. >> >> I've asked for permission to share. Worst-case scenario, I'll send it >> unicast. >> > Look foward to learning more. Please see above. >>>>> I hear others saying that it is now more often being set, ... so >>>>> I'm just urging caution here, because I am not sure v6OPS need to >>>>> comment on the results of this on-going work at this stage. For >>>>> instance... what is the chance that a router now observes a flow >>>>> label set to non-zero? ... >>>> >>>> It's not only to have a non-zero FL, but also that the FL is set >>>> correctly -- e.g., some implementations used to employ one FL value >>>> during 3WHS, and another during the life of a connection. Thus, if >>>> you were using the FL for load-sharing, it would actually break things. >>>> >>>> FWIW, I wish the FL was widely and correctly implemented and >>>> deployed -- I'm just the messenger here. >>>> >>> So, I'm urging that the message is represented as saying that at the >>> time of publication, load-sharing and other techniques utilise the >>> transport header information [REF]. To access this information, a >>> router need to process the EH chain, and this leads to issues ... as >>> you decribe. >> >> Would this be addressed by: >> >> OLD: >> As layer-4 port >>    information increases the entropy of the hash, it is normally highly >>    desirable to use it where possible. >> >> NEW: >>    Most forwarding engines employ layer-4 port information to increase >>    the entropy of the hash, and this implies the need to process the >>    IPv6 header chain, thus leading to the issues discussed in this >>    document. >> >> ? >> > Hmmm... can we more neutral: > > "Forwarding engines that employ layer-4 port information to increase >    the entropy of the hash have a need to process the >    IPv6 header chain, thus leading to the issues discussed in this >    document." Fine for me (FWIW, the intent was to be neutral.. although at times it's hard to author and "review" from the eyes of a read at the same time.. So apologies for the pain caused... :-) ) (Ive omitted the proposed changes that didn't need further discussion) P.S: I'll rev the document this next weekend as the latest. Thanks for helping us improve the document, btw! Regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Dec 3 07:44:07 2020 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 935633A0EAA; Thu, 3 Dec 2020 07:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 qo-N9eojRrwy; Thu, 3 Dec 2020 07:44:00 -0800 (PST) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 406B43A0EA8; Thu, 3 Dec 2020 07:44:00 -0800 (PST) Received: by mail-ot1-x32e.google.com with SMTP id 11so2119750oty.9; Thu, 03 Dec 2020 07:44:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+kFh6OdL+UxMA8YmIOFfjtBDc7L5ECoTMxS3zuGZvCs=; b=YbBL7UoB8stOdenoDlgvmWjmK0F9r/QusBVcjr2uzassJN4QyaRu4YT72i4RtHvahg Cvq57cdtNiqKFXPYXmYs25bVHEvRj0uOM4NNm5kvY40Izri3r36dqAhfWnFee8D7bKd0 n+HTgoBGUP2gMK/YLncMKcetKg/Ptw2wHCQ2na2dZDYoi4wQa6DOrT3TqylVDk/MoIX7 xsIbE7bWM8lkhj+4wSelSPjq3oIMpLa2xN/H/1EluIOGhidqbiAZi9BqcUhYzODdD2Ry TBVLlt/fVOYNMkiO4FNTf37Rz6t5aVEZFNfcsRJd6QHGHARW5CtQc8CzG/tJR2st/wf4 vMnw== 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=+kFh6OdL+UxMA8YmIOFfjtBDc7L5ECoTMxS3zuGZvCs=; b=bVKu1cdZRNcO4oWxP5x6mhBDIKaOBk1zREjKgdD1f/9n0BU7Z9BefrDdug7byTw/AP +Rkdb91nLrmq+6xYRRUWD0esFFjKszx5gZmbIREFmO9BwtIJiVtFHU4AUpOHsnWvmWHT NOBsEO2mDa4ihI/1PMIL1383veBJQ7XclGibzYY1KPKg7d7xW0CwNIHmWWhXowPVtspo S2roF0/wfmrGyYMo8MN2URwokK5TfsiSmF8pi25RHjYzMuwZAdbJD3Q8H2obHrJe+8ey HH8T6sRPks/b9Bq7cUMF04HU9mX6eGPvoZxF9Gaw2aLldRxgogC9QRIae6+faOPmDwfC 9BRA== X-Gm-Message-State: AOAM532z2hBA0Pd01lT//LXT4oBhfp5Di/MRpu+Hq6AEkDXzOzPPluhH 9G8iWv+xIwiWnGHnTHG+H9WQRCqTuWHnZHJN2lEnlOwL/t4= X-Google-Smtp-Source: ABdhPJz8I3Inx3vi4c5yjmgSdh3eJCyyi7m44gfgI9Ijar4SI8PQlahAB2F2Lgb9mRVyQ4Vz6QqOkiCrXVPa9efRYNo= X-Received: by 2002:a9d:62cb:: with SMTP id z11mr2444166otk.191.1607010239448; Thu, 03 Dec 2020 07:43:59 -0800 (PST) MIME-Version: 1.0 References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> <0d38980a-f1c5-fac5-a9b1-0711d61353d1@gont.com.ar> <42b6e327-08b5-292b-be65-28f1a8508a69@si6networks.com> In-Reply-To: <42b6e327-08b5-292b-be65-28f1a8508a69@si6networks.com> From: Erik Kline Date: Thu, 3 Dec 2020 07:43:48 -0800 Message-ID: To: Fernando Gont Cc: Tom Herbert , Fernando Gont , IPv6 Operations , tcpm Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] [tcpm] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 15:44:02 -0000 > > Please include requirements for both hosts and network nodes. If there > > is going to the be a requirement that hosts MUST make a 1:1 mapping to > > a transport connection and the flow label MUST be consistent for the > > life of connection, then I would expect there to also be a requirement > > that the flow label MUST be immutable by all devices in the path-- in > > particular the requirement of RFC6437 would need to be updated: "A > > forwarding node MUST either leave a non-zero flow label value > > unchanged or change it only for compelling operational security > > reasons..."-- if hosts are not allowed to change a field they are > > primarily responsible for setting, then the network should not be > > allowed to modify it either. > > I don't recall _(of the top of my head) why we ended up making the field > mutable ("SHOULD NOT be modified" rather than "MUST NOT.."). IIRC, it > had to do with allowing middle-boxes to mitigate FL-based covert > channels. If that's the case (Brian CC'ed) then, in retrospective, that > seems to have been a bad idea. -- I was part of the discussion, so I > take my share of blame. :-) My understanding/recollection is that since there were never any restrictions on modification of the flow label from the very beginning it wasn't super meaningful to try to close the barn door after all these years. From nobody Thu Dec 3 08:08:51 2020 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 38D073A0EB2; Thu, 3 Dec 2020 08:08:50 -0800 (PST) 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 l-dL_QExK2jU; Thu, 3 Dec 2020 08:08:47 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10D833A0E29; Thu, 3 Dec 2020 08:08:46 -0800 (PST) Received: from [IPv6:2800:810:464:8164:9c91:27c0:253d:5241] (unknown [IPv6:2800:810:464:8164:9c91:27c0:253d:5241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id C0E242803C8; Thu, 3 Dec 2020 16:08:42 +0000 (UTC) To: Erik Kline Cc: Tom Herbert , Fernando Gont , IPv6 Operations , tcpm References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> <0d38980a-f1c5-fac5-a9b1-0711d61353d1@gont.com.ar> <42b6e327-08b5-292b-be65-28f1a8508a69@si6networks.com> From: Fernando Gont Message-ID: <86de5b0a-73b1-320a-166b-152567d4e313@si6networks.com> Date: Thu, 3 Dec 2020 13:08:03 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] [tcpm] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 16:08:50 -0000 On 3/12/20 12:43, Erik Kline wrote: >>> Please include requirements for both hosts and network nodes. If there >>> is going to the be a requirement that hosts MUST make a 1:1 mapping to >>> a transport connection and the flow label MUST be consistent for the >>> life of connection, then I would expect there to also be a requirement >>> that the flow label MUST be immutable by all devices in the path-- in >>> particular the requirement of RFC6437 would need to be updated: "A >>> forwarding node MUST either leave a non-zero flow label value >>> unchanged or change it only for compelling operational security >>> reasons..."-- if hosts are not allowed to change a field they are >>> primarily responsible for setting, then the network should not be >>> allowed to modify it either. >> >> I don't recall _(of the top of my head) why we ended up making the field >> mutable ("SHOULD NOT be modified" rather than "MUST NOT.."). IIRC, it >> had to do with allowing middle-boxes to mitigate FL-based covert >> channels. If that's the case (Brian CC'ed) then, in retrospective, that >> seems to have been a bad idea. -- I was part of the discussion, so I >> take my share of blame. :-) > > My understanding/recollection is that since there were never any > restrictions on modification of the flow label from the very beginning > it wasn't super meaningful to try to close the barn door after all > these years. Well, yeah, but there was also no use of the FL, either ;-) . And for load-balancing among a group of servers, you need the FL to be stable for the life of the flow, or otherwise packet may end up ebig delivered to different servers. Otherwise, the FL is likely to be inored, and we'll continue figuring out what to use those 20 bits for... Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Dec 3 09:02:51 2020 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 414E83A091B for ; Thu, 3 Dec 2020 09:02:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=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 XL5nXofrs6EA for ; Thu, 3 Dec 2020 09:02:48 -0800 (PST) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 B20773A08D6 for ; Thu, 3 Dec 2020 09:02:47 -0800 (PST) Received: by mail-ed1-x52b.google.com with SMTP id d18so2841873edt.7 for ; Thu, 03 Dec 2020 09:02:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=UEeLxtG6NamhCR7Gw3Apk87QgqXuzqwCTFGuePm+lso=; b=xfvXEUleaBGKlua9UL3f5gWc3sq5UYbckRvzpH9d61KWaJXUh9rFykoSfPZDz0/kmP tCFkm57uwPy5WOPnrzr5n8F7XDydO8ajbl11GzPwjgCOHy53flj5Tmhaq5DnlKGT+ni7 g+LRRhEgqjmF576AHShBei8jTv3GkHZa+1cCkrPH0W0Boar0Ie8YPCuX2YCeSkVHbw7w z0oJQB7mGYlTgUF0NBZekOyn6Ln+/QOy6CDgpLvIr4rkSAIbCvrZ1eOmBLothkvGIcZj MDKmj/abBMUT7opLZ4JLfy6wmbRzoeBPycaTZgRyLbOQiyJ2BKM0XlVEAzjNPDv38L2I IL/Q== 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=UEeLxtG6NamhCR7Gw3Apk87QgqXuzqwCTFGuePm+lso=; b=njBZ78DpZLClU9AkmIVFKJ205l8cuK764CyMPHppPCzH4Pj25qQiGWtKSOV7wV0Z4/ MM9YwddsZ0P/8dJGGVtY2miuRIRysg6kuLwiasZ7Vf0vMZ017r5gZGrjpitCiTXFfllr qeUfLSs5dHxRh8iisM2OSYV/2AbSv0uy25SclpozH0Sn+Fiqhfzrg5oJbzKSWUZsiV0n HQpYV+094Mytg77RxQ+ERJ0bhqJh/R2/54zEKN+vSkEL6/n2oIYa+rQ1+A9As2O8ngmc cOX55Vn4PHFLgUzawKn/Hu46tmcbmI4jVpCNZAqN67UxHcNcj42FHrtTINQwp7icmVw8 Avng== X-Gm-Message-State: AOAM5332gnO1XEbCt0cQjqJRdtXEtVjok1FikDVRbccD484V0rsQ8Pu6 CEZgfW3T83y89wDM6P4zOdquNtuBCmM/T5wHG1lGcg== X-Google-Smtp-Source: ABdhPJzHAUZWrIyPVapxhyOctxK4Z9N4RKCZpe91PFb9PILaZqvrhmyhPYFzAXFR9HseRrMHohp6+FHbgBZF2ZVa2N4= X-Received: by 2002:a05:6402:114b:: with SMTP id g11mr3764164edw.228.1607014965791; Thu, 03 Dec 2020 09:02:45 -0800 (PST) MIME-Version: 1.0 References: <0c121812-44cf-119e-fd09-bb138ff789de@erg.abdn.ac.uk> <676f329d-658b-4398-3b2e-4e8b835686de@si6networks.com> <7b483c43-288b-dc4b-3df8-79d529c7e163@erg.abdn.ac.uk> <59b0ae50-079d-ddca-1cc5-dc478e502d8c@si6networks.com> In-Reply-To: <59b0ae50-079d-ddca-1cc5-dc478e502d8c@si6networks.com> From: Tom Herbert Date: Thu, 3 Dec 2020 10:02:33 -0700 Message-ID: To: Fernando Gont Cc: Gorry Fairhurst , IPv6 Operations , draft-ietf-v6ops-ipv6-ehs-packet-drops.authors@ietf.org, Fernando Gont Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-packet-drops-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 17:02:50 -0000 On Thu, Dec 3, 2020 at 3:58 AM Fernando Gont wrote: > > Hi, Gorry! > > On 3/12/20 05:32, Gorry Fairhurst wrote: > > HI, I think we are converging... > > Indeed! > > > [....] > >>>>> * On the measurement evidence: I have a slight concern that the > >>>>> results might not cover the wide variety of use cases and you may > >>>>> like to be more careful in the words you use to generalise these > >>>>> for the "internet". I think we should be aware that in some > >>>>> scenarios an EH might still be effectively used, where path can > >>>>> safely support this. > >>>> > >>>> We're targeting the general case here. As they say, "with sufficient > >>>> thrust, pigs fly just fine". You can, of course, build a network > >>>> where EHs can be used just fine. -- but what we're discussing is the > >>>> general case. > >>>> > >>> Why? - as a transport guy, the only thing that matters is whether a > >>> specific path supports them, the average case just tells me whether I > >>> need a fallback mechanism to cope with a particular path not > >>> supporting;-) > >> > >> The evil comment would be that, as a transport guy, you don't control > >> the path. Or, furthermore, there's no concept of "path" for a > >> transport guy ;-) > >> > > We do have the notion of a path... but it may be that is different to > > your notion. > > For curiosity sake: what would be that notion? It would seem to me > that, if anything, the transport view of a path is kind of single-hop > with varying properties. As opposed to e.g. multiple ways to get to the > same destination. > > i.e., internet-layer could find a working path, where transport cannot. > > > > >>>> Some additional comments/questions based on the PDF you've attached: > >>>> > >>>>> However, common implementation limitations suggest > >>>>> that EHs present a challenge for IPv6 packet routing equipment and > >>>>> middle-boxes, and evidence exists that IPv6 packets with EHs have b= een > >>>> > >>>> Doesn't this imply that this is no longer the case? (i.e. your > >>>> proposed change is "have been") > >>>> > >>>> > >>> /have been/are/ ... if that makes better sense to you, they're > >>> equivalent to me - you observe what has happens and you can predict > >>> what is happening, you might now know the future. > >> > >> What I mean is that we're not referring to the occurence of some event > >> in the past, but rather about something that is still the case. > >> > > Sure, why not write this is still the case? > > s/may be/are/? > > > > >>>>> As layer-4 port > >>>>> information increases the entropy of the hash, it is normally highl= y > >>>>> desirable to use it where possible. > >>>>>>>> I don=E2=80=99t agree with that actually, - but maybe others thi= nk so, > >>>>>>>> please check > >>>>>>>> RFCs relating to ECMP or perhaps rephrase, something like: > >>>>>>>> /Layer-4 port > >>>>> information can increase the entropy of the hash, and is often > >>>>> thought desirable to use it where it is available. > >>>>> /? > >>>> > >>>> Your suggested change seems fine to me. That said, what would you > >>>> employ for the hash if not the ports? > >>>> > >>> flow label? > >> > >> The thing is that you cannot rely on it. So, if you want entropy, your > >> safe bet is to use the port numbers.... > >> > > OK, but I still do not understand why this particular RFC-to-be would > > make a judgment on this issue, it is not related to EH, the desire of > > some devices to look for transport headers is irrefutable. This happens > > for various reasons of which this is one. There are other things that > > happen also - but in the context of this document, the text can be > > entirely neutral as to whether this is good or bad practice. > > I'll apply the suggested edit unless I hear otherwise from the > group/co-authors. > > FWIW, the only thing that were meaning was "Yes, we know folks are > supposed to use the FL for that... but that's not feasible... hence the > *need* to look up the port numbers" > Fernando, There is no protocol requirement that "folks", I assume meaning intermediate devices, need use the flow label nor transport port numbers for anything, neither is there any requirement that hosts have to expose port numbers in plain text or set a non-zero flow label. These are both optional and best-effort by definition; RFC6437 describes how flow labels are only best effort, and RFC7605 describes the perils of intermediate devices attempting to interpret port numbers. As for using flow labels not being feasible I don't see the basis for that statement. There are deployed devices that have been using flow labels for various purposes for quite a while, for instance Linux OS has been setting and consuming non-zero flow labels for years in both host and router configurations for RSS, ECMP, etc. Yes, like anything else we occasionally encounter issues and sometimes they hit interoperable devices, but we do fix issues and haven't declared they aren't feasible. Tom > > > >>>>> We note that in the IPv6 world, flows are expected to be identified > >>>>> by means of the IPv6 Flow Label [RFC6437]. Thus, ECMP and Hash-base= d > >>>>> Load-Sharing is possible without the need to process the entire > >>>>>>>> why /would be possible/ ... some networks do this, and many RFCs > >>>>>>>> encourage this? > >>>> > >>>> Support for the FL is not widely deployed and implemented (see > >>>> [Cunha-2020]) > >>>> > >>> Yes I looked at Cunha - it's just a slide deck - is there a paper > >>> that can be read to check the measurement methodology and results? > >> > >> There's also a paper -- my apologies for not referencing it. I will > >> check if it's online, and otherwise ask the author for permission to > >> share it. > >> > > That would help a lot to read that. > > I've asked for permission to share. Worst-case scenario, I'll send it > unicast. > > > > > >>> I hear others saying that it is now more often being set, ... so I'm > >>> just urging caution here, because I am not sure v6OPS need to comment > >>> on the results of this on-going work at this stage. For instance... > >>> what is the chance that a router now observes a flow label set to > >>> non-zero? ... > >> > >> It's not only to have a non-zero FL, but also that the FL is set > >> correctly -- e.g., some implementations used to employ one FL value > >> during 3WHS, and another during the life of a connection. Thus, if you > >> were using the FL for load-sharing, it would actually break things. > >> > >> FWIW, I wish the FL was widely and correctly implemented and deployed > >> -- I'm just the messenger here. > >> > > So, I'm urging that the message is represented as saying that at the > > time of publication, load-sharing and other techniques utilise the > > transport header information [REF]. To access this information, a route= r > > need to process the EH chain, and this leads to issues ... as you decri= be. > > Would this be addressed by: > > OLD: > As layer-4 port > information increases the entropy of the hash, it is normally highly > desirable to use it where possible. > > NEW: > Most forwarding engines employ layer-4 port information to increase > the entropy of the hash, and this implies the need to process the > IPv6 header chain, thus leading to the issues discussed in this > document. > > ? > > > >>>>> Perhaps; > >>>>> /When many IPv6 > >>>>> implementations failed to set the Flow Label, many ECMP and Hash-ba= sed > >>>>> Load-Sharing devices also did not include the Flow Label [Cunha-202= 0], > >>>>> possibly as a result of issues that have been found > >>>>> in host implementations and middle-boxes [Jaeggli-2018]./ > >>>>> although it seems like > >>>> > >>>> The suggested change seems to imply that the situation has changed, > >>>> but I believe it hasn't. [Cunha-2020] provides evidence in this > >>>> respect. SO assuming that this is something from the past would be > >>>> inaccurate. > >>>> > >>> Well.... we can debate this, if we need to, however: - i.e., I think > >>> the existence of techniques that utilise ports is sufficient to > >>> justify why the router wishes to traverse the header chain, and why > >>> extension headers are problematic - that does not need to present > >>> anything about what is good practice for ECMP without predjudice to > >>> deployment of FL-based methods. > >> > >> What we mean here is: the reader might wonder "why don't you just use > >> the FL? -- Because we can't". > >> > >> More of empirical evidence than prejudice. > > > > Observing this happens is helfpul - with more clarity of recent trends > > in setting and using. > > > > However, I will objec interpretation of this to how to use (or not) the > > FL. This document is not the correct place to offer this advice. > > > > One: because this document is not about ECMP and FL, it is about EH. > > Not sure what you mean. THis section is discussing why some boxes may > need to access the layer-4 information. For load-sharing, the reader > might wonder "why aren't you using the FL in the first place?" -- that=C2= =A1s > the only reason why we're mentioning the FL here... > > We're not advising whether to use or not the FL. We're simmply > explaining why boxes actually need to access the layer-4 info... > > > > > Two: because this is an informational document from an OPS WG trying to > > change something that is being used by PS in Transport and Internet are= as. > > I'm a bit lost here. This document is not trying to provide any sort of > advice. We essentially elaborate on why boxes need to access layer-4 > information, and what are the options they have on the table (if any) if > they can't. > > > > >>>>>>>> I suggest the section includes mention of the IETF recommendatio= n, > >>>>>>>> and there the path with =E2=80=9Cclearly...=E2=80=9D should be a= t the end! > >>>> > >>>> Ok with moving the para "Clearly.." to the end. That said, could you > >>>> elaborate on what IETF recommendation you're referring to? > >>>> > >>>>> Use of extension headers can result problematic for NIDS/IPS, since= : > >>>>>>> /may/can/ ... not necessary, but might as well use /can/ in this > >>>>>>> case? > >>>> > >>>> Doesn't "may" imply possibility here? > >>>> > >>> No. In many reader's eyes this is permissive ... do it would read are > >>> permitted to. > >> > >> Any alternative wording that would convey "possibility" rather than > >> "ability" or "permission"? > >> > > Trying to be close to your original wording: > > > > Problems can arise when EH are used for NIDS/IPS, since: > > Maybe /used for/processed by/ ? > > > > >>>>> As a result, in order to increase the efficiency or effectiveness o= f > >>>>> these systems, packets employing IPv6 extension headers can be > >>>>>>>> /can/ or /have been/are being/ ... to follow the previous argume= nt? > >>>>> dropped at the network ingress point(s) of networks that deploy the= se > >>>>> systems. > >>>> > >>>> (Must admit that since you're a native English speaker, I have a > >>>> high probability of being wrong :-), but, anyway): > >>>> > >>>> Packets can be drop, whether with EHs or anything else (i.e., the > >>>> contents of a packet does not affect the ability of a device > >>>> dropping them -- at the end of the day, a device can drop *all* > >>>> packets if it feels like). > >>>> > >>> :-) > >>>> What we are meaning here is that dropping packets with EHs is indeed > >>>> one option to increase the efficiency and effectiveness of these > >>>> systems. > >>> That sounds correct. > >> > >> Would modifying the text as phrased address your comment? > >> > > Pehaps, you could try something. > > > > I'd suggest just being neutral and saying: > > > > As a result, IPS systems have been observed to drop packets employing > > IPv6 extension headers at the network ingress point(s). > > Looks good to me. > > > > >>>>> o Use of unknown extension headers can prevent an NIDS/IPS to > >>>>> process layer-4 information > >>>> > >>>> I this case, I think both are fine: -- "can" as in ability, and > >>>> "may" as in possibility > >>>> > >>> - but not may as in "are permitted to"... > >> > >> Would "could" be better to convey "posibility" rather than ability or > >> permission? > >> > >> > > Could is fine. > > Done ;-) > > > >> > >>>>> When such devices are unable to obtain the > >>>>> required information, they might simply resort to dropping the > >>>>>>>> /may/might/ ? > >>>> > >>>> "might" reads as a possibly imaginary situation. What we are meaning > >>>> is that some devices *do* this. > >>>> > >>> OK : then say that devices do this,... rather than they are permitted > >>> to. > >> > >> I'll tweak to: > >> > >> "Some of such devices, when unable to obtain the required information, > >> simply resort to...". OK? > >> > >> > > /such/these/ ... seems like a reasonable statement to me:-). > > Will do. > > > [....] > >>> They are actually cited in RFC7872 if taht is your reason, so that is > >>> already clear! > >> > >> That said, I don't mind removing these two references. They were > >> including in this document at a time RFC7872 didn't exist -- i.e. we > >> don't have any special motivation for including them. > >> > > Aha - that now make sense, if RFC7872 hadn't been finalised. > > Indeed, this text (with these references) had been crafted before > RFC7872 got published. > > > > So removing them would be good for me. > > I don't mind, and thus will do unless I hear otherwise from the group. > > Thanks! > > Regards, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Dec 3 09:11:33 2020 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 3058E3A0957; Thu, 3 Dec 2020 09:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=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=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 HHOid4N02RpI; Thu, 3 Dec 2020 09:11:30 -0800 (PST) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 EADB83A08BB; Thu, 3 Dec 2020 09:11:29 -0800 (PST) Received: by mail-pg1-x529.google.com with SMTP id o4so1794169pgj.0; Thu, 03 Dec 2020 09:11:29 -0800 (PST) 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=vWSPK90cxtXFdYPpN+7PTI/2jX737yQ7zwYejUsCFHQ=; b=vZFfwuuGFHwtouoSAVxtq6gXQK3tMZKVvGfehbOVEucPvx1lGJJdCHucUj0oeWMPbp 5Nj2MygsOqpfkKsremJbNYkn7R3I6JbWWBKDatx8dPIDKQFu56ORosZ/AqHCrlTRt3n0 pPTjRifgvI3qQ8yXV4kcY0AH000lr8MO8m1qwE6CmuiXxmoI+GNzeHfM6P1sBzRGIzrh hvIHiNDDRCNAm2GW/5nxgkViHWDmLtL2w8fDzz/k+d4NOfQnzAQJ0lh2xtxSU2tYRTXO tsy3MIaeqB/PMoPH6PXkgP9jvy5ZBtayYRXGlvmkFUUkVhwkt0kDW2GvEHMlFB1BSEMv 3olA== 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=vWSPK90cxtXFdYPpN+7PTI/2jX737yQ7zwYejUsCFHQ=; b=gzwIbRVCndqJx9HhiDo4yZ3y3LRl6bHmT9/3v/lYxmco5tPrmG+GUvBYq5g8Pz86NP SubkWm9Z8mNalQKSluZo0mKraYhBBmjSrqUsS8ZbbyBdbLpGFQ8smDarsaQNQyq9nIhR NXvbZsJJPmUgn53/UvSSbeIw+NHOm8tJlPygS5NaenqggXVn570aUKbbiwu9rJnsWqkN 1KH1UCThjuLcNcDRf5S3r3JYDxBGm+Avf5ZW+D1RWg7PlX4c8cS+FXQ0aYMuoCeqS+S3 8kCPVvcueXH/VLusiFA4GRjIfQ+24TnI2ook2ZEenF92LHPs03b4sS3GO4+zlsBDex2/ ZjOg== X-Gm-Message-State: AOAM530bZKhdTK+SNlL7YOR+lv2tKQA1THaoSak8Id38UzWg8MKsnTUZ uD52fKIOBfvsbWcDSXQSMLuTj1YpI9k= X-Google-Smtp-Source: ABdhPJw+SIOmW17uwct6ol7LUpnJ3yefeNpokBRXON2WvH9Lu8SnoKGQPZNcUCq+SwzZHpHOd1Wt2w== X-Received: by 2002:a63:1107:: with SMTP id g7mr3777650pgl.432.1607015489399; Thu, 03 Dec 2020 09:11:29 -0800 (PST) Received: from [192.168.1.11] (ip72-205-75-17.sb.sd.cox.net. [72.205.75.17]) by smtp.gmail.com with ESMTPSA id i14sm1714441pgm.35.2020.12.03.09.11.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Dec 2020 09:11:28 -0800 (PST) From: Fred Baker Message-Id: <2B7068A6-AB53-4685-AF47-9290A745BD13@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_9EC350C0-747B-4D66-A749-7BAB8380F53F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.21\)) Date: Thu, 3 Dec 2020 09:11:25 -0800 In-Reply-To: Cc: Gorry Fairhurst , IPv6 Operations , draft-ietf-v6ops-ipv6-ehs-packet-drops.authors@ietf.org, Fernando Gont To: Fernando Gont References: <0c121812-44cf-119e-fd09-bb138ff789de@erg.abdn.ac.uk> X-Mailer: Apple Mail (2.3654.40.0.2.21) Archived-At: Subject: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-packet-drops-01: "can" vs "may" in English usage. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 17:11:31 -0000 --Apple-Mail=_9EC350C0-747B-4D66-A749-7BAB8380F53F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Dec 2, 2020, at 9:52 AM, Fernando Gont = wrote: >=20 > ("can" =3D ability, "may" =3D possibility) I tend to use "can" in the sense of capability, which may correspond to = your word "ability". "May", however, is about permission. "You can get = get hot water from the kitchen" indicates that hot water is to be found = there, and that you have the capability of trotting off there - whether = or not you're interested in hot water or have any desire to go to the = kitchen. "You may get hot water from the kitchen" gives you permission = to go to the kitchen for that purpose. Note that this differs from colloquial usage. "Can" is often used in the = sense of "may" in common usage ("can I please have some candy?" with the = meaning "may I please...?"), which can be very confusing. In written = communications, I try to keep theses straight. --Apple-Mail=_9EC350C0-747B-4D66-A749-7BAB8380F53F 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+AFAl/JHD0ACgkQEhdRnd2G P+B03xAAxPEQnt6EeycLRZdjqQ0r/fGC9iDfBya/PcgUWDFrJgsY006MHo+g2WYP nOe+TpP35oaFIa7RJFlIFUFRPcFLG7Pf0oU7wBVIPcOxIvHUezekYO3a7R3vvK8w /lNBnjL6tp/lSCR6hxyTRgynIfSySwEAVEAGJ/Cm+531LMeWVVwrY1SnRU3V5yFb N6qpLJso31OM57ynAmPYxj+SA209ytJ1fjMVW3TJ4GtTygP23kzg0qwHyGxPy9E8 EYRj14Dh7tXRe/UVfVk3Ubc2yAbnxcLxw0p+ZN5/uoHRn75iRC/YdsRWimZ9sNtq Px7Td3k+/77wEncgpVihvdhZhcYR2UtbmZtmD8Qhp6221Cv//79PKspebr+LwbFD Il4bA+t25UACxF0WISRPAocfLEOUkV3ZmNx1AD8wzfiNDPWm3N+aw7Rk1OFfxZDm UaFuAg7Slkw5rzPZrgYJxt7MErWFKBustS2qt2so+CMJwHQcj+6/MGq1omeir90c I0nSrY89Mbe/folvXutr54Vqv+xI7XgVZ8zWgg192C0k5JxqvH1S4VoG7WZQdraq dRHsJq6UMfHYLPWsrlZLbRvyPwvaIQFJi8xheYt0LcD/vR67JYydyxr593r81vNi Xp3NFSp7jpVg0jLOUMGY8mgX/PVTnrLNmd36KGiZJUi9kBFw8u8= =jEXi -----END PGP SIGNATURE----- --Apple-Mail=_9EC350C0-747B-4D66-A749-7BAB8380F53F-- From nobody Thu Dec 3 09:31:06 2020 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 8CE2F3A09C9 for ; Thu, 3 Dec 2020 09:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 dfKK-bUi2hUW for ; Thu, 3 Dec 2020 09:30:59 -0800 (PST) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 0A5BA3A09D7 for ; Thu, 3 Dec 2020 09:30:58 -0800 (PST) Received: by mail-ej1-x62c.google.com with SMTP id 7so4711688ejm.0 for ; Thu, 03 Dec 2020 09:30:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5t9/bnLlHge8qv6Cj3rUOp3tZdHHx9aErFK3U8IONFI=; b=JsyTgtjwWqbesx9WmpkjHKhgm+A20C2FRZrslv20jOhSfGD9v2vSiM5ssw7IH+btCi BPOVnEe9AAD5Lq6MY5xysJrmWPNGfsaKZWTlVL2wdN0tU6K+f+M0iLyihjBy+6NlxcmI r3Ahhp118YqZzr1HZV803K/jvSvmTJVykGIwrrDluiQuIAXRty3iZnwfsI03SywftN23 DnQqzGVhlFfAVZRd3fuv4lXwotdDeOeLjrwNZajhWVhgih0XWGAydaJil7KPDXlrpgQ4 Y84qtHGNptq5hE9dn++XdVONsHAPIW+mgtFvPaxD9xv4zPVc5ZVjTrMptXvw0NZzHvzt aHWg== 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=5t9/bnLlHge8qv6Cj3rUOp3tZdHHx9aErFK3U8IONFI=; b=hWQ4TtC3/x7ffcM1wrcV8ZNtLYv/6sCmKi1Qt0kGnQx+kj1oTadRu/iNo8Vj402G2D fWWQ5CgI1dMX0THL26hIED5M4U2npwZ7cMe+omIF8b0zlE5I3lZxu761XYGNeUh922hM AoUR41YMkULB8/s3zHUzov6+Y7WL4xEVpwlEkxdkychnPyB0e7ZlDSLKKLzhLxkT3C1V IRln6+eXNYy1zY7htnIk3TfOZIC6S5ciuTe/Rgnrt1v26/ySEC9/wUorJq+xclRVtY8O d6vJq3HmaY2gGZ5It7CT+cpHD6uTXHho+g4C22oujVMyq5nPRu279Y2ubwE8jgd8j/5G /sGA== X-Gm-Message-State: AOAM530xzD6aK2Wt+hzGgfHf5KFcG+QpboA9yvPdd6xBrr4PszApPXLI w5z9VamtRYPod+4dGF5pLGFKlJnvVwZHKrzzu9+UQg== X-Google-Smtp-Source: ABdhPJyQO3nqK6zp3jU+YFnu28S5HOMBcOTffN700tu6Btr61fvvq3fnPN22roqyXMbpJ59WDubFfLf7xkrU4VCYgjA= X-Received: by 2002:a17:906:26cc:: with SMTP id u12mr3590035ejc.295.1607016656907; Thu, 03 Dec 2020 09:30:56 -0800 (PST) MIME-Version: 1.0 References: <63e7aad3-7094-7492-dbe4-3eefb5236de3@gont.com.ar> <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> <0d38980a-f1c5-fac5-a9b1-0711d61353d1@gont.com.ar> <42b6e327-08b5-292b-be65-28f1a8508a69@si6networks.com> In-Reply-To: From: Tom Herbert Date: Thu, 3 Dec 2020 10:30:45 -0700 Message-ID: To: Erik Kline Cc: Fernando Gont , Fernando Gont , IPv6 Operations , tcpm Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] [tcpm] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 17:31:01 -0000 On Thu, Dec 3, 2020 at 8:43 AM Erik Kline wrote: > > > > Please include requirements for both hosts and network nodes. If there > > > is going to the be a requirement that hosts MUST make a 1:1 mapping to > > > a transport connection and the flow label MUST be consistent for the > > > life of connection, then I would expect there to also be a requirement > > > that the flow label MUST be immutable by all devices in the path-- in > > > particular the requirement of RFC6437 would need to be updated: "A > > > forwarding node MUST either leave a non-zero flow label value > > > unchanged or change it only for compelling operational security > > > reasons..."-- if hosts are not allowed to change a field they are > > > primarily responsible for setting, then the network should not be > > > allowed to modify it either. > > > > I don't recall _(of the top of my head) why we ended up making the field > > mutable ("SHOULD NOT be modified" rather than "MUST NOT.."). IIRC, it > > had to do with allowing middle-boxes to mitigate FL-based covert > > channels. If that's the case (Brian CC'ed) then, in retrospective, that > > seems to have been a bad idea. -- I was part of the discussion, so I > > take my share of blame. :-) > > My understanding/recollection is that since there were never any > restrictions on modification of the flow label from the very beginning > it wasn't super meaningful to try to close the barn door after all > these years. Erik, There are two apropos statements in RFC6437: "There is no way to verify whether a flow label has been modified en route or whether it belongs to a uniform distribution. Therefore, no Internet-wide mechanism can depend mathematically on unmodified and uniformly distributed flow labels; they have a "best effort" quality." "From an upper-layer viewpoint, a flow could consist of all packets in one direction of a specific transport connection or media stream. However, a flow is not necessarily 1:1 mapped to a transport connection." So building a load balancer, or any other intermediate network device, that *depends* on the flow label to be consistent for the life of a transport connection and 1:1 mapped to a transport connection is contrary to this guidance. The ship has already sailed on this in deployment, and even if the protocol requirements were to be sufficiently tightened that would take years to reach full effect and that would preclude other use cases where modifying the flow label is useful. If a stable 1:1 mapped identifier for transport ports is needed in the network layer, it might make sense to create a new HBH option for that. Personally, if I were building a load balancer I'd use neither the flow label nor transport ports for entropy, I'd look at using the destination address since 128 bits allows plenty of bits of entropy, it's consistent per transport flow and always set in an IPv6 packet. Tom Tom From nobody Thu Dec 3 11:42:34 2020 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 848383A0930; Thu, 3 Dec 2020 11:42:32 -0800 (PST) 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 5fASOGs6iIaN; Thu, 3 Dec 2020 11:42:29 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34BE33A03C9; Thu, 3 Dec 2020 11:42:27 -0800 (PST) Received: from [IPv6:2800:810:464:8164:9c91:27c0:253d:5241] (unknown [IPv6:2800:810:464:8164:9c91:27c0:253d:5241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 1D5F7283B84; Thu, 3 Dec 2020 19:42:23 +0000 (UTC) To: Fred Baker Cc: Gorry Fairhurst , IPv6 Operations , draft-ietf-v6ops-ipv6-ehs-packet-drops.authors@ietf.org, Fernando Gont References: <0c121812-44cf-119e-fd09-bb138ff789de@erg.abdn.ac.uk> <2B7068A6-AB53-4685-AF47-9290A745BD13@gmail.com> From: Fernando Gont Message-ID: Date: Thu, 3 Dec 2020 16:29:42 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <2B7068A6-AB53-4685-AF47-9290A745BD13@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-packet-drops-01: "can" vs "may" in English usage. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 19:42:33 -0000 On 3/12/20 14:11, Fred Baker wrote: > > >> On Dec 2, 2020, at 9:52 AM, Fernando Gont wrote: >> >> ("can" = ability, "may" = possibility) > > I tend to use "can" in the sense of capability, which may correspond to your word "ability". "May", however, is about permission. "You can get get hot water from the kitchen" indicates that hot water is to be found there, and that you have the capability of trotting off there - whether or not you're interested in hot water or have any desire to go to the kitchen. "You may get hot water from the kitchen" gives you permission to go to the kitchen for that purpose. > > Note that this differs from colloquial usage. "Can" is often used in the sense of "may" in common usage ("can I please have some candy?" with the meaning "may I please...?"), which can be very confusing. In written communications, I try to keep theses straight. Thanks for the note! I will definitely go back to my grammar book and try to save everyone's time -- I do remember that the last year I took English lessons there was a unit about "need" vs "must" vs "have to" vs "may" vs "can" vs "might". I also remember another on "that" vs "which". Definitely need to check both of these, since I've been getting both of them wrong lately :-( Thanks for the help! Regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Dec 3 11:42:40 2020 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 60E6A3A09BE; Thu, 3 Dec 2020 11:42:35 -0800 (PST) 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 w989z0O3SJup; Thu, 3 Dec 2020 11:42:33 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2C8A3A097E; Thu, 3 Dec 2020 11:42:32 -0800 (PST) Received: from [IPv6:2800:810:464:8164:9c91:27c0:253d:5241] (unknown [IPv6:2800:810:464:8164:9c91:27c0:253d:5241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 79B06283C03; Thu, 3 Dec 2020 19:42:29 +0000 (UTC) To: Tom Herbert Cc: Gorry Fairhurst , IPv6 Operations , draft-ietf-v6ops-ipv6-ehs-packet-drops.authors@ietf.org, Fernando Gont References: <0c121812-44cf-119e-fd09-bb138ff789de@erg.abdn.ac.uk> <676f329d-658b-4398-3b2e-4e8b835686de@si6networks.com> <7b483c43-288b-dc4b-3df8-79d529c7e163@erg.abdn.ac.uk> <59b0ae50-079d-ddca-1cc5-dc478e502d8c@si6networks.com> From: Fernando Gont Message-ID: <0c927820-6459-c0a2-4a2d-66d30124969e@si6networks.com> Date: Thu, 3 Dec 2020 16:32:36 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-packet-drops-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 19:42:38 -0000 On 3/12/20 14:02, Tom Herbert wrote: > On Thu, Dec 3, 2020 at 3:58 AM Fernando Gont wrote: >> [...] >>>>>> >>>>>> Your suggested change seems fine to me. That said, what would you >>>>>> employ for the hash if not the ports? >>>>>> >>>>> flow label? >>>> >>>> The thing is that you cannot rely on it. So, if you want entropy, your >>>> safe bet is to use the port numbers.... >>>> >>> OK, but I still do not understand why this particular RFC-to-be would >>> make a judgment on this issue, it is not related to EH, the desire of >>> some devices to look for transport headers is irrefutable. This happens >>> for various reasons of which this is one. There are other things that >>> happen also - but in the context of this document, the text can be >>> entirely neutral as to whether this is good or bad practice. >> >> I'll apply the suggested edit unless I hear otherwise from the >> group/co-authors. >> >> FWIW, the only thing that were meaning was "Yes, we know folks are >> supposed to use the FL for that... but that's not feasible... hence the >> *need* to look up the port numbers" >> > Fernando, > > There is no protocol requirement that "folks", I assume meaning > intermediate devices, Yes, that's what I meant .- for the case of ECMP. > need use the flow label nor transport port > numbers for anything, neither is there any requirement that hosts have > to expose port numbers in plain text or set a non-zero flow label. > These are both optional and best-effort by definition; RFC6437 > describes how flow labels are only best effort, and RFC7605 describes > the perils of intermediate devices attempting to interpret port > numbers. As for using flow labels not being feasible I don't see the > basis for that statement. There are deployed devices that have been > using flow labels for various purposes for quite a while, for instance > Linux OS has been setting and consuming non-zero flow labels for years > in both host and router configurations for RSS, ECMP, etc. Yes, like > anything else we occasionally encounter issues and sometimes they hit > interoperable devices, but we do fix issues and haven't declared they > aren't feasible. Please see [Cunha-2020] ni our doc. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Dec 3 11:42:50 2020 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 4FD4D3A0C01; Thu, 3 Dec 2020 11:42:41 -0800 (PST) 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 mYbz3k9XNrk3; Thu, 3 Dec 2020 11:42:38 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C28343A0BCC; Thu, 3 Dec 2020 11:42:37 -0800 (PST) Received: from [IPv6:2800:810:464:8164:9c91:27c0:253d:5241] (unknown [IPv6:2800:810:464:8164:9c91:27c0:253d:5241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 6304B283B84; Thu, 3 Dec 2020 19:42:34 +0000 (UTC) To: Tom Herbert , Erik Kline Cc: Fernando Gont , IPv6 Operations , tcpm References: <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> <0d38980a-f1c5-fac5-a9b1-0711d61353d1@gont.com.ar> <42b6e327-08b5-292b-be65-28f1a8508a69@si6networks.com> From: Fernando Gont Message-ID: <148b6caf-0eba-3e3b-9826-e57036e4e748@si6networks.com> Date: Thu, 3 Dec 2020 16:40:21 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] [tcpm] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 19:42:49 -0000 On 3/12/20 14:30, Tom Herbert wrote: [....] > > There are two apropos statements in RFC6437: > > "There is no way to verify whether a flow label has been modified en > route or whether it belongs to a uniform distribution. Therefore, no > Internet-wide mechanism can depend mathematically on unmodified and > uniformly distributed flow labels; they have a "best effort" quality." > > "From an upper-layer viewpoint, a flow could consist of all packets in > one direction of a specific transport connection or media stream. > However, a flow is not necessarily 1:1 mapped to a transport > connection." > > So building a load balancer, or any other intermediate network device, > that *depends* on the flow label to be consistent for the life of a > transport connection and 1:1 mapped to a transport connection is > contrary to this guidance. We don't need 1:1. We just need 1:N where N is how flows would be aggregated/grouped for the purpose of load-sharing. > The ship has already sailed on this in > deployment, and even if the protocol requirements were to be > sufficiently tightened that would take years to reach full effect and > that would preclude other use cases where modifying the flow label is > useful. If a stable 1:1 mapped identifier for transport ports is > needed in the network layer, it might make sense to create a new HBH > option for that. The above said, I would probably agree that if havinga non-stable FL breaks something, whatever it breaks is probably already broken, since there's not even a checksum to try to detect whether the IPv6 header has been corrupted. > Personally, if I were building a load balancer I'd > use neither the flow label nor transport ports for entropy, I'd look > at using the destination address since 128 bits allows plenty of bits > of entropy, it's consistent per transport flow and always set in an Problem is that if you have two systems that need a lot of banswitdth (e.g., they are transferring file via several TCP connections)< you wouldn't be able to load-share them -- since the result of the hash would be the sme for all TCP connections.... Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Dec 3 12:07:21 2020 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 838683A0CDB for ; Thu, 3 Dec 2020 12:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=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 DriJdaUVlRUL for ; Thu, 3 Dec 2020 12:07:07 -0800 (PST) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (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 DF53B3A0D05 for ; Thu, 3 Dec 2020 12:06:56 -0800 (PST) Received: by mail-ej1-x62f.google.com with SMTP id 7so5391041ejm.0 for ; Thu, 03 Dec 2020 12:06:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ndQFvwaUXmS8GuBoJIOycXq2OUb8TPic10DtRNt0Njo=; b=xJhti7Zb9pYkM2bf/S93YLdLpdrbFu6Lc0dPGMNtw+iJkJnlsp/3Jp7LNT8Xnh3B4I 0ZB5jl26Fm6G6vO+AMe1n35sYtWyfwSovChi0RH87zdwKWRDLP8dR8/wkTBgWfE06awX 5Qjj9LBifqwJkIOWCYxzrAk5c3eJcdrjc7mybgRULWftWmDKNix8dN9+R5mi/Q4Hc2aJ eZphh1PQnWIWtqo7K2Ie0VZNqn8j2oFlL8+duOq4GsX0QsrYfIE1TdltxUQuldKkcukz z0r3vXhxsxdIUAPTXEIJZfaco2o7u5kEklzGXTB4DBMJmiVKCfOBRVfchlKi+KY/4VVx 4XTQ== 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=ndQFvwaUXmS8GuBoJIOycXq2OUb8TPic10DtRNt0Njo=; b=stiQRAQ4FO0ARKLjrzJAu4nHXQlOwabcEO2hqDlKkJ5MLtB94s3mGzBHR+b5D/57mU YGfn6jRNbVc6vhtHe9iyJAM6T6s7BpNthom4mJLs6Nqi3y8H1QB0AduMLvCOJuamr6HV g5FSbLWZ6ZRETuexwL9BCkWq1mS2qOzGJfMiQfoK656FHzLsVTe9IP0i51PHhQaEkSKL joxC30+Iqm+nzzvml4wjGa9ASaEP/12l0U18BoHqKP8tJUt6xaFBJJACfRfcjUxGWXQU 57NJbLqOa2nDh296YUbygTaWetMJtakHLRYFCFjiV7V5sEK5E043VBXNW8yieWaUu8as r09g== X-Gm-Message-State: AOAM532lii/zQRj7I6oRKgVNCH8Ux9uGrLVjjEPnem99NoVXPyEqVrWo ZljK20ussDNOAsTJ8bNITpiB8kLoAzr7003gDK0MLQ== X-Google-Smtp-Source: ABdhPJwYz/layhzIvh4CvZ7th7UFO/Yc/NNmwyyO68M5/RIcjwHogbYbdKamvckXC7IgCwS3hbXkxux+i5UYhUbIFx8= X-Received: by 2002:a17:906:26cc:: with SMTP id u12mr4181798ejc.295.1607026014894; Thu, 03 Dec 2020 12:06:54 -0800 (PST) MIME-Version: 1.0 References: <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> <0d38980a-f1c5-fac5-a9b1-0711d61353d1@gont.com.ar> <42b6e327-08b5-292b-be65-28f1a8508a69@si6networks.com> <148b6caf-0eba-3e3b-9826-e57036e4e748@si6networks.com> In-Reply-To: <148b6caf-0eba-3e3b-9826-e57036e4e748@si6networks.com> From: Tom Herbert Date: Thu, 3 Dec 2020 13:06:43 -0700 Message-ID: To: Fernando Gont Cc: Erik Kline , Fernando Gont , IPv6 Operations , tcpm Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] [tcpm] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 20:07:17 -0000 On Thu, Dec 3, 2020 at 12:42 PM Fernando Gont wrote: > > On 3/12/20 14:30, Tom Herbert wrote: > [....] > > > > There are two apropos statements in RFC6437: > > > > "There is no way to verify whether a flow label has been modified en > > route or whether it belongs to a uniform distribution. Therefore, no > > Internet-wide mechanism can depend mathematically on unmodified and > > uniformly distributed flow labels; they have a "best effort" quality." > > > > "From an upper-layer viewpoint, a flow could consist of all packets in > > one direction of a specific transport connection or media stream. > > However, a flow is not necessarily 1:1 mapped to a transport > > connection." > > > > So building a load balancer, or any other intermediate network device, > > that *depends* on the flow label to be consistent for the life of a > > transport connection and 1:1 mapped to a transport connection is > > contrary to this guidance. > > We don't need 1:1. We just need 1:N where N is how flows would be > aggregated/grouped for the purpose of load-sharing. > > > > > The ship has already sailed on this in > > deployment, and even if the protocol requirements were to be > > sufficiently tightened that would take years to reach full effect and > > that would preclude other use cases where modifying the flow label is > > useful. If a stable 1:1 mapped identifier for transport ports is > > needed in the network layer, it might make sense to create a new HBH > > option for that. > > The above said, I would probably agree that if havinga non-stable FL > breaks something, whatever it breaks is probably already broken, since Fernando, Not to belabor the point, but stable flow labels were never guaranteed, so if some node has a problem with non-stable flow labels then they are themselves broken because they are making an incorrect assumption. > there's not even a checksum to try to detect whether the IPv6 header has > been corrupted. > Neither is there checksum that covers the UDP port numbers when UDP checksum is zero. A "stable" identifier that the network can use to conclusively identify transport flows does not generally exist. > > > > Personally, if I were building a load balancer I'd > > use neither the flow label nor transport ports for entropy, I'd look > > at using the destination address since 128 bits allows plenty of bits > > of entropy, it's consistent per transport flow and always set in an > Problem is that if you have two systems that need a lot of banswitdth > (e.g., they are transferring file via several TCP connections)< you > wouldn't be able to load-share them -- since the result of the hash > would be the sme for all TCP connections.... > Use a different IP address per connection. This idea has already been brought up in the context of security since it could make it harder for malicious network observers to correlate different flows as having the same source, and the same principle could be applied to load balancers where each of the backends is assigned a block of IP addresses (like a /64). After that, it's a matter of getting clients to use some random address from the load balancer blocks (instead of always using one). IIRC, Brian Carpenter once suggested that we really didn't need port numbers any more since they could be part of the address-- for load balancers there might be some merit to that. Tom > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > From nobody Thu Dec 3 12:18:08 2020 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 81E4E3A0C5E; Thu, 3 Dec 2020 12:17:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 rEsAJ2NhXSdG; Thu, 3 Dec 2020 12:17:58 -0800 (PST) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 CF1823A0C64; Thu, 3 Dec 2020 12:17:57 -0800 (PST) Received: by mail-pf1-x42a.google.com with SMTP id w187so2066642pfd.5; Thu, 03 Dec 2020 12:17:57 -0800 (PST) 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=kEDGKP4sfCroZwuQ1m6T+B62pz/0WYqGJkbq/af38D0=; b=BM0srVnAxB6OzD5rI1HvPKyqbaKO7YVJvj/MlIq36GHUhdhh9Eg3mU23RIF5i32CBH Pd4a9Grla+Ko28SbsbqAyTZi4awDOSP0P9VJRceIrGcLeTwPrDFQ7cDbDxGdCNmPgSFr IWL+tmDatE6XnDoqV3U6ciloJW6VdF7yFV86twdR4cFZ71EyfLb4/3uoXjRi2zRFfo9s FWZtFFLGIV1iuih1DTBMHXZBtSZG7isClRIER9iGRJHzsmrmOQDPdT0xPXeSisynHcWI tqfVGTiN0PH1zWMyH2TcRYi7iY6ENerTmoY1kpcZ3EWw3UfJ2BsCdlYu9uhjUktXb4HZ iSIg== 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=kEDGKP4sfCroZwuQ1m6T+B62pz/0WYqGJkbq/af38D0=; b=FNS0mcY5lTa0CL31+pzwv11Y/24t/kXBaitLxufNP3lQDZg7UNc5ipV4GC7xfC4xNI oupBGp5CKvhVLHdYNa60c1TuOwn7fTxp1kJA5Fq+6HIOVR63/iXH6Yh1lwHFMc/vNueW 8tvJiCYvVUWVZqWgGgkLyQYfYkn8f8ge7e8ehA2aryqvr28scp0e3A9VPpfIB5/DkniR yU+rG2dCyUNEO+zkukv0biX0rWTTflxo6KtU2sBhELUVl8UpjldaPZC0/z6uvUbeCHYa jazCnL/L+ClK4KbWUWvhFdNQBqyfoaVDP4rgHq4sQ3AGrLIbc0/CdcFwDW8oY9Y9W5kE SJbg== X-Gm-Message-State: AOAM533JwTgoz1Utuhr5ZSkMTONXPEBLRw/W/e8nU/4sKX+r6iBR4ch2 wd9RZ0CF/wy+FtYz5gdoaZ0= X-Google-Smtp-Source: ABdhPJyT7qAWiTzVh7vy6L7onRvcGwGPiQC1thZmWfkJ43/b9jp6HKwf4pS4WEGtXpp0RipntecwHQ== X-Received: by 2002:a63:d90a:: with SMTP id r10mr4506831pgg.336.1607026677263; Thu, 03 Dec 2020 12:17:57 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id a16sm2647308pfl.125.2020.12.03.12.17.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Dec 2020 12:17:56 -0800 (PST) To: Tom Herbert , Erik Kline Cc: Fernando Gont , IPv6 Operations , tcpm , Fernando Gont References: <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> <0d38980a-f1c5-fac5-a9b1-0711d61353d1@gont.com.ar> <42b6e327-08b5-292b-be65-28f1a8508a69@si6networks.com> From: Brian E Carpenter Message-ID: <85dd3823-ff2d-94ac-3535-d3d042bdd338@gmail.com> Date: Fri, 4 Dec 2020 09:17:52 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.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] [tcpm] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 20:18:04 -0000 On 04-Dec-20 06:30, Tom Herbert wrote: > On Thu, Dec 3, 2020 at 8:43 AM Erik Kline wrote: >> >>>> Please include requirements for both hosts and network nodes. If there >>>> is going to the be a requirement that hosts MUST make a 1:1 mapping to >>>> a transport connection and the flow label MUST be consistent for the >>>> life of connection, then I would expect there to also be a requirement >>>> that the flow label MUST be immutable by all devices in the path-- in >>>> particular the requirement of RFC6437 would need to be updated: "A >>>> forwarding node MUST either leave a non-zero flow label value >>>> unchanged or change it only for compelling operational security >>>> reasons..."-- if hosts are not allowed to change a field they are >>>> primarily responsible for setting, then the network should not be >>>> allowed to modify it either. >>> >>> I don't recall _(of the top of my head) why we ended up making the field >>> mutable ("SHOULD NOT be modified" rather than "MUST NOT.."). IIRC, it >>> had to do with allowing middle-boxes to mitigate FL-based covert >>> channels. If that's the case (Brian CC'ed) then, in retrospective, that >>> seems to have been a bad idea. -- I was part of the discussion, so I >>> take my share of blame. :-) >> >> My understanding/recollection is that since there were never any >> restrictions on modification of the flow label from the very beginning >> it wasn't super meaningful to try to close the barn door after all >> these years. > > Erik, > > There are two apropos statements in RFC6437: > > "There is no way to verify whether a flow label has been modified en > route or whether it belongs to a uniform distribution. Therefore, no > Internet-wide mechanism can depend mathematically on unmodified and > uniformly distributed flow labels; they have a "best effort" quality." Yes, a MUST NOT is futile because it cannot be enforced. Also, the firewall folk seemed very insistent that they would change the flow label (or zero it) because paranoia. So specifying that if they changed it, they should do it consistently, seemed better than a MUST NOT which they would definitely ignore. > "From an upper-layer viewpoint, a flow could consist of all packets in > one direction of a specific transport connection or media stream. > However, a flow is not necessarily 1:1 mapped to a transport > connection." > > So building a load balancer, or any other intermediate network device, > that *depends* on the flow label to be consistent for the life of a > transport connection and 1:1 mapped to a transport connection is > contrary to this guidance. The ship has already sailed on this in > deployment, and even if the protocol requirements were to be > sufficiently tightened that would take years to reach full effect and > that would preclude other use cases where modifying the flow label is > useful. If a stable 1:1 mapped identifier for transport ports is > needed in the network layer, it might make sense to create a new HBH > option for that. Personally, if I were building a load balancer I'd > use neither the flow label nor transport ports for entropy, I'd look > at using the destination address since 128 bits allows plenty of bits > of entropy, it's consistent per transport flow and always set in an > IPv6 packet. But that doesn't help with server load balancing. For ECMP/LAG in a transit network, the DA alone doesn't help either, if a particular destination is prone to very heavy flows for some reason. And of course the ports don't help if they're encrypted. There's no simple answer here. Brian From nobody Thu Dec 3 12:38:55 2020 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 723FA3A0C35 for ; Thu, 3 Dec 2020 12:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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 1Pft6cIdT2DT for ; Thu, 3 Dec 2020 12:38:52 -0800 (PST) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 8CB6D3A0C46 for ; Thu, 3 Dec 2020 12:38:52 -0800 (PST) Received: by mail-ej1-x633.google.com with SMTP id 7so5515343ejm.0 for ; Thu, 03 Dec 2020 12:38:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NIrav4tdAcakDCg0n7gnAvqr1Mn5aNrsxiqiFjmNwOU=; b=Eldg9cCt3VsCZru0t/MYk6TnPGRoZ0z9YbeRjy+CxTrIV1HR1Cla/V4roks76YPScc cdUuEx3cS/LvcKftzwEG6xXLrUhZAPCVteNlHMgLtC2ZEK4muNLxO6FVkqGRWkzvVMyS 1GKH8wGFvRUbgZnZFZX58Y/PsUjvfyjwnmunF1u0pjPE50cnRWQ0EE1GwqXOgtJUaT46 4MsR7Hv6NXy5f+eUT2wn4NbO5iWZcAYb3VsPuBG3MIftTFr9KRTpdrrrM6ILGLVoJ9ow StxAGPGBYvolI5FeERFXYVZX3TN9Z11pawKEm2b1OZCTC4uzRz5udT3f8+u8WBhLYzFY MUSg== 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=NIrav4tdAcakDCg0n7gnAvqr1Mn5aNrsxiqiFjmNwOU=; b=MwnD64AAZD3kYEuxT6ddUGY8CuFUOiIjkRC86ezMX/F/6KahHOjQTDxvWtVu+JZeTu 2DidKRgPCw/TOOit8/qmlY+fMdAagxtzmXLvofAW2iDY2usP7JeJJ36AzpkaLHG8jv5/ iWP3uMlG5Bzl9a7+QG2KyLDJZfba7iwdfWeBvfhwOZDu8If3KxORTrpvxW9KTJh6uuub 2ij/mSiDhuAeOKAf+yMhiALobpBOnh3cx4CWmebi/f/wXRE6efsRdiV7nGXi9TeFaQj2 xWXALT6iQ7KB5UJWdOertgK0sAo5qM13RDXVcSaUdTAvuLUIBYrGisfjMatFfZAVCGFO 3mvA== X-Gm-Message-State: AOAM533/WI8SnF1yOHQzqQ+v77kM3hfWX4PdDRZ9vebwtt6H1Ia9Ubd/ TaI5MUlUNENuTbh8B6uHDIpspzz1+kauuZJ+Sum1Uw== X-Google-Smtp-Source: ABdhPJzZzjuN8kyMl/2KzkfB5VN9VLQdYIkL7Ss22z65BHIUJXYdebynZmKFfPdsHOskTBjN54JrM0Dd+JC55vvg1Ow= X-Received: by 2002:a17:906:3294:: with SMTP id 20mr4211114ejw.239.1607027930742; Thu, 03 Dec 2020 12:38:50 -0800 (PST) MIME-Version: 1.0 References: <96b6d04b-e5bb-ba79-0281-e9599109be95@gont.com.ar> <0d38980a-f1c5-fac5-a9b1-0711d61353d1@gont.com.ar> <42b6e327-08b5-292b-be65-28f1a8508a69@si6networks.com> <85dd3823-ff2d-94ac-3535-d3d042bdd338@gmail.com> In-Reply-To: <85dd3823-ff2d-94ac-3535-d3d042bdd338@gmail.com> From: Tom Herbert Date: Thu, 3 Dec 2020 13:38:39 -0700 Message-ID: To: Brian E Carpenter Cc: Erik Kline , Fernando Gont , IPv6 Operations , tcpm , Fernando Gont Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] [tcpm] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2020 20:38:55 -0000 On Thu, Dec 3, 2020 at 1:17 PM Brian E Carpenter wrote: > > On 04-Dec-20 06:30, Tom Herbert wrote: > > On Thu, Dec 3, 2020 at 8:43 AM Erik Kline wrote: > >> > >>>> Please include requirements for both hosts and network nodes. If there > >>>> is going to the be a requirement that hosts MUST make a 1:1 mapping to > >>>> a transport connection and the flow label MUST be consistent for the > >>>> life of connection, then I would expect there to also be a requirement > >>>> that the flow label MUST be immutable by all devices in the path-- in > >>>> particular the requirement of RFC6437 would need to be updated: "A > >>>> forwarding node MUST either leave a non-zero flow label value > >>>> unchanged or change it only for compelling operational security > >>>> reasons..."-- if hosts are not allowed to change a field they are > >>>> primarily responsible for setting, then the network should not be > >>>> allowed to modify it either. > >>> > >>> I don't recall _(of the top of my head) why we ended up making the field > >>> mutable ("SHOULD NOT be modified" rather than "MUST NOT.."). IIRC, it > >>> had to do with allowing middle-boxes to mitigate FL-based covert > >>> channels. If that's the case (Brian CC'ed) then, in retrospective, that > >>> seems to have been a bad idea. -- I was part of the discussion, so I > >>> take my share of blame. :-) > >> > >> My understanding/recollection is that since there were never any > >> restrictions on modification of the flow label from the very beginning > >> it wasn't super meaningful to try to close the barn door after all > >> these years. > > > > Erik, > > > > There are two apropos statements in RFC6437: > > > > "There is no way to verify whether a flow label has been modified en > > route or whether it belongs to a uniform distribution. Therefore, no > > Internet-wide mechanism can depend mathematically on unmodified and > > uniformly distributed flow labels; they have a "best effort" quality." > > Yes, a MUST NOT is futile because it cannot be enforced. > > Also, the firewall folk seemed very insistent that they would change > the flow label (or zero it) because paranoia. So specifying that if they > changed it, they should do it consistently, seemed better than a MUST NOT > which they would definitely ignore. > > > "From an upper-layer viewpoint, a flow could consist of all packets in > > one direction of a specific transport connection or media stream. > > However, a flow is not necessarily 1:1 mapped to a transport > > connection." > > > > So building a load balancer, or any other intermediate network device, > > that *depends* on the flow label to be consistent for the life of a > > transport connection and 1:1 mapped to a transport connection is > > contrary to this guidance. The ship has already sailed on this in > > deployment, and even if the protocol requirements were to be > > sufficiently tightened that would take years to reach full effect and > > that would preclude other use cases where modifying the flow label is > > useful. If a stable 1:1 mapped identifier for transport ports is > > needed in the network layer, it might make sense to create a new HBH > > option for that. Personally, if I were building a load balancer I'd > > use neither the flow label nor transport ports for entropy, I'd look > > at using the destination address since 128 bits allows plenty of bits > > of entropy, it's consistent per transport flow and always set in an > > IPv6 packet. > > But that doesn't help with server load balancing. For ECMP/LAG in a > transit network, the DA alone doesn't help either, if a particular > destination is prone to very heavy flows for some reason. Brian, Specifically, that is a problem for a host that uses a _single_ IPv6 address for all its connections. What I am suggesting is to give hosts many addresses, which we already do anyway like when mobile devices and data center servers are assigned /64s. If a host then randomly chooses an address from that block for each connection it creates thenl the address 2-tuple contains all the entropy needed for purposes of load balancing, ECMP, etc. is contained in the source address. Addresses are guaranteed to be present and plaintext in each packet so no DPI required, they're as stable as any flow identifying information in a packet can be and they offer much more entropy than sixteen bits of port number of twenty bit flow label. Since the block address assignments or already happening, this seems more to be a host implementation matter where we perform address selection for a new connection by random selection in the block. It's on my wish list of things to implement :-) Tom > And of course > the ports don't help if they're encrypted. > > There's no simple answer here. > > Brian From nobody Thu Dec 3 18:25:44 2020 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 6A7D93A1241 for ; Thu, 3 Dec 2020 18:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=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 BW270iu0vNMs for ; Thu, 3 Dec 2020 18:25:40 -0800 (PST) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (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 95DE23A1233 for ; Thu, 3 Dec 2020 18:25:40 -0800 (PST) Received: by mail-pj1-x1031.google.com with SMTP id o7so2288518pjj.2 for ; Thu, 03 Dec 2020 18:25:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:references:to:date; bh=qjzgCy6NwIPSuc/VQq7V15v500O+j9tjvwS40tHglO0=; b=kBmt5VN6GwDapQHAOxezIuAeM70HYgWGQV/qfiW/TtnyB0jq4qscJcxD1CBG8b+2kY /sq6ZexMbO77Bzbe3c8/MHF2sLPFleTtOYwi6+Tt/qVRa4AxC0nby9W2rwkDXTKtGJkv XXHu8j71zwYspn5Di0d+yB9IR/MY0pLH5qpm6zgNkkMP7azwjjjscYZQVxRnjvVakULc +Yh8vzgQuieugUPlGXQ8qeKXEMYSulAfRap5NZT/Qp9Hw4HHrZF/3J7Nj7AjAua0W2sA hciy8NiGVtzJjnwZc3tDp8axyuW1N2cppZpVsXKkZoPwW6VzQcGpbI4f8gC3Zn0YQ6Qa lxcA== 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:references :to:date; bh=qjzgCy6NwIPSuc/VQq7V15v500O+j9tjvwS40tHglO0=; b=sT6nBNRxPJHipKBXaTP4SLIWTXq7tdtQChI1r4nbpX6nAaoU+qjmREEhUiykbwJ95w fJe4FZrd8vRD3WUKfYRAwFMDPeiQ6quVET5h9oNVnFVaRpfXZ+wJfp3tw9Hgq6XiZuCq XXX0LrX7KtbjOnLO+PwUtIs8vRn9wA4Dys1FD8az/aIBFCH4+fugPc+US4bT9dTAuSXI 3EVcxxV459tilNG9s3ATJkj5gKpftnv6ecI5D/be4bYJwMvGYcOSWuw5CvHn00JkBS64 5prWaM9JLTYjJwl1nbRQhml8eZJAzFrgHRiNjvkFzs0Of47SewCDpt+hH2nkQXDaOGtz 1U0Q== X-Gm-Message-State: AOAM532Mw6bB99HYMgwd9jFnVADScMmlzyaduUix8Ft3X/vAd0rqzyeR x6fuiU4Dh5VjhVKJYGwJneEx5g/gl9c= X-Google-Smtp-Source: ABdhPJxXXcBXbot1KMc0sGKJwRrK9/Wd96fhMdMVje5uG1xMI+puDIhyqPfeY/Nzb/oGpiYWN7S5Cw== X-Received: by 2002:a17:902:b948:b029:da:877:6b94 with SMTP id h8-20020a170902b948b02900da08776b94mr2028285pls.63.1607048739794; Thu, 03 Dec 2020 18:25:39 -0800 (PST) Received: from [192.168.1.10] (ip72-205-75-17.sb.sd.cox.net. [72.205.75.17]) by smtp.gmail.com with ESMTPSA id w22sm2899323pfu.33.2020.12.03.18.25.38 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Dec 2020 18:25:39 -0800 (PST) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_12B15FAF-0E06-4F67-A8F0-84996505EA14"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.21\)) Message-Id: <920253E0-22D1-4413-86EA-FD9423FDA892@gmail.com> References: To: IPv6 Operations Date: Thu, 3 Dec 2020 18:25:38 -0800 X-Mailer: Apple Mail (2.3654.40.0.2.21) Archived-At: Subject: [v6ops] Fwd: Videos of virtual interim meetings. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 02:25:43 -0000 --Apple-Mail=_12B15FAF-0E06-4F67-A8F0-84996505EA14 Content-Type: multipart/alternative; boundary="Apple-Mail=_37384731-ABF5-4370-B30E-537F4C10786F" --Apple-Mail=_37384731-ABF5-4370-B30E-537F4C10786F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FYI, if you were wondering about the recording, Warren found it... > Begin forwarded message: >=20 > From: Warren Kumari > Subject: Re: Videos of virtual interim meetings. > Date: December 3, 2020 at 4:33:33 PM PST > To: Fred Baker > Cc: Alexa Morris , IETF WG Chairs = >=20 > https://datatracker.ietf.org/meeting/109/agenda >=20 > for v6ops: https://www.youtube.com/watch?v=3DBCETJKYGUNQ >=20 > W >=20 > On Thu, Dec 3, 2020 at 7:12 PM Fred Baker = wrote: >>=20 >> Do we have recordings from IETF 109? >>=20 >>> On Dec 3, 2020, at 10:32 AM, Alexa Morris wrote: >>>=20 >>> Hi Yoav, >>>=20 >>> As previously announced [1] you used the name =E2=80=9Cinterim=E2=80=9D= for your meeting AND the meeting took place using WebEx, the = Secretariat will publish the recording to YouTube within approximately = 10 days of the meeting. We are also happy to publish recordings made on = other platforms if you send the recording to proceedings@ietf.org. >>>=20 >>> Best, >>> Alexa >>>=20 >>> [1] = https://mailarchive.ietf.org/arch/msg/wgchairs/wNMi_HNzIb_VqIA8z2OCxMhKj5c= / >>>=20 >>>> On Dec 3, 2020, at 10:26 AM, Yoav Nir wrote: >>>>=20 >>>> Hi. >>>>=20 >>>> I see that videos of at least some of the interim meetings are up = on the IETF=E2=80=99s YouTube channel. >>>>=20 >>>> How do they get there? My group just had a meeting and I have the = recording file, but no idea what the process is. >>>>=20 >>>> Anyone know? >>>>=20 >>>> Thanks >>>>=20 >>>> Yoav >>>=20 >>=20 >=20 >=20 > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf --Apple-Mail=_37384731-ABF5-4370-B30E-537F4C10786F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 FYI, = if you were wondering about the recording, Warren found it...

Begin forwarded message:

From: = Warren Kumari <warren@kumari.net>
Subject: = Re: Videos of = virtual interim meetings.
Date: = December 3, 2020 at 4:33:33 PM = PST
To: = Fred Baker <fredbaker.ietf@gmail.com>
Cc: = Alexa Morris <amorris@amsl.com>, = IETF WG Chairs <wgchairs@ietf.org>

https://datatracker.ietf.org/meeting/109/agenda

for v6ops: =  https://www.youtube.com/watch?v=3DBCETJKYGUNQ

W

On Thu, Dec 3, 2020 at 7:12 PM = Fred Baker <fredbaker.ietf@gmail.com> wrote:

Do we = have recordings from IETF 109?

On Dec 3, 2020, at 10:32 AM, Alexa Morris = <amorris@amsl.com> wrote:

Hi Yoav,

As previously announced [1] you used the name = =E2=80=9Cinterim=E2=80=9D for your meeting AND the meeting took place = using WebEx, the Secretariat will publish the recording to YouTube = within approximately 10 days of the meeting. We are also happy to = publish recordings made on other platforms if you send the recording to = proceedings@ietf.org.

Best,
Alexa

[1] = https://mailarchive.ietf.org/arch/msg/wgchairs/wNMi_HNzIb_VqIA8z2OCxMhKj5c= /

On = Dec 3, 2020, at 10:26 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:

Hi.

I see that = videos of at least some of the interim meetings are up on the IETF=E2=80=99= s YouTube channel.

How do they get there? =  My group just had a meeting and I have the recording file, but no = idea what the process is.

Anyone know?

Thanks

Yoav




--
I = don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting = rabid weasels in your pants, and later expressing
regret = at having chosen those particular rabid weasels and that pair
of pants.
  ---maf

= --Apple-Mail=_37384731-ABF5-4370-B30E-537F4C10786F-- --Apple-Mail=_12B15FAF-0E06-4F67-A8F0-84996505EA14 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+AFAl/JniIACgkQEhdRnd2G P+D4rg//WnYBCROQ2gpoFo8XUrNIlkdjFO1lXT3aV+MdmRU0Av7Y18iN3ltYCoAt 38SiACGw5Ad0MWp5HHoLxKiamnfCZbUjHqRrSoorzca86LNnNLDtf8ZtI/xDwIP6 /jBG5hbnkVMBm3VHCToW5c4LlW6Rw4LP1ERSfAM7SwatW4PVG1/sQiaqHfxvJyVi cb6ZwvyX72BlP+4xyQ6OvYAKZSh0QhMaYF/odyKilFmLU7tLTcjL6H0RXV0li6YA xccVEn7QaMi5UFIEMX1NM32bPh2nBxN4OJknV9B5HfK2tJ1OS5LA/BrBz7WtWeuQ tB64UmV6SEjQH/4rYQ3ONrIMihRUwJ3P2RfF21W8F8VW6UvFy24rPtG0pCYuNvMD njZuS/ebZlLEEThI7lSRMbsM6E+I8Ln6i4ZQPErevsfMtxVMZtD8Ei0w8SD6YZOw IFF41Bwk4l9MGfAN2/mdSt9KeVQufdiPMxY/XeIQA87mgnDGrg3rWWNub9Acfxt1 868gGYzgepk18S1ExrxEMpcW867k5EJprsSI5/rGW5yr3hQEKRIiRd6dlZEkoHll dBVfb7ixi0MueTZkPO8kc6CzBuj6BvJ9KY/M6uSv5O2rjBnpc+pN3kI2uEDkMP/Q 1AcrCHFb6aO529eI71Bg5KwTj4v5nq4uMtxIsOHaEpCj6SbK0UQ= =AZ6H -----END PGP SIGNATURE----- --Apple-Mail=_12B15FAF-0E06-4F67-A8F0-84996505EA14-- From nobody Fri Dec 4 05:48:24 2020 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 A98753A0CDD for ; Fri, 4 Dec 2020 05:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.548 X-Spam-Level: ** X-Spam-Status: No, score=2.548 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, 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 tmOZLSQ7Yc5h for ; Fri, 4 Dec 2020 05:48:22 -0800 (PST) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) (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 804E93A0CD7 for ; Fri, 4 Dec 2020 05:48:22 -0800 (PST) Received: from [IPv6:2a01:e35:2e59:ce10::da3d:a356] (unknown [IPv6:2a01:e35:2e59:ce10::da3d:a356]) by smtp4-g21.free.fr (Postfix) with ESMTP id D7F8619F58A for ; Fri, 4 Dec 2020 14:48:19 +0100 (CET) To: "v6ops@ietf.org" From: Alexandre Petrescu Message-ID: <1346b5c0-9ac6-7493-0082-094ae4ae4c88@gmail.com> Date: Fri, 4 Dec 2020 14:48:18 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------358B819EED767FACCE8BF94F" Content-Language: fr Archived-At: Subject: [v6ops] IPv6 Barometer webinar in France X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 13:48:24 -0000 This is a multi-part message in MIME format. --------------358B819EED767FACCE8BF94F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit "IPv6 Barometer" webinar in France Organised by ISOC France. Happening right now during one hour.  It speaks in French. Talks about IPv6 deployment in France. (I cant share the URL because it is personal) Alex --------------358B819EED767FACCE8BF94F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

"IPv6 Barometer" webinar in France

Organised by ISOC France.

Happening right now during one hour.  It speaks in French.

Talks about IPv6 deployment in France.

(I cant share the URL because it is personal)

Alex

--------------358B819EED767FACCE8BF94F-- From nobody Fri Dec 4 09:09:25 2020 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 5D94F3A0E43; Fri, 4 Dec 2020 09:09:22 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 (1024-bit key) header.d=btconnect.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 V3XNiTQCgRo8; Fri, 4 Dec 2020 09:09:20 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150134.outbound.protection.outlook.com [40.107.15.134]) (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 5DCE63A0E3B; Fri, 4 Dec 2020 09:09:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RJTYpFcBrJ21f6ECneO68eRU7D8CRdOWXQY5vM58ZNyeh/Wg0nUdf7SsyYrhqJQRxnhS8Pkw9Uqms9wPTnvBbduDdk2epKZH+dAKzNi0d3HkUMaKpiEnVGdOI8M0u0HkVPCwGxSxpc4r6lyzQsSgzGuHF96WVN4t4xOEpKYJiTXAvy3ScF/J5DV62JTdiHtfAJb9fRSOJKo0S+LF8NGsmbf7rT2KKgnJa50sASE7qCabumig4iek2lHC7GKWOdtKdCf6BteAHv0cXDTA2gpn0DAPnlrthBBaHsbjBzaZ3WI5vHvPTGJzU2iUu/vN3fty9mz9E7j8aK+U1AuacqukNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Sv84j2jjKij6B6xJAX/JYCYhWyWGf1rgcZHVlqU/gO4=; b=iKaoJ4rAYPO0kcMZzZCbCaBuXU2PeRF2aBWol4MinIZqxIxvRx2ZiyI0hNmqkA/S07SLwH+BJtKZbZGPpxgap2aOf3lknH2gKpDJFfhQJuzgDgeRXRk7yk8CNdYnxbJNgki6lLHLdXuT2FXxUkYVlDbu8XavihAaV5X0se/vk5TAi0k396jKPNg/9z2/lcpvrbC36WOydbIjTP07Fc4xMH97ruLCdoNVa5wOLgiSqbt+9FSRzgsdff6ekBnP0N5tNhRSRERqkC+AmK0yMDxX6AeQi3hurQRDTgvDQ56q1GZXbcFM7LZlzN/9tQjeREYEjN4nl847g6Z6Mu/ZcxqYsw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Sv84j2jjKij6B6xJAX/JYCYhWyWGf1rgcZHVlqU/gO4=; b=iV4z3MpnkKWsbEnN26UGk2Lio6+CJ/sfvPTobcxGQ0Kz817V9tVX9qJUYc7+gTBCpK3MyILY2zfGPaXYBVGroGvn6nGLnY2yMLt4YO9wTvGD4j2Nei3E/pwg0yrJu+0kdr7pT/TDLSIdc0SB7YsfW4U5EYg+x2ycOUV6I+7d9PI= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM7PR07MB6785.eurprd07.prod.outlook.com (2603:10a6:20b:1c2::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.9; Fri, 4 Dec 2020 17:09:10 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::ad44:1086:3767:a804]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::ad44:1086:3767:a804%7]) with mapi id 15.20.3632.018; Fri, 4 Dec 2020 17:09:10 +0000 From: tom petch To: Fernando Gont , Fred Baker CC: Gorry Fairhurst , IPv6 Operations , "draft-ietf-v6ops-ipv6-ehs-packet-drops.authors@ietf.org" , Fernando Gont Thread-Topic: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-packet-drops-01: "can" vs "may" in English usage. Thread-Index: AQHWyZdmMR9RE2wt+UO2CzbqPBA7pqnlwh0AgAFplJ0= Date: Fri, 4 Dec 2020 17:09:10 +0000 Message-ID: References: <0c121812-44cf-119e-fd09-bb138ff789de@erg.abdn.ac.uk> <2B7068A6-AB53-4685-AF47-9290A745BD13@gmail.com>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: si6networks.com; dkim=none (message not signed) header.d=none;si6networks.com; dmarc=none action=none header.from=btconnect.com; x-originating-ip: [86.146.121.140] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0ce831a6-71d5-4195-f8ae-08d89877517a x-ms-traffictypediagnostic: AM7PR07MB6785: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /XfC2P15ft8zlP2yy0Z6t6iCaibLBEKxb7MRWWPXcbcXtgtOkfjIcDDAted3sPcMRuCLtDQggBDlXqcmZ/gevaq0WXghunjJlsokFdWjqbwRA3dxRWJN0DSiGGuoKFKEfN0PHi4tfNZgaxRUyiX/r0zxf8l7fwS9kufEQILDVLUFC6bZGuCvDY8ZyX6lP7moiApjpMrvk+zYxgMwgufAH87mjQgACW75PkHxM9f3LfuzTRj92y4IgxcGjvv7B5aesENbR8XFcwwtKTqAoXoU7JkQW0wrpvZiVhaYOdhE1wMcwaltHXA401Z5ZGJ3EBzze/ww/R4lY2JlBDgvMl9XbbIx9p6lumOEzfjLkkmKq4tiF/x0a4NMT+PonfroT9N1H7Ht3cDpqVlHBQF+k5bcgQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(346002)(366004)(39860400002)(136003)(396003)(8936002)(86362001)(8676002)(33656002)(966005)(478600001)(26005)(2906002)(6506007)(53546011)(83380400001)(186003)(110136005)(55016002)(9686003)(54906003)(316002)(71200400001)(4326008)(66446008)(64756008)(66556008)(66476007)(66946007)(7696005)(5660300002)(52536014)(76116006)(91956017); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?SBvI9GCirOJZzh7SkJseac8QJYBULPomiBETQ7pHGPhCQxja2BhbZojrKK?= =?iso-8859-1?Q?kCmoTKtZQQ6ZQoN2bwNk9YeAO578CRenzt6PAGOxd+OulAMVwgCP5zNG6V?= =?iso-8859-1?Q?WSCHV0LqdT/warbBxc5wz4Bz8mdBphCqxn/upiMq/0dVnVI6Pm8tQH9Qlw?= =?iso-8859-1?Q?xi3yjfB7/sGNh6C0XgSatGm1upX2rj5sno/koJEXWPUgbTEYMdifHym2ka?= =?iso-8859-1?Q?B8PpJk+tquQiD640MAtB9hgVYGpjE3K4Jm7O74zh9fblvD2IRKGTy+y5cU?= =?iso-8859-1?Q?EAzyvLPs8DYaWkXgXliTM4nrcfIak8DH8aQZJp0WCU5toQS2Ijy05evqEt?= =?iso-8859-1?Q?K4a1fe08b0pj6JRlcca9xIQU5vW9Oa9xcwUvszJflyNR6JbrlAKvevhDmd?= =?iso-8859-1?Q?hQSN2pSW5436514Apczy2ilY2/hpLOSVeEnujxyIhWF4kG1gzQA+z79CXF?= =?iso-8859-1?Q?lbF54O92oJcTy2/40CVlw0XTZtslwavzYqn7oJfcpofY/RKHaYxJRxVWpX?= =?iso-8859-1?Q?3lKZwNllI4fofJ2sQ6kGe3xNolm9m1qv83H9/dkXa6o8KBEsuxQIbfJDeO?= =?iso-8859-1?Q?Hb2424zRl5qYrra0QyqYh0JSUMfEZrtA4sfI+5GxwNTP9PLDpBu1DKuE0T?= =?iso-8859-1?Q?52Kx2GYr+e2YGAB/eJ15kl8gW3E4iah9AssHiWOBGjcYpD4WK7ULEDDwNx?= =?iso-8859-1?Q?5FFU4OoeM/uH4MkHG3O5LiDByTPfLTkVjrI7BOq6OIIwqPZFncMyFWo77R?= =?iso-8859-1?Q?ct7WGU6GxS8zJR/Nb9sLreIx80vgp0jRVuq5erWspOC3CmXKKWWSHSaT/T?= =?iso-8859-1?Q?mgTOkLjyIAL1PoirkBWhRh6gjEuUWHmcbh3Cq2P/ZZVjE/h/oA4X396afx?= =?iso-8859-1?Q?2vLntErrcAZ9JE3fX2vQcsc8qLywXdP5mhMFlNt/R20kRwCPH8L6sRD9fc?= =?iso-8859-1?Q?xuXo98VZ1uKmylX1mJdEjC5zDr+qIbyxhu/diBmxouuTfct37zkebSnWoY?= =?iso-8859-1?Q?I1woH96cOA+z8fcdQ=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0ce831a6-71d5-4195-f8ae-08d89877517a X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2020 17:09:10.7602 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ex2ohU6WbyrHD0h5EUMEBNsBAytSPnSEo9GVnl5/uUAIpNwuDOq4oClANLIor4ts3CQPVDImQqjkXyCDW6rPaw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6785 Archived-At: Subject: Re: [v6ops] Comments on draft-ietf-v6ops-ipv6-ehs-packet-drops-01: "can" vs "may" in English usage. X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 17:09:22 -0000 From: v6ops on behalf of Fernando Gont =0A= Sent: 03 December 2020 19:29=0A= =0A= On 3/12/20 14:11, Fred Baker wrote:=0A= >=0A= >=0A= >> On Dec 2, 2020, at 9:52 AM, Fernando Gont wrote:= =0A= >>=0A= >> ("can" =3D ability, "may" =3D possibility)=0A= >=0A= > I tend to use "can" in the sense of capability, which may correspond to y= our word "ability". "May", however, is about permission. "You can get get h= ot water from the kitchen" indicates that hot water is to be found there, a= nd that you have the capability of trotting off there - whether or not you'= re interested in hot water or have any desire to go to the kitchen. "You ma= y get hot water from the kitchen" gives you permission to go to the kitchen= for that purpose.=0A= >=0A= > Note that this differs from colloquial usage. "Can" is often used in the = sense of "may" in common usage ("can I please have some candy?" with the me= aning "may I please...?"), which can be very confusing. In written communic= ations, I try to keep theses straight.=0A= =0A= Thanks for the note! I will definitely go back to my grammar book and=0A= try to save everyone's time -- I do remember that the last year I took=0A= English lessons there was a unit about "need" vs "must" vs "have to" vs=0A= "may" vs "can" vs "might". I also remember another on "that" vs "which".=0A= Definitely need to check both of these, since I've been getting both of=0A= them wrong lately :-(=0A= =0A= =0A= =0A= My pet hate is those who say something cannot be done when it patently can;= they just do not want to say they will not do it.=0A= You might want to add to your list 'e.g.' versus 'i.e.' a choice which does= change the meaning and which I think is wrong in some I-D. A statement th= at an option can be signalled by an IGP e.g. OSPF is very different to sayi= ng that an option can be signalled by an IGP i.e OSPF. I came across one = such earlier this week.=0A= =0A= Tom Petch=0A= =0A= =0A= Thanks for the help!=0A= =0A= Regards,=0A= --=0A= Fernando Gont=0A= SI6 Networks=0A= e-mail: fgont@si6networks.com=0A= PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492=0A= =0A= =0A= =0A= =0A= _______________________________________________=0A= v6ops mailing list=0A= v6ops@ietf.org=0A= https://www.ietf.org/mailman/listinfo/v6ops=0A= From nobody Fri Dec 4 15:35:15 2020 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 5D7E63A0E32; Fri, 4 Dec 2020 15:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_24_48=1.34, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, 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 gUitAfVsZUdG; Fri, 4 Dec 2020 15:35:10 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E2083A1083; Fri, 4 Dec 2020 15:35:07 -0800 (PST) Received: from [IPv6:2800:810:464:8164:896a:de13:c010:ff3a] (unknown [IPv6:2800:810:464:8164:896a:de13:c010:ff3a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 29AF2283AA7; Fri, 4 Dec 2020 23:35:02 +0000 (UTC) To: Tom Herbert , Brian E Carpenter Cc: Erik Kline , IPv6 Operations , tcpm , Fernando Gont References: <0d38980a-f1c5-fac5-a9b1-0711d61353d1@gont.com.ar> <42b6e327-08b5-292b-be65-28f1a8508a69@si6networks.com> <85dd3823-ff2d-94ac-3535-d3d042bdd338@gmail.com> From: Fernando Gont Message-ID: <70c456f7-ce86-1bd2-a580-71524ce2606f@si6networks.com> Date: Thu, 3 Dec 2020 19:41:33 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] [tcpm] Flow Label Load Balancing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2020 23:35:14 -0000 Tom, On 3/12/20 17:38, Tom Herbert wrote: > On Thu, Dec 3, 2020 at 1:17 PM Brian E Carpenter > wrote: >> >> On 04-Dec-20 06:30, Tom Herbert wrote: >>> On Thu, Dec 3, 2020 at 8:43 AM Erik Kline wrote: [....] >> >> But that doesn't help with server load balancing. For ECMP/LAG in a >> transit network, the DA alone doesn't help either, if a particular >> destination is prone to very heavy flows for some reason. > > Brian, > > Specifically, that is a problem for a host that uses a _single_ IPv6 > address for all its connections. That that's the vast majority of current hosts - if not all. > What I am suggesting is to give hosts > many addresses, which we already do anyway like when mobile devices > and data center servers are assigned /64s. If a host then randomly > chooses an address from that block for each connection it creates > thenl the address 2-tuple contains all the entropy needed for purposes > of load balancing, ECMP, etc. is contained in the source address. > Addresses are guaranteed to be present and plaintext in each packet so > no DPI required, they're as stable as any flow identifying information > in a packet can be and they offer much more entropy than sixteen bits > of port number of twenty bit flow label. Agreed. Although that move is not-trivial: e.g. if you move from shared link to /64 per hosts, then stuff like mDNS breaks. There's also an API to be specifiied. P.S.: And, in the process, we have kind of burned 64-bits of the 128-bit IPv6 addresses, too... Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sat Dec 5 07:00:33 2020 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 E94B43A0CEF; Sat, 5 Dec 2020 07:00:32 -0800 (PST) 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: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <160718043290.26536.17340262004597618489@ietfa.amsl.com> Date: Sat, 05 Dec 2020 07:00:32 -0800 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Dec 2020 15:00: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 : Operational Implications of IPv6 Packets with Extension Headers Authors : Fernando Gont Nick Hilliard Gert Doering Warren Kumari Geoff Huston Will (Shucheng) Liu Filename : draft-ietf-v6ops-ipv6-ehs-packet-drops-02.txt Pages : 20 Date : 2020-12-05 Abstract: This document summarizes the operational implications of IPv6 extension headers specified in the IPv6 protocol specification (RFC8200), and attempts to analyze reasons why packets with IPv6 extension headers are often dropped in the public Internet. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-packet-drops/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-02 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-ehs-packet-drops-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 Sun Dec 6 04:52:19 2020 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 76E453A0D42 for ; Sun, 6 Dec 2020 04:52:17 -0800 (PST) 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 CZaP9D6n2PZW for ; Sun, 6 Dec 2020 04:52:13 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 471303A0D41 for ; Sun, 6 Dec 2020 04:52:12 -0800 (PST) Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 467541B00196 for ; Sun, 6 Dec 2020 12:52:09 +0000 (GMT) To: v6ops@ietf.org References: <160718043308.26536.7991095281194976496@ietfa.amsl.com> <5ec0a78c-df25-830a-df03-23bcbee70758@si6networks.com> From: Gorry Fairhurst Message-ID: Date: Sun, 6 Dec 2020 12:52:07 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <5ec0a78c-df25-830a-df03-23bcbee70758@si6networks.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB Archived-At: Subject: Re: [v6ops] Fwd: New Version Notification for draft-ietf-v6ops-ipv6-ehs-packet-drops-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Dec 2020 12:52:18 -0000 I read the new version and the issues I saw have now been resolved, and this version looks good to me. Thanks for taking the trouble to look into this! I do think the new text will prove useful in the ongoing discussion of how to improve deployment of IPv6 features. Best wishes, Gorry P.S. I noted a couple of very minor English NiTs to the authors that may be addressed next revison. > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-ietf-v6ops-ipv6-ehs-packet-drops-02.txt > Date: Sat, 05 Dec 2020 07:00:33 -0800 > From: internet-drafts@ietf.org > To: Warren Kumari , Geoff Huston , > Gert Doering , Will Liu (Shucheng) > , Will LIU , Nick > Hilliard , Fernando Gont > > > A new version of I-D, draft-ietf-v6ops-ipv6-ehs-packet-drops-02.txt > has been successfully submitted by Fernando Gont and posted to the > IETF repository. > > Name:        draft-ietf-v6ops-ipv6-ehs-packet-drops > Revision:    02 > Title:        Operational Implications of IPv6 Packets with Extension > Headers > Document date:    2020-12-05 > Group:        v6ops > Pages:        20 > URL: > https://www.ietf.org/archive/id/draft-ietf-v6ops-ipv6-ehs-packet-drops-02.txt > Status: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-ehs-packet-drops/ > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-ehs-packet-drops > Htmlized: > https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-02 > Diff: > https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-ehs-packet-drops-02 > > Abstract: >    This document summarizes the operational implications of IPv6 >    extension headers specified in the IPv6 protocol specification >    (RFC8200), and attempts to analyze reasons why packets with IPv6 >    extension headers are often dropped in the public Internet. > > > > > 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. > > The IETF Secretariat > > From nobody Mon Dec 7 10:19:31 2020 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 4A8CC3A1649 for ; Mon, 7 Dec 2020 10:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=juniper.net header.b=2aJPXkzF; dkim=pass (1024-bit key) header.d=juniper.net header.b=WC+IfAFx 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 cHKIu9e3FlcW for ; Mon, 7 Dec 2020 10:19:28 -0800 (PST) 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 066D63A164A for ; Mon, 7 Dec 2020 10:19:27 -0800 (PST) Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0B7I8ogS016507 for ; Mon, 7 Dec 2020 10:19:27 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=LoyuTTikNPn3ClFl2JH7ngW0XwqyZP688axahT7nEEc=; b=2aJPXkzFbCV4SG8IjX8Y6CP/Sv89WPP8Db5PF4mj7NT5HHaRWp44IOBt/yMnIRBntXYi sMgaTA/RQ6jt9AI+NLBN0bma2ZDfptP1fFfl7LV2SL3Z8KrSr2ugLY8vBLeTRvvV42k9 P9edFh8KOhvBbIXQ+iPnZ1DZNi5E84oAzEzrnUM4agD/ghymlzbkREra47F6KxZs2Tsk baad1p1v2dhBVfDHogNcSZgDoo9lOeY1rzvj4n+W7xqcMcj5XKltF61dIxauQgt+TLIy qYBnj+YpBNNrp5hK7yDr2PajCOKV18wP039AeUygYrKOi4xeMM5qvGlh63G06ZkqHb1e RQ== Received: from nam04-dm6-obe.outbound.protection.outlook.com (mail-dm6nam08lp2047.outbound.protection.outlook.com [104.47.73.47]) by mx0b-00273201.pphosted.com with ESMTP id 3589bdau75-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 07 Dec 2020 10:19:27 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fj+zGl97r0yxT2nrutsQXJ9NeEGN/XWLtxdz07ONkF79sIrykKIzVGFNmUPqXTlKwAnFVoPtMTW2j1Lz+Lq0mtydU/gmGASAk+egKV/Il/WJxQwmNxlcOKAm0DKCM+8EcJKhxt9gJiox/bi39JE9x9fcG+x0f3kfxY3T23XT9R3QJHKeWr/Y+sr5qvR1oo2PUTcUWpFPBh71E3HrtTvKAZta751xcEJhvhHo7QBkmQuhEV4WUxEOosqqSYt5uK2VZr/PE12CkcRCMvZsohUmpNn0dJYucVZorj72F6nVqG2mac9kHWsFQdvI498gog8IQQfRH4AeN9mUvNQYlAYISw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LoyuTTikNPn3ClFl2JH7ngW0XwqyZP688axahT7nEEc=; b=ASRT2NN3WkdBQNB8eu5WvHruAyKfDaL7dmglK2eLeBkyVnd6dAFcRT9hF6NBXSmzFwwPvTdEgwjuSIyIbFFaP5PBtUvnqXOwb3w2+BO6MNOImPC/bx7ckXngdxVPnB7IfaTLlAuXgbyrny0pi7GueUevXdvcOLH8Ncl06MgjpvK4PAFuEEeZ7SlbyQicwzgJLcA+vEmxJI799vzROKENehXlRrzraRUrdy/cOJMmgIypoCGhlYI8FOPhihyU6D6PMATdYUjvFADxKoCRCd2GYWHae3GBhkrgyIC3akimav7CPWJF/TvGfRVNlXB04MI390xR/tOY4hg2YWFpNCibDQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LoyuTTikNPn3ClFl2JH7ngW0XwqyZP688axahT7nEEc=; b=WC+IfAFxWA8eZMQHZnBRO2QUtcOpMnx4Qr/Jawhejdd3NlBvjTqgKDO7ihEHyi2uMmNSnGw6uEwLp6dsgUJiJVQs9PJnq7dR9TofmGZAWWDfC1JJxFtDH58kxjO8pufW1B8C6Bzj+ftYT01V7dzhD45+Jki+9Mlu75jjfuYVD8A= Received: from DM6PR05MB6348.namprd05.prod.outlook.com (2603:10b6:5:122::15) by DM5PR0501MB3830.namprd05.prod.outlook.com (2603:10b6:4:7c::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.10; Mon, 7 Dec 2020 18:19:25 +0000 Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::a435:88ed:7e2a:4fe6]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::a435:88ed:7e2a:4fe6%5]) with mapi id 15.20.3654.012; Mon, 7 Dec 2020 18:19:25 +0000 From: Ron Bonica To: "v6ops@ietf.org" Thread-Topic: draft-ietf-v6ops-ipv6-ehs-packet-drops Thread-Index: AdbMxWnHfcCKbNKfSbeduGei9jL9RA== Date: Mon, 7 Dec 2020 18:19: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.5.0.60 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-12-07T18:19:24Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=ec8cc26a-7438-49e4-b991-d7631eb15e2f; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [173.79.115.7] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 9c99e66a-aefd-4bf3-0f46-08d89adca0e1 x-ms-traffictypediagnostic: DM5PR0501MB3830: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jtYlGnHDCQ0z/3tivCaxowb228Ua1Jfc7R8BP5z2aJlo9MSv8fN0Ir17nBbsliu0kjKzqZh/wd9ddPURBfznDA1SkJGYbbmui86GHa0W6CFaSXyTuQ3VJB1Gn87UxnLcCtn1KbaVqU74YZaRXvzwzUPMwgnqgXb0TXIBIXuFPg6iR7MzTlWbF4NAxHQd7RtKRjZFKLSJEoOMiUR+IZDLUgWWu01qAWxSxBUObD/NREwOMSkkEa3fUR7pKVASo6j8qp3EEvERozTxzOWYzn3Ptl5MnorugjyNb3mYfHr19MhT2RhKM1osQMF0qEaa0RewJ3zsVksEJmbG1vDWCi0/Kmc5AjUj0e73DmGOBuiKc7Tutx1Rpv4Ni6Q7EgcUgUbhpN4Edyo/s5OiorCmVFkOxA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6348.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(39860400002)(376002)(366004)(136003)(396003)(66476007)(316002)(7696005)(55016002)(64756008)(76116006)(9686003)(66556008)(478600001)(8676002)(5660300002)(66946007)(2906002)(8936002)(6916009)(33656002)(26005)(71200400001)(558084003)(52536014)(66446008)(6506007)(166002)(86362001)(186003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?omCWv7sNyzL9hAV+TBRrnh9w+FbMwAFxauR/IAQ7sf4nxbrFxl3TrFnc6Ref?= =?us-ascii?Q?pNT+sDl/zJdoDqI7tPlKIjwz13YjHTwWQ05co3K1PSJIFkchRnzR3wWkw027?= =?us-ascii?Q?IPG/FqDDRwnYQd02DXLMH8DXKm5afiCs4pkTUgpF8uNoIqM6pyRDX0meOGdr?= =?us-ascii?Q?BnETeMa8UVBNt7Qneqc6e+yQuAdEFSF+pUpUvUTvryiAGhtJKDsrQRSwJt4y?= =?us-ascii?Q?Gs6K28oS8X0Fsjff53Pf/GizFUcU/v0RDqUlad/8GImzEgs1iqMvFJ+bjNVt?= =?us-ascii?Q?ubBEScMo8oo7xPeJ/c0bykRY+VOny/GElFE+WBvp2O9+FCUc422yO+Srtghb?= =?us-ascii?Q?jrKvHgN0e0azSj22A5MuebW/L/XQzezLHx8SFRl8w+w1sevhoC7QZrq1a9SF?= =?us-ascii?Q?nxmoJUfa0wHGAaT/g5kTSDT0vBe2VzmD82cICoF4MalDWypZrXyQlksQJRev?= =?us-ascii?Q?ESgs1lIkA1/IqcX4xij6ZOHB1FJlFaxVUr7CDuWaxklVldier3Le1bQSqrND?= =?us-ascii?Q?a/d5XpVFrvANmQ2WS4ulsOL8dnSq1XlAWz/0CBbrkU8Dix2QswPftmXCk1if?= =?us-ascii?Q?4cj75GmBM30VAiuLsx1t3+Zv4Dp2N3NgEl2bglyCmOPHDDTyZzD2Dxcjzec8?= =?us-ascii?Q?YCKhLaspE0K2pMoTyyotTtsWzFTes/IBh8mXKq+kMmcn24zmGUW+mnD0p2KS?= =?us-ascii?Q?Oy/9EAWZc89GNM+jRD+9n9ekjtOBsoesUupiVC+EhSXtgaibkkx2zETTWONE?= =?us-ascii?Q?cuQlnLPKjqJRELElHEHW1BQjSkOFrtcMTSBCK34hteJqupa4pC6j6ZDu2CqA?= =?us-ascii?Q?s+62kE5tatvgIN3xeu2NBxHn8NfzM+bzp1MeoWw6YzGZmz3rmRcFz4gWBV6t?= =?us-ascii?Q?dfUPZ6nQJSvbkGpQ7wy+/8aEaRtURwTupvNSOlAoIveapaU5VdRENBYKD5jO?= =?us-ascii?Q?KtWZ2I9AmMlGTMKPWJapglWjlM8li689S/AKJOUcfdI=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR05MB6348B41875CFEA2E492F9DF2AECE0DM6PR05MB6348namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR05MB6348.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9c99e66a-aefd-4bf3-0f46-08d89adca0e1 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2020 18:19:25.4292 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: PZ9FK+YYUjpdy34s+5eOFFmVDNdMeSb4HzoSGSrteNGmcCUEOJsllGx4lf61O9bCVfIdGScJUUf1gB5NTjZs2g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR0501MB3830 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-07_16:2020-12-04, 2020-12-07 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 phishscore=0 spamscore=0 malwarescore=0 impostorscore=0 lowpriorityscore=0 clxscore=1015 suspectscore=0 adultscore=0 mlxscore=0 mlxlogscore=916 bulkscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012070118 Archived-At: Subject: [v6ops] draft-ietf-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 18:19:29 -0000 --_000_DM6PR05MB6348B41875CFEA2E492F9DF2AECE0DM6PR05MB6348namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, We didn't have much time to discuss presentations at IETF 109. So, this wee= k, the chairs invite discussion of Fernando's draft draft-ietf-v6ops-ipv6-e= hs-packet-drops. We will discuss each remaining presentation in the weeks to come. Ron Juniper Business Use Only --_000_DM6PR05MB6348B41875CFEA2E492F9DF2AECE0DM6PR05MB6348namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

We didn’t have much time to discuss presentati= ons at IETF 109. So, this week, the chairs invite discussion of Fernando= 217;s draft draft-ietf-v6ops-ipv6-ehs-packet-drops.

 

We will discuss each remaining presentation in the w= eeks to come.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;    Ron

 


Juniper Business= Use Only

--_000_DM6PR05MB6348B41875CFEA2E492F9DF2AECE0DM6PR05MB6348namp_-- From nobody Mon Dec 7 11:49:13 2020 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 2787A3A0990 for ; Mon, 7 Dec 2020 11:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 Xs1Y4l3MudQc for ; Mon, 7 Dec 2020 11:49:03 -0800 (PST) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 E17383A0880 for ; Mon, 7 Dec 2020 11:49:01 -0800 (PST) Received: by mail-pg1-x531.google.com with SMTP id t37so9838630pga.7 for ; Mon, 07 Dec 2020 11:49:01 -0800 (PST) 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=TjAhAFDNPeZhK4RX8L9RpX3e3HZDLgH0NGwpN5tJ9Lc=; b=AwtFS2pr+tZx3JLYLk5uCDUtTss4ympn8oksoX9jIvlb/BBQSEYdBWxwjhnvWo5Zh1 olO29p2i4Se3qUOW33tz5p+GdtXJaRB/cuF1nMn4GUGgIAKc41zEvJe4UmzEfp7Lb+O7 VQXpXgEjD9kr0oV8EApKojUQQyQ+vrOFOohggCYR7/0LSYHkdBp51/oGHqCdZF/HBZcM STAwx//wH1EjLFYz4U48XdHyKMg1XaBuTrTTNNZgPwZ1f/d/mJNBP5Wv0SYOrTyf4qJO Nz0AfIek+4Z9bHql2NLvPMVwpfYAkK54x+y/crdX8Ba92/tQjNdPUplLUwkSGxJ85RC1 f6wg== 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=TjAhAFDNPeZhK4RX8L9RpX3e3HZDLgH0NGwpN5tJ9Lc=; b=XUZMB0V2Lvf8RbDr516olr19w1CNOJdnbmlJYbsiCkXdXX8e/yyANTxcrYzsgYgC7F UdKRfdfmk3/mfwDk8M0p2vdo1islfyMoEhpbNpMEgjj/FTfOdlSQ2geo8wao0lpFe3By dLfDhni63PKXNwrtuS0pNLJ0ky0lKECtdS/sjMtuVVAyzJze1vtCvYVW1xyFBlDH23Vo aR5Wrn7im9YVtPkbrOr0UlUt6uZkCuSDRY5xAFkMpDrpDqOwSFkMhJCORzSu9lc5x9AG QEvFumWuuCSPpbgY1nUzf/39AOciiUoF9tzC4YNunRrMiONcgerh+9UxeY6/ovcUQt3P yoMA== X-Gm-Message-State: AOAM532JBcvezPLisYaptDFFRynQhWOVpImv/abpRz8h44MSwDDLmp+J waSaQWdghUu070EO/CFTHelhbnJb47MN9A== X-Google-Smtp-Source: ABdhPJzwKYDdU/X0M/ZCkB+kUJGnqn1Krd5khS44PEVW1T0BYQQRR+R17jWTjzaXCDaXMbjEMocUzA== X-Received: by 2002:a17:90a:2c04:: with SMTP id m4mr404913pjd.35.1607370541012; Mon, 07 Dec 2020 11:49:01 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id gj15sm165878pjb.9.2020.12.07.11.48.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Dec 2020 11:49:00 -0800 (PST) To: Ron Bonica , "v6ops@ietf.org" References: From: Brian E Carpenter Message-ID: <18f7f3ce-5b28-1c16-f1de-16078043f09c@gmail.com> Date: Tue, 8 Dec 2020 08:48:58 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-ipv6-ehs-packet-drops X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 19:49:12 -0000 Hi Ron, I think this is useful work and mature enough for WGLC. Regards Brian On 08-Dec-20 07:19, Ron Bonica wrote: > Folks, >=20 > =C2=A0 >=20 > We didn=E2=80=99t have much time to discuss presentations at IETF 109. = So, this week, the chairs invite discussion of Fernando=E2=80=99s draft d= raft-ietf-v6ops-ipv6-ehs-packet-drops . >=20 > =C2=A0 >=20 > We will discuss each remaining presentation in the weeks to come. >=20 > =C2=A0 >=20 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Ron >=20 > =C2=A0 >=20 >=20 > Juniper Business Use Only >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From nobody Mon Dec 7 13:25:44 2020 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 CCAD63A0B26 for ; Mon, 7 Dec 2020 13:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.647 X-Spam-Level: X-Spam-Status: No, score=0.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, 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 6F5npbKRS74l for ; Mon, 7 Dec 2020 13:25:41 -0800 (PST) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435313A0B18 for ; Mon, 7 Dec 2020 13:25:41 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0B7LPcBA009379; Mon, 7 Dec 2020 22:25:38 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id C5EE420B833; Mon, 7 Dec 2020 22:25:38 +0100 (CET) Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id B863720B793; Mon, 7 Dec 2020 22:25:38 +0100 (CET) Received: from [10.11.240.40] ([10.11.240.40]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0B7LPcEV004436; Mon, 7 Dec 2020 22:25:38 +0100 To: Fernando Gont , v6ops@ietf.org References: <38cb7e50-a44f-0fa8-dd70-8caa7846cb78@gmail.com> <0c7c442e-a128-2ed4-4ef0-b1a56411990c@si6networks.com> From: Alexandre Petrescu Message-ID: Date: Mon, 7 Dec 2020 22:25:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <0c7c442e-a128-2ed4-4ef0-b1a56411990c@si6networks.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] IETF109:: IPv6-only adoption challenges and standardization requirements X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2020 21:25:43 -0000 Le 30/11/2020 19:54, Fernando Gont a crit: > On 30/11/20 14:47, Alexandre Petrescu wrote: > [....] >> >> I wanted to get confirmation that is the way that it is? >> >> UEs getting IPv6-only is a great step forward. >> >> But the /64 prefix for an UE might be a relatively limiting aspect if >> considering mobile hotspots. > > That's already the case for e.g. many fixed-line (e.g. Cable) ISPs. > e.g., I get a /64 from my ISP. I obtained a short list of operators (mobile and home) doing /64 where I live. I am still digging for exceptional cases that might do shorter-than-64 and I was hoping this one could be the case. Another thing I look at operators is whether IPv6 is carried in IPv4 (e.g. GTP is IPv6 in UDP IPv4) or is IPv6 on bare metal. I was hoping this operator here might do GTP IPv6 in UDP in IPv6. But probably this slot of discussion expired. I will ask later. Alex > > Thanks, From nobody Tue Dec 8 12:22:44 2020 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 B88783A112B; Tue, 8 Dec 2020 12:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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=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 lcTb_K2NLkdt; Tue, 8 Dec 2020 12:22:36 -0800 (PST) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 4150B3A1129; Tue, 8 Dec 2020 12:22:36 -0800 (PST) Received: by mail-pf1-x432.google.com with SMTP id 131so14965036pfb.9; Tue, 08 Dec 2020 12:22:36 -0800 (PST) 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=eYs/r0WzY6dNsFT0eupBFT4VaVjaPNww8ACMhUgrqqw=; b=JVrRup6dmku6wjhrf1TmdZBxAF7PA/kXLSSbSvgg4AgB9C94yf+CzwfoYsn2B83DOu hrIRTbHLHJu2yQsZdyULf7fvi/VHX+gEmxrDb4TnIOMpNDpOtUcUX17lu/8rivoXRDJ3 G2b8AwGGjS4WzZLlr1SPoDqgz4TXW3PV0cOHq1VaeKdBFC7IJBODlQwkad4noR3qjon+ o2/fezf/9LQgktbeSbZcpLUfILe6iZhoEgkHwNtWHSR04qtmkWqg2auVf6Hw6HVltyzW QyEilfjiSon5GvlUH5c8k4AmyjQa0td6E2svmnBGcVGHbt0X7B97T0pY2elnYdxfWIWT qYPA== 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=eYs/r0WzY6dNsFT0eupBFT4VaVjaPNww8ACMhUgrqqw=; b=MuIn0UCs77bMIYYq9yOTGW6VqQ5d9Mqdis7yO1XWfPaHUYpbuvs8XhpWyUar0Tjw4t ZnDiIPNdr4oXm/h2Ol0QAq/HadoT9CvBZu0uM0wkfLs69pshcR4tmJOfvkuNFfnYfclP KRiAvHRg1jN0gI4beuZiIAgbwnRoMOukuozNHwYldAcYgBGyyuQaxiMERe2YMuiDpc6F uiXD5cJ/h7IzYdS24HPLK7SBw9dLvW1YpRbb7ZPMExa1+O+q5CYoA4UnaIQWlEwC0hrg UvLxHvjzyzR0rRqn6iZykgmAAaxAbmMjCgN3jHntnx1CyQ1v8jhEy0N+eGfKHJtEbAx/ f5mA== X-Gm-Message-State: AOAM5324IL7YvABLE8IrAwii4lGIUybGL0AhZRuRndQNMwOTsl5YMcH1 LFo8kdosjhJwZoG4/+x9qMsYxRPKmi1NmuMYGcuzsZi+YR8= X-Google-Smtp-Source: ABdhPJxmlRK414dtqHoHKz7IxZhS3VINTqA8G8br/yK186V6+WUjJLQlY11nDmZ/Z+9O/Lwn9Ujnoo0o2FmT65R4rn4= X-Received: by 2002:a17:90a:178b:: with SMTP id q11mr5824577pja.132.1607458955229; Tue, 08 Dec 2020 12:22:35 -0800 (PST) MIME-Version: 1.0 From: Gyan Mishra Date: Tue, 8 Dec 2020 15:22:24 -0500 Message-ID: To: IPv6 IPv6 List , IPv6 Operations Content-Type: multipart/alternative; boundary="000000000000047fe505b5f9b4aa" Archived-At: Subject: [v6ops] RFC 6437 - IPv6 flow label usage in context of ECMP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 20:22:39 -0000 --000000000000047fe505b5f9b4aa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear v6ops & 6man, I have a question related to how IPv6 flow label works in the context of router ECMP load balancing characteristics resulting in even or uneven load balancing based on the understanding flow based or n-tuple ECMP hash based per packet algorithm. My understanding of RFC 6437 is that the IPv6 flow label is a means of classification of packets that are part of the same flow from a particular flow for use in QOS marking. >From a load balancing perspective the flow key could be used to identify a flow and path taken on routes in a case of load balancing ECMP hash. The goal of IPv6 flow label is for ordering of packets to be part of the same network path in an ECMP hash resulting in flow based load balancing identical to what exists today with IPv4. What is confusing is if flow label 5 tuple is input to a ECMP hash algorithm similar to LAG and MLAG which yields per packet load balancing based on n-tuple hash implemented by most vendors. This would be preferable if as it would yield even load balancing. Or is the flow label goal to maintain the per flow load balancing and use for QOS packet classification so all packets that are part of a particular flow use the same ECMP path. In this case the n-tuple hash key generated is just to identify which path the flow had taken on a router but not an input to a hash algorithm function as exists with LAG or MLAG. The difference is significant as far as load balancing as a n-tuple input to ECMP hash algorithm achieves close to 50/50 load balancing where per flow load balancing can be uneven as it=E2=80=99s based on flows and thus f= rom a network standpoint high bandwidth flows may hash to one ECMP path and low bandwidth flows may hash to another ECMP path. So in general with parallel links bundling LAG and MLAG is always preferred method for load balancing distribution over ECMP. However L3 ECMP always exists and is optimal to assist further load balancing which often times exists in conjunction with LAG and MLAG. Excerpt from a doc I found online related to IPv6 flow label operation: A flow is a sequence of packets sent from a particular source to a particular (unicast or multicast) destination for which the source desires special handling by the intervening routers. The nature of that special handling might be conveyed to the routers by a control protocol, such as a resource reservation protocol, or by information within the flow's packets themselves, e.g., in a hop-by-hop option. The details of such control protocols or options are beyond the scope of this document. There may be multiple active flows from a source to a destination, as well as traffic that is not associated with any flow. A flow is uniquely identified by the combination of a source address and a non-zero flow label. Packets that do not belong to a flow carry a flow label of zero. A flow label is assigned to a flow by the flow's source node. New flow labels must be chosen (pseudo-)randomly and uniformly from the range 1 to FFFFF hex. The purpose of the random allocation is to make any set of bits within the Flow Label field suitable for use as a hash key by routers, for looking up the state associated with the flow. All packets belonging to the same flow must be sent with the same source address, destination address, and flow label. If any of those packets includes a Hop-by-Hop Options header, then they all must be originated with the same Hop-by-Hop Options header contents (excluding the Next Header field of the Hop-by-Hop Options header). If any of those packets includes a Routing header, then they all must be originated with the same contents in all extension headers up to and including the Routing header (excluding the Next Header field in the Routing header). The routers or destinations are permitted, but not required, to verify that these conditions are satisfied. If a violation is detected, it should be reported to the source by an ICMP Parameter Problem message, Code 0, pointing to the high-order octet of the Flow Label field (i.e., offset 1 within the IPv6 packet). The maximum lifetime of any flow-handling state established along a flow's path must be specified as part of the description of the state-establishment mechanism, e.g., the resource reservation protocol or the flow-setup hop-by-hop option. A source must not re- use a flow label for a new flow within the maximum lifetime of any flow-handling state that might have been established for the prior use of that flow label. Excerpt from Section 2 below: The 20-bit Flow Label field in the IPv6 header [RFC2460 ] is used by a node to label packets of a flow. A Flow Label of zero is used to indicate packets that have not been labeled. Packet classifiers can use the triplet of Flow Label, Source Address, and Destination Address fields to identify the flow to which a particular packet belongs. Packets are processed in a flow-specific manner by nodes that are able to do so in a stateless manner or that have been set up with flow-specific state. The nature of the specific treatment and the methods for flow state establishment are out of scope for this specification. Flow label values should be chosen such that their bits exhibit a high degree of variability, making them suitable for use as part of the input to a hash function used in a load distribution scheme. At the same time, third parties should be unlikely to be able to guess the next value that a source of flow labels will choose. o Forwarding nodes such as routers and load distributors MUST NOT depend only on Flow Label values being uniformly distributed. In any usage such as a hash key for load distribution, the Flow Label bits MUST be combined at least with bits from other sources within the packet, so as to produce a constant hash value for each flow and a suitable distribution of hash values across flows. Typically, the other fields used will be some or all components of the usual 5-tuple. In this way, load distribution will still occur even if the Flow Label values are poorly distributed. Although uniformly distributed flow label values are recommended below, and will always be helpful for load distribution, it is unsafe to assume their presence in the general case, and the use case needs to work even if the flow label value is zero. As a general practice, packet flows should not be reordered, and the use of the Flow Label field does not affect this. In particular, a Flow label value of zero does not imply that reordering is acceptable. Kind Regards Gyan --=20 *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --000000000000047fe505b5f9b4aa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear v6ops & 6man,
<= div dir=3D"auto">
I have a question related to h= ow IPv6 flow label works in the context of router ECMP load balancing chara= cteristics resulting in even or uneven load balancing based on the understa= nding flow based or n-tuple ECMP hash based per packet algorithm.

My understanding of RFC 6437 is t= hat the IPv6 flow label is a means of classification of packets that are pa= rt of the same flow from a particular flow for use in QOS marking.

From a load balancing perspectiv= e the flow key could be used to identify a flow and path taken on routes in= a case of load balancing ECMP hash. =C2=A0

The goal of IPv6 flow label is for ordering of packets = to be part of the same network path in an ECMP hash resulting in flow based= load balancing identical to what exists today with IPv4. =C2=A0

What is confusing is if flow label= 5 tuple is input to a ECMP hash algorithm similar to LAG and MLAG which yi= elds =C2=A0per packet load balancing based on n-tuple hash implemented by m= ost vendors.=C2=A0 This would be preferable if as it would yield even load = balancing.

Or is the flo= w label goal to maintain the per flow load balancing and use for QOS packet= classification so all packets that are part of a particular flow use the s= ame ECMP path.=C2=A0 In this case the n-tuple hash key generated is just to= identify which path the flow had taken on a router but not an input to a h= ash algorithm function as exists with LAG or MLAG. =C2=A0

The difference is significant as far as l= oad balancing as a n-tuple input to ECMP hash algorithm achieves close to 5= 0/50 load balancing where per flow load balancing can be uneven as it=E2=80= =99s based on flows and thus from a network standpoint high bandwidth flows= may hash to one ECMP path and low bandwidth flows may hash to another ECMP= path.

So in general wit= h parallel links bundling LAG and MLAG is always preferred method for load = balancing distribution over ECMP.=C2=A0 However L3 ECMP always exists and i= s optimal to assist further load balancing which often times exists in conj= unction with LAG and MLAG.

Excerpt from a doc I found online related to IPv6 flow label operation:<= /div>

A flow is a sequence of pack= ets sent from a particular source to a=C2=A0 particular (unicast or multica= st) destination for which the source=C2=A0 desires special handling by the = intervening routers. The nature of=C2=A0 that special handling might be con= veyed to the routers by a control=C2=A0 protocol, such as a resource reserv= ation protocol, or by information=C2=A0 within the flow's packets thems= elves, e.g., in a hop-by-hop option.=C2=A0 The details of such control prot= ocols or options are beyond the scope of this document.

There may be multipl= e active flows from a source to a destination, as well as traffic that is n= ot associated with any flow. A flow is uniquely identified by the combinati= on of a source address and a=C2=A0 non-zero flow label. Packets that do not= belong to a flow carry a=C2=A0 flow label of zero.

A flow label is assigned= to a flow by the flow's source node. New flow labels must be chosen (p= seudo-)randomly and uniformly from the=C2=A0 range 1 to FFFFF hex. The purp= ose of the random allocation is to=C2=A0 make any set of bits within the Fl= ow Label field suitable for use as=C2=A0 a hash key by routers, for looking= up the state associated with the=C2=A0 flow.

All pac= kets belonging to the same flow must be sent with the same=C2=A0 source add= ress, destination address, and flow label. If any of those packets includes= a Hop-by-Hop Options header, then they all must be=C2=A0 originated with t= he same Hop-by-Hop Options header contents=C2=A0 (excluding the Next Header= field of the Hop-by-Hop Options header).=C2=A0 If any of those packets inc= ludes a Routing header, then they all must be originated with the same cont= ents in all extension headers up to=C2=A0 and including the Routing header = (excluding the Next Header field in=C2=A0 the Routing header). The routers = or destinations are permitted, but=C2=A0 not required, to verify that these= conditions are satisfied. If a=C2=A0 violation is detected, it should be r= eported to the source by an ICMP Parameter Problem message, Code 0, pointin= g to the high-order octet=C2=A0 of the Flow Label field (i.e., offset 1 wit= hin the IPv6 packet).=C2=A0

The maximum lifetime of any flow-ha= ndling state established along a flow's path must be specified as part = of the description of the=C2=A0 state-establishment mechanism, e.g., the re= source reservation=C2=A0 protocol or the flow-setup hop-by-hop option. A so= urce must not re-=C2=A0 use a flow label for a new flow within the maximum = lifetime of any=C2=A0 flow-handling state that might have been established = for the prior=C2=A0 use of that flow label.

Excerpt from Section 2 below:

   The 20-bit Flow Label field in the IPv6 header [RFC2460<=
/a>] is used by a
   node to label packets of a flow.  A Flow Label of zero is used to
   indicate packets that have not been labeled.  Packet classifiers can
   use the triplet of Flow Label, Source Address, and Destination
   Address fields to identify the flow to which a particular packet
   belongs.  Packets are processed in a flow-specific manner by nodes
   that are able to do so in a stateless manner or that have been set up
   with flow-specific state.  The nature of the specific treatment and
   the methods for flow state establishment are out of scope for this
   specification.

   Flow label values should be chosen such that their bits exhibit a
   high degree of variability, making them suitable for use as part of
   the input to a hash function used in a load distribution scheme.  At
   the same time, third parties should be unlikely to be able to guess
   the next value that a source of flow labels will choose.

   o  Forward=
ing nodes such as routers and load distributors MUST NOT
      depend only on Flow Label values being uniformly distributed.  In
      any usage such as a hash key for load distribution, the Flow Label
      bits MUST be combined at least with bits from other sources within
      the packet, so as to produce a constant hash value for each flow
      and a suitable distribution of hash values across flows.
      Typically, the other fields used will be some or all components of
      the usual 5-tuple.  In this way, load distribution will still
      occur even if the Flow Label values are poorly distributed.

   Although uniformly distributed flow label values are recommended
   below, and will always be helpful for load distribution, it is unsafe
   to assume their presence in the general case, and the use case needs
   to work even if the flow label value is zero.

   As a general practice, packet flows should not be reordered, and the
   use of the Flow Label field does not affect this.  In particular, a
   Flow label value of zero does not imply that reordering is
   acceptable.

=


Kind Regards 

Gyan

--
--000000000000047fe505b5f9b4aa-- From nobody Tue Dec 8 12:24:17 2020 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 280AA3A112D; Tue, 8 Dec 2020 12:24:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: warren@kumari.net, fredbaker.ietf@gmail.com, v6ops@ietf.org, v6ops-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160745905514.27951.6960853209959004394@ietfa.amsl.com> Date: Tue, 08 Dec 2020 12:24:15 -0800 Archived-At: Subject: [v6ops] v6ops - New Meeting Session Request for IETF 110 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 20:24:15 -0000 A new meeting session request has just been submitted by Fred Baker, a Chair of the v6ops working group. --------------------------------------------------------- Working Group Name: IPv6 Operations Area Name: Operations and Management Area Session Requester: Fred Baker Number of Sessions: 2 Length of Session(s): 2 Hours, 2 Hours Number of Attendees: 100 Conflicts to Avoid: Chair Conflict: spring lsr 6man intarea idr bess tsvwg Key Participant Conflict: rtgwg panrg grow People who must be present: Fred Baker Ron Bonica Warren "Ace" Kumari Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Dec 8 12:43:27 2020 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 217973A116E for ; Tue, 8 Dec 2020 12:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=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=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 fuqNt3TOdmnU for ; Tue, 8 Dec 2020 12:43:20 -0800 (PST) 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 43FC03A1158 for ; Tue, 8 Dec 2020 12:43:20 -0800 (PST) Received: by mail-pf1-x42e.google.com with SMTP id s21so15030005pfu.13 for ; Tue, 08 Dec 2020 12:43:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:subject:cc:to:message-id; bh=4hz5KV5jz8sZ8zj32931SiLCSsd/kHQGennZzmq2BDM=; b=HEG2MWWykasvuQMoHG6lr9kD5jrnXt1LPPPIO2N7p1Pl5ROVNirsoq9HGGT4uTRcP1 W30wTrAyR6KmkoG8wdy+tjh0v/+8YdXUWAsEzdcGqaYh5eOk2ApVwwhJULGOJPbt5tO7 kcEdE1WeYDY2c8lwnkPCPD2dENf14Us56z/CkLrW6gYIJCfMUZyCt2oP2/OL2/WdY1pW d8ZlXlGSjQ5af1BJiilAZi5DA7jMJNdVUVR8xYSJjtKcMqnH5na8Nwzw3UowifAjCkaw hZ5b8MvmCfxxdbcrfqrjBirve0v3v4k7PPMatogQBA3VDv/P6ELEahSfCdRl2WW9nPDJ S1wA== 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:cc:to:message-id; bh=4hz5KV5jz8sZ8zj32931SiLCSsd/kHQGennZzmq2BDM=; b=I9V2MReVkKZjH9QRBqhH9StrjS9aCgCncGJNow8xYk4WyzqIaFqeSPGdnx/wR/5n+7 3Q9pjdM6bZf3KNEpD+gwGAlJv7C3xNKaATtKDJjpa9CvNE+tHoIcnpRmjW+1BnxNHgMv ij+0AubCPAKU6HTQfQkJ3DCB5Vz6bfnPHI9HDpNF6b/oJTu+1l0N/RsEm/gg7zl1KEYA uaMqWB2+pDZI2LZMijJszZ1JVxrnnR1TULBM+h5DZm6pyvthPEbR0cZQBqhR7YhbQEIy zzLbxO8fTqlmleX6e0IaJ93JRcV3FlJGQJz65w2yleoGebO5vZtNLF6y5FOeOiZUnb9L DfmQ== X-Gm-Message-State: AOAM531O0zZRI4239bveIraZoCx3D4+94qY7d0fVQxG9TMELu6HaJvKg yJGCiR6760Ib851R4Yg2lmN8CZOk2hxoslJa X-Google-Smtp-Source: ABdhPJz6lDAI8d8NBmTpDJfo3LceSZ9QBahu22q+dUXZCs9LdfJkPxfWCEEtheH6rkqEY/x5NqlqUQ== X-Received: by 2002:a63:e90e:: with SMTP id i14mr24863918pgh.298.1607460199477; Tue, 08 Dec 2020 12:43:19 -0800 (PST) Received: from [192.168.1.10] (ip72-205-75-17.sb.sd.cox.net. [72.205.75.17]) by smtp.gmail.com with ESMTPSA id z7sm8583024pgz.43.2020.12.08.12.43.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Dec 2020 12:43:18 -0800 (PST) From: Fred Baker Content-Type: multipart/signed; boundary="Apple-Mail=_C70E5F9A-C12B-4EC1-BB49-1B4CC272E0A6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.31\)) Date: Tue, 8 Dec 2020 12:43:15 -0800 To: IPv6 Operations Message-Id: <468FFA00-099E-4E0B-ABCB-C2CB2E82577C@gmail.com> X-Mailer: Apple Mail (2.3654.40.0.2.31) Archived-At: Subject: [v6ops] Planning for IETF 110 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 20:43:22 -0000 --Apple-Mail=_C70E5F9A-C12B-4EC1-BB49-1B4CC272E0A6 Content-Type: multipart/mixed; boundary="Apple-Mail=_BEDF2E60-7B15-4528-9151-E8864E997AA2" --Apple-Mail=_BEDF2E60-7B15-4528-9151-E8864E997AA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have requested two 120 minute sessions at IETF 110; we wound up being = very rushed at IETF 109, so I'm leaving some extra room on the = assumption that we can cancel one if we don't need it. It is my = understanding that IETF 110 will again be virtual, although I can hope = for a f2f meeting in San Francisco for IETF 111. I have attached the = current state of play in v6ops, which Ron and I use in planning an = agenda. I list working group drafts and individual submissions as = updated or unupdated since IETF 108, 31 July 2020 - if it has not been = updated, I don't consider it an active draft. I would usually date that = from the previous IETF meeting, but this seems sensible at the moment. We have five comment periods scheduled post-IETF-109, working around = holidays. We will likely have one or two WGLCs in February, to move work = along that seem to have reached consensus; to that end, as Ron invites = discussion, I'd appreciate it if people take it upon themselves to do a = thorough review of each such draft and post it to the list. I'd like to = believe that we will have new drafts in December or January that we can = discuss in email and potentially discuss at IETF 110. --Apple-Mail=_BEDF2E60-7B15-4528-9151-E8864E997AA2 Content-Disposition: attachment; filename=raw-agenda-data-v6ops.html Content-Type: text/html; x-unix-mode=0644; name="raw-agenda-data-v6ops.html" Content-Transfer-Encoding: 7bit IETF Working Group Agenda Analysis

This document describes the drafts associated with this group. It describes their current state as seen by the RFC Editor, IESG/AD, and the working or research group. For working group drafts and individual submissions, it also indicates whether the draft has been updated since the previous IETF meeting. Drafts that are new or have been updated are "current"; other drafts are "old".

On each draft, there are three or four links:

  • the relevant datatracker link,
  • a pointer to the HTML version of the draft in the tools directory,
  • a pointer to the email archived on IETF mailing lists related to the draft, and
  • a pointer to RFCDIFF against the previous version, if there was one.

IESG: Dead

IESG: IESG Evaluation

WG: In WG Last Call

WG: Updated (since 2020-07-31) WG Document

Individual Submission: Unupdated

Individual Submission: Updated (since 2020-07-31)

The charter for this group is at https://datatracker.ietf.org/group/v6ops/about/

Tue Dec 8 12:24:39 2020

--Apple-Mail=_BEDF2E60-7B15-4528-9151-E8864E997AA2-- --Apple-Mail=_C70E5F9A-C12B-4EC1-BB49-1B4CC272E0A6 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+AFAl/P5WMACgkQEhdRnd2G P+BodBAAhFLJVLEDVF41A/XOwdx83WFZuA+kYZDktQM9nGd2vLaQgkb5+hbAmLb8 18qwpB/UT+p8T3DUAcUK/h5g0z4ktgK9DMNRWMjx5BBzDN0OJKFVMnqCVknSSekb 7m++W3og01g5VlfusAzDvvaJzuVIC2NGHjlE6mlhFfEUnn4kX5hhZ6tW3yxH20Tk HaujlIs7+SMZsl9n+TpJfDYrWX+AvtKyaeMdxKyjOBWTQvHfs1PAJkDIVL9gotDC Kt9LfScxOoFdE4JmKtTrnYljdfe8vkL3oVMSAm9zXLViPPOeYD2yaoldxk0M9ipW VUXo/SpHj1FnIcHPhwGc4IlvsGJdi8kuqklC2bVzcfV+CVK/3RI0VeTcH03srq4H Bu4ZyCXUScdVux9Cw0VN0suFDqTW/dgWbcqe7DXODmAGexQLk4F3m4gwmu6aOgDu wZCpCtwbOggbjQdV2IgjTWwhwZ4A3aVqJ9Jlh9/q9uY3hj64MxcASzcy0425e9QQ gLPOv2WZhJxxIDfC8dHpBWu5xsH1xZ3F3OCBOGVT4PWpsnaMUnYsrfR2rjkUXiX7 jxLEruA6KD2C964lhDt309Y9/oywG3rSsggnLgWwucts1DM76LIES3aOa5FhzdZM AreTRgGjsREBOY3Fo5iUFwUOnkD/7n1QEYyclVbYcQtWQ/EtvQM= =OG0T -----END PGP SIGNATURE----- --Apple-Mail=_C70E5F9A-C12B-4EC1-BB49-1B4CC272E0A6-- From nobody Tue Dec 8 12:51:19 2020 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 8D1D03A0855; Tue, 8 Dec 2020 12:51:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , draft-ietf-v6ops-slaac-renum@ietf.org, v6ops-chairs@ietf.org, owen@delong.com, warren@kumari.net, rfc-editor@rfc-editor.org, Owen DeLong , v6ops@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <160746067455.24047.1927290908179515572@ietfa.amsl.com> Date: Tue, 08 Dec 2020 12:51:14 -0800 Archived-At: Subject: [v6ops] Document Action: 'Reaction of Stateless Address Autoconfiguration (SLAAC) to Flash- Renumbering Events' to Informational RFC (draft-ietf-v6ops-slaac-renum-05.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 20:51:15 -0000 The IESG has approved the following document: - 'Reaction of Stateless Address Autoconfiguration (SLAAC) to Flash- Renumbering Events' (draft-ietf-v6ops-slaac-renum-05.txt) as Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Warren Kumari and Robert Wilton. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-slaac-renum/ Technical Summary This is a companion document to https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/. This document provides advice for the operator side of the process whereas the other document provides advice for the client or CPE side of the process. Together, both documents attempt to improve the user experience when unplanned SLAAC renumbering events occur. Working Group Summary The document does not specify new protocol, but rather provides guidance regarding how to override the default values of some parameters in the existing protocols. The document (along side its companion document https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/ has received substantial comments from the working group. Document Quality The document(s) are clear, easy to read, and explain the issues and procedures. Personnel Owen DeLong is the Document Shepherd Fred Baker and Ron Bonica are the WG chairs Warren Kumari is RAD! From nobody Tue Dec 8 13:14:33 2020 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 9FD093A0C04 for ; Tue, 8 Dec 2020 13:14:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=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=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fet3u6pLO8Ta for ; Tue, 8 Dec 2020 13:14:26 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::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 678AE3A0AE6 for ; Tue, 8 Dec 2020 13:14:26 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id f24so22011019ljk.13 for ; Tue, 08 Dec 2020 13:14:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=DLJ9JYOc0/j6JnYcy3FmEjTOZscY0bdLf4JJy1XeWDw=; b=aEBJywbC/UoFhWN0RCxjrBqRz2NbmfFlMOMLnAtgWPVGQTsPl3sn7ARKBZPffEK7yD UlrSZoPUu3EzMsFlqpMMzzvwLJWV0Wb+9iuUGrhWb3yJ7cTf+fiyEQ2l8mZ60qmN/Edk jWcB66W7LlNC/qX68hLqkPOwK/GWJktxVUjVjilnxA0CqoQyth8Bbaq3iIzlO6nnmIMK Lw0NInvOVPvtdVHqnTsazu09U8F+H+BxWxCIknzHBluGOp6gTW0D3cxZgoMiMYtqmX7K NedUhrJSvo0Ty02jAYKTAAxFPaeLckax84O5soNBS6Qsd6S4yrrS69vl8TeIhWrlgHU7 UVPw== 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=DLJ9JYOc0/j6JnYcy3FmEjTOZscY0bdLf4JJy1XeWDw=; b=qEYB2DkgJQu5e+BQYN4Uj3zNUdwkvewe6QLUiWKcgFOYPerYFB3HQIV9vtVlXy/fVa 31iyehpWY7ibBa/+ed+XZH3Gl8pXTuaFo1GpRNp087oUFX69TchOi9MYGoqZ2VyljoJR GQcEkF9nFi06n/loUBVXdsc/ZH4dczMSeqQTf/MoGPTykJ2YHx4aowbJzXMoKc4r9N9s 12zwI1mo9Au4EpNXcy1RW6NARTJBaGyBoQR8xK+UerVCCa73YxGn2dl1mtysIGDLTMy9 oR6fwLtE2cIoB8yg3jRTorVM3Iysjpx+ZeUGderMr6+gWMGfuTNIvxKGAWDtZgcxoKdD 3uQw== X-Gm-Message-State: AOAM531+6eNapBnv+t21yBSX8GqHESLlU4LfatkdEEJArP+11RyleYbh AX3kTsr0Op2S7Vhk0NMgGizp8f4JKRroq5scjasDgVv7OTVEUcLX X-Google-Smtp-Source: ABdhPJzJQuj7Gd360uLRUfRvBF+J6oY45M5myWuYBCgTKWu33mf1trXiHhrNbaX/y+V7qoRdquER38U1ROLlNXZoL14= X-Received: by 2002:a2e:b5cb:: with SMTP id g11mr1211136ljn.502.1607462062267; Tue, 08 Dec 2020 13:14:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warren Kumari Date: Tue, 8 Dec 2020 16:13:45 -0500 Message-ID: To: IPv6 Operations , Fernando Gont , "Rob Wilton (rwilton)" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [v6ops] Pretty Please? - Disposition of draft-ietf-v6ops-cpe-slaac-renum-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 21:14:31 -0000 [ Subject edited to start new thread ] Hello again all, I started this thread back in October, and then didn't really follow-up; so= rry. This document went through WGLC as Informational, but uses "pseudo-RFC2119" language (https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/, Section 2). This section says things like (cribbed from RFC7084): " Take careful note: Unlike other IETF documents, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used as described in [RFC2119]. This document uses these keywords not strictly for the purpose of interoperability, but rather for the purpose of establishing industry-common baseline functionality. " This caused confusion during IESG eval -- what does the MUST in "CE routers MUST signal stale configuration..." mean if not in the RFC2119 sense? Also, much of the document reads like a BCP - Alissa specifically called this out in her DISCUSS, but there were quite a few others who agreed. As an example, is it not a Best Current Practice that e.g: "CE routers SHOULD NOT automatically send DHCPv6-PD RELEASE messages upon reboot events."? If not, what does this document mean for an implementer? There are 2 options here: 1: We change Section 2 to use normal RFC2119/RFC8174 language. I send it back to the WG and it gets WGLCed as BCP. 2: We remove Section 2, and all of the uppercase/lowercase words. I send it back to the WG (because of the changes) and it gets WGLCed as Informational again. I really prefer Option 1 -- to me it reads much more like a BCP, documenting Best Current Practices for CPE implementers. The last time I sent this, there was only one response[0] and then the thread died -- I'd REALLY appreciate clear responses from the WG on which option (1 or 2) you prefer... W [0]: https://mailarchive.ietf.org/arch/msg/v6ops/xVv4f73kB8tRFag3yJCBAraXwX= k/ On Thu, Oct 22, 2020 at 11:53 AM Warren Kumari wrote: > > Hi all, > > draft-ietf-v6ops-cpe-slaac-renum-05 was on today's telechat, and ran > into issues. > > Alissa (based on the Gen ART review) asked why this was not a BCP, and > there was general agreement within the IESG that BCP seems like most > reasonable status. > There was also discussions on the: > "Take careful note: Unlike other IETF documents, the key words "MUST", > [...] "OPTIONAL" in this document are not used as described in [RFC2119]= ." > and that this was very confusing. > > I proposed that we change the status to BCP, and that the terms be > used in the normal manner. > > I'd like to give the WG 2 weeks to object to this proposal, and, if > none received, start another IETF LC as BCP. > > So, please let me know (by Nov 5th) if you strongly object to this > becoming a BCP, and the "normal" RFC2119/BCP14 meanings being used for > the recommendations **in this document**. > > > W > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf --=20 The computing scientist=E2=80=99s main challenge is not to get confused by = the complexities of his own making. -- E. W. Dijkstra From nobody Tue Dec 8 14:01:05 2020 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 84AEC3A1211 for ; Tue, 8 Dec 2020 14:01:03 -0800 (PST) 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 OtYB5FZdcYWf for ; Tue, 8 Dec 2020 14:01:01 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB8D93A120A for ; Tue, 8 Dec 2020 14:00:57 -0800 (PST) Received: from [192.168.1.5] (unknown [190.179.27.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 3E912283C67; Tue, 8 Dec 2020 22:00:19 +0000 (UTC) To: Warren Kumari , IPv6 Operations , "Rob Wilton (rwilton)" References: From: Fernando Gont Message-ID: Date: Tue, 8 Dec 2020 18:59:51 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Pretty Please? - Disposition of draft-ietf-v6ops-cpe-slaac-renum-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 22:01:04 -0000 On 8/12/20 18:13, Warren Kumari wrote: [....] > There are 2 options here: > 1: We change Section 2 to use normal RFC2119/RFC8174 language. I send > it back to the WG and it gets WGLCed as BCP. > > 2: We remove Section 2, and all of the uppercase/lowercase words. I > send it back to the WG (because of the changes) and it gets WGLCed as > Informational again. > > I really prefer Option 1 -- to me it reads much more like a BCP, > documenting Best Current Practices for CPE implementers. FWIW, I agree that option 1 is the way forward. Thanks! Regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Dec 8 14:05:16 2020 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 A44DF3A1211; Tue, 8 Dec 2020 14:05:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: "Owen DeLong" , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160746511566.29220.1623575367318603466@ietfa.amsl.com> Date: Tue, 08 Dec 2020 14:05:15 -0800 From: IETF Secretariat Archived-At: Subject: [v6ops] Datatracker State Update Notice: X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 22:05:16 -0000 IANA action state changed to "In Progress" Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-v6ops-slaac-renum/ From nobody Tue Dec 8 14:41:52 2020 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 15C953A12AE for ; Tue, 8 Dec 2020 14:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=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=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 aS4iEJMWXOvS for ; Tue, 8 Dec 2020 14:41:47 -0800 (PST) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 46F613A12AD for ; Tue, 8 Dec 2020 14:41:47 -0800 (PST) Received: by mail-pl1-x62b.google.com with SMTP id v3so68622plz.13 for ; Tue, 08 Dec 2020 14:41:47 -0800 (PST) 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=rwNs/9PAOaFs7dpW3Hx64mHMmLvRJIffp4DSVPz6ydo=; b=Li4HaGO/T11t1eDVMzi+cYiwPFzYwzA/HF3/D5a3KjffFhkUJY+R/1jswklE0c+k5K KRi3DavPg5XH6lfuMsi0DZt26BaZJyuLJ4M2os3z7eQvq5UnILVfh3eHJqUtuhYKWnI9 4RtEQmEQaV+ukhmSoj4i4xXytc9+nK2K4RRyYZYPxl9PBZ8IEQoVPhtMxrp+GxMqNxuK Vr7EARzajvQ+MhTEe9MlZy0g0q7f+h5GeyGfNtLUt1zTZvjr1jy7yH92ZaZD12lkASF9 SOKkJogLDDNOgJCJy/LdZEI0IXwNZNJ96DKUFiD/iIOC8kqn1JA0K3PPx1GbxVwl7SrZ jAEQ== 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=rwNs/9PAOaFs7dpW3Hx64mHMmLvRJIffp4DSVPz6ydo=; b=fCuA9nIg754AwoYGoAUDaYfhvfNfOPOWxysxOV/GZtW6o6zKlQjY/VNS12u7J2ZyYg HP/AMkpNR6lSzUanEg5TVxzNgpUUTtGxxSMFRrBI8Amzogmb+jShs4Au5/03a1lOYOC3 i5wTkV0eayIZbFXMviw3kr14jyfF5cYPHnyVKm+PCmtd1+hk9xhYTpUfICcjHAhCk1d7 rWclZMe9nQ+WVp2is6RLq3b9qyMh6jIraLOG8k7yK0WCQ43y5UogABjiMKHYgwdJ71Ra oRpP+cpesfyvv3YmVLDlSyU0Hq4zPxxV9TnJU0PvTKTkKfyWx+CdtJUZbV1frOTH+u5u mUUQ== X-Gm-Message-State: AOAM532TlkL0GZPucyEJk9+st9fD8sjIXKS41F08adE9NCDd/MRyLV4U D5TV9nT5PCHoHWhwFjB8QEQ= X-Google-Smtp-Source: ABdhPJy7F3gwv3A0k17LpdczCx/+6DR7HZX9VmofloQmC/mnvki3UKS8REdzYuhHFVX0S9MLCymjXA== X-Received: by 2002:a17:902:c20c:b029:da:b4d4:4f42 with SMTP id 12-20020a170902c20cb02900dab4d44f42mr1163732pll.85.1607467306508; Tue, 08 Dec 2020 14:41:46 -0800 (PST) Received: from [192.168.220.117] ([131.203.179.213]) by smtp.gmail.com with ESMTPSA id z6sm203542pfj.22.2020.12.08.14.41.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Dec 2020 14:41:45 -0800 (PST) To: Warren Kumari , IPv6 Operations , Fernando Gont , "Rob Wilton (rwilton)" References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <25f0e7e4-0f8d-aa2c-5b93-ac13e846ed40@gmail.com> Date: Wed, 9 Dec 2020 11:41:39 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.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] Pretty Please? - Disposition of draft-ietf-v6ops-cpe-slaac-renum-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 22:41:50 -0000 Option 1 please. BCPs were meant for this. The current "RFC2119 but not really" stuff is confusing (as it is in 7084 IMHO). Regards Brian On 09-Dec-20 10:13, Warren Kumari wrote: > [ Subject edited to start new thread ] > Hello again all, > > I started this thread back in October, and then didn't really follow-up; sorry. > > This document went through WGLC as Informational, but uses > "pseudo-RFC2119" language > (https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/, > Section 2). This section says things like (cribbed from RFC7084): > " Take careful note: Unlike other IETF documents, the key words "MUST", > "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", > "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used as > described in [RFC2119]. This document uses these keywords not > strictly for the purpose of interoperability, but rather for the > purpose of establishing industry-common baseline functionality. " > > This caused confusion during IESG eval -- what does the MUST in "CE > routers MUST signal stale configuration..." mean if not in the RFC2119 > sense? > > Also, much of the document reads like a BCP - Alissa specifically > called this out in her DISCUSS, but there were quite a few others who > agreed. > > As an example, is it not a Best Current Practice that e.g: "CE routers > SHOULD NOT automatically send DHCPv6-PD RELEASE messages upon reboot > events."? If not, what does this document mean for an implementer? > > > There are 2 options here: > 1: We change Section 2 to use normal RFC2119/RFC8174 language. I send > it back to the WG and it gets WGLCed as BCP. > > 2: We remove Section 2, and all of the uppercase/lowercase words. I > send it back to the WG (because of the changes) and it gets WGLCed as > Informational again. > > I really prefer Option 1 -- to me it reads much more like a BCP, > documenting Best Current Practices for CPE implementers. > > The last time I sent this, there was only one response[0] and then the > thread died -- I'd REALLY appreciate clear responses from the WG on > which option (1 or 2) you prefer... > > W > > [0]: https://mailarchive.ietf.org/arch/msg/v6ops/xVv4f73kB8tRFag3yJCBAraXwXk/ > > > On Thu, Oct 22, 2020 at 11:53 AM Warren Kumari wrote: >> >> Hi all, >> >> draft-ietf-v6ops-cpe-slaac-renum-05 was on today's telechat, and ran >> into issues. >> >> Alissa (based on the Gen ART review) asked why this was not a BCP, and >> there was general agreement within the IESG that BCP seems like most >> reasonable status. >> There was also discussions on the: >> "Take careful note: Unlike other IETF documents, the key words "MUST", >> [...] "OPTIONAL" in this document are not used as described in [RFC2119]." >> and that this was very confusing. >> >> I proposed that we change the status to BCP, and that the terms be >> used in the normal manner. >> >> I'd like to give the WG 2 weeks to object to this proposal, and, if >> none received, start another IETF LC as BCP. >> >> So, please let me know (by Nov 5th) if you strongly object to this >> becoming a BCP, and the "normal" RFC2119/BCP14 meanings being used for >> the recommendations **in this document**. >> >> >> W >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf > > > From nobody Tue Dec 8 14:57:41 2020 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 2033C3A12E2 for ; Tue, 8 Dec 2020 14:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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 YNVvrLPJqPwk for ; Tue, 8 Dec 2020 14:57:37 -0800 (PST) Received: from gw2mail.telecentro.net.ar (mail.telecentro.net.ar [190.55.63.7]) (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 9192F3A12DE for ; Tue, 8 Dec 2020 14:57:37 -0800 (PST) Received: from gw2mail.telecentro.local (localhost [127.0.0.1]) by gw2mail.telecentro.net.ar (Postfix) with ESMTP id CB53320024; Tue, 8 Dec 2020 19:57:34 -0300 (-03) Received: from mail.telecentro.net.ar (unknown [10.4.20.96]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gw2mail.telecentro.net.ar (Postfix) with ESMTPS; Tue, 8 Dec 2020 19:57:33 -0300 (-03) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id F0D1032013E3; Tue, 8 Dec 2020 19:57:33 -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 Q8DZzESiLwAS; Tue, 8 Dec 2020 19:57:33 -0300 (-03) Received: from localhost (localhost [127.0.0.1]) by mail.telecentro.net.ar (Postfix) with ESMTP id 1981332014CC; Tue, 8 Dec 2020 19:57:33 -0300 (-03) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.telecentro.net.ar 1981332014CC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telecentro.net.ar; s=25118654-7AE4-11E8-AD98-8D0B0E6845CD; t=1607468253; bh=0YDXueyptY+tKB28J/bJ6fWpXfeIWWlN8zurz3JLG8U=; h=Date:From:To:Message-ID:MIME-Version; b=euFUO4bexpnf0rbbfASB4dPIGHL9FhTOBHrvqtWgQ+c/MF3r25XDVxZRf/urI85WK 0yumMxRTjYMwyziOhuHBImd1rOw2T+Ntu6cA2w2kBvSkF87Ckpien/gvbUUgO7uY86 J1TLcgrjB4imqlr7DzoTO9+DCArVupiGjCYkya8Wkb+fb64s2JXIjn+71bAPgJet/0 oL3v8MnTcXDPGKJWTZseRTPD/2a3DX6SawksOLIWaZnLvwNQYcVMYnfA5joq83VuH+ kuBNRwhzzyr3VSCgR0rl3VL7NSzIQ2ODR0Cn6HQsoZmYQiRagzxgGsOqKWVywJcEzW FjEUq4a0Qzhaw== 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 OKLVd2VF7kB1; Tue, 8 Dec 2020 19:57:33 -0300 (-03) Received: from tclmail6.telecentro.local (tclmail6.telecentro.local [10.210.50.96]) by mail.telecentro.net.ar (Postfix) with ESMTP id 0153F32013E3; Tue, 8 Dec 2020 19:57:33 -0300 (-03) Date: Tue, 8 Dec 2020 19:57:32 -0300 (ART) From: Alejandro D'Egidio To: Brian E Carpenter Cc: Warren Kumari , "v6ops@ietf.org list" , Fernando Gont , "Rob Wilton (rwilton)" Message-ID: <1776978474.35481985.1607468252874.JavaMail.zimbra@telecentro.net.ar> In-Reply-To: <25f0e7e4-0f8d-aa2c-5b93-ac13e846ed40@gmail.com> References: <25f0e7e4-0f8d-aa2c-5b93-ac13e846ed40@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.210.50.96] X-Mailer: Zimbra 8.8.12_GA_3803 (ZimbraWebClient - GC86 (Win)/8.8.12_GA_3794) Thread-Topic: Pretty Please? - Disposition of draft-ietf-v6ops-cpe-slaac-renum-05 Thread-Index: +2GXoyDvGqfhnZKMMSl6DCvC+Lg9DQ== X-KSMG-Rule-ID: 1 X-KSMG-Message-Action: clean X-KSMG-AntiSpam-Lua-Profiles: 160462 [Dec 08 2020] X-KSMG-AntiSpam-Version: 5.9.16.0 X-KSMG-AntiSpam-Envelope-From: adegidio@telecentro.net.ar X-KSMG-AntiSpam-Auth: dkim=pass header.d=telecentro.net.ar X-KSMG-AntiSpam-Rate: 0 X-KSMG-AntiSpam-Status: not_detected X-KSMG-AntiSpam-Method: none X-KSMG-AntiSpam-Info: LuaCore: 418 418 0543ccf0fa7d0fb1227549dfdef7708d8d092243, {Tracking_content_type, plain}, {Tracking_date, brazil}, {Tracking_subj, underscore}, {Tracking_c_tr_enc, eight_bit}, {Tracking_uf_ne_domains}, {Tracking_from_domain_doesnt_match_to}, d41d8cd98f00b204e9800998ecf8427e.com:7.1.1; 127.0.0.199:7.1.2; mail.telecentro.net.ar:7.1.1; telecentro.net.ar:7.1.1; mailarchive.ietf.org:7.1.1; datatracker.ietf.org:7.1.1; www.ietf.org:7.1.1 X-MS-Exchange-Organization-SCL: -1 X-KSMG-AntiSpam-Interceptor-Info: scan successful X-KSMG-AntiPhishing: Clean, bases: 2020/12/08 21:47:00 X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 1.1.2.12, bases: 2020/12/08 09:54:00 #15812285 X-KSMG-AntiVirus-Status: Clean, skipped Archived-At: Subject: Re: [v6ops] Pretty Please? - Disposition of draft-ietf-v6ops-cpe-slaac-renum-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 22:57:40 -0000 Hello, This document states a real and known issue and describes Best Practices to solve or minimize it. So, I agree with Option 1. Regards, Alejandro ----- Mensaje original ----- De: "Brian E Carpenter" Para: "Warren Kumari" , "v6ops@ietf.org list" , "Fernando Gont" , "Rob Wilton (rwilton)" Enviados: Martes, 8 de Diciembre 2020 19:41:39 Asunto: Re: [v6ops] Pretty Please? - Disposition of draft-ietf-v6ops-cpe-slaac-renum-05 Option 1 please. BCPs were meant for this. The current "RFC2119 but not really" stuff is confusing (as it is in 7084 IMHO). Regards Brian On 09-Dec-20 10:13, Warren Kumari wrote: > [ Subject edited to start new thread ] > Hello again all, > > I started this thread back in October, and then didn't really follow-up; sorry. > > This document went through WGLC as Informational, but uses > "pseudo-RFC2119" language > (https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/, > Section 2). This section says things like (cribbed from RFC7084): > " Take careful note: Unlike other IETF documents, the key words "MUST", > "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", > "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used as > described in [RFC2119]. This document uses these keywords not > strictly for the purpose of interoperability, but rather for the > purpose of establishing industry-common baseline functionality. " > > This caused confusion during IESG eval -- what does the MUST in "CE > routers MUST signal stale configuration..." mean if not in the RFC2119 > sense? > > Also, much of the document reads like a BCP - Alissa specifically > called this out in her DISCUSS, but there were quite a few others who > agreed. > > As an example, is it not a Best Current Practice that e.g: "CE routers > SHOULD NOT automatically send DHCPv6-PD RELEASE messages upon reboot > events."? If not, what does this document mean for an implementer? > > > There are 2 options here: > 1: We change Section 2 to use normal RFC2119/RFC8174 language. I send > it back to the WG and it gets WGLCed as BCP. > > 2: We remove Section 2, and all of the uppercase/lowercase words. I > send it back to the WG (because of the changes) and it gets WGLCed as > Informational again. > > I really prefer Option 1 -- to me it reads much more like a BCP, > documenting Best Current Practices for CPE implementers. > > The last time I sent this, there was only one response[0] and then the > thread died -- I'd REALLY appreciate clear responses from the WG on > which option (1 or 2) you prefer... > > W > > [0]: https://mailarchive.ietf.org/arch/msg/v6ops/xVv4f73kB8tRFag3yJCBAraXwXk/ > > > On Thu, Oct 22, 2020 at 11:53 AM Warren Kumari wrote: >> >> Hi all, >> >> draft-ietf-v6ops-cpe-slaac-renum-05 was on today's telechat, and ran >> into issues. >> >> Alissa (based on the Gen ART review) asked why this was not a BCP, and >> there was general agreement within the IESG that BCP seems like most >> reasonable status. >> There was also discussions on the: >> "Take careful note: Unlike other IETF documents, the key words "MUST", >> [...] "OPTIONAL" in this document are not used as described in [RFC2119]." >> and that this was very confusing. >> >> I proposed that we change the status to BCP, and that the terms be >> used in the normal manner. >> >> I'd like to give the WG 2 weeks to object to this proposal, and, if >> none received, start another IETF LC as BCP. >> >> So, please let me know (by Nov 5th) if you strongly object to this >> becoming a BCP, and the "normal" RFC2119/BCP14 meanings being used for >> the recommendations **in this document**. >> >> >> W >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf > > > _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Dec 8 15:49:02 2020 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 2F2863A1374 for ; Tue, 8 Dec 2020 15:48:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=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=messagingengine.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 zkPoQoPxgZKD for ; Tue, 8 Dec 2020 15:48:55 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 694973A1373 for ; Tue, 8 Dec 2020 15:48:55 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 927A25C00FB for ; Tue, 8 Dec 2020 18:48:54 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 08 Dec 2020 18:48:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=sGZTbr E58EChVOQexjDLOtvy5nd4Yc19ElCDQAFcTf0=; b=SlYPy0xciaxdLt3iQ6b3EC 8U7Z/sLdeMKYNLYJ1cqijFg7ktW9meyIiDUpDsNcNSyS8PAHpGjVW5S6pbhDsVOV zwz72BH5n18R4liAV2msf2gkOsIglghVpQ704fHvFrVdJ72p0T3671Lb5uLycOD/ 3iRJRCFq2Epg3urYKteN7qIf+C+xw2NWd4HGpL1qCP48kDHWqagrhWZcwPVWNMXs S5wLlzGPKriTgQqauNhr07P5r0+9fQs0P9brEcSbTQtuUCo8TZi9HsuOytknT2DV Cnb+PtLPtp+msNYi9Oq3Q/BTgRkkZLhgCRXuw5qb9X7ZJ0ZBHIqxByzj62a+hjdg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudejjedgudefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgesrgdtre ertdefjeenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvghtfiho rhhkqdhhvghrvghtihgtshdrtghomheqnecuggftrfgrthhtvghrnhepudetfeekveevfe eltdekffeigeelkefgudevgedtvdehjefggffglefhvdeuudeinecuffhomhgrihhnpehi vghtfhdrohhrghenucfkphepuddtkedrvddvuddrudektddrudehnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhoohhrvgesnhgvthifohhr khdqhhgvrhgvthhitghsrdgtohhm X-ME-Proxy: Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id F264824005D for ; Tue, 8 Dec 2020 18:48:53 -0500 (EST) To: v6ops@ietf.org References: From: Keith Moore Message-ID: <10364e4c-c037-bc7f-6db3-e69ef42d05a1@network-heretics.com> Date: Tue, 8 Dec 2020 18:48:53 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D6AA91BBDFD1699414E85994" Content-Language: en-US Archived-At: Subject: Re: [v6ops] Pretty Please? - Disposition of draft-ietf-v6ops-cpe-slaac-renum-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2020 23:48:58 -0000 This is a multi-part message in MIME format. --------------D6AA91BBDFD1699414E85994 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/8/20 4:13 PM, Warren Kumari wrote: > [ Subject edited to start new thread ] > Hello again all, > > I started this thread back in October, and then didn't really follow-up; sorry. > > This document went through WGLC as Informational, but uses > "pseudo-RFC2119" language > (https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/, > Section 2). This section says things like (cribbed from RFC7084): > " Take careful note: Unlike other IETF documents, the key words "MUST", > "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", > "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used as > described in [RFC2119]. This document uses these keywords not > strictly for the purpose of interoperability, but rather for the > purpose of establishing industry-common baseline functionality. " > > This caused confusion during IESG eval -- what does the MUST in "CE > routers MUST signal stale configuration..." mean if not in the RFC2119 > sense? My take - Either a standards-track document or a BCP document should be able to use 2119 keywords in a non-2119 way, but only if it provides prominent and explicit definitions of the meanings of the words as used in the document. Having said that I am starting to dislike use of 2119 definitions for keywords in in BCPs, because they inherently need to mean different things in the context of a BCP, than in the context of a protocol specification.   For example: In a BCP - MUST NOT presumably means "doing this violates what we consider best current practice". In a protocol specification - MUST NOT means "a protocol implementation violates the standard if it does this" Though 2026 definitions could be said to apply equally to either kind of document, I've come to believe that it's easy for readers to confuse the two cases.   e.g. a BCP should not constrain behavior of a protocol implementation, since an operator may always have valid reasons for not configuring a protocol implementation to adhere to "best" practice and may need the flexibility to use an implementation that doesn't strictly enforce "best" practice. IMO, regardless of intended status, you should have more explicit definitions for those keywords than you do in the -05 draft.   And though I can think of valid reasons for an Informational document to use 2119 keywords, in general I think it's confusing if they do so. (hope that's clear) > Also, much of the document reads like a BCP - Alissa specifically > called this out in her DISCUSS, but there were quite a few others who > agreed. > > As an example, is it not a Best Current Practice that e.g: "CE routers > SHOULD NOT automatically send DHCPv6-PD RELEASE messages upon reboot > events."? If not, what does this document mean for an implementer? My litmus test for BCP vs. standards-track is this:  A protocol specification says how to implement a protocol in a way to produce some desired behavior and also to interoperate with other implementations of that protocol.   Standards track is intended for protocol specifications.   If it's meaningless to test an implementation of a specification for interoperability with other implementations, it's probably not appropriate for standards track. This is not usually a problem with a BCP.   Similarly, BCP isn't intended for protocol specifications, it's intended for (usually but not always operational) practices.   Of course poorly chosen operational practices /can/ harm interoperability, but I don't think we test BCPs for interoperability in the way that we test implementations of protocol specifications. Sometimes standards-track protocol specifications also make recommendations for operational practice, which is not a problem as long as the two kinds of recommendations are clearly distinguished.   Generally, when evaluating such a specification for advancement only the protocol implementations are tested for interoperability. As for the document at hand: To me draft-ietf-v6ops-cpe-slaac-renum-05 reads more like a protocol specification than a recommendation for operational practice.  As I understand it, its intent is to constrain implementations of IPv6 edge routers (at least, those that get upstream prefixes using DHCPv6) rather than merely to recommend how such routers be configured.    I think implementations of this specification could reasonably be tested for interoperability, at least when DHCPv6 is used to obtain the upstream prefix.   If you can get IETF consensus on these recommendations I wonder why you're not requesting Proposed Standard. So my recommendation is: figure out what kind of document you really want, and revise the document (not just the keyword definitions) to be consistent with that intended status.   If you want standards-track, write it with a router implementer in mind; if you want BCP; write it with an operator in mind who is going to be adjusting settings on routers.   If you want to both constrain implementations and make operational recommendations, standards-track with a non-normative section on operational recommendations sounds about right. (And if you can get consensus around Informational but not around Proposed, I wonder what the gap is about, but I'm thinking in that case you should avoid absolutes like MUST or MUST NOT.) FWIW I've never really believed it would be feasible in general to seamlessly renumber IPv6 subnets of significant size, and I still don't.   But for the specific scenario envisioned by this document, I think its recommendations make sense.  So I expect I would support publication of a revised version of this document once the intended status is ironed out and the language is revised to be consistent with that status. Keith [*]. for any IESG folks watching I'd make the same statement about draft-ietf-tls-oldversions-deprecate use of 2119 keywords - will send a separate message on that in response to that LC --------------D6AA91BBDFD1699414E85994 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 12/8/20 4:13 PM, Warren Kumari wrote:

[ Subject edited to start new thread ]
Hello again all,

I started this thread back in October, and then didn't really follow-up; sorry.

This document went through WGLC as Informational, but uses
"pseudo-RFC2119" language
(https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/,
Section 2). This section says things like (cribbed from RFC7084):
" Take careful note: Unlike other IETF documents, the key words "MUST",
   "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used as
   described in [RFC2119].  This document uses these keywords not
   strictly for the purpose of interoperability, but rather for the
   purpose of establishing industry-common baseline functionality. "

This caused confusion during IESG eval -- what does the MUST in "CE
routers MUST signal stale configuration..." mean if not in the RFC2119
sense?

My take - Either a standards-track document or a BCP document should be able to use 2119 keywords in a non-2119 way, but only if it provides prominent and explicit definitions of the meanings of the words as used in the document.

Having said that I am starting to dislike use of 2119 definitions for keywords in in BCPs, because they inherently need to mean different things in the context of a BCP, than in the context of a protocol specification.   For example:

In a BCP - MUST NOT presumably means "doing this violates what we consider best current practice".
In a protocol specification - MUST NOT means "a protocol implementation violates the standard if it does this"

Though 2026 definitions could be said to apply equally to either kind of document, I've come to believe that it's easy for readers to confuse the two cases.   e.g. a BCP should not constrain behavior of a protocol implementation, since an operator may always have valid reasons for not configuring a protocol implementation to adhere to "best" practice and may need the flexibility to use an implementation that doesn't strictly enforce "best" practice.

IMO, regardless of intended status, you should have more explicit definitions for those keywords than you do in the -05 draft.   And though I can think of valid reasons for an Informational document to use 2119 keywords, in general I think it's confusing if they do so.

(hope that's clear)

Also, much of the document reads like a BCP - Alissa specifically
called this out in her DISCUSS, but there were quite a few others who
agreed.

As an example, is it not a Best Current Practice that e.g: "CE routers
SHOULD NOT automatically send DHCPv6-PD RELEASE messages upon reboot
events."? If not, what does this document mean for an implementer?

My litmus test for BCP vs. standards-track is this:  A protocol specification says how to implement a protocol in a way to produce some desired behavior and also to interoperate with other implementations of that protocol.   Standards track is intended for protocol specifications.   If it's meaningless to test an implementation of a specification for interoperability with other implementations, it's probably not appropriate for standards track. 

This is not usually a problem with a BCP.   Similarly, BCP isn't intended for protocol specifications, it's intended for (usually but not always operational) practices.   Of course poorly chosen operational practices can harm interoperability, but I don't think we test BCPs for interoperability in the way that we test implementations of protocol specifications.

Sometimes standards-track protocol specifications also make recommendations for operational practice, which is not a problem as long as the two kinds of recommendations are clearly distinguished.   Generally, when evaluating such a specification for advancement only the protocol implementations are tested for interoperability.

As for the document at hand:

To me draft-ietf-v6ops-cpe-slaac-renum-05 reads more like a protocol specification than a recommendation for operational practice.  As I understand it, its intent is to constrain implementations of IPv6 edge routers (at least, those that get upstream prefixes using DHCPv6) rather than merely to recommend how such routers be configured.    I think implementations of this specification could reasonably be tested for interoperability, at least when DHCPv6 is used to obtain the upstream prefix.   If you can get IETF consensus on these recommendations I wonder why you're not requesting Proposed Standard.

So my recommendation is: figure out what kind of document you really want, and revise the document (not just the keyword definitions) to be consistent with that intended status.   If you want standards-track, write it with a router implementer in mind; if you want BCP; write it with an operator in mind who is going to be adjusting settings on routers.   If you want to both constrain implementations and make operational recommendations, standards-track with a non-normative section on operational recommendations sounds about right. 

(And if you can get consensus around Informational but not around Proposed, I wonder what the gap is about, but I'm thinking in that case you should avoid absolutes like MUST or MUST NOT.)

FWIW I've never really believed it would be feasible in general to seamlessly renumber IPv6 subnets of significant size, and I still don't.   But for the specific scenario envisioned by this document, I think its recommendations make sense.  So I expect I would support publication of a revised version of this document once the intended status is ironed out and the language is revised to be consistent with that status.

Keith

[*].  for any IESG folks watching I'd make the same statement about draft-ietf-tls-oldversions-deprecate use of 2119 keywords - will send a separate message on that in response to that LC --------------D6AA91BBDFD1699414E85994-- From nobody Tue Dec 8 20:20:07 2020 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 89F583A0B0C; Tue, 8 Dec 2020 20:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=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=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 I0-ZI7oigeOU; Tue, 8 Dec 2020 20:19:59 -0800 (PST) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (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 65B943A0B0B; Tue, 8 Dec 2020 20:19:59 -0800 (PST) Received: by mail-pf1-x429.google.com with SMTP id s21so159335pfu.13; Tue, 08 Dec 2020 20:19:59 -0800 (PST) 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=VdixiaI29dXdFnUyvvdEeJPfwyOCKLuW+lesoN5pigc=; b=uRO0Cy2G+icQvQ7DvThgBhzauQJ+hOQdWkefjKXjvfIa8NKaG4NN+OSeRgMUr/eDu4 rHADxjXhD16+Ck1RMCtWnaJGcaNw1LnhUXSVnOte62mNAprtOIG7TL5fDvzWiOrhZ7ph R+FHXuz+kpuUuuSr+hIIeXdqlAQFbNVOAetZYZ2cpsZCZsNWDALhb591ur49yu9Ly+lT 2JBI2Oo/Z5Fbp/xH2dju8X/a4U/zcrtX7RZ5in8+JcmL3tLvm6WBWOo5ij5Vk41mS6bM 3I6WZx6hPQzzn3zpgTrlcrQ4iYuz2X6pzGgOQcorEhhchPo8bDV+bTytnZSE/IzvMijo u4Sw== 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=VdixiaI29dXdFnUyvvdEeJPfwyOCKLuW+lesoN5pigc=; b=GazV/blofOrc+BS4i2empLnfdzOS7zxacAFBgixiGiiAghO3j4YOuIqxd0ceaG3fdQ //OgBfLK0bK3K+H9YkIf6rVOqwqoikZ0cZPY1iJUZBIEvz8jjIZZLBGCP4a3A9tI6gu1 3Ssrpqz1OC7eO5sAz+BMT2J6KzrxL79QDQA+qhVG76nGSgoTVptO3ELkfaT6hpbuzsGd Xtgw0AGwoCmEPaVkG2ZIu7fhmxL4c44NH3J+uQUn0gLSnl545UdneZaO/u3xFCRdx9tQ H3cNt5rp4azPQGzwCa7eY65W0YjSkta2woWCzJ6dVXhbZbFw6TIRm0InW0Wmq7x53XS5 5Jdw== X-Gm-Message-State: AOAM532coAgq1bCiS9r3auS+g5L5o5NrK+IVWtmny4LIaXwNH4y4Xgu+ wJW5c7bD7AbZo3iQrYSNGV6vDEO9rIZ3Uw== X-Google-Smtp-Source: ABdhPJwd4pg58Z4GKEvaWI2FuHfUBrDgfhG3t4TXKXGC0hRcYFejK3AXDBQSPv4+EUhE7fBuYzckpA== X-Received: by 2002:aa7:9af4:0:b029:19d:975a:3ef2 with SMTP id y20-20020aa79af40000b029019d975a3ef2mr406439pfp.5.1607487598241; Tue, 08 Dec 2020 20:19:58 -0800 (PST) Received: from [172.20.15.112] ([202.134.35.146]) by smtp.gmail.com with ESMTPSA id j19sm408368pff.74.2020.12.08.20.19.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Dec 2020 20:19:57 -0800 (PST) To: Gyan Mishra , IPv6 IPv6 List , IPv6 Operations References: From: Brian E Carpenter Message-ID: <196a4f29-0148-21db-8269-07e6bf54bb7c@gmail.com> Date: Wed, 9 Dec 2020 17:19:52 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] RFC 6437 - IPv6 flow label usage in context of ECMP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 04:20:02 -0000 Gyan, I'm sorry, I don't understand what your question is. The reason that RFC6= 437 calls for a hash algorithm with certain properties when setting the f= low label is precisely so that the reulting flow label is suitable input = to any further ECMP or LAG hash, with or without the traditional n-tuple = being available. There is background info in RFC6436, and specific uses cases in RFC6438 a= nd RFC7098. Maybe you can refine your question after reviewing those RFCs= ? Regards Brian Carpenter On 09-Dec-20 09:22, Gyan Mishra wrote: >=20 > Dear v6ops & 6man, >=20 > I have a question related to how IPv6 flow label works in the context o= f router ECMP load balancing characteristics resulting in even or uneven = load balancing based on the understanding flow based or n-tuple ECMP hash= based per packet algorithm. >=20 > My understanding of RFC 6437 is that the IPv6 flow label is a means of = classification of packets that are part of the same flow from a particula= r flow for use in QOS marking. >=20 > From a load balancing perspective the flow key could be used to identif= y a flow and path taken on routes in a case of load balancing ECMP hash. = =C2=A0 >=20 > The goal of IPv6 flow label is for ordering of packets to be part of th= e same network path in an ECMP hash resulting in flow based load balancin= g identical to what exists today with IPv4. =C2=A0 >=20 > What is confusing is if flow label 5 tuple is input to a ECMP hash algo= rithm similar to LAG and MLAG which yields =C2=A0per packet load balancin= g based on n-tuple hash implemented by most vendors.=C2=A0 This would be = preferable if as it would yield even load balancing. >=20 > Or is the flow label goal to maintain the per flow load balancing and u= se for QOS packet classification so all packets that are part of a partic= ular flow use the same ECMP path.=C2=A0 In this case the n-tuple hash key= generated is just to identify which path the flow had taken on a router = but not an input to a hash algorithm function as exists with LAG or MLAG.= =C2=A0 >=20 > The difference is significant as far as load balancing as a n-tuple inp= ut to ECMP hash algorithm achieves close to 50/50 load balancing where pe= r flow load balancing can be uneven as it=E2=80=99s based on flows and th= us from a network standpoint high bandwidth flows may hash to one ECMP pa= th and low bandwidth flows may hash to another ECMP path. >=20 > So in general with parallel links bundling LAG and MLAG is always prefe= rred method for load balancing distribution over ECMP.=C2=A0 However L3 E= CMP always exists and is optimal to assist further load balancing which o= ften times exists in conjunction with LAG and MLAG. >=20 > Excerpt from a doc I found online related to IPv6 flow label operation:= >=20 > A flow is a sequence of packets sent from a particular source to a=C2=A0= particular (unicast or multicast) destination for which the source=C2=A0= desires special handling by the intervening routers. The nature of=C2=A0= that special handling might be conveyed to the routers by a control=C2=A0= protocol, such as a resource reservation protocol, or by information=C2=A0= within the flow's packets themselves, e.g., in a hop-by-hop option.=C2=A0= The details of such control protocols or options are beyond the scope of= this document. >=20 > There may be multiple active flows from a source to a destination, as w= ell as traffic that is not associated with any flow. A flow is uniquely i= dentified by the combination of a source address and a=C2=A0 non-zero flo= w label. Packets that do not belong to a flow carry a=C2=A0 flow label of= zero. >=20 > A flow label is assigned to a flow by the flow's source node. New flow = labels must be chosen (pseudo-)randomly and uniformly from the=C2=A0 rang= e 1 to FFFFF hex. The purpose of the random allocation is to=C2=A0 make a= ny set of bits within the Flow Label field suitable for use as=C2=A0 a ha= sh key by routers, for looking up the state associated with the=C2=A0 flo= w. >=20 >=20 > All packets belonging to the same flow must be sent with the same=C2=A0= source address, destination address, and flow label. If any of those pac= kets includes a Hop-by-Hop Options header, then they all must be=C2=A0 or= iginated with the same Hop-by-Hop Options header contents=C2=A0 (excludin= g the Next Header field of the Hop-by-Hop Options header).=C2=A0 If any o= f those packets includes a Routing header, then they all must be originat= ed with the same contents in all extension headers up to=C2=A0 and includ= ing the Routing header (excluding the Next Header field in=C2=A0 the Rout= ing header). The routers or destinations are permitted, but=C2=A0 not req= uired, to verify that these conditions are satisfied. If a=C2=A0 violatio= n is detected, it should be reported to the source by an ICMP Parameter P= roblem message, Code 0, pointing to the high-order octet=C2=A0 of the Flo= w Label field (i.e., offset 1 within the IPv6 packet).=C2=A0 >=20 > The maximum lifetime of any flow-handling state established along a flo= w's path must be specified as part of the description of the=C2=A0 state-= establishment mechanism, e.g., the resource reservation=C2=A0 protocol or= the flow-setup hop-by-hop option. A source must not re-=C2=A0 use a flow= label for a new flow within the maximum lifetime of any=C2=A0 flow-handl= ing state that might have been established for the prior=C2=A0 use of tha= t flow label. >=20 > Excerpt from Section 2 below: >=20 > The 20-bit Flow Label field in the IPv6 header [RFC2460 ] is used by a > node to label packets of a flow. A Flow Label of zero is used to > indicate packets that have not been labeled. Packet classifiers can= > use the triplet of Flow Label, Source Address, and Destination > Address fields to identify the flow to which a particular packet > belongs. Packets are processed in a flow-specific manner by nodes > that are able to do so in a stateless manner or that have been set u= p > with flow-specific state. The nature of the specific treatment and > the methods for flow state establishment are out of scope for this > specification. >=20 > Flow label values should be chosen such that their bits exhibit a > high degree of variability, making them suitable for use as part of > the input to a hash function used in a load distribution scheme. At= > the same time, third parties should be unlikely to be able to guess > the next value that a source of flow labels will choose. >=20 >=20 > o Forwarding nodes such as routers and load distributors MUST NOT > depend only on Flow Label values being uniformly distributed. In= > any usage such as a hash key for load distribution, the Flow Labe= l > bits MUST be combined at least with bits from other sources withi= n > the packet, so as to produce a constant hash value for each flow > and a suitable distribution of hash values across flows. > Typically, the other fields used will be some or all components o= f > the usual 5-tuple. In this way, load distribution will still > occur even if the Flow Label values are poorly distributed. >=20 > Although uniformly distributed flow label values are recommended > below, and will always be helpful for load distribution, it is unsaf= e > to assume their presence in the general case, and the use case needs= > to work even if the flow label value is zero. >=20 > As a general practice, packet flows should not be reordered, and the= > use of the Flow Label field does not affect this. In particular, a > Flow label value of zero does not imply that reordering is > acceptable. >=20 >=20 >=20 > Kind Regards=20 >=20 >=20 > Gyan >=20 >=20 > --=20 >=20 > >=20 > *Gyan Mishra* >=20 > /Network Solutions A//rchitect=C2=A0/ >=20 > /M 301 502-1347 > 13101 Columbia Pike=C2=A0 > /Silver Spring, MD >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Tue Dec 8 22:58:33 2020 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 111C83A0D3D; Tue, 8 Dec 2020 22:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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=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 SqJnh4GQldXC; Tue, 8 Dec 2020 22:58:16 -0800 (PST) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 9905E3A0B26; Tue, 8 Dec 2020 22:58:16 -0800 (PST) Received: by mail-pf1-x42d.google.com with SMTP id f9so390439pfc.11; Tue, 08 Dec 2020 22:58:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0HZmlrtA+hdhYCq5HFcQ8BRC+1qmyYRAjL7uvSuqu8g=; b=TByuY1VvV9C6M24GqlBClXytTTMu4Cj83oJZLOvHjPLL21dlosbuD0MJcrQh0INWSX s4TSfMFFciylvFcrS4UgYt/gzDzBLg4MP5oVsDEDlp67amkf0nQhQwZ8DtNibUeLwNyb x3nHkLUjQp5Qb1kTncBB/Rr+EkUeRrtKK4VYpW2sQzq6iS4Tn1cEJmqpG3l2iIBLZD9a rDneulFEIMnVU5H0+xs6FilbkQ/zYORPDDkKJMdrtVr8uaJs5cM96b+JkpEp4jxsOP53 Dv/C4LigSd72lUDPuBLyAsfURtZ1tQbITsGAv0CaBnpMkesk0F0Xv4omawkkAu3uImnu Lj/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=0HZmlrtA+hdhYCq5HFcQ8BRC+1qmyYRAjL7uvSuqu8g=; b=Oi7M94ybFk22AoTIjvKKcMAW41cp1+dlCOUYeClZqloOgG1bjCLtWFDcasBg8Epnoj XKz/kZV00Z0JAmp7WNd+Oi1nZiyk1dBPXHzVB2mpF9hqs4Y2WQ388hE46R9VC+BPrq0G T001R1D/6iCJvRKzauiDhJOe8th+X12jtZzdC/xiCTScQSAQZ+EAamgCWCq05oi6dDY9 /8WGiwX8OgMWqpBD3BzbDuvZOjTx9lf25hP2z83DJvonzm7YLHfcKAHEDng1SYPhiy5S RYnIWHJ64tBNnLZeNdK+JvaRCCs3LuVU+qi69WellOlIbenTmGHaBasf6buPuhlrNnoR XfkA== X-Gm-Message-State: AOAM533vXxwFQYOQ14RDPA8p+ggKUgoOaGCu7CeLlN2FOh93j9oP5y5U B/8nqPPRTEq/ZxAPQYsNj6JCHl9T60tl9pJVosM= X-Google-Smtp-Source: ABdhPJxgjzANc8EQifyEXUrCuC+ihsyIk+rGHJDDSjMNWwyN+x3/h4NaGVv9U+ajmk3gzss9/olJuUbe2vpiBv+9WRM= X-Received: by 2002:a65:5547:: with SMTP id t7mr774357pgr.50.1607497095868; Tue, 08 Dec 2020 22:58:15 -0800 (PST) MIME-Version: 1.0 References: <196a4f29-0148-21db-8269-07e6bf54bb7c@gmail.com> In-Reply-To: <196a4f29-0148-21db-8269-07e6bf54bb7c@gmail.com> From: Gyan Mishra Date: Wed, 9 Dec 2020 01:57:56 -0500 Message-ID: To: Brian E Carpenter Cc: IPv6 IPv6 List , IPv6 Operations Content-Type: multipart/alternative; boundary="00000000000060788605b602952c" Archived-At: Subject: Re: [v6ops] RFC 6437 - IPv6 flow label usage in context of ECMP X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 06:58:27 -0000 --00000000000060788605b602952c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Brian The RFCs mentioned helped a lot. So basically my confusion was on the stateful signaled usage which is implies the source tagging the packets and flow or session based load balancing. The stateless option is the mutable flow label local generation of 20 bit hash key via 5-tuple headers to generate uniform statistical hash that provides even per packet load balancing to avoid chance of out of order packets. I believe most modern routers on current code support RFC 6437 5-tuple hash which I have to validate per vendor support and code. This feature as mentioned is extremely valuable for operators and will help gain momentum to push forward to accelerate deployments to IPv6 only core moving away from MPLS and straight to SRv6 as quick as possible to reap the benefits of 5-tuple load balancing hash. The 5-tuple uniform statistical load balancing hash is a major gain for IPv6 and fills a huge gap for both MPLS and IPv4 that utilizes ECMP flow or session based very uneven load balancing. I am working on an SR analysis draft that compare and contrasts SR-MPLS to SRv6 and so this is one more major benefit for SRv6 over SR-MPLS. MPLS has an entropy label which helps eliminate control plane and data plane state with having to allocate additional labels per path but unfortunately does not provide statistical uniform load balancing entropy. https://tools.ietf.org/html/rfc6790 I have a draft on BESS WG below I presented at the last three IETFs which I am working with 5 of the major industry stakeholder router vendors Cisco, Juniper, Arista, Nokia and Huawei to validate a solution for RFC 5549 / RFC 8950 that allows an IPv6 peer to carry IPV4 NLRI. The proposal is geared to eliminate IPv4 peering at the edge PE-CE by stacking AFIs, basically using IPv6 peer as a pure transport to carry IPv4 NLRI AFI so AFI/SAFI 1/1 2/1 are carried over 2/1. BGP AFI SAFI https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml https://datatracker.ietf.org/doc/draft-mishra-bess-ipv4nlri-ipv6nh-use-case= s/ IETF 109 BESS presentation- look for Gyan https://datatracker.ietf.org/meeting/agenda/ This draft also resolves IPv4 address depletion issue at IXP peering points as now IPv4 can be 100% eliminated from all PE-CE peering worldwide for both enterprises and service providers. With this draft the operator core will now be 100% pure IPv6 only from the P core to the PE edge customer peering. So all that will be v4 is the customer payload overlay. As we do the vendor QA for the draft mentioned, we will also try to add in RFC 6437 5-tuple stateless statistical load balancing to ensure that works without issue. I am going to try to spin up another draft to tackle this effort for QA testing of RFC 6437 for 5-tuple ECMP hash entropy key uniform statistical load balancing. I think v6ops would be the right spot as we would be QA testing of uniform load balancing to provide valuable data point for operators to give another reason to move towards IPv6 only SRv6 core. Thank you Gyan On Tue, Dec 8, 2020 at 11:19 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Gyan, > > I'm sorry, I don't understand what your question is. The reason that > RFC6437 calls for a hash algorithm with certain properties when setting t= he > flow label is precisely so that the reulting flow label is suitable input > to any further ECMP or LAG hash, with or without the traditional n-tuple > being available. > > There is background info in RFC6436, and specific uses cases in RFC6438 > and RFC7098. Maybe you can refine your question after reviewing those RFC= s? > > Regards > Brian Carpenter > > On 09-Dec-20 09:22, Gyan Mishra wrote: > > > > Dear v6ops & 6man, > > > > I have a question related to how IPv6 flow label works in the context o= f > router ECMP load balancing characteristics resulting in even or uneven lo= ad > balancing based on the understanding flow based or n-tuple ECMP hash base= d > per packet algorithm. > > > > My understanding of RFC 6437 is that the IPv6 flow label is a means of > classification of packets that are part of the same flow from a particula= r > flow for use in QOS marking. > > > > From a load balancing perspective the flow key could be used to identif= y > a flow and path taken on routes in a case of load balancing ECMP hash. > > > > The goal of IPv6 flow label is for ordering of packets to be part of th= e > same network path in an ECMP hash resulting in flow based load balancing > identical to what exists today with IPv4. > > > > What is confusing is if flow label 5 tuple is input to a ECMP hash > algorithm similar to LAG and MLAG which yields per packet load balancing > based on n-tuple hash implemented by most vendors. This would be > preferable if as it would yield even load balancing. > > > > Or is the flow label goal to maintain the per flow load balancing and > use for QOS packet classification so all packets that are part of a > particular flow use the same ECMP path. In this case the n-tuple hash ke= y > generated is just to identify which path the flow had taken on a router b= ut > not an input to a hash algorithm function as exists with LAG or MLAG. > > > > The difference is significant as far as load balancing as a n-tuple > input to ECMP hash algorithm achieves close to 50/50 load balancing where > per flow load balancing can be uneven as it=E2=80=99s based on flows and = thus from > a network standpoint high bandwidth flows may hash to one ECMP path and l= ow > bandwidth flows may hash to another ECMP path. > > > > So in general with parallel links bundling LAG and MLAG is always > preferred method for load balancing distribution over ECMP. However L3 > ECMP always exists and is optimal to assist further load balancing which > often times exists in conjunction with LAG and MLAG. > > > > Excerpt from a doc I found online related to IPv6 flow label operation: > > > > A flow is a sequence of packets sent from a particular source to a > particular (unicast or multicast) destination for which the source desir= es > special handling by the intervening routers. The nature of that special > handling might be conveyed to the routers by a control protocol, such as= a > resource reservation protocol, or by information within the flow's packe= ts > themselves, e.g., in a hop-by-hop option. The details of such control > protocols or options are beyond the scope of this document. > > > > There may be multiple active flows from a source to a destination, as > well as traffic that is not associated with any flow. A flow is uniquely > identified by the combination of a source address and a non-zero flow > label. Packets that do not belong to a flow carry a flow label of zero. > > > > A flow label is assigned to a flow by the flow's source node. New flow > labels must be chosen (pseudo-)randomly and uniformly from the range 1 t= o > FFFFF hex. The purpose of the random allocation is to make any set of bi= ts > within the Flow Label field suitable for use as a hash key by routers, f= or > looking up the state associated with the flow. > > > > > > All packets belonging to the same flow must be sent with the same > source address, destination address, and flow label. If any of those > packets includes a Hop-by-Hop Options header, then they all must be > originated with the same Hop-by-Hop Options header contents (excluding t= he > Next Header field of the Hop-by-Hop Options header). If any of those > packets includes a Routing header, then they all must be originated with > the same contents in all extension headers up to and including the Routi= ng > header (excluding the Next Header field in the Routing header). The > routers or destinations are permitted, but not required, to verify that > these conditions are satisfied. If a violation is detected, it should be > reported to the source by an ICMP Parameter Problem message, Code 0, > pointing to the high-order octet of the Flow Label field (i.e., offset 1 > within the IPv6 packet). > > > > The maximum lifetime of any flow-handling state established along a > flow's path must be specified as part of the description of the > state-establishment mechanism, e.g., the resource reservation protocol o= r > the flow-setup hop-by-hop option. A source must not re- use a flow label > for a new flow within the maximum lifetime of any flow-handling state th= at > might have been established for the prior use of that flow label. > > > > Excerpt from Section 2 below: > > > > The 20-bit Flow Label field in the IPv6 header [RFC2460 < > https://tools.ietf.org/html/rfc2460>] is used by a > > node to label packets of a flow. A Flow Label of zero is used to > > indicate packets that have not been labeled. Packet classifiers can > > use the triplet of Flow Label, Source Address, and Destination > > Address fields to identify the flow to which a particular packet > > belongs. Packets are processed in a flow-specific manner by nodes > > that are able to do so in a stateless manner or that have been set u= p > > with flow-specific state. The nature of the specific treatment and > > the methods for flow state establishment are out of scope for this > > specification. > > > > Flow label values should be chosen such that their bits exhibit a > > high degree of variability, making them suitable for use as part of > > the input to a hash function used in a load distribution scheme. At > > the same time, third parties should be unlikely to be able to guess > > the next value that a source of flow labels will choose. > > > > > > o Forwarding nodes such as routers and load distributors MUST NOT > > depend only on Flow Label values being uniformly distributed. In > > any usage such as a hash key for load distribution, the Flow Labe= l > > bits MUST be combined at least with bits from other sources withi= n > > the packet, so as to produce a constant hash value for each flow > > and a suitable distribution of hash values across flows. > > Typically, the other fields used will be some or all components o= f > > the usual 5-tuple. In this way, load distribution will still > > occur even if the Flow Label values are poorly distributed. > > > > Although uniformly distributed flow label values are recommended > > below, and will always be helpful for load distribution, it is unsaf= e > > to assume their presence in the general case, and the use case needs > > to work even if the flow label value is zero. > > > > As a general practice, packet flows should not be reordered, and the > > use of the Flow Label field does not affect this. In particular, a > > Flow label value of zero does not imply that reordering is > > acceptable. > > > > > > > > Kind Regards > > > > > > Gyan > > > > > > -- > > > > > > > > *Gyan Mishra* > > > > /Network Solutions A//rchitect / > > > > /M 301 502-1347 > > 13101 Columbia Pike > > /Silver Spring, MD > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --00000000000060788605b602952c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Brian=C2=A0

The RFCs mentioned helped a lot. =C2=A0
So basically my confusion was on the stateful sig= naled usage which is implies the source tagging the packets and flow or ses= sion based load balancing. =C2=A0

The stateless option is the mutable flow label local generation o= f 20 bit hash key via 5-tuple headers to generate uniform statistical hash = that provides even per packet load balancing to avoid chance of out of orde= r packets.

I believe mos= t modern routers on current code support RFC =C2=A06437 5-tuple hash which = I have to validate per vendor support and code. =C2=A0

This feature as mentioned is extremely valua= ble for operators and will help gain momentum to push forward to accelerate= deployments to IPv6 only core moving away from MPLS and straight to SRv6 a= s quick as possible to reap the benefits of 5-tuple load balancing hash. = =C2=A0

The 5-tuple unifo= rm statistical load balancing hash is a major gain for IPv6 and fills a =C2= =A0huge gap for both MPLS and IPv4 that utilizes ECMP =C2=A0flow or session= based very uneven load balancing.

I am working on an SR analysis draft that compare and contrasts = SR-MPLS to SRv6 and so this is one more major benefit for SRv6 over SR-MPLS= .

MPLS has an entropy la= bel which helps eliminate control plane and data plane state with having to= allocate additional labels per path but unfortunately does not provide sta= tistical uniform load balancing entropy. =C2=A0

=
=
I have a draft on BESS WG below I presented at = the last three IETFs which I am working with 5 =C2=A0of the major industry = stakeholder router vendors Cisco, Juniper, Arista, Nokia and Huawei to vali= date a solution for RFC 5549 / RFC 8950 that allows an IPv6 peer to carry I= PV4 NLRI.=C2=A0 The proposal is geared to eliminate IPv4 peering at the edg= e PE-CE by stacking AFIs, =C2=A0basically using IPv6 peer as a pure transpo= rt to carry IPv4 NLRI AFI so AFI/SAFI 1/1 2/1 are carried over 2/1.=C2=A0

BGP AFI SAFI


IETF 109 BESS presentation- look for Gyan
=


This draft also resolves = IPv4 address depletion issue at IXP peering points as now IPv4 can be 100% = eliminated from all PE-CE peering worldwide for both enterprises and servic= e providers.

With this draft the operator = core will now be 100% pure IPv6 =C2=A0only from the P core to the PE edge c= ustomer peering.=C2=A0 So all that will be v4 is the customer payload overl= ay.

As we do the vendor = QA for the draft mentioned, we will also try to add in RFC 6437 5-tuple sta= teless statistical load balancing to ensure that works without issue. =C2= =A0

I am going to try to= spin up another draft to tackle this effort for QA testing of RFC 6437 for= 5-tuple ECMP hash entropy key uniform statistical load balancing.=C2=A0 I = think v6ops would be the right spot as we would be QA testing of uniform lo= ad balancing to provide valuable data point for operators to give another r= eason to move towards IPv6 only SRv6 core.

Thank you=C2=A0

Gyan

On Tue, Dec 8, 2020 at 11:19 PM Brian E Carpenter <<= a href=3D"mailto:brian.e.carpenter@gmail.com">brian.e.carpenter@gmail.com> wrote:
Gyan,

I'm sorry, I don't understand what your question is. The reason tha= t RFC6437 calls for a hash algorithm with certain properties when setting t= he flow label is precisely so that the reulting flow label is suitable inpu= t to any further ECMP or LAG hash, with or without the traditional n-tuple = being available.

There is background info in RFC6436, and specific uses cases in RFC6438 and= RFC7098. Maybe you can refine your question after reviewing those RFCs?
Regards
=C2=A0 =C2=A0Brian Carpenter

On 09-Dec-20 09:22, Gyan Mishra wrote:
>
> Dear v6ops & 6man,
>
> I have a question related to how IPv6 flow label works in the context = of router ECMP load balancing characteristics resulting in even or uneven l= oad balancing based on the understanding flow based or n-tuple ECMP hash ba= sed per packet algorithm.
>
> My understanding of RFC 6437 is that the IPv6 flow label is a means of= classification of packets that are part of the same flow from a particular= flow for use in QOS marking.
>
> From a load balancing perspective the flow key could be used to identi= fy a flow and path taken on routes in a case of load balancing ECMP hash. = =C2=A0
>
> The goal of IPv6 flow label is for ordering of packets to be part of t= he same network path in an ECMP hash resulting in flow based load balancing= identical to what exists today with IPv4. =C2=A0
>
> What is confusing is if flow label 5 tuple is input to a ECMP hash alg= orithm similar to LAG and MLAG which yields =C2=A0per packet load balancing= based on n-tuple hash implemented by most vendors.=C2=A0 This would be pre= ferable if as it would yield even load balancing.
>
> Or is the flow label goal to maintain the per flow load balancing and = use for QOS packet classification so all packets that are part of a particu= lar flow use the same ECMP path.=C2=A0 In this case the n-tuple hash key ge= nerated is just to identify which path the flow had taken on a router but n= ot an input to a hash algorithm function as exists with LAG or MLAG. =C2=A0=
>
> The difference is significant as far as load balancing as a n-tuple in= put to ECMP hash algorithm achieves close to 50/50 load balancing where per= flow load balancing can be uneven as it=E2=80=99s based on flows and thus = from a network standpoint high bandwidth flows may hash to one ECMP path an= d low bandwidth flows may hash to another ECMP path.
>
> So in general with parallel links bundling LAG and MLAG is always pref= erred method for load balancing distribution over ECMP.=C2=A0 However L3 EC= MP always exists and is optimal to assist further load balancing which ofte= n times exists in conjunction with LAG and MLAG.
>
> Excerpt from a doc I found online related to IPv6 flow label operation= :
>
> A flow is a sequence of packets sent from a particular source to a=C2= =A0 particular (unicast or multicast) destination for which the source=C2= =A0 desires special handling by the intervening routers. The nature of=C2= =A0 that special handling might be conveyed to the routers by a control=C2= =A0 protocol, such as a resource reservation protocol, or by information=C2= =A0 within the flow's packets themselves, e.g., in a hop-by-hop option.= =C2=A0 The details of such control protocols or options are beyond the scop= e of this document.
>
> There may be multiple active flows from a source to a destination, as = well as traffic that is not associated with any flow. A flow is uniquely id= entified by the combination of a source address and a=C2=A0 non-zero flow l= abel. Packets that do not belong to a flow carry a=C2=A0 flow label of zero= .
>
> A flow label is assigned to a flow by the flow's source node. New = flow labels must be chosen (pseudo-)randomly and uniformly from the=C2=A0 r= ange 1 to FFFFF hex. The purpose of the random allocation is to=C2=A0 make = any set of bits within the Flow Label field suitable for use as=C2=A0 a has= h key by routers, for looking up the state associated with the=C2=A0 flow.<= br> >
>
> All packets belonging to the same flow must be sent with the same=C2= =A0 source address, destination address, and flow label. If any of those pa= ckets includes a Hop-by-Hop Options header, then they all must be=C2=A0 ori= ginated with the same Hop-by-Hop Options header contents=C2=A0 (excluding t= he Next Header field of the Hop-by-Hop Options header).=C2=A0 If any of tho= se packets includes a Routing header, then they all must be originated with= the same contents in all extension headers up to=C2=A0 and including the R= outing header (excluding the Next Header field in=C2=A0 the Routing header)= . The routers or destinations are permitted, but=C2=A0 not required, to ver= ify that these conditions are satisfied. If a=C2=A0 violation is detected, = it should be reported to the source by an ICMP Parameter Problem message, C= ode 0, pointing to the high-order octet=C2=A0 of the Flow Label field (i.e.= , offset 1 within the IPv6 packet).=C2=A0
>
> The maximum lifetime of any flow-handling state established along a fl= ow's path must be specified as part of the description of the=C2=A0 sta= te-establishment mechanism, e.g., the resource reservation=C2=A0 protocol o= r the flow-setup hop-by-hop option. A source must not re-=C2=A0 use a flow = label for a new flow within the maximum lifetime of any=C2=A0 flow-handling= state that might have been established for the prior=C2=A0 use of that flo= w label.
>
> Excerpt from Section 2 below:
>
>=C2=A0 =C2=A0 The 20-bit Flow Label field in the IPv6 header [RFC2460 &= lt;https://tools.ietf.org/html/rfc2460>] is used by a
>=C2=A0 =C2=A0 node to label packets of a flow.=C2=A0 A Flow Label of ze= ro is used to
>=C2=A0 =C2=A0 indicate packets that have not been labeled.=C2=A0 Packet= classifiers can
>=C2=A0 =C2=A0 use the triplet of Flow Label, Source Address, and Destin= ation
>=C2=A0 =C2=A0 Address fields to identify the flow to which a particular= packet
>=C2=A0 =C2=A0 belongs.=C2=A0 Packets are processed in a flow-specific m= anner by nodes
>=C2=A0 =C2=A0 that are able to do so in a stateless manner or that have= been set up
>=C2=A0 =C2=A0 with flow-specific state.=C2=A0 The nature of the specifi= c treatment and
>=C2=A0 =C2=A0 the methods for flow state establishment are out of scope= for this
>=C2=A0 =C2=A0 specification.
>
>=C2=A0 =C2=A0 Flow label values should be chosen such that their bits e= xhibit a
>=C2=A0 =C2=A0 high degree of variability, making them suitable for use = as part of
>=C2=A0 =C2=A0 the input to a hash function used in a load distribution = scheme.=C2=A0 At
>=C2=A0 =C2=A0 the same time, third parties should be unlikely to be abl= e to guess
>=C2=A0 =C2=A0 the next value that a source of flow labels will choose.<= br> >
>
>=C2=A0 =C2=A0 o=C2=A0 Forwarding nodes such as routers and load distrib= utors MUST NOT
>=C2=A0 =C2=A0 =C2=A0 =C2=A0depend only on Flow Label values being unifo= rmly distributed.=C2=A0 In
>=C2=A0 =C2=A0 =C2=A0 =C2=A0any usage such as a hash key for load distri= bution, the Flow Label
>=C2=A0 =C2=A0 =C2=A0 =C2=A0bits MUST be combined at least with bits fro= m other sources within
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the packet, so as to produce a constant hash= value for each flow
>=C2=A0 =C2=A0 =C2=A0 =C2=A0and a suitable distribution of hash values a= cross flows.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Typically, the other fields used will be som= e or all components of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the usual 5-tuple.=C2=A0 In this way, load d= istribution will still
>=C2=A0 =C2=A0 =C2=A0 =C2=A0occur even if the Flow Label values are poor= ly distributed.
>
>=C2=A0 =C2=A0 Although uniformly distributed flow label values are reco= mmended
>=C2=A0 =C2=A0 below, and will always be helpful for load distribution, = it is unsafe
>=C2=A0 =C2=A0 to assume their presence in the general case, and the use= case needs
>=C2=A0 =C2=A0 to work even if the flow label value is zero.
>
>=C2=A0 =C2=A0 As a general practice, packet flows should not be reorder= ed, and the
>=C2=A0 =C2=A0 use of the Flow Label field does not affect this.=C2=A0 I= n particular, a
>=C2=A0 =C2=A0 Flow label value of zero does not imply that reordering i= s
>=C2=A0 =C2=A0 acceptable.
>
>
>
> Kind Regards
>
>
> Gyan
>
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> /Network Solutions A//rchitect=C2=A0/
>
> /M 301 502-1347
> 13101 Columbia Pike=C2=A0
> /Silver Spring, MD
>
>
>
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman= /listinfo/ipv6
> -------------------------------------------------------------------- >

--
--00000000000060788605b602952c-- From nobody Wed Dec 9 04:57:06 2020 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 7B2983A1455 for ; Wed, 9 Dec 2020 04:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=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 d7yXJsD4rsX5 for ; Wed, 9 Dec 2020 04:57:03 -0800 (PST) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 306DA3A1438 for ; Wed, 9 Dec 2020 04:57:02 -0800 (PST) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-CHACHA20-POLY1305) (Smail #157) id m1kmz1g-00007vC; Wed, 9 Dec 2020 13:57:00 +0100 Message-Id: To: v6ops@ietf.org Cc: Keith Moore From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <10364e4c-c037-bc7f-6db3-e69ef42d05a1@network-heretics.com> In-reply-to: Your message of "Tue, 8 Dec 2020 18:48:53 -0500 ." <10364e4c-c037-bc7f-6db3-e69ef42d05a1@network-heretics.com> Date: Wed, 09 Dec 2020 13:56:58 +0100 Archived-At: Subject: Re: [v6ops] Pretty Please? - Disposition of draft-ietf-v6ops-cpe-slaac-renum-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 12:57:05 -0000 > Having said that I am starting to dislike use of 2119 definitions > for keywords in in BCPs, because they inherently need to mean > different things in the context of a BCP, than in the context > of a protocol specification. For example: > > In a BCP - MUST NOT presumably means "doing this violates what > we consider best current practice". In a protocol specification > - MUST NOT means "a protocol implementation violates the standard > if it does this" In the context of this document I don't see much difference. Changing how protocol values are set does change the protocol. In general, violating a MUST in a protocol means that bad things are likely to happen. That's the same in this BCP. From nobody Wed Dec 9 05:54:35 2020 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 073D83A1689 for ; Wed, 9 Dec 2020 05:54:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, 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 header.b=jHpv+GO5; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=aKjbpfO8 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 2qvWENiDb821 for ; Wed, 9 Dec 2020 05:54:32 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E62A73A1686 for ; Wed, 9 Dec 2020 05:54:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5498; q=dns/txt; s=iport; t=1607522071; x=1608731671; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=H1SHEC051X0jjrQlZAypaIUF95Hy1anbRuJ3vPdaxMI=; b=jHpv+GO5sDAs5S5zA/1ryAqprdhJbhQ1WHa6hwk6x6hAB8KklV3uAUiQ gwqr31HmxNDgP6MZwk0qeYkn922Siyic0wu7kwqeDxj6drNNbj4YscaOn bmCTgHjRO9Dsr+1dG/VEL/WjIEyBdRS5WAEZH7JoUcwluCuwBjduC5dAo w=; X-IPAS-Result: =?us-ascii?q?A0CpAADc1tBfmIkNJK1iHQEBAQEJARIBBQUBQIE+BQELA?= =?us-ascii?q?YFRUXxbLy4KhDSDSAONXgOZCYJTA1QLAQEBDQEBJQgCBAEBhEoCF4FoAiU3B?= =?us-ascii?q?g4CAwEBAQMCAwEBAQEFAQEBAgEGBBQBAQEBAQEBAYY2DIVyAQEBAQMSEREMA?= =?us-ascii?q?QE4CwQCAQgRBAEBAQICJgICAjAVCAgCBAESCBqDBAGCVQMuAQMLoVkCgTyIa?= =?us-ascii?q?XaBMoMEAQEFgTMBE0GDOhiCEAMGgQ4qAYJzgmZOQoJEhBUbgUE/gRFDglU+g?= =?us-ascii?q?l0CAwGBXYMVM4IsgWkBKjMGWgEDLyQhdVEICgcPH5AegnilBQqCdIkekkaDJ?= =?us-ascii?q?IoliBuMU4YTiHiEcYsMkUSEUwIEAgQFAg4BAQWBbCKBWXAVgnABATJQFwINj?= =?us-ascii?q?iEag1eFFIVEdDcCBgEJAQEDCXyHGgeBLgGBEAEB?= IronPort-HdrOrdr: A9a23:eVC1kKFN/LzTHutrpLqFj5rXdLJzesId70hD6mlYcjYQWtCEls yogfQQ3QL1jjFUY307hdWcIsC7IE/03aVepa0cJ62rUgWjgmunK4l+8ZDvqgePJwTXzcQY76 tpdsFFZ+HYJVJxgd/mpCyxFNg9yNeKmZrY+dv25XFrUA1sduVE5wB2Fg6UHiRNNXZ7LLA+E4 eR4dcCmiGpfm4ZYt/+Kn4OWeXCoNOjruOpXTctARk75A6SyQ658bKSKWnW4j4ycRNqhY0j/2 /MjhDj6syY082T5xfA2wbonuxrsfT7zN8rPr3otuE0LXHWhh+sdMBdXdS5zU0IicWOzHpvr9 XWuRcnOK1ImjLsV0W4uwHk1QWl8BtG0Q6Y9XaijXHuodP0SVsBYqIr7+80A3ipiXYIh91y3L lG2GiUrfNsfGn9tR7g7NvFXQwCrDvSnVMekPUeh3EacYwSZK45l/1nwGppEYwNFC+/1YY/EO MGNrC72N9qdzqhHhTkl1gq5ObpcmU4Hx+ATERHkNeSySJqkHdwyFZd7NADn18bnahNC6Vs1q DhCOBFhbtORsgZYeZWH+EaW/a6DWTLXFblLH+SG1L6D6sKUki96KLf0fEQ3qWHaZYIxJw9lN DqS1VDr1M/fEroFImo0IBU9AvOBEGwRy7kxM0bx5URgMy/eJPbdQm4DHw+mcqppPsSRufBXe yoBZ5QC/j/aWT0H4JE2BD/RolSJXESXNZ9gKd+Z3u+5ubwbqH6vO3Sd/jeYJD3Fyw/Z2/5Cn wfGDj/Tf8wqXyDazvdulz8Snntckvw8dZbC67B5dUez4ALK8lJuggRglKp+9GTJVR5w+oLVX o7BImivrKwpGGw82qNxX5uIABhAkFc56ilVWhLqw8MO0b9aq0CpN2bZGBX0BK8V1pCZvKTND Qai0V8+KqxIZDV7zslEcibPmWTiGZWuGiHVI4GmqqI5d7sf5QxCppOYt0pKSz7UzhO3Sp6om ZKbwEJAnLFHjT1kKO/kdg/H+fEbeRxhw+tPO9ZoX/Srl+nuMkqX3cXNgTeCfK/sEILfX50jk c027IDiLCA8AzfV1cXsaAdChlwT0i5RJhBFx+IYY1InKuDQnAAcU66wRqAix8yfWL28V41nW KJF1zORdj7RnxAp3tfzqHmtHRze2n1RTMsVllK9atgCG/BpnF/ldWuW5P2+W6QZlweq9ttag 3taScOIw9o2tC83AOUnjHHDnk92pAyJIXmfcQeWqCW1XW3JIKSk6YaW/dS4ZZ+Ldjr9vQGSO SFZmauXXnFIvJs3wyevXA+PiZo7HEijPPzwRXghVLIlEIXEL7XIF58QascLMzZ52/4R+yQ2J E8id4up+O/PiHwbdGBoJunJAJrO1fWoWSsSfsvpo0RtaUutKFrF52eSCDWzhh8rWIDBdaxkF lbTLVw4bjHNIMqd8sOezhB9l5skNiUNkMkvgH/H+dWRyBhs1bLe9eSp7bYo7smBUOM4BH9Pl SS6CVR9fbIVSnr789SN4sgZWBNLEQs4nVr++2PM5DKAAKxbudZ4R60NGS+fLI1ctnIJZwA6h Jhp9eGkO+ce3CmhETevT5nLrlP9GjiS8WoGw6IEfNJ9dv/OVnkuNre3OejyDPsDT28YAAEgI cAc0oaZMFKkCMjg406yTLacN2Anms1119FpSh6nVvs0JW86GjVHUtaIRTU668mLwV7IzyNl4 DZ6uCW23T2/Shd1ZTCHElWeMtSG9J4dPmCEw5+bc4KvLCp+KIzgiNMJBc2ZlRM+wzA9uZt67 e1yZzucuXpA3vwJBYF8TlKGoZ7kkUQ2B19WsCk59a0fhgXGukUA/E2+4BRl3ZzpkLu6kAHBi 8NiiUhzYuIKlD8JXxzGez1nYXwiAUFv6Tq0TNTjX1KkBe8hFmY0mKbo++8p2c0o2rBrgVutK WaQ38rjDxEsxN8qJYRQkalW2jqXH+DLRfzxKwnJXVqBQkUupoWpRDEKLQGkY370nFtqi41Dj N1z7agEGveTjv6L6y/EBmhEtOpDNluJ+tAI2ZrFQ/4CD3Ikok9Jyi4AOtJ2xetnjMVBaaIMr 67ew71Nvkw1aMKPaiEef/6ue7P0UxD+2gWv8bnjxW+7Y9XxMeWPBR1v954c6UBAHbQwA590t +eGR3CJJIW5ia9lR2h1Q1CKNUbwxsYzCAhzE96ck7FdrDDJH1JvzIIx4TkQycV06+6OKxomH 3cql2ssmS+DnHyDGCwWqYA639s9AHNTJOyhSnCR5PtNgtf8PzpDKGhlSCS7X69m/ydilDlx3 dQ+HIZShMvxwiPWtMNT3/Q0kABKhJpUghhiQy4x8MmkzFarF5hdjwaX88Y+ir1TRjaEi3/nT zVTAEAv70vQitwheJTuWBPjV9nkFgITa5knpHKrFu2bG9LQkJNwNUR4jH+3/AVRjB7O0XrNv Dzt8XuK8O23o1CFzTZ9+4bNpRCG1NyoKOQ4POaRTNIbgye07sWxR3W+gsk51xmn8M+rknvjI bRYzCb2s4liocVEavuwiwjRPdQf9dz63aUBtBb674ij0Xiq8DAxiMmfM6N0Vl1KDfuV8QHdA A8bH+Uif4j19SLujuGfpVgoaOD2TknaOzRKW018enJXDV/y7RyxM+XaJXFPzTTpsUKBvIdzA 3Z4UM3zHeplp78D427Lh+lnDeWRGIqE+90bQhLM/CeQII9sqEhnxJbxuUkNhpCm+hiZi6Oqo tJozqWvvganag95EVCHI+B/1Fn/jx9UfeHtp0/xn/bwGE+3vvLgqYsqbqxHLkBUnT0QKFYMb cJroC7SePcNk3aGXxhiY9PakuRBTaP2FR13rR1Yy8V37ppMPg2950XtpoFgX6CE0bZXkM/cr PweoVj9KwDXtqxmwssXj2czPapIB0mx5Ig5DA7PdchrvHkfrA8l1ZS6b8zl87m+th2MNgLm5 u3JBG++nTetX/WRRiZOtGAATRdBj9SOQfyvibgNkG+BjfP+K4Lg39gomMyESTLqt+qg3b1du TpnHce0yzfcCBa7tqWz9ENi3XYhzDZz8YSDLiLLun1WKWt/j1fxoF1gLXAxJLGh7reGa9b3s B0tqZzYfdpjWqO2NadYaBopRamedNo6rpnAUy+/Ckst9zA6dPmKaC1yy0ChdPOhmeXQK3bDW 7iWfJQCojHWlp/MTcYa+Uj1WUDdhkJp0LCR2o5fEjK+rSWVPp6JVnBKDAvUdKjRj/+asJ/cX mbscbVbtLIULd4c0Z+c3etN4+uo5GT4QumLBP7BkrtgmJaMhGsjT3olfrUk7ner5LsbWymgo xyD6XfyjCuMkXvPhTiqoMKSQrXkAmkR5iHwEopZl9wZNKln6wAUOvbI/fM1fkuTM7BTQdk3h fCYWHekhmnXGqmxWsSELZxOUn+/ctoTtLBNDNNx6GsPKmFUFUW9CPbaZQT2Fz4mzw6XPVjrY S1GNsvtlkcSdC0Kd0vs5IzaxcbTohbiS59UEkMIYP456V2E3HhiUL1PBBkD+64ZW1XASDhR4 vePRuY8lUDdURc IronPort-PHdr: A9a23:ve1ZLBCv+WOZzMg0ihgQUyQVmhdPi93PFgcI9poqja5Pea2//pPke VbS/uhpkEShdYbG7vteiqzQvryzEWAD4JPUtncEfdQMUhIekswZkkQmB9LNEkz0KvPmLklYV MRPXVNo5Te3ZE5SHsutZEDXq2ezqzgfBka3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+I Q/wox/Ws5wdgJBpLeA6zR6aykY= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,405,1599523200"; d="scan'208";a="631572250" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Dec 2020 13:54:30 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 0B9DsUQV006078 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 9 Dec 2020 13:54:30 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 9 Dec 2020 07:54:30 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 9 Dec 2020 07:54:30 -0600 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 9 Dec 2020 08:54:29 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ev5g2TJE4NydAFokLEWttN2g7ElS+Ru1VSHQyhzJhNfFx7J+iJA1YMlZExIOGTFQTdNyOS6CqNSV8W2n03o6RNzVoD0KGcnXwlWO4zBd4iG4NBVgjzstkCEGdc+U83WACRytD6DQcoduShvStHZCPThL2HUhR9INNuYqfRyQ2vuWN1N9nHKWolkp0KkteN3jlGBUqvFhLczlsgApnzj1iu8bLPwyv1U53fWS+wRl5zrWQvXXLly7ECL8F91L0SNoZl2h1LdrL6aN4/PDj5ZYy3s64aID95K8HTyz3BmYPEu8Xp90V8zJonQRmkTh/+F4yRyMZvZbJwkSMYkg9jeQaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=H1SHEC051X0jjrQlZAypaIUF95Hy1anbRuJ3vPdaxMI=; b=aG8u8vg1J8M2B9JfR61xqNO4OS509dlEBonaKNgj9paJ8eeXQr7oTQVZDR1x3DxSy1imXUomLcWprPv+RTXAAfmI2oubLtXDOxg73Hg72NQmLGrgnFjcUL+kRuIkbFs3DdHdB31GGo3Aa1riCwDO5aE+vHivNTU+CXbNWO0pPHZnAwpXMCNT3fFqSF9cg5zIdRcHp2xtij9vJDbkb8JH4neOI68gpSaE7wEgR2FYJgjZEDn/Dqvu7hn/AFzNOHtIseZmE7rjd9ys4sLXkp9bd3R0VsMG9+GWncQAI8Xx42wwuUkBU1CVFDAGawkDTZsDWN47+maCB1f9u+kdRu2eoA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=H1SHEC051X0jjrQlZAypaIUF95Hy1anbRuJ3vPdaxMI=; b=aKjbpfO8iIWdg8CfMem/qGYPaOR5qYXr8S5ezsZS2r1zuIBh1f3NfMuES6UHke0i9dpBWUHm4wmiXzkFWc+Y5Ho+MohHZCbTiHvdjSAYui1PLqMp47+N/o5GhVooaKiRrjo87nlFiJ4DDov13YBwx8l1Udohx+xQ0U73n2ML2sg= Received: from BY5PR11MB4355.namprd11.prod.outlook.com (2603:10b6:a03:1c3::13) by BY5PR11MB4070.namprd11.prod.outlook.com (2603:10b6:a03:181::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12; Wed, 9 Dec 2020 13:54:28 +0000 Received: from BY5PR11MB4355.namprd11.prod.outlook.com ([fe80::4032:c3ea:174e:ad96]) by BY5PR11MB4355.namprd11.prod.outlook.com ([fe80::4032:c3ea:174e:ad96%6]) with mapi id 15.20.3654.012; Wed, 9 Dec 2020 13:54:28 +0000 From: "Rob Wilton (rwilton)" To: Warren Kumari , IPv6 Operations , Fernando Gont Thread-Topic: Pretty Please? - Disposition of draft-ietf-v6ops-cpe-slaac-renum-05 Thread-Index: AQHWqIu+ukmi20Q+/0eKh5o2j5PZj6nt/O6AgADojjA= Date: Wed, 9 Dec 2020 13:54:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: kumari.net; dkim=none (message not signed) header.d=none;kumari.net; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8b4c8c53-5a45-4ade-7e6f-08d89c49f23b x-ms-traffictypediagnostic: BY5PR11MB4070: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Uf9s8llkItJyduYqRETzmwrf6PumJWaWheWVsbPrYml5hTFXOj4axhp5q61cKpcQ3ssNtOJWrB8bPAm+Cubb0GwWNhawBSdheezDbCaO/cWjcJTvjWLLX5P4Sag1g4Gos/GacFtHY969R6jmNYv3/4VeoXNaJ/FjOXURsdmRVzesGXZUbtBaEGdLaG8cDIM5zrbrTdu4nl/blJyWKdsLT2qzgcL7M/WoB1UiIwSvN7llcZE52gqqy4Y33P5565+jiNLE2brYt337lcIbz81fgHFhKIW2b+nnpdXj0qrYijXEoDWqdgp68FhK795N1YEqvxTOQCeZwles88aZJV62a0/NlJZXFz+jVlBM/Fp0Ms/Z+vXa3rA1J7P5YB9JbBHTy9WL1LkDVheRoo0T5kW0XQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4355.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(136003)(346002)(376002)(66556008)(33656002)(64756008)(83380400001)(66446008)(2906002)(71200400001)(5660300002)(9686003)(7696005)(52536014)(6506007)(55016002)(53546011)(8936002)(110136005)(66946007)(8676002)(966005)(26005)(66476007)(186003)(86362001)(508600001)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?R0dOcHhvS0dseDZPVmI2a2d2cGM2RzJEcnA3bWI1M3BhZk1NanpEdWEyRmFq?= =?utf-8?B?Y3NLUHpBazJvVHhBdnBuVUIvcFQrd05YZ0lWV0hPUnBvVkJGZko1R3owQ0V1?= =?utf-8?B?VEhVbXZPQytQdUdrdUhtd3ZaWU8rdmxUVHBsWnJFUitMb2JhR013M0JmaWZW?= =?utf-8?B?cVFVWVg4T2dXVHE3STNVaEJyb1drbnRabTV2cWNiQW80QUlDQzNLZUJFME1J?= =?utf-8?B?LzA5ekJiY1lsd3RxZEt4UHBnemtoVmVoMllzNFIwSGlTQzgzK2RNdjdkNG1K?= =?utf-8?B?MElFNWRkeVBSSlNLMlQrUXJlaU9ZM0huNThDd21IYlBkRWg2dmIwRi9KakF4?= =?utf-8?B?NGVCTnBZYWJyTXNINEtVQTRhdTlodDl6UG9nOUZncllzdW9KY3M0UEZQdDd4?= =?utf-8?B?Yk45K3d3MFBzb3IrUGVqWWtSZmpMaTZTbzYvUUd3VWd0RnVocUtURjUyVUFF?= =?utf-8?B?Y3VveWthL3VLZVBWeS9rdEc5MHFWZjU2ZVhQV3V6TFdJU0JsR2tGZnFMZzNM?= =?utf-8?B?SmRKOTNvbTJIRDFoTHlObUdmcjNETExOWjkvZWpDQ3g2Y3dpZDFBR2ZzczU0?= =?utf-8?B?bWY4dnJnWXVpemMxOVlPSTFkajVmWXZSZklEdERDWTRncWNEOW1JUVB0SDlp?= =?utf-8?B?akxzc3lzczB3WmZOZHU2L1pSN0RpOVZ0aGtzb1Jlek9NcWRHWDNWSGhzMFJM?= =?utf-8?B?SWxnWFhqcmpZSmFocURwdEsvUHNRMGdpdjIxN0h4dFJXKzg0dlc5Qm4xN1h4?= =?utf-8?B?M3JyTGx1Kzg4aDFTa0JRUW5Fc0E3UFBLVnFhSllvWld0SVh5VXFyNG9UMDZJ?= =?utf-8?B?Z2JtNk1TejNCQ0RWWFZ5a2RNZ1dFaDVPZGFONUVITDR3RWplZCt5NUh6dFAz?= =?utf-8?B?ZXhaNHJHcTFEK1JJSGFuZ01lVGJCRG83dFE4cTN3SVdUb2N4YnZwaDlvbFhy?= =?utf-8?B?M3NWODM0SGhpRmNDcjhQREF4Y2dIRWtoK1BiUWF0ZzY2dXRkc2s2T29LRlE3?= =?utf-8?B?NU1rNW8yV3V1VVdrWEVTK0xiMGJranFWOUo2WER1SW02ZmZxeFQrT3ZaTXN6?= =?utf-8?B?cjNsQWt6Y0V0VlphUEM2S0RySG9QTnBFcGFWaVE5RHcwNitTbVdaOTN3VWo4?= =?utf-8?B?K0JJVjZRdHNVbU9LZjVHRFNkZXI4NGROa2ZHd3Z1T3pMRlBVbXNRQ0ZmMTcz?= =?utf-8?B?dlY4U1R3Y0NuN3BuREpLdk1oWkZqZFhLdk9LR1FWUzBhWWRsajRBSUdzWHNO?= =?utf-8?B?bytDT0tMVzc2OEpidDhNYUlEeTBNZWZlUnY5cm5HWlV3OXdKQlVSaVF1SnRa?= =?utf-8?Q?DdMni0yJiIvMg=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4355.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8b4c8c53-5a45-4ade-7e6f-08d89c49f23b X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2020 13:54:28.1647 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9TFWGxSiPqUsG5LdahCQOBJUHjtDEWDNt+ZXzRXXNwsTa71PCRX9v2XDEF62u3FZagKE7GTgoQjgkuJ78rAGkA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4070 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [v6ops] Pretty Please? - Disposition of draft-ietf-v6ops-cpe-slaac-renum-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 13:54:34 -0000 SSBhbHNvIGFncmVlIHdpdGggV2FycmVuIHRoYXQgb3B0aW9uIDEgaXMgYmVzdC4NCg0KUmVnYXJk cywNClJvYg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogV2FycmVu IEt1bWFyaSA8d2FycmVuQGt1bWFyaS5uZXQ+DQo+IFNlbnQ6IDA4IERlY2VtYmVyIDIwMjAgMjE6 MTQNCj4gVG86IElQdjYgT3BlcmF0aW9ucyA8djZvcHNAaWV0Zi5vcmc+OyBGZXJuYW5kbyBHb250 DQo+IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+OyBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRv bkBjaXNjby5jb20+DQo+IFN1YmplY3Q6IFByZXR0eSBQbGVhc2U/IC0gRGlzcG9zaXRpb24gb2Yg ZHJhZnQtaWV0Zi12Nm9wcy1jcGUtc2xhYWMtcmVudW0tDQo+IDA1DQo+IA0KPiBbIFN1YmplY3Qg ZWRpdGVkIHRvIHN0YXJ0IG5ldyB0aHJlYWQgXQ0KPiBIZWxsbyBhZ2FpbiBhbGwsDQo+IA0KPiBJ IHN0YXJ0ZWQgdGhpcyB0aHJlYWQgYmFjayBpbiBPY3RvYmVyLCBhbmQgdGhlbiBkaWRuJ3QgcmVh bGx5IGZvbGxvdy11cDsNCj4gc29ycnkuDQo+IA0KPiBUaGlzIGRvY3VtZW50IHdlbnQgdGhyb3Vn aCBXR0xDIGFzIEluZm9ybWF0aW9uYWwsIGJ1dCB1c2VzDQo+ICJwc2V1ZG8tUkZDMjExOSIgbGFu Z3VhZ2UNCj4gKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZv cHMtY3BlLXNsYWFjLXJlbnVtLywNCj4gU2VjdGlvbiAyKS4gVGhpcyBzZWN0aW9uIHNheXMgdGhp bmdzIGxpa2UgKGNyaWJiZWQgZnJvbSBSRkM3MDg0KToNCj4gIiBUYWtlIGNhcmVmdWwgbm90ZTog VW5saWtlIG90aGVyIElFVEYgZG9jdW1lbnRzLCB0aGUga2V5IHdvcmRzICJNVVNUIiwNCj4gICAg Ik1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsICJTSE9VTEQiLCAi U0hPVUxEIE5PVCIsDQo+ICAgICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBp biB0aGlzIGRvY3VtZW50IGFyZSBub3QgdXNlZCBhcw0KPiAgICBkZXNjcmliZWQgaW4gW1JGQzIx MTldLiAgVGhpcyBkb2N1bWVudCB1c2VzIHRoZXNlIGtleXdvcmRzIG5vdA0KPiAgICBzdHJpY3Rs eSBmb3IgdGhlIHB1cnBvc2Ugb2YgaW50ZXJvcGVyYWJpbGl0eSwgYnV0IHJhdGhlciBmb3IgdGhl DQo+ICAgIHB1cnBvc2Ugb2YgZXN0YWJsaXNoaW5nIGluZHVzdHJ5LWNvbW1vbiBiYXNlbGluZSBm dW5jdGlvbmFsaXR5LiAiDQo+IA0KPiBUaGlzIGNhdXNlZCBjb25mdXNpb24gZHVyaW5nIElFU0cg ZXZhbCAtLSB3aGF0IGRvZXMgdGhlIE1VU1QgaW4gIkNFDQo+IHJvdXRlcnMgTVVTVCBzaWduYWwg c3RhbGUgY29uZmlndXJhdGlvbi4uLiIgbWVhbiBpZiBub3QgaW4gdGhlIFJGQzIxMTkNCj4gc2Vu c2U/DQo+IA0KPiBBbHNvLCBtdWNoIG9mIHRoZSBkb2N1bWVudCByZWFkcyBsaWtlIGEgQkNQIC0g QWxpc3NhIHNwZWNpZmljYWxseQ0KPiBjYWxsZWQgdGhpcyBvdXQgaW4gaGVyIERJU0NVU1MsIGJ1 dCB0aGVyZSB3ZXJlIHF1aXRlIGEgZmV3IG90aGVycyB3aG8NCj4gYWdyZWVkLg0KPiANCj4gQXMg YW4gZXhhbXBsZSwgaXMgaXQgbm90IGEgQmVzdCBDdXJyZW50IFByYWN0aWNlIHRoYXQgZS5nOiAi Q0Ugcm91dGVycw0KPiBTSE9VTEQgTk9UIGF1dG9tYXRpY2FsbHkgc2VuZCBESENQdjYtUEQgUkVM RUFTRSBtZXNzYWdlcyB1cG9uIHJlYm9vdA0KPiBldmVudHMuIj8gSWYgbm90LCB3aGF0IGRvZXMg dGhpcyBkb2N1bWVudCBtZWFuIGZvciBhbiBpbXBsZW1lbnRlcj8NCj4gDQo+IA0KPiBUaGVyZSBh cmUgMiBvcHRpb25zIGhlcmU6DQo+IDE6IFdlIGNoYW5nZSBTZWN0aW9uIDIgdG8gdXNlIG5vcm1h bCBSRkMyMTE5L1JGQzgxNzQgbGFuZ3VhZ2UuIEkgc2VuZA0KPiBpdCBiYWNrIHRvIHRoZSBXRyBh bmQgaXQgZ2V0cyBXR0xDZWQgYXMgQkNQLg0KPiANCj4gMjogV2UgcmVtb3ZlIFNlY3Rpb24gMiwg YW5kIGFsbCBvZiB0aGUgdXBwZXJjYXNlL2xvd2VyY2FzZSB3b3Jkcy4gSQ0KPiBzZW5kIGl0IGJh Y2sgdG8gdGhlIFdHIChiZWNhdXNlIG9mIHRoZSBjaGFuZ2VzKSBhbmQgaXQgZ2V0cyBXR0xDZWQg YXMNCj4gSW5mb3JtYXRpb25hbCBhZ2Fpbi4NCj4gDQo+IEkgcmVhbGx5IHByZWZlciBPcHRpb24g MSAtLSB0byBtZSBpdCByZWFkcyBtdWNoIG1vcmUgbGlrZSBhIEJDUCwNCj4gZG9jdW1lbnRpbmcg QmVzdCBDdXJyZW50IFByYWN0aWNlcyBmb3IgQ1BFIGltcGxlbWVudGVycy4NCj4gDQo+IFRoZSBs YXN0IHRpbWUgSSBzZW50IHRoaXMsIHRoZXJlIHdhcyBvbmx5IG9uZSByZXNwb25zZVswXSBhbmQg dGhlbiB0aGUNCj4gdGhyZWFkIGRpZWQgLS0gSSdkIFJFQUxMWSBhcHByZWNpYXRlIGNsZWFyIHJl c3BvbnNlcyBmcm9tIHRoZSBXRyBvbg0KPiB3aGljaCBvcHRpb24gKDEgb3IgMikgeW91IHByZWZl ci4uLg0KPiANCj4gVw0KPiANCj4gWzBdOg0KPiBodHRwczovL21haWxhcmNoaXZlLmlldGYub3Jn L2FyY2gvbXNnL3Y2b3BzL3hWdjRmNzNrQjh0UkZhZzN5SkNCQXJhWHdYay8NCj4gDQo+IA0KPiBP biBUaHUsIE9jdCAyMiwgMjAyMCBhdCAxMTo1MyBBTSBXYXJyZW4gS3VtYXJpIDx3YXJyZW5Aa3Vt YXJpLm5ldD4gd3JvdGU6DQo+ID4NCj4gPiBIaSBhbGwsDQo+ID4NCj4gPiBkcmFmdC1pZXRmLXY2 b3BzLWNwZS1zbGFhYy1yZW51bS0wNSB3YXMgb24gdG9kYXkncyB0ZWxlY2hhdCwgYW5kIHJhbg0K PiA+IGludG8gaXNzdWVzLg0KPiA+DQo+ID4gQWxpc3NhIChiYXNlZCBvbiB0aGUgR2VuIEFSVCBy ZXZpZXcpIGFza2VkIHdoeSB0aGlzIHdhcyBub3QgYSBCQ1AsIGFuZA0KPiA+IHRoZXJlIHdhcyBn ZW5lcmFsIGFncmVlbWVudCB3aXRoaW4gdGhlIElFU0cgdGhhdCBCQ1Agc2VlbXMgbGlrZSBtb3N0 DQo+ID4gcmVhc29uYWJsZSBzdGF0dXMuDQo+ID4gVGhlcmUgd2FzIGFsc28gZGlzY3Vzc2lvbnMg b24gdGhlOg0KPiA+ICJUYWtlIGNhcmVmdWwgbm90ZTogVW5saWtlIG90aGVyIElFVEYgZG9jdW1l bnRzLCB0aGUga2V5IHdvcmRzICJNVVNUIiwNCj4gPiBbLi4uXSAgIk9QVElPTkFMIiBpbiB0aGlz IGRvY3VtZW50IGFyZSBub3QgdXNlZCBhcyBkZXNjcmliZWQgaW4NCj4gW1JGQzIxMTldLiINCj4g PiBhbmQgdGhhdCB0aGlzIHdhcyB2ZXJ5IGNvbmZ1c2luZy4NCj4gPg0KPiA+IEkgcHJvcG9zZWQg dGhhdCB3ZSBjaGFuZ2UgdGhlIHN0YXR1cyB0byBCQ1AsIGFuZCB0aGF0IHRoZSB0ZXJtcyBiZQ0K PiA+IHVzZWQgaW4gdGhlIG5vcm1hbCBtYW5uZXIuDQo+ID4NCj4gPiBJJ2QgbGlrZSB0byBnaXZl IHRoZSBXRyAyIHdlZWtzIHRvIG9iamVjdCB0byB0aGlzIHByb3Bvc2FsLCBhbmQsIGlmDQo+ID4g bm9uZSByZWNlaXZlZCwgc3RhcnQgYW5vdGhlciBJRVRGIExDIGFzIEJDUC4NCj4gPg0KPiA+IFNv LCBwbGVhc2UgbGV0IG1lIGtub3cgKGJ5IE5vdiA1dGgpIGlmIHlvdSBzdHJvbmdseSBvYmplY3Qg dG8gdGhpcw0KPiA+IGJlY29taW5nIGEgQkNQLCBhbmQgdGhlICJub3JtYWwiIFJGQzIxMTkvQkNQ MTQgbWVhbmluZ3MgYmVpbmcgdXNlZCBmb3INCj4gPiB0aGUgcmVjb21tZW5kYXRpb25zICoqaW4g dGhpcyBkb2N1bWVudCoqLg0KPiA+DQo+ID4NCj4gPiBXDQo+ID4NCj4gPiAtLQ0KPiA+IEkgZG9u J3QgdGhpbmsgdGhlIGV4ZWN1dGlvbiBpcyByZWxldmFudCB3aGVuIGl0IHdhcyBvYnZpb3VzbHkg YSBiYWQNCj4gPiBpZGVhIGluIHRoZSBmaXJzdCBwbGFjZS4NCj4gPiBUaGlzIGlzIGxpa2UgcHV0 dGluZyByYWJpZCB3ZWFzZWxzIGluIHlvdXIgcGFudHMsIGFuZCBsYXRlciBleHByZXNzaW5nDQo+ ID4gcmVncmV0IGF0IGhhdmluZyBjaG9zZW4gdGhvc2UgcGFydGljdWxhciByYWJpZCB3ZWFzZWxz IGFuZCB0aGF0IHBhaXINCj4gPiBvZiBwYW50cy4NCj4gPiAgICAtLS1tYWYNCj4gDQo+IA0KPiAN Cj4gLS0NCj4gVGhlIGNvbXB1dGluZyBzY2llbnRpc3TigJlzIG1haW4gY2hhbGxlbmdlIGlzIG5v dCB0byBnZXQgY29uZnVzZWQgYnkgdGhlDQo+IGNvbXBsZXhpdGllcyBvZiBoaXMgb3duIG1ha2lu Zy4NCj4gICAtLSBFLiBXLiBEaWprc3RyYQ0K From nobody Wed Dec 9 13:05:13 2020 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 358D73A1155; Wed, 9 Dec 2020 13:05:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , "Owen DeLong" , , , X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160754791219.31227.17034893730915950183@ietfa.amsl.com> Date: Wed, 09 Dec 2020 13:05:12 -0800 From: IETF Secretariat Archived-At: Subject: [v6ops] Datatracker State Update Notice: X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2020 21:05:12 -0000 IANA action state changed to "No IANA Actions" Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-v6ops-slaac-renum/ From nobody Thu Dec 10 01:15:30 2020 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 D820D3A0B76; Thu, 10 Dec 2020 01:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.307 X-Spam-Level: X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, 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=go6.si header.b=m+JceneM; dkim=pass (1024-bit key) header.d=go6.si header.b=qMU3xSXB 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 S4_l7Jz9pIZJ; Thu, 10 Dec 2020 01:15:22 -0800 (PST) Received: from mailgate.go6lab.si (unknown [IPv6:2001:67c:27e4::18]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 094183A0B75; Thu, 10 Dec 2020 01:15:21 -0800 (PST) Received: from mailgate.go6lab.si (localhost [127.0.0.1]) by mailgate.go6lab.si (Proxmox) with ESMTP id AB59810105E; Thu, 10 Dec 2020 10:15:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=go6.si; h=cc:cc :content-transfer-encoding:content-type:content-type:date:from :from:in-reply-to:message-id:mime-version:references:reply-to :subject:subject:to:to; s=mailgate; bh=rcSwHfyEGA36ktWM0G0ps0bw7 ToTJkXjifeMONAE/U4=; b=m+JceneMkaq/A8qKAWHp2DoVG+ez/0JFbHaWKu2m5 gFbkfYTlVz6GOQ7JR13bVBNeEsw+AJfmFD/BYKpUdQ7uijAfvLa33BCTuz2FYhir 9kzm7tRvmYCjPHp1Yuy2O8jaEP8S8aMCUUcYu3ifHUwZ62W/Lyvn3OinHfEnwxYW JgfukZeyFkiJhieRVR/ZwyU081F7OyJxM1akhDtCHsTqOokPZflc3wzMme+yHD5w AwHIMUxTFUWI3m0O5XXGzpUTvdEfhRodro2HXD0szMHHtUZQwdyItmmdk8GIXnWR lZltUcnDjDEQdcCg0HRaOURSInZ1I4L4wzVzbjQ2+cpbA== Received: from mail.go6.si (mail.go6.si [IPv6:2001:67c:27e4::61]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgate.go6lab.si (Proxmox) with ESMTPS id 91070100088; Thu, 10 Dec 2020 10:15:18 +0100 (CET) Received: from haktar.local (unknown [IPv6:2a00:ee2:e08:1b03:11e2:3659:958e:28e8]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "jan@go6.si", Issuer "Actalis Client Authentication CA G2" (verified OK)) (Authenticated sender: jan) by mail.go6.si (Postfix) with ESMTPSA id 6D3AD20151; Thu, 10 Dec 2020 10:15:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=go6.si; s=mail; t=1607591718; bh=KqI2zN94C4nJQJS1gB3yoiUvH38D6AkTK6XNQWlsQHg=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=qMU3xSXBpQ4oB6bZ1H4l8FPq9zgeUOMhYC/J/JabvqFl+2qE8eOxbgq+UWBNiAsHY YINgtx+t7tfaGCx/okRqC8U1GJ6XO0GAA4BzXRxlVieybeNWOFlT9R7azkUMdN/SDp Sj5zlFn4NHSkgnaavFsJEyNxreulc5ZFBL0v7djw= To: Nick Hilliard Cc: Vasilenko Eduard , "6man@ietf.org" <6man@ietf.org>, IPv6 Operations References: <8f964b8650cd4b619ff47aed5b07bc67@huawei.com> <7ef6cbcc-164f-383c-658b-b3c0df859535@go6.si> <1af87e24-1410-8f89-b50d-9c61694e4644@foobar.org> From: Jan Zorz - Go6 Message-ID: Date: Thu, 10 Dec 2020 10:15:17 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:84.0) Gecko/20100101 Thunderbird/84.0 MIME-Version: 1.0 In-Reply-To: <1af87e24-1410-8f89-b50d-9c61694e4644@foobar.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Flash renumbering X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2020 09:15:25 -0000 On 17/09/2020 10:05, Nick Hilliard wrote: > Jan Zorz - Go6 wrote on 16/09/2020 23:44: >> This problem is so real in deployments where operators decided to go >> with non-persistent IPv6 prefix delegations that we documented it in >> RIPE-690 where we suggest to deploy prefix delegations as >> persistent/static as possible so networks/hosts behind CPEs don't >> suffer from this issue. > > You mean to have the ISPs to provide persistent state so that SLAAC can > handle things better?  Only half joking here :-) What you say - that actually sums it up quite nicely :) "Dear ISP, please make your network topology as static as possible so SLAAC (in current shape and form) doesn't break end-users connectivity in some quite interesting ways..." :) Cheers, Jan From nobody Fri Dec 11 02:58:35 2020 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 7FA793A09F6 for ; Fri, 11 Dec 2020 02:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, 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=swm.pp.se Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFLQf71YOOLc for ; Fri, 11 Dec 2020 02:58:30 -0800 (PST) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2FCB3A09F5 for ; Fri, 11 Dec 2020 02:58:30 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0EB80AF; Fri, 11 Dec 2020 11:58:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1607684307; bh=vMeFxFYglFiOjaZs9PppeUwREQs8ujLfvgYd7oE8yGA=; h=Date:From:To:Subject:From; b=GYWF47trBw8+dm6ZJQdQ8dNFsO9VBQCSpuYg5sfNIYgQ4D575M4KAt+3yomg+TC6F wdpecSwq4+xLCk7OQGKDqbCvm9gA55OEiqwP/380LomttmkG/ip/JBhL/ZtIBpY6Jb ukaxL89EBy3AYBRJLPVDBLX7bQsaeZ9YQZ0LYwWY= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0A2B89F for ; Fri, 11 Dec 2020 11:58:27 +0100 (CET) Date: Fri, 11 Dec 2020 11:58:27 +0100 (CET) From: Mikael Abrahamsson To: v6ops@ietf.org Message-ID: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [v6ops] RFC7217 and flash renumbering and IID change X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2020 10:58:34 -0000 Hi, just wanted to share my experience. My home has a /56 PD from my ISP. For some (unknown to me) reason my home was flash renumbered little over 24 hours ago. I didn't notice, generally everything worked. What made me discover that this happened was when I tried to access something that had a static entry in my /etc/hosts file. This is understandable, and has happened to me before in my 10+ years of running IPv6 in my home. I proceeded to change the first 64 bits of the address in /etc/hosts, and tried again. Still nothing. Investigated further, and then I discovered that the last 64 bits had changed as well. This seems to be because ubuntu 20.04 machines (and others) are using RFC7217 to generate the last 64 bits, and reading RFC7217 in the light of this, it says to generate a unique IID when it "moves". Now, my machine certainly didn't "move" (for some definition of move), its NIC always had link, default gateway was the same etc, but RFC7217 says to generate unique IID per Prefix, so that's what it did. There are HGWs where the firewall allows you to configure rules that take the PIO Prefix first 64 bits and then a static IID, so that if the Prefix changes, the firewall rule but not IID changes, it'll still be correct. With the current behavior of IID change when PIO Prefix changes, above functionality doesn't work. So I guess my question is, how do we want these things to work? What's the guidance we want to give? I'd like people to be able to configure their HGW with firewall rules that keep working across renumbering, so what should these firewall rules be based on? If we augment RFC7217 and say that new IID should not be generated in a flash renumbering event (for instance, if default gw is the same, a new Prefix being announced, keep the IID) that would work. Another way might be to suggest some more advanced logic for the HGW in handling these firewall rules, perhaps based on MAC address or something? However, I don't know how the HGW would figure out what addresses are which from temporary privacy addresses, stable RFC7217 etc. Thoughts? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Fri Dec 11 04:05:49 2020 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 08C603A0B25 for ; Fri, 11 Dec 2020 04:05:48 -0800 (PST) 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 r2_8-yPhxMdL for ; Fri, 11 Dec 2020 04:05:44 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B6D53A0B1F for ; Fri, 11 Dec 2020 04:05:38 -0800 (PST) Received: from [IPv6:2800:810:464:8164:2564:6883:7d0c:efbb] (unknown [IPv6:2800:810:464:8164:2564:6883:7d0c:efbb]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 91A9F283A2F; Fri, 11 Dec 2020 12:05:32 +0000 (UTC) To: Mikael Abrahamsson , v6ops@ietf.org References: From: Fernando Gont Message-ID: <28ec97ca-355b-e4d8-200d-1c14160b51c0@si6networks.com> Date: Fri, 11 Dec 2020 09:05:06 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] RFC7217 and flash renumbering and IID change X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2020 12:05:48 -0000 On 11/12/20 07:58, Mikael Abrahamsson wrote: > > Hi, > > just wanted to share my experience. > > My home has a /56 PD from my ISP. For some (unknown to me) reason my > home was flash renumbered little over 24 hours ago. FWIW, same happens at home, albeit for the /64 I get delegated from my ISP. -- still trying to debug the reason with my ISP. > I didn't notice, > generally everything worked. What made me discover that this happened > was when I tried to access something that had a static entry in my > /etc/hosts file. This is understandable, and has happened to me before > in my 10+ years of running IPv6 in my home. > > I proceeded to change the first 64 bits of the address in /etc/hosts, > and tried again. Still nothing. Investigated further, and then I > discovered that the last 64 bits had changed as well. > > This seems to be because ubuntu 20.04 machines (and others) are using > RFC7217 to generate the last 64 bits, and reading RFC7217 in the light > of this, it says to generate a unique IID when it "moves". Now, my > machine certainly didn't "move" (for some definition of move), its NIC > always had link, default gateway was the same etc, but RFC7217 says to > generate unique IID per Prefix, so that's what it did. If the prefix changed, the your node changed it's location in the network topology. -- note that while the default router didn't change, that could simply be the result of connecting the same router to a different ISP/upstream. So the behavior you got is a feature, indeed. :-) > There are HGWs where the firewall allows you to configure rules that > take the PIO Prefix first 64 bits and then a static IID, so that if the > Prefix changes, the firewall rule but not IID changes, it'll still be > correct. > > With the current behavior of IID change when PIO Prefix changes, above > functionality doesn't work. > > So I guess my question is, how do we want these things to work? What's > the guidance we want to give? I'd like people to be able to configure > their HGW with firewall rules that keep working across renumbering, so > what should these firewall rules be based on? What I'd say is: Any of: 1) Manually configure the address -- e.g., IIRC some systems allow you to use a "token" that will be employed along the prefix. Similar to what you mention for the HGW. (i.e., override RFC7217) 2) Filter based on the MAC address (may or may not be of use depending on the set up) 3) Use something ala UPnP -- although unfortunately many HGWs do not include the relevant support for the IPv6 case. 4) Have the node update its e.g. DNS record, and have the FW build the rules from the domain -> IPv6 addresses Note: I assume that your HGW FW rules are for incoming connections -- since otherwise for outgoing connections you'd run into the same problem due to IPv6 temporary addresses. > If we augment RFC7217 and say that new IID should not be generated in a > flash renumbering event (for instance, if default gw is the same, a new > Prefix being announced, keep the IID) that would work. The problem here is that when a prefix changes, that means the system has moved. Think, e.g. a user that employs a portable 4G router -- the default gw will always be the same, but you certainly want the IID to change as the user travels around. > Another way might be to suggest some more advanced logic for the HGW in > handling these firewall rules, perhaps based on MAC address or > something? Yep, that's one of the possibilities. > However, I don't know how the HGW would figure out what > addresses are which from temporary privacy addresses, stable RFC7217 etc. It certainly can't (both temporary and stable addresses look the same). So it should be the host talking to the firewall and telling what to do with which address. -- with e.g. something like UPnP. Thanks! Regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Dec 11 06:07:27 2020 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 1ED453A0C16 for ; Fri, 11 Dec 2020 06:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NO_DNS_FOR_FROM=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 cGXqWTxy4Uxq for ; Fri, 11 Dec 2020 06:07:24 -0800 (PST) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 EACC13A0C11 for ; Fri, 11 Dec 2020 06:07:23 -0800 (PST) Received: by mail-qt1-x82b.google.com with SMTP id y15so6434150qtv.5 for ; Fri, 11 Dec 2020 06:07:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=u20U+7kmkEMj/roOIUJpTlm1BIC9lNeWHB5oq/13NgU=; b=spljCXKoCJezX1MAFzExM/au5Rrcc1/5qubXHTYcObUxvgFoKhJ7D3MJjEfmSwn+Iz qUmMEAPy/K+eiKFz9CAYYOFEmCOoAtiXV2pD6aQYLbuHppsydlaD92XjGRaAwhLbtuhx j4gsmBuAe10WWJc6/44/XsMdg68TR68uqn0Rgny7eJV9gjPlsLbaTMl043yx9IHCQeNz 9brNiDyVJ5QDQOZAd8lCCL5Ns66K3Fx0Gkr7olOJVr1z+Rd6XdaWUv4gjB+a2EG2FvBV LbgQ6EzjTpIpjzLBqSb1VPawm0RBfeEiqSLvgr99GRby9Ff74NA853JQYMbHRA9ocR8A VzuQ== 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=u20U+7kmkEMj/roOIUJpTlm1BIC9lNeWHB5oq/13NgU=; b=teugRu4FWg/iB4zvipb90STVTGssEh/F3RfbwTqXEYXaEkaBgUcVt89iFOE8zvlWi0 NO6bR+mPMo2lJ7tQqLEXH4PU34JfZdpAQdWRXzKAEKlnItxxu8RQ8aiEUzAw4oN+qiCE w4D4f2ik6So2uqtQfb+7XzI/7Jm2VUtZ+wxv0P2B5qXXgUQ2F0b5CclsIoA4Xf1TAPlj L1nd0bZSiSsExwlsww98CMBTSHxZaTBFrT7rf5rUIc70vxftUn3WhnlDiCePPOtNA6Ua um1xvgj5T1FPuy7kl35pcKF7nR5hNkOtP81a/mI5UJ/DFGeuWmq99tM/VfU0Wqr/s+zU 94CQ== X-Gm-Message-State: AOAM5301Brr9Lzz7FGqKcZsOWmBnqzA0MavopUJgTyvEQ1/JzcJJNoHQ Tpp0kGtX/CHLinBtG+AMA36pLli7PW5oEV5S X-Google-Smtp-Source: ABdhPJyeS5oOhMWWVyZPfTtYhm1S877uc6ScHfv6x4CjqQ5BmoA2v+0b5VnwtlpXeXpGh4ZWgTv07A== X-Received: by 2002:ac8:5ccd:: with SMTP id s13mr15967711qta.87.1607695642424; Fri, 11 Dec 2020 06:07:22 -0800 (PST) Received: from [192.168.1.241] (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id h125sm6810080qkc.36.2020.12.11.06.07.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Dec 2020 06:07:21 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) From: Ted Lemon In-Reply-To: Date: Fri, 11 Dec 2020 09:07:20 -0500 Cc: v6ops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Mikael Abrahamsson X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [v6ops] RFC7217 and flash renumbering and IID change X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2020 14:07:26 -0000 Mikael, it sounds like you want to be able to reliably find devices by = IPv6 address. I think there=E2=80=99s general agreement that this = isn=E2=80=99t a sustainable model. There are a couple of solutions that = may work better than this, that you might consider. 1. Use multicast DNS. If you have an ssh host key, this should work = pretty well. 2. Use DNS Update: track IP address changes in an appropriate way, and = when the IP address changes, do a DNS update. 3. Use Service Registration Protocol. If you=E2=80=99re interested, I = have an SRP client that I think will do the job; what=E2=80=99s nice = about SRP is that once a name has been claimed, as long as the client = continues to renew, the name can=E2=80=99t be taken by a competing = client, as is possible with multicast DNS. I also have an SRP proxy that = will take well-formed SRP updates, validate them, and then use them to = update your DNS server. Works well with BIND, should work with other = name servers that support DNS update. That=E2=80=99s the guidance I would give. > On Dec 11, 2020, at 5:58 AM, Mikael Abrahamsson = wrote: >=20 >=20 > Hi, >=20 > just wanted to share my experience. >=20 > My home has a /56 PD from my ISP. For some (unknown to me) reason my = home was flash renumbered little over 24 hours ago. I didn't notice, = generally everything worked. What made me discover that this happened = was when I tried to access something that had a static entry in my = /etc/hosts file. This is understandable, and has happened to me before = in my 10+ years of running IPv6 in my home. >=20 > I proceeded to change the first 64 bits of the address in /etc/hosts, = and tried again. Still nothing. Investigated further, and then I = discovered that the last 64 bits had changed as well. >=20 > This seems to be because ubuntu 20.04 machines (and others) are using = RFC7217 to generate the last 64 bits, and reading RFC7217 in the light = of this, it says to generate a unique IID when it "moves". Now, my = machine certainly didn't "move" (for some definition of move), its NIC = always had link, default gateway was the same etc, but RFC7217 says to = generate unique IID per Prefix, so that's what it did. >=20 > There are HGWs where the firewall allows you to configure rules that = take the PIO Prefix first 64 bits and then a static IID, so that if the = Prefix changes, the firewall rule but not IID changes, it'll still be = correct. >=20 > With the current behavior of IID change when PIO Prefix changes, above = functionality doesn't work. >=20 > So I guess my question is, how do we want these things to work? What's = the guidance we want to give? I'd like people to be able to configure = their HGW with firewall rules that keep working across renumbering, so = what should these firewall rules be based on? >=20 > If we augment RFC7217 and say that new IID should not be generated in = a flash renumbering event (for instance, if default gw is the same, a = new Prefix being announced, keep the IID) that would work. >=20 > Another way might be to suggest some more advanced logic for the HGW = in handling these firewall rules, perhaps based on MAC address or = something? However, I don't know how the HGW would figure out what = addresses are which from temporary privacy addresses, stable RFC7217 = etc. >=20 > Thoughts? >=20 > --=20 > Mikael Abrahamsson email: swmike@swm.pp.se >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Fri Dec 11 08:08:42 2020 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 DC0C63A0CEB for ; Fri, 11 Dec 2020 08:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 7cAtHGtqQdGy for ; Fri, 11 Dec 2020 08:08:38 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 506423A0CEC for ; Fri, 11 Dec 2020 08:08:35 -0800 (PST) Received: from [IPv6:2800:810:464:8164:2564:6883:7d0c:efbb] (unknown [IPv6:2800:810:464:8164:2564:6883:7d0c:efbb]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id A5FE3280A9E; Fri, 11 Dec 2020 16:08:33 +0000 (UTC) To: IPv6 Operations From: Fernando Gont Message-ID: <5449dd52-6adb-488c-e4bd-58726218bbb4@si6networks.com> Date: Fri, 11 Dec 2020 13:07:04 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] IPv6 Addressing Considerations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2020 16:08:41 -0000 Folks, We have published a new Internet-Draft entitled "IPv6 Addressing Considerations". It is available at: https://www.ietf.org/archive/id/draft-gont-v6ops-ipv6-addressing-considerations-00.txt The Abstract of the I-D is: IPv6 addresses can differ in a number of properties, such as scope, stability, and intended usage type. This document analyzes the impact of these properties on aspects such as security, privacy, interoperability, and network operations. Additionally, it identifies challenges and gaps that currently prevent systems and applications from leveraging the increased flexibility and availability of IPv6 addresses. We have discussed this topic with some of you off-list, and part of those comments still need to be incorporated (apologies for the delay!). However, we felt that this -00 version already contains quite a bit of material for discussion. (and given that there have been other recent threads related to IPv6 addressing on this list and on 6man@, we felt it would be timely to get this -00 version posted now). Your comments will be very welcome. Thanks! Regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Dec 11 09:17:56 2020 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 770943A0D21 for ; Fri, 11 Dec 2020 09:17:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=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=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6d5dhe-TPJeo for ; Fri, 11 Dec 2020 09:17:51 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::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 57B5A3A0D32 for ; Fri, 11 Dec 2020 09:17:50 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id m13so11720231ljo.11 for ; Fri, 11 Dec 2020 09:17:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=oD2kOg1JDZSDE6mNRB9tT/6g87azSwcM7BbbUJzJLEw=; b=Ze1euAbKFxSSwyxL4IL9PuwyulaS1CoM8O5CjWIaCnvaSgC65yfX5pk4DGHEwkumrC ecoevSd8zgaL/V79sqoFiVuLd56+vY6bANFN325BYH0iL8kQWksWTCxXYTvjXvKQrR8X Ued/v3Qan0d7wEOSx+dRODvP+E6a0NY55YDeCmRXefx5/lm2h2YKFprt62Z5DkSYCgC6 24lkF4ywQW6iGMleZCQd0hd9zcGNH79PpZ0xHoa6dGPujJpn6qKOZeSnqrbFJSagb2Jj 540odaxr14e3Ou5RbHCXG/BwWUoaaeoc/anZsXHINw+kDYBL6JJXUWqNM7uw1vjspTar 9Xhw== 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=oD2kOg1JDZSDE6mNRB9tT/6g87azSwcM7BbbUJzJLEw=; b=WDJjvvDmdB8wSudEnXiyXMYnsZdTtokI+/4N9435rv8MQdtZ6bjXwYpRKmNFbw732Q d1s7Reh3tUy8oPDG7oruNUMsq7Kta4RhRJU8JMRziaUfx8qywXDE3EWWC+Qoag+ojOv5 zaPKvelWzSZYYVnIViH7k5S8oQBIXJrKTvPgAlbjoNuCFEtY71vVgxLZfMvwU4fpCmiz YBB5PNF/BucZfnKmxBlEFhVfSRRviD5KJq6TgpZ9V55RcUQqW3pDdtFUJPMMvOdkm5sm xTMXE55xBkldyuLh78x4DBj3ah/c0BuIZLTp72rTcJxjmHeLJpm1SwEp3wC7h4enuxRn 3z4Q== X-Gm-Message-State: AOAM531rCAVPcPRGiwuvKhl1okW9/bECRG0i6Gkeb8rs4Rs7HrYFuysX 1OYNj+l9YJvSVSMj2YvXINslr+EOB3+N5F47Lq9L08c9r13smijn X-Google-Smtp-Source: ABdhPJxHc5soOjdjdwprNMz0bUBqowB30h2Hi/aS9Xc48fNYIE43yHKUUVnbYLWZOJbyC1t2CXJEZ6WIww9X+WYh78E= X-Received: by 2002:a05:651c:1214:: with SMTP id i20mr5428638lja.324.1607707065771; Fri, 11 Dec 2020 09:17:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Warren Kumari Date: Fri, 11 Dec 2020 12:17:08 -0500 Message-ID: To: "Rob Wilton (rwilton)" Cc: IPv6 Operations , Fernando Gont Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Pretty Please? - Disposition of draft-ietf-v6ops-cpe-slaac-renum-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2020 17:17:55 -0000 [ Top post ] Awesome, thank you everyone. I'm returning this document to the V6OPS WG, and requesting that it be updated with: 1: The "normal" RFC2119/RFC8174 language 2: The track to be BCP Hopefully it can be WGLCed soon, and that the comments are restricted to just those needed for the above changes. Once the WG sends it back to me I'll do another IETF LC (required because of the track change). Thank you everyone, and sorry for the process wonkey -- changing status "up" is harder than changing "down" :-) W On Wed, Dec 9, 2020 at 8:54 AM Rob Wilton (rwilton) wro= te: > > I also agree with Warren that option 1 is best. > > Regards, > Rob > > > > -----Original Message----- > > From: Warren Kumari > > Sent: 08 December 2020 21:14 > > To: IPv6 Operations ; Fernando Gont > > ; Rob Wilton (rwilton) > > Subject: Pretty Please? - Disposition of draft-ietf-v6ops-cpe-slaac-ren= um- > > 05 > > > > [ Subject edited to start new thread ] > > Hello again all, > > > > I started this thread back in October, and then didn't really follow-up= ; > > sorry. > > > > This document went through WGLC as Informational, but uses > > "pseudo-RFC2119" language > > (https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/, > > Section 2). This section says things like (cribbed from RFC7084): > > " Take careful note: Unlike other IETF documents, the key words "MUST", > > "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT"= , > > "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used a= s > > described in [RFC2119]. This document uses these keywords not > > strictly for the purpose of interoperability, but rather for the > > purpose of establishing industry-common baseline functionality. " > > > > This caused confusion during IESG eval -- what does the MUST in "CE > > routers MUST signal stale configuration..." mean if not in the RFC2119 > > sense? > > > > Also, much of the document reads like a BCP - Alissa specifically > > called this out in her DISCUSS, but there were quite a few others who > > agreed. > > > > As an example, is it not a Best Current Practice that e.g: "CE routers > > SHOULD NOT automatically send DHCPv6-PD RELEASE messages upon reboot > > events."? If not, what does this document mean for an implementer? > > > > > > There are 2 options here: > > 1: We change Section 2 to use normal RFC2119/RFC8174 language. I send > > it back to the WG and it gets WGLCed as BCP. > > > > 2: We remove Section 2, and all of the uppercase/lowercase words. I > > send it back to the WG (because of the changes) and it gets WGLCed as > > Informational again. > > > > I really prefer Option 1 -- to me it reads much more like a BCP, > > documenting Best Current Practices for CPE implementers. > > > > The last time I sent this, there was only one response[0] and then the > > thread died -- I'd REALLY appreciate clear responses from the WG on > > which option (1 or 2) you prefer... > > > > W > > > > [0]: > > https://mailarchive.ietf.org/arch/msg/v6ops/xVv4f73kB8tRFag3yJCBAraXwXk= / > > > > > > On Thu, Oct 22, 2020 at 11:53 AM Warren Kumari wrot= e: > > > > > > Hi all, > > > > > > draft-ietf-v6ops-cpe-slaac-renum-05 was on today's telechat, and ran > > > into issues. > > > > > > Alissa (based on the Gen ART review) asked why this was not a BCP, an= d > > > there was general agreement within the IESG that BCP seems like most > > > reasonable status. > > > There was also discussions on the: > > > "Take careful note: Unlike other IETF documents, the key words "MUST"= , > > > [...] "OPTIONAL" in this document are not used as described in > > [RFC2119]." > > > and that this was very confusing. > > > > > > I proposed that we change the status to BCP, and that the terms be > > > used in the normal manner. > > > > > > I'd like to give the WG 2 weeks to object to this proposal, and, if > > > none received, start another IETF LC as BCP. > > > > > > So, please let me know (by Nov 5th) if you strongly object to this > > > becoming a BCP, and the "normal" RFC2119/BCP14 meanings being used fo= r > > > the recommendations **in this document**. > > > > > > > > > W > > > > > > -- > > > I don't think the execution is relevant when it was obviously a bad > > > idea in the first place. > > > This is like putting rabid weasels in your pants, and later expressin= g > > > regret at having chosen those particular rabid weasels and that pair > > > of pants. > > > ---maf > > > > > > > > -- > > The computing scientist=E2=80=99s main challenge is not to get confused= by the > > complexities of his own making. > > -- E. W. Dijkstra --=20 The computing scientist=E2=80=99s main challenge is not to get confused by = the complexities of his own making. -- E. W. Dijkstra From nobody Fri Dec 11 09:53:58 2020 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 338B73A0D40; Fri, 11 Dec 2020 09:53:53 -0800 (PST) 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: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <160770923315.24958.12394835085945420116@ietfa.amsl.com> Date: Fri, 11 Dec 2020 09:53:53 -0800 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-cpe-slaac-renum-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2020 17:53:53 -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 : Improving the Reaction of Customer Edge Routers to Renumbering Events Authors : Fernando Gont Jan Zorz Richard Patterson Bernie Volz Filename : draft-ietf-v6ops-cpe-slaac-renum-06.txt Pages : 11 Date : 2020-12-11 Abstract: In scenarios where network configuration information becomes invalid without any explicit signaling of that condition (such as when a Customer Edge Router crashes and reboots without knowledge of the previously-employed configuration information), hosts on the local network will continue using stale network configuration information for an unacceptably long period of time, thus resulting in connectivity problems. This document specifies improvements to Customer Edge Routers that help mitigate the aforementioned problem for typical residential and small office scenarios. This document updates RFC7084. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-v6ops-cpe-slaac-renum-06 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-cpe-slaac-renum-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-cpe-slaac-renum-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 Dec 11 09:57:03 2020 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 0D7E73A0D66 for ; Fri, 11 Dec 2020 09:57:02 -0800 (PST) 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 N8jR2o0-wlTu for ; Fri, 11 Dec 2020 09:57:00 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC8243A0D64 for ; Fri, 11 Dec 2020 09:56:59 -0800 (PST) Received: from [IPv6:2800:810:464:8164:2564:6883:7d0c:efbb] (unknown [IPv6:2800:810:464:8164:2564:6883:7d0c:efbb]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 06203283D05; Fri, 11 Dec 2020 17:56:56 +0000 (UTC) To: Warren Kumari , "Rob Wilton (rwilton)" Cc: IPv6 Operations References: From: Fernando Gont Message-ID: Date: Fri, 11 Dec 2020 14:54:45 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Pretty Please? - Disposition of draft-ietf-v6ops-cpe-slaac-renum-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2020 17:57:02 -0000 Hi, Warren, On 11/12/20 14:17, Warren Kumari wrote: > [ Top post ] > > > Awesome, thank you everyone. > > I'm returning this document to the V6OPS WG, and requesting that it be > updated with: > 1: The "normal" RFC2119/RFC8174 language > 2: The track to be BCP Done. Thanks a lot! Regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Dec 13 11:53:11 2020 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 38E013A0755 for ; Sun, 13 Dec 2020 11:53:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=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 IyO0Jfms-6xX for ; Sun, 13 Dec 2020 11:53:08 -0800 (PST) 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 5058F3A074E for ; Sun, 13 Dec 2020 11:53:07 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.137.104] (unknown [192.168.137.104]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id C389A64028 for ; Sun, 13 Dec 2020 19:53:02 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Simon Hobson In-Reply-To: <28ec97ca-355b-e4d8-200d-1c14160b51c0@si6networks.com> Date: Sun, 13 Dec 2020 19:53:01 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <4AC2A13C-9FE6-4D2C-B14C-D1DCC3169700@thehobsons.co.uk> References: <28ec97ca-355b-e4d8-200d-1c14160b51c0@si6networks.com> To: IPv6 Operations X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [v6ops] RFC7217 and flash renumbering and IID change X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Dec 2020 19:53:10 -0000 Fernando Gont wrote: > So it should be the host talking to the firewall and telling what to = do with which address. -- with e.g. something like UPnP. So we're back to each host deciding on the security policy for the = network - not a network admin (as a proxy for the owners of the = site/network). I make a point of disabling upnp as one of the first steps when setting = up a network. Who wants ${random device which may or may not be = "friendly"} to be able to determine what traffic is allowed into the = network - it's not like there is anyone out there in the wild west of = the internet who'd have any hostile intent :-/ Simon From nobody Sun Dec 13 21:33:13 2020 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 28C323A03F2 for ; Sun, 13 Dec 2020 21:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 ICGqgdAnmyz8 for ; Sun, 13 Dec 2020 21:33:10 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E8523A03EF for ; Sun, 13 Dec 2020 21:33:07 -0800 (PST) Received: from [IPv6:2800:810:464:8164:e9e5:9ed3:2e64:7aa8] (unknown [IPv6:2800:810:464:8164:e9e5:9ed3:2e64:7aa8]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 33A4C284692; Mon, 14 Dec 2020 05:33:02 +0000 (UTC) To: Simon Hobson , IPv6 Operations References: <28ec97ca-355b-e4d8-200d-1c14160b51c0@si6networks.com> <4AC2A13C-9FE6-4D2C-B14C-D1DCC3169700@thehobsons.co.uk> From: Fernando Gont Message-ID: Date: Mon, 14 Dec 2020 01:32:43 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <4AC2A13C-9FE6-4D2C-B14C-D1DCC3169700@thehobsons.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] RFC7217 and flash renumbering and IID change X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2020 05:33:13 -0000 Hi, Simon, On 13/12/20 16:53, Simon Hobson wrote: > Fernando Gont wrote: > >> So it should be the host talking to the firewall and telling what to do with which address. -- with e.g. something like UPnP. > > So we're back to each host deciding on the security policy for the network - not a network admin (as a proxy for the owners of the site/network). For the home scenarios case, we're not "back", because we never went away from there. The number of people manually configuring home firewalls is not statistically significant. OTOH, if you want to manually configure rules based on addresses that are not guaranteed to remain stable... you know what you are going to get. In such scenarios, you probably should use RADIUS or something else. > I make a point of disabling upnp as one of the first steps when setting up a network. Who wants ${random device which may or may not be "friendly"} to be able to determine what traffic is allowed into the network - it's not like there is anyone out there in the wild west of the internet who'd have any hostile intent :-/ Who wants a network with a random device? :-) If the device is evil enough to use UPnP to open wholes in the FW, it could also be evil to act as a proxy and tunnel everything into the internal network. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Dec 14 02:44:25 2020 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 5B7EB3A0F46 for ; Mon, 14 Dec 2020 02:44:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.177 X-Spam-Level: *** X-Spam-Status: No, score=3.177 tagged_above=-999 required=5 tests=[DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.972] 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 gkYIAh9HiJ6T for ; Mon, 14 Dec 2020 02:44:21 -0800 (PST) Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 714483A0F3D for ; Mon, 14 Dec 2020 02:44:21 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0BEAiJkZ030642 for ; Mon, 14 Dec 2020 11:44:19 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 5505B20EA18 for ; Mon, 14 Dec 2020 11:44:19 +0100 (CET) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 41FA120E97B for ; Mon, 14 Dec 2020 11:44:19 +0100 (CET) Received: from [10.14.7.103] ([10.14.7.103]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 0BEAiITJ019115 for ; Mon, 14 Dec 2020 11:44:19 +0100 To: "v6ops@ietf.org" From: Alexandre Petrescu Message-ID: <80f9817e-93c1-5bab-d9e6-0bb6bc95253b@gmail.com> Date: Mon, 14 Dec 2020 11:44:18 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 7bit Archived-At: Subject: [v6ops] Observation of /64s of cellular operators X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Dec 2020 10:44:23 -0000 In the place where I live, a majority of the main cellular operators offer a /64 to the User Equipment. This is public data. There is some exception (operator Free) but the exception is not about delivering a shorter or longer prefix to the smartphone; the exception is about delivering or not delivering IPv6 connectivity to smartphone. Once it is delivered, I suspect it will also be /64. In other places, e.g. Reliance JIO operator in Asia, also the length is /64. This situation (only a /64 per User Equipment) creates problems for vehicular networks that I work with. Alex From nobody Wed Dec 16 12:53:24 2020 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 265303A1051 for ; Wed, 16 Dec 2020 12:53:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=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=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 amc9sqSILSEh for ; Wed, 16 Dec 2020 12:53:17 -0800 (PST) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 B08603A1065 for ; Wed, 16 Dec 2020 12:53:17 -0800 (PST) Received: by mail-pl1-x633.google.com with SMTP id x18so7530234pln.6 for ; Wed, 16 Dec 2020 12:53:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:in-reply-to :date:cc:message-id:references:to; bh=X+U8x3It34IYNgENa4LgBgNKCpSdjL82VGx2SHTd5aY=; b=C4pJmqQHBAPcdye4v69yYJ18Lwi+Wzr+TYTgZz5VCt/lM2Zt7kI6eoJv4LzmvQS6RI k2OhgnUTkk2eVmnZBWpfkddfwSEidhZqJ0IDfZfJT3MdlCNiVXp5B+omvxU9tIEclR6a g+cHVh/YqKpUYgVIJ8satgiC30GBom+mDeP86BVvKp/0HSFaRnmsW2F6OFXD7beWd9Sq fFm1bxxdz2dHgRRbvhJbAokAiutzZZPKDCoq6O33ewfZ5HjINL+mJyqqG04KA2HSXHCw sqLPxir4aURYC4wgIFVNHXA7iwCyE5tmPMMBSf3we9DEUz0rAJOhEVl0202pOSRQHZ+7 qZHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:in-reply-to:date:cc:message-id:references:to; bh=X+U8x3It34IYNgENa4LgBgNKCpSdjL82VGx2SHTd5aY=; b=hvlFt2kh2yLpjI+k8l/VrcLSXhQM1vpTYlcdlaHydUu3uID+0HmGgw4IJDT41faRit FMhbgCzIpImvhn1L/80TbCTP2rOT7wAg2ciZQ1ikRF74YuKRJXua27pyRk2nobAC5S7u L0uBTIACwwSf2CQnxmuBUpjVbh4heNCf8De9NICtODXs2r00qoy5QZv50EWMoBrh5bR1 nY8uZVWnwnC/rNioCrsAy2jMNls/eXWqyi1uQSqxhPG5GnSYVYBCkKI2uFlPlONQ9Cv3 LBc+gY8M/e4B1aWXD5cpr0UmS0Z9Ij70y4p6TS5y3ogcNydWEKw1IJtp7QazVAJMT9gG C7tA== X-Gm-Message-State: AOAM530Pms1KcmBcu1p/9/nzMqymzyCXbeKzi5PgECftooYjKyAn68WD RioWDKD1lCgA9K7Vlrs4ZuY= X-Google-Smtp-Source: ABdhPJwan6CBuv1Zb/VWLMStwxOBgKVpxZ0UPxiudZkzQv/41NBipuGLuKaoLM6DStzeURY8ObGNqg== X-Received: by 2002:a17:902:b943:b029:dc:6bd:5562 with SMTP id h3-20020a170902b943b02900dc06bd5562mr11426122pls.59.1608151997085; Wed, 16 Dec 2020 12:53:17 -0800 (PST) Received: from ?IPv6:2600:8802:5800:567::1007? ([2600:8802:5800:567::1007]) by smtp.gmail.com with ESMTPSA id g7sm2813479pjm.46.2020.12.16.12.53.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Dec 2020 12:53:16 -0800 (PST) From: Fred Baker X-Google-Original-From: Fred Baker Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) In-Reply-To: Date: Wed, 16 Dec 2020 12:53:15 -0800 Cc: IPv6 Operations Message-Id: <8BFD9F23-624A-4FA0-B23D-C19FE076CC9B@gmail.com> References: To: Ron Bonica , Fernando Gont X-Mailer: iPhone Mail (18C66) Archived-At: Subject: Re: [v6ops] Disposition of draft-ietf-v6ops-cpe-slaac-renum-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2020 20:53:22 -0000 Fernando: please update as requested. Ron: when he posts it, we can inform the working group of the changes and ru= n a one week WGLC. Let=E2=80=99s either finish no later than 23 December, or= start just after New Year=E2=80=99s. Asking folks to be =E2=80=9Con=E2=80=9D= during holidays doesn=E2=80=99t work. Sent using a machine that autocorrects in interesting ways... > On Dec 16, 2020, at 10:19 AM, Ron Bonica wrote: >=20 > =EF=BB=BFFernando, >=20 > How do you want to deal with Ole's objection ? Informational or BCP? >=20 > Also, Warren has already left for vacation. So, this draft probably won't p= rogress until after the holiday. >=20 > Ron >=20 >=20 >=20 >=20 > Juniper Business Use Only >=20 >> -----Original Message----- >> From: Warren Kumari >> Sent: Monday, December 7, 2020 2:38 PM >> To: Fred Baker >> Cc: Fernando Gont ; draft-ietf-v6ops-cpe-slaac- >> renum.all@ietf.org; Ron Bonica >> Subject: Re: Disposition of draft-ietf-v6ops-cpe-slaac-renum-05 >>=20 >> [External Email. Be cautious of content] >>=20 >>=20 >>> On Sun, Dec 6, 2020 at 7:34 PM Fred Baker >>> wrote: >>>=20 >>> My understanding is that it has been submitted to the IESG and >>> discussed, with four =E2=80=9CDISCUSS=E2=80=9D Ballots as a result. I as= sume that your >>> October update resolved the issues, but I haven=E2=80=99t seen any of th= e four >>> ADs agree that they did. So - >>>=20 >>> Warren, could you ask the IESG what the current state is? I believe that= if the >> ballots have been satisfactorily addressed, the ball is in the IESG=E2=80= =99s court. They >> should either pass it to the RFC Editor or tells us why they have not. >>=20 >> Actually, I've been trying to reach Fernando via chat methods >> (hangouts) for a few days to chat about it. >>=20 >> IIRC, Ole objected fairly strongly to the "just keep the RFC2119 language= and >> make it BCP", and there wasn't a good show of support. >>=20 >> On Nov 2nd I said: >> "Thank you Fred for asking for clarification -- I suspect that, seeing as= >> objections were raised (and based on the comments on the telechat) I'm go= ing >> to have to send it to the WG to: >> 1: just call consensus that BCP is fine, and Ole is in the rough or >> 2: agree that Informational is fine, and remove the MUST/SHOULD and >> "similar to RFC2119" bit." >>=20 >> I had thought that I had actually returned the document to the WG, but >> apparently not... >>=20 >>=20 >> Fernando/authors -- I believe that the easiest is to just take option >> 2 (which I think you said that y'all were OK with?) -- I believe that th= is will >> address the main stickiness (track / modified use of 2119 terms). Do you >> believe that you have addressed all of the other comments? Should I start= >> threads with each of the DISCUSS holders to confirm 1: that option 2 will= >> address their concerns and 2: that they are OK with the other changes. >>=20 >>=20 >> W >>=20 >>>=20 >>> Sent from my iPad >>>=20 >>>> On Dec 5, 2020, at 8:18 PM, Fernando Gont >> wrote: >>>>=20 >>>> Question: What's the status of this one? And, what are the next steps t= o >> progress it? >>=20 >>=20 >>=20 >> -- >> The computing scientist=E2=80=99s main challenge is not to get confused b= y the >> complexities of his own making. >> -- E. W. Dijkstra From nobody Wed Dec 16 15:45:39 2020 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 242493A12E8 for ; Wed, 16 Dec 2020 15:45:38 -0800 (PST) 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 rtkF0dEO4TNL for ; Wed, 16 Dec 2020 15:45:35 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B897B3A094E for ; Wed, 16 Dec 2020 15:45:21 -0800 (PST) Received: from [10.0.0.129] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 3BD8E283C88; Wed, 16 Dec 2020 23:45:16 +0000 (UTC) To: Fred Baker , Ron Bonica Cc: IPv6 Operations References: <8BFD9F23-624A-4FA0-B23D-C19FE076CC9B@gmail.com> From: Fernando Gont Message-ID: <4152be4d-f0a5-57e9-68da-04de15aba7a3@si6networks.com> Date: Wed, 16 Dec 2020 20:44:46 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <8BFD9F23-624A-4FA0-B23D-C19FE076CC9B@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] Disposition of draft-ietf-v6ops-cpe-slaac-renum-05 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2020 23:45:38 -0000 Hi, Fred, On 16/12/20 17:53, Fred Baker wrote: > Fernando: please update as requested. > > Ron: when he posts it, we can inform the working group of the changes > and run a one week WGLC. Let’s either finish no later than 23 > December, or start just after New Year’s. Asking folks to be “on” > during holidays doesn’t work. I've already revised and posted the I-D. The latest rev incorporates the changes requested by Warren, and should be ready for WGLC. Thanks! Regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Dec 17 10:10:18 2020 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 A98043A0E61 for ; Thu, 17 Dec 2020 10:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=juniper.net header.b=ndFZODVK; dkim=pass (1024-bit key) header.d=juniper.net header.b=AfY3UQvq 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 C7VoQs9Bx31v for ; Thu, 17 Dec 2020 10:10:14 -0800 (PST) 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 B62183A0E60 for ; Thu, 17 Dec 2020 10:10:14 -0800 (PST) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0BHIAAwt011373 for ; Thu, 17 Dec 2020 10:10:13 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=Et+glyMN+TnuJrg6HJn8/Vl0dwXurM9o2xspw44VsvI=; b=ndFZODVKX8YPhK+Xrrv6qkSSQnCxlWeVlT+KyseRM/yh8gfzULgHZ72DxPgWRqfMKqRz gi43UtrvTrtbsyed/7KeFyc/4rF0hhN41iBSoreO+dls/JIDZ4je4vjJVXGuoKKKQYJF 9yfvLJMA6C8CW+v7B1R/hJsclZc4jTbITyPUQkX6F4MYvrbKV//4HrP06cnHJNZwQB3h NuQVoZSuq0mZye7O2QDauXR1FdeQ/sg/Rmrn5Tv2kIumDy2WsdqXcZ4jRzndcmRU1tTd AjN85Yah5eBvCDit3H+vZt6NFNPkqn/pfz/0f4EFPgjrVCz+Y/+Xt9pwmUkjPNA/yXsd WQ== Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2100.outbound.protection.outlook.com [104.47.55.100]) by mx0b-00273201.pphosted.com with ESMTP id 35fqtn1yu7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 17 Dec 2020 10:10:13 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jm//GyonJ+A3I+Dubot7RrAtuhJ9WSyH9pQMqFhXK9vQL3IBkA38xEQGjYr5seH+BqpUfTVnEcmUQvnwdOHVqZ3whX+SJpLyOAubDfwUpkllGrx8jqBHw/gi08uI1jrHQHZKd5ID88voG98wS2Rzl96cDk+iPM969clLjC/+hxL2p8xKlz2jplEUQre4Jll21ubWLP+8dEl/3yeZJyW9UJDYiddn3pbS+4SV2KbeIUWs5qG32GIqX/rvgM70EnF9hzrv2xombfbKDwkdtOLee9bFJEL0b5aTH0RlU3pm2E+mdBkAnmMCzTvxHb9yqH9Xr6GfDzPhg1ewEop/WgRvPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Et+glyMN+TnuJrg6HJn8/Vl0dwXurM9o2xspw44VsvI=; b=U7fcWQPhXgZb+aePz10AVevw55EuxmOwRPmygnQidgCt2a+2W2JOWlIzUPwmKB1puPLB4lac+fz0c2z3mTVjo/TWZdds84z6+QKQF6OIVWVEwP5dZXB91fThQJxFQhHynDx8KbwmKVs2sTilujIP3nBvTi8rxEkHlopR3svcqfhNi+Vw1jsPTXvsB4+NzBRul2ZZBtm8LwW4IiRb/FAHPvL7iZKIsQ17KWA9r0gqlTuQ7+LA/qzumveEhxR/1HijSDaf3w7B2vZqt1cd3AY6U68Abhc2wnjxGBnOpsmG90Nre66uoLjDLE5OCRVs/dH3aYJRdyhu0h468EG0X5Xw6Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Et+glyMN+TnuJrg6HJn8/Vl0dwXurM9o2xspw44VsvI=; b=AfY3UQvqfK0iblPkBWaecKsS5QqxYKnSjDd6R+dT7Z/uiXqIqjzawoexTSVZWKD7i6HPQojc95DV9uWRUf7p8tePwoY8i78u26qRkqi+FbaG4aIn0p52ZZ13bpeIlCYhFs5E9g5/MmYhUck7b+L8fZjd4yY/1VNVC5R0JfMM8ow= Received: from DM6PR05MB6348.namprd05.prod.outlook.com (2603:10b6:5:122::15) by DM5PR05MB2907.namprd05.prod.outlook.com (2603:10b6:3:59::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3676.11; Thu, 17 Dec 2020 18:10:11 +0000 Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::a435:88ed:7e2a:4fe6]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::a435:88ed:7e2a:4fe6%5]) with mapi id 15.20.3676.013; Thu, 17 Dec 2020 18:10:11 +0000 From: Ron Bonica To: "v6ops@ietf.org" Thread-Topic: WGLC draft-ietf-v6ops-cpe-slaac-renum Thread-Index: AdbUn4KQzD3Awd89TBKR+ahShiehyg== Date: Thu, 17 Dec 2020 18:10:11 +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.5.0.60 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-12-17T18:10:10Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=0bd23c93-d0f0-4d08-90f8-789a85516750; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [173.79.115.7] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: a4a1032a-c108-46e4-ce29-08d8a2b6fecb x-ms-traffictypediagnostic: DM5PR05MB2907: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Zq0+JllyadEqfEEExST3S9sVXeekQZn8JIXn6zJrUTtIg0EwB2o9st+fYr60ce6BhrhZEVye4fBZ9DeDEKOEyxf3g3L2JWZcf/XJGLjmRznaWRoVNNozTpoG4hy6PgQNCcisYVjYJPfSJEZY/P+kdtlvRi7Q3Q24OPrHOrQR4bRwNJkPprTSwgQ9iMrVLxKOizhyMx9VevFxzCo9D+5jLsxQh3pjLWA7+Foha4sVWFuI7p7Lh+CRKkY2i3HHEU5SF3+cQvn+LXfHAaWPmUjmqsM0GbDYW8Fkv9cWezlkCwz/6TU+gn1ZaZvuyepFJMev0CwdrzqPD6VhpFLIVQ2Ry4+jtkIB9XOLi/uqZLYkg3LrywNC94YILSmYcgVIf1ipcYa08ZG9MDQZ6PnJpBJ/xw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6348.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(376002)(136003)(396003)(39860400002)(366004)(55016002)(52536014)(7696005)(64756008)(66446008)(86362001)(66946007)(9686003)(76116006)(8676002)(316002)(66476007)(186003)(478600001)(71200400001)(6506007)(66556008)(2906002)(26005)(558084003)(33656002)(83380400001)(8936002)(6916009)(5660300002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?VcHP1jZMUAGW7RVHpeYET4WZySFDZxk6XoRR+UqgjpVEB01TFjCbQKbHqE1b?= =?us-ascii?Q?ZJW4NH1hHKbm7sEIHBob3BBhXP/aSLsvFT1kvfB6+BatJ0aJS1dysFPsK2P5?= =?us-ascii?Q?X89E+ShSYBoKDup84b5ZGmB6uGb4Gj/j5z1GaOItJb06M3AiY6+IruRUJigc?= =?us-ascii?Q?qMK+T9wr2j9ze1DLM6KAsufjKpFLMidk9YrzlAo2E5dxcG3Q8CCaqdWcjV77?= =?us-ascii?Q?/3l4mZTixQdaXVCVKrFhHqqxdr4VBx6seKaWeC067SQ2OVSApQvkHVCkdVCN?= =?us-ascii?Q?l9/DardoXIz4wSkDJw91pU+Ep/mKDq/NU56gqCaOzsd6/SrDY5vVp0c/axJE?= =?us-ascii?Q?jABIEPExBmtvKetmx0MyzjrhyuMZsNjIXIoxctoXFLvNGCVUSKGqDPX2iJm8?= =?us-ascii?Q?+xXtpLQv0cVI4fNDu90j3CNv9a/+B6gF5lGuFGauDr16IC/tcuLNo3fgJUCt?= =?us-ascii?Q?xAN33vRT3xzz91mdbdkkYkVXmp3QQ07kbX9UXC3jret1z95SopBJcqI91fXr?= =?us-ascii?Q?b72wODBzYbSFqVCRbSZ/hJhwFt/Q1bZu2jM2947McUczNayjhsWRTdIrskq5?= =?us-ascii?Q?+j5orJBxUBJpxoGFAT5o9nfKQFk/A4GRdf92rwXfufUt+8jjHxcg44cbc8mu?= =?us-ascii?Q?AkrsSgK9gR/oHdI3xKkcvGu8RKVI4kZLiyZH/E3H820Gp6JXy+mddbvlvRHF?= =?us-ascii?Q?vTGGF9YsJUu7ETek0GM4GyGAi/5LjTWxsE1vjlUKWyvI/uHn5dbpkcSwSTxT?= =?us-ascii?Q?GYa1/1LL2qj/7Ep6VEGPeH9KHxUCP4xhPm4vyaihiSxlKqtzzjWdNHJ9o4dS?= =?us-ascii?Q?VzvmMx/o6Fn9CgMIcLaufpJ6aIXEu6mbtaOapIcsETJDujCPlJzKXBZpDJuh?= =?us-ascii?Q?zWo7TKJDEykMlLIwNbIhzvKg6UJxedO9uyvIIY5pphQ9AamqkZi7DtrITR5U?= =?us-ascii?Q?h52uI61eNuKnVn26XV/ilXHpOkvrcbWzvynoI9KXTV4=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR05MB6348DE2A16F4E365BD7B976EAEC40DM6PR05MB6348namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR05MB6348.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a4a1032a-c108-46e4-ce29-08d8a2b6fecb X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2020 18:10:11.5122 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: l/JQxPV/uJxtLVUfd0V4NeNNkvcxmCWFDf+bYTpm6rB9odzVL4B7ivkUxpySrgoYzPI681JyCWDUPF+UL75bfQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB2907 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-17_13:2020-12-15, 2020-12-17 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 adultscore=0 clxscore=1015 priorityscore=1501 mlxscore=0 lowpriorityscore=0 malwarescore=0 spamscore=0 bulkscore=0 suspectscore=0 phishscore=0 impostorscore=0 mlxlogscore=494 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012170125 Archived-At: Subject: [v6ops] WGLC draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 18:10:17 -0000 --_000_DM6PR05MB6348DE2A16F4E365BD7B976EAEC40DM6PR05MB6348namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, This email begins a one week last call on draft-ietf-v6ops-cpe-slaac-renum.= The scope of this last call is limited to text that has changed since the = document was sent to the IESG. = Ron Juniper Business Use Only --_000_DM6PR05MB6348DE2A16F4E365BD7B976EAEC40DM6PR05MB6348namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

This email begins a one week last call on draft-ietf= -v6ops-cpe-slaac-renum. The scope of this last call is limited to text that= has changed since the document was sent to the IESG.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Ron

 


Juniper Business= Use Only

--_000_DM6PR05MB6348DE2A16F4E365BD7B976EAEC40DM6PR05MB6348namp_-- From nobody Thu Dec 17 11:41:46 2020 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 EB3653A0EF9 for ; Thu, 17 Dec 2020 11:41:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 9tgtT7zeLxAX for ; Thu, 17 Dec 2020 11:41:41 -0800 (PST) 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 5EC533A0EF3 for ; Thu, 17 Dec 2020 11:41:41 -0800 (PST) Received: by mail-pf1-x42e.google.com with SMTP id d2so25669pfq.5 for ; Thu, 17 Dec 2020 11:41:41 -0800 (PST) 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=RJGcCx0wpXkqAKhxUimk6dBx60qWRzzxw1UahL0PPsM=; b=ehnDIU/TiHb1azF1HPLMIAuIwAggXX9dfpMexHc+NFd4Ub2N0choH0Ymf4GFbfBIYU gixXn0fbC5H/2n3DNUGtAJm152AepsNv1pjbqebmoXJfwfK2IOdPqM0NHjxXDkVRR947 /BKwigjJrxdWUwKIAiSL699ggO4qKRjHOPSjCt0mrxRJkrV7nMAKiiqBk2PEXorAr389 LCyqoJia/ObkXU0PLARKx2kyLpfXhqUcsD3CoctW6BGNe5WeQIfTEMu0uFVGCrO4zQCb hDwjrm7ezpG+MWPkXDBVRBLoC630souhqATHfh3JeHSPMzapWyqYvy7JN5RoJrksp6b0 cnaA== 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=RJGcCx0wpXkqAKhxUimk6dBx60qWRzzxw1UahL0PPsM=; b=OEiav7tzm8UbxfPLsBjPjqIBR8rfVsVhQBAvgHNr2mUddKsa5tNzlfx+DDiF+3JEjK B6wjAbLs+53PSKbX6vURQ/YW9npksfkdPnzS9hjmR95py5N1Z+nLh2L7ChrLkT/9m2NC CXU6ozKifBY2L1QIguN01+xXxdaX8ibzzUpFCkf2oLD2DMnSsMt5agYcPnXNvSOL/ips 82CfYuhnMKrZcAoFMxbGpA7wkSDJWjCHigcAveg4lS2kPuRe5ysJ1HfC5wQat0Co/Y8m yLmQv9Z0jQ/jMbeqJ39Wp+66aBfttpzrQlhQWuxunlYXfMhRl6XakwNy2RUtiMtXATmZ 4oiA== X-Gm-Message-State: AOAM533VpGKUqgwAP0dMH/sa1SMF952SbZGEQD3bVm8nBNx1FQ7XFszE Eke6T47W0KVYamkX4ieWj/7gA6waWYmMcg== X-Google-Smtp-Source: ABdhPJw2rvjArUSLDpd/o+bR5IP3oNzEA0tXMQw8DP37BX/wYDkg86bEMNfDDgW7/3az+wZFccudqw== X-Received: by 2002:a63:7d47:: with SMTP id m7mr741517pgn.405.1608234100320; Thu, 17 Dec 2020 11:41:40 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id c10sm6928724pgj.67.2020.12.17.11.41.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Dec 2020 11:41:39 -0800 (PST) To: Ron Bonica , "v6ops@ietf.org" References: From: Brian E Carpenter Message-ID: Date: Fri, 18 Dec 2020 08:41:35 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] WGLC draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 19:41:44 -0000 Hi, I believe the change to BCP status and language is a good idea. Regards Brian Carpenter On 18-Dec-20 07:10, Ron Bonica wrote: > Folks, >=20 > =C2=A0 >=20 > This email begins a one week last call on draft-ietf-v6ops-cpe-slaac-re= num. The scope of this last call is limited to text that has changed sinc= e the document was sent to the IESG. >=20 > =C2=A0 >=20 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Ron From nobody Thu Dec 17 12:20:14 2020 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 0B0B33A0FEE for ; Thu, 17 Dec 2020 12:20:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=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=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 NWa051yjbDrf for ; Thu, 17 Dec 2020 12:20:11 -0800 (PST) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 362A23A0FEC for ; Thu, 17 Dec 2020 12:20:11 -0800 (PST) Received: by mail-qk1-x72e.google.com with SMTP id w79so27676860qkb.5 for ; Thu, 17 Dec 2020 12:20:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=F8KLK6kECyo3KApUutnyLgEiTJLy4TIfIhJJhgO8TOM=; b=C197B9wZlq/RKP1CtN+92FPJOiDXAE1TRVlhH93F40TZkYbXjnhs7pJWd45PZe9RoD ZDyxLHAPjqDqTexnZBekUW7LF08xObjGNfBv7UG//XDqtoiu2yBgZEjNAkaWkNQRmhy+ agE9a2o2OKKeyYCa0I9JwuEaxCI+Gu9xWbj4h9qTYvfXkyqzV3KH+RW4sNUuA3Q5BV0s HB/b1zBWCA/uTdQ8pfYrLbB/7oWgtllpJ5160FizfWwr98+G/fQrJYDCOQLFKrZGpRKF /f+XVs3VP7LUCwSGIWypfAoAFyTlKyQjYuWbXbANs5iI+QdJLSlvK1m4EZ4nP8eGR+Cw wZrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=F8KLK6kECyo3KApUutnyLgEiTJLy4TIfIhJJhgO8TOM=; b=thXfZkLe4UJ+HMm/KAv3zApW6iM1vU7TEeUEjWMdTg0/SZHAY+swWrlxVIW9sPioYs 3NGG5XZMn0EzybZnuwVSCuRxkWuQMyArgGqe36cG5jh29yFm9kIw27GZQc4P4SUKGUFe edyiSAyJYg0J+BRgXCmAQEuQqIs0h1ERnHZw0/vtpft3ri0yGOh2wmD1jB2L6YGqyh56 2wxbk5rn5ihjdlBIIuSrUCTX9s9HHZTnz6O3sYVueHEXimMy6FVO5mvElHK4I590J5oQ ehQXRvPjo1KlbYWJ2MLv/Y5E2de8S4rLjCsEhx3Ew0AbgVq24o0CnWx8RWq/m86Sf90f rGbQ== X-Gm-Message-State: AOAM533yRLbWKeYL9Jhyc9pA1GvVfURpZvm96FkWh0XKywFEqf1WQ1+F SlfNaDLxcrYXXerBNeIV8fjZKYQCm7hl/A== X-Google-Smtp-Source: ABdhPJzc4UIPmycmEd9wukA6FtLjC+5nCJsmHQXJlaWIOVmk/EAkIgk/X1SFVHYXKps+LbHLHvYHRA== X-Received: by 2002:a37:2742:: with SMTP id n63mr1136418qkn.390.1608236410158; Thu, 17 Dec 2020 12:20:10 -0800 (PST) Received: from [192.168.4.114] (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id v137sm4423900qka.110.2020.12.17.12.20.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 17 Dec 2020 12:20:09 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Thu, 17 Dec 2020 15:20:08 -0500 Message-Id: References: Cc: Ron Bonica , v6ops@ietf.org In-Reply-To: To: Brian E Carpenter X-Mailer: iPhone Mail (18E118) Archived-At: Subject: Re: [v6ops] WGLC draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 20:20:13 -0000 Seconded. BCP good.=20 > On Dec 17, 2020, at 14:42, Brian E Carpenter = wrote: >=20 > =EF=BB=BFHi, >=20 > I believe the change to BCP status and language is a good idea. >=20 > Regards > Brian Carpenter >=20 >> On 18-Dec-20 07:10, Ron Bonica wrote: >> Folks, >>=20 >> =20 >>=20 >> This email begins a one week last call on draft-ietf-v6ops-cpe-slaac-renu= m. The scope of this last call is limited to text that has changed since the= document was sent to the IESG. >>=20 >> =20 >>=20 >> = Ron >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Sat Dec 19 20:44:46 2020 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 6EE493A0AC5; Sat, 19 Dec 2020 20:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=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 KFO__vkbr_Qb; Sat, 19 Dec 2020 20:44:37 -0800 (PST) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 0D5AC3A0B45; Sat, 19 Dec 2020 20:44:32 -0800 (PST) Received: by mail-pl1-x62e.google.com with SMTP id q4so3827739plr.7; Sat, 19 Dec 2020 20:44:32 -0800 (PST) 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=1HqHpr4F/gSJBX5O1VNwxJMyC9k606lttGrphiyfY20=; b=sn7+SPfs/yDPDJNHVWF8VzKPU+kyQ8bGfmyoJUHKq7k1PlGF+ZV7hVb4vJGZpxMD65 IiTcNv+X8gBC8qv/sqcw5/E4DJ4SYEirsULjQCKsbZnntbEuUUF43+KpJuYS2wnsF+T4 GSmw3zd701wGQkh+UZNVeBn/khw9J+ZaiG8ti+C+8WhK8yVoYAUuDVe+69qZqZsYkpfx MQn2NScnvPvaPLZopN32O4ZWD3btK7+5YcQ8YPRbXa6nB+SvUirXnc3y5WTLvG/6N0B2 Zptt/trr0B4HexfwOvjGln9aiGM8jR8BoAtKafhS6mN9SfDOV76A7W662HjdDT2FC/9m sg4Q== 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=1HqHpr4F/gSJBX5O1VNwxJMyC9k606lttGrphiyfY20=; b=NPIYbnCvYHGzy9D1EKYMeFnoZQvEX503XW8XYrAe1V8Z7N+q6YnsC2KInxSjX5KUSP glsaXTghESvkM+KOpwlntICee9t5RGS1uR6N/V5dz1TcpT7uUAvyidR2KvzgVHyrLi7J k+hJVdgVMWu42RdAUSsu0L6NFzTBfg6Jskt0BkXsaScRe+qRCbz+ycdh1bXbmTS178kC 39xhh81WehgXamQpG8KEdW3zvimtzk67+r2LJt1tqDHIlH7MQrMOiJ2rr4v6N/SPfLi/ smlZEwo9Q0BgBRGq5BJdP4MnRxtDswu3iAhNAbC6dsktPZhXkmLzyj56csq+BgBDKQSL HS7Q== X-Gm-Message-State: AOAM53301lTD8n4bODtSytQEFeKyDIqWTvTh7bR6yidjK3BbIrZNc9hn ZsCECFbxsxTS4lzDFImaxy3V2g39fK3Ydw== X-Google-Smtp-Source: ABdhPJzBJ//A6SQZPveIQA4d/3KTZl6BctQYkJ275QTgRUV4QU1ATAm6PjSp+LLIrFVBs6PLjHSZhw== X-Received: by 2002:a17:90b:1087:: with SMTP id gj7mr11436951pjb.41.1608439471938; Sat, 19 Dec 2020 20:44:31 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id w22sm12363120pfu.33.2020.12.19.20.44.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Dec 2020 20:44:31 -0800 (PST) To: IPv6 Operations , draft-gont-v6ops-ipv6-addressing-considerations@ietf.org References: <160770241261.18071.12524922630334294118@ietfa.amsl.com> From: Brian E Carpenter Message-ID: Date: Sun, 20 Dec 2020 17:44:27 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <160770241261.18071.12524922630334294118@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-gont-v6ops-ipv6-addressing-considerations-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Dec 2020 04:44:45 -0000 Hi, Thanks for this draft. > 3.1. Legacy Specifications and Schemes I don't think that section is complete without mentioning site-local and why it was scrapped (RFC3879). > 3.2. Unique Local IPv6 Unicast Addresses (ULAs) ... > However, the only reasons > for which these addresses are considered to have "global scope" are: > > o given two different networks that employ ULAs, it's unlikely that > they will employ the same ULA prefix Not at all. The reason they formally have global scope is because when site-local was scrapped (as being meaningless and unenforcable, see RFC3879), only two scopes were left: link-local and global. There was no other choice. What that means is that protocols treat them *exactly the same* as RIR-assigned prefixes. That applies to all protocols: ND, RA, DHCPv6, and every routing protocol. They are only treated differently by policy, such as address selection policy or boundary router policy. And, if you like, the pseudo-random prefix assignment mechanism is also a policy, by making prefix collision highly unlikely. ULA-C would be a different policy, by making prefix registration compulsory. > > o the ULA address block formally belongs to the Global Unicast > Address (GUA) address block ... > The ULA address block has been carved out of the GUA address block, This statement seems misleading to me. GUA is not actually defined very well in RFC4291. True, the table in section 2.4 says "Global Unicast (everything else)" and none of the formal updates to RFC4291 change that. But the choice of fc00::/7 by RFC4193 makes it clear that these are not normal GUAs; by definition they are not assigned by the RIRs or announced on the public Internet. They are listed in the IANA Special-Purpose IP Address registry and discussed explicitly in RFC8190, so the claim that they are part of the GUA block seems very dubious. (I think it's a bug in RFC4193 that it didn't make an update to RFC3513, the predecessor of RFC4291, which actually foresaw such a case: "Future specifications may redefine one or more sub-ranges of the global unicast space for other purposes, but unless and until that happens, implementations must treat all addresses that do not start with any of the above-listed prefixes as global unicast addresses.") > Therefore, ULAs are not globally meaningful and thus, for most (if > not all) practical purposes, ULAs can be considered to have non- > global scope. For this reason, ULAs are treated as non-global scope > addresses, even when from a specifications point of view they have > global scope. I don't accept that. I believe we've had that discussion and the consensus is in RFC8190 and the IANA registry already. Later in the draft you say: > In the same light, a ULA prefix > generated by a local router will be, by definition, provider > independent. However, a router might also be leased an ULA sub- > prefix from its upstream, in which case this prefix would be > "provider dependent". Exactly. This illustrates that as far as protocols go, ULA prefixes behave exactly like RIR-assigned prefixes. They are global in protocol terms, but not globally routed in operational terms. These are orthogonal properties. Regards Brian On 12-Dec-20 05:00, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : IPv6 Addressing Considerations > Authors : Fernando Gont > Guillermo Gont > Filename : draft-gont-v6ops-ipv6-addressing-considerations-00.txt > Pages : 27 > Date : 2020-12-11 > > Abstract: > IPv6 addresses can differ in a number of properties, such as scope, > stability, and intended usage type. This document analyzes the > impact of these properties on aspects such as security, privacy, > interoperability, and network operations. Additionally, it > identifies challenges and gaps that currently prevent systems and > applications from leveraging the increased flexibility and > availability of IPv6 addresses. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-addressing-considerations/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-gont-v6ops-ipv6-addressing-considerations-00 > https://datatracker.ietf.org/doc/html/draft-gont-v6ops-ipv6-addressing-considerations-00 > > > 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/ > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Wed Dec 23 21:52:10 2020 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 0FE713A1026; Wed, 23 Dec 2020 21:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=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 EYaEF6ujHpEj; Wed, 23 Dec 2020 21:52:03 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30DE83A101E; Wed, 23 Dec 2020 21:51:49 -0800 (PST) Received: from [10.0.0.134] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 541452845C7; Thu, 24 Dec 2020 05:51:44 +0000 (UTC) To: Brian E Carpenter , IPv6 Operations , draft-gont-v6ops-ipv6-addressing-considerations@ietf.org References: <160770241261.18071.12524922630334294118@ietfa.amsl.com> From: Fernando Gont Message-ID: <299f492f-4cb7-fa9d-967f-b2a5df49034e@si6networks.com> Date: Thu, 24 Dec 2020 02:50:58 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-gont-v6ops-ipv6-addressing-considerations-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2020 05:52:08 -0000 Hello, Brian, Thanks for your comments! In-line.... On 20/12/20 01:44, Brian E Carpenter wrote: [....] > >> 3.1. Legacy Specifications and Schemes > > I don't think that section is complete without mentioning site-local > and why it was scrapped (RFC3879). Will do. Comment/question (since I wasn't participating in 6man when RFC3879 was published, and I've never used site-locals myself): There seem to be two main issues with site-locals: 1) use of the zone index ("%___") 2) "ambiguitiy" of the addresses. Regarding #1: My understanding is that site-locals where expected to be used with a zone index (as we normally do for e.g. link-locals) in the case the same prefix is employed on two different networks. Now, my question is: why do this in the first place? What I would expect is that you simply use the address. Then, if the same node attaches to two networks that employ the same prefix, that's a configuration problem. Period. *If* in such scenario, *and for debugging purposes* you want to be able to specify which interface to use to send packets to a site-local address (that looks like "on-link" on two different interfaces), then you use the zone index -- but that's for *debugging* purposes, since having two subnets employ the same site-local prefix would be an error. Regarding #2: Modulo the above, for the most part non-global addresses *are* ambiguous. So this is kind of a feature. With the minor consideration in #1, site-locals do not seem to be a lot different than ULAs. -- Yes, you are supposed to randomize the ULA prefix ( which I don't when using them in labs, since I don't want ugly-looking addresses :-) ).. but you might also argue than when using site-locals you better made sure that you didn't employ the same site-local prefix in to interconnected networks, anyway. Am I missing something? >> 3.2. Unique Local IPv6 Unicast Addresses (ULAs) > ... >> However, the only reasons for which these addresses are considered >> to have "global scope" are: >> >> o given two different networks that employ ULAs, it's unlikely >> that they will employ the same ULA prefix > > Not at all. The reason they formally have global scope is because > when site-local was scrapped (as being meaningless and unenforcable, > see RFC3879), only two scopes were left: link-local and global. > There was no other choice. Why not, say, "IPv6 Private Address Space"? -- Yes, in the light of "ipv6 is all about the global addresses", mimicking IPv4's private addresses probably wasn't "sexy", but IMO the concept is useful, and well understood. > What that means is that protocols treat > them *exactly the same* as RIR-assigned prefixes. That applies to > all protocols: ND, RA, DHCPv6, and every routing protocol. They are > only treated differently by policy, such as address selection policy > or boundary router policy. Wouldn't this also be the case if they were redefined as "IPv6 private address space"? i.e., from the point of routing, modulo the link-local prefixes, you simply have prefixes that you distribute information about. i.e. "Private address space" (i.e., non-global) shouldn't be treated differently by routing protocols. > And, if you like, the pseudo-random > prefix assignment mechanism is also a policy, by making prefix > collision highly unlikely. ULA-C would be a different policy, by > making prefix registration compulsory. Comment/question (rather than "objection"): since the "scope" is essentially defined as the region of the network topology where an address is meaningful, it would seem to me that claiming "ULAs" are global-scope is at odds with the fact that ULAs prefixes are locally-generated. Put another way: when you analyze what "scope" means, ULAs really have nothing of "global scope". ULAs are not centrally managed, and as such are ambiguous. (I guess you could argue that ULA-C could be global for some meaning of the concept. But then I don't see much of a point for such a thing. -- just use global addresses, and filter where appropriate.) >> o the ULA address block formally belongs to the Global Unicast >> Address (GUA) address block > ... >> The ULA address block has been carved out of the GUA address >> block, > > This statement seems misleading to me. GUA is not actually defined > very well in RFC4291. True, the table in section 2.4 says "Global > Unicast (everything else)" and none of the formal updates to RFC4291 > change that. Yes, that was my rationale. > But the choice of fc00::/7 by RFC4193 makes it clear > that these are not normal GUAs; by definition they are not assigned > by the RIRs or announced on the public Internet. They are listed in > the IANA Special-Purpose IP Address registry and discussed > explicitly in RFC8190, so the claim that they are part of the GUA > block seems very dubious. FWIW, I think that RFC4193 should have formally updated RFC4291 (or, well, since probably they were published together, RFC4291 could have marked the ULA space in the addressing architecture, and point to RFC4193 for further details). BTW, there are no macros that would distinguish ULAs them from regular global addresses: https://tools.ietf.org/html/rfc2553#section-6.7 > (I think it's a bug in RFC4193 that it didn't make an update to > RFC3513, the predecessor of RFC4291, which actually foresaw such a > case: "Future specifications may redefine one or more sub-ranges of > the global unicast space for other purposes, but unless and until > that happens, implementations must treat all addresses that do not > start with any of the above-listed prefixes as global unicast > addresses.") Ok, it looks like we are on the same page. :-) >> Therefore, ULAs are not globally meaningful and thus, for most (if >> not all) practical purposes, ULAs can be considered to have non- >> global scope. For this reason, ULAs are treated as non-global >> scope addresses, even when from a specifications point of view >> they have global scope. > > I don't accept that. I believe we've had that discussion and the > consensus is in RFC8190 and the IANA registry already. Sorry: what we *meant* here is that, throughout our document, when we refer to "non-global addresses" we are also thinking about ULAs. (e.g., the "possible isolation provided by the address scope" applies (to different degrees) to both e.g. link-locals and ULAs...) > Later in the draft you say: > >> In the same light, a ULA prefix generated by a local router will >> be, by definition, provider independent. However, a router might >> also be leased an ULA sub- prefix from its upstream, in which case >> this prefix would be "provider dependent". > > Exactly. This illustrates that as far as protocols go, ULA prefixes > behave exactly like RIR-assigned prefixes. Couldn't one also argue that ULAs are, e.g., "IPv6 private address space" and that, as with the RFC1918 space, no special provisions are needed in routing protocols -- other than one filtering prefixes when/where deemed appropriate? > They are global in > protocol terms, but not globally routed in operational terms. These > are orthogonal properties. Sorry for insisting on this one -- I'm bringing up this issues because I found myself trying to provide an explanation for "global in protocol terms", without a lot of success. :-) It would seem to me that virtually every use of "global" for ULAs (modulo ULA-C, I guess) is, conceptually speaking, kind of cumbersome and incorrect. -- and creates expectations that, at the end of the day, are probably not going to be fulfilled. Wouldn't the most natural thing be to flag ULAs as "IPv6 Private Address Space", where e.g. from the point of view of protocols, the same considerations as for RFC1918 apply (no, I wouldn't *say* this in a spec), and we simply have the additional feature in the spec that we recommend how to generate the ULAs prefixes to avoid possible hassles when merging two different networks? Or, to put in a different way: RFC1918 is private address space, and we don't need to call it "global" in any way to flag the fact that addresses from that private address space are not treated in any special way by e.g. routing protocols -- for instance, why should they? Thanks! Regards, and Merry Christmas! -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Dec 24 14:15:44 2020 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 43FDE3A0B55; Thu, 24 Dec 2020 14:15:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=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=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 9dwM825t_nWi; Thu, 24 Dec 2020 14:15:41 -0800 (PST) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 EA0E63A0B45; Thu, 24 Dec 2020 14:15:40 -0800 (PST) Received: by mail-pj1-x1033.google.com with SMTP id f14so1662289pju.4; Thu, 24 Dec 2020 14:15:40 -0800 (PST) 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=I9p05iN890+12HWwNv0ISFMuYox6Qs1oOqMGeQqnfY4=; b=P5vnBt7huhFq9Hb2ddBcsdZ/OEIFWDF8GttfhDN1zS61J3UAyTtnWfU60/NuNuDFwj nt4hrKGTk1ekQP/NcBaZf4fiT+V9WlUVppPnx73J2Xuz9WP88/YEvYuK9WieQVuM8BRH Je0/6M2RuR6n7K/BHj4tDxDVtRpYt68xSHYtyrqgj7ij4S72EzKTgUdaMD/U/Uwk9zv7 QjPydfWPEB7gQFvb5k4OZUzymjmOX74orA2pFFANj9vvuYVz/2r762umxqGZeDQB8HL8 iumY5oEMhkUbkFqXx2U/kRppznR0EgP9ihBXjVqZ9R+6+bj19qPLgitQnmlvAZn1i+mJ Cx0A== 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=I9p05iN890+12HWwNv0ISFMuYox6Qs1oOqMGeQqnfY4=; b=OOUKvn7yKFg396HFfyD3v5a1kEMY6FPZ1CsdKwTfgcD4D0iu/Y7QmxetJ7nh2Hbfu6 KH+A/4ZG6WHJbKpYaroEjMVyd22aKWnuhRzUDG0jnNzILm+eahLBo1u+CJfLGISEKtYB aacfSxFEso2rAGKTVnmVehz5xUKwjH4x8Za0zPOj/S0uL5W+Nw13eA0oMnBF5Zb/rlK6 GIqZGk2b9C+O088sNrY1i2P8i/CCX2lZ2JOQEbBErcPTWNHpYNKgNgm8vHESmC+AyS0d t0k9OTpGDudtwhbkXwXIe8vJRjZDiCp/XnTr0YTTJWa3dVDA1N5Q5rkQ3WtwCOmDug2i T33Q== X-Gm-Message-State: AOAM53392/YAKWCFtfMUMIxLEjvK3bPhw/++arl+1CoxhMNh0nxfqXvP P1pH9Nfo5FKeqeQFWeWbZx75K7G2LOmYcg== X-Google-Smtp-Source: ABdhPJz9RgQj+zi9QUaxMc4chNDxcYxKmr7xy88BM2/3P2/xmvgRqzZB3NsnteIf8w4XMbRXkXpRGw== X-Received: by 2002:a17:90a:fa81:: with SMTP id cu1mr6047732pjb.39.1608848139630; Thu, 24 Dec 2020 14:15:39 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id u12sm26631523pfh.98.2020.12.24.14.15.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Dec 2020 14:15:38 -0800 (PST) To: Fernando Gont , IPv6 Operations , draft-gont-v6ops-ipv6-addressing-considerations@ietf.org References: <160770241261.18071.12524922630334294118@ietfa.amsl.com> <299f492f-4cb7-fa9d-967f-b2a5df49034e@si6networks.com> From: Brian E Carpenter Message-ID: <759efdb1-a59c-788c-0c7a-5a8ca2ced904@gmail.com> Date: Fri, 25 Dec 2020 11:15:35 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <299f492f-4cb7-fa9d-967f-b2a5df49034e@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-gont-v6ops-ipv6-addressing-considerations-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Dec 2020 22:15:43 -0000 Hi Fernando, On 24-Dec-20 18:50, Fernando Gont wrote: > Hello, Brian, > > Thanks for your comments! In-line.... > > On 20/12/20 01:44, Brian E Carpenter wrote: > [....] >> >>> 3.1. Legacy Specifications and Schemes >> >> I don't think that section is complete without mentioning site-local >> and why it was scrapped (RFC3879). > > Will do. > > Comment/question (since I wasn't participating in 6man when RFC3879 was > published, and I've never used site-locals myself): > > > There seem to be two main issues with site-locals: > > 1) use of the zone index ("%___") > > 2) "ambiguitiy" of the addresses. > > > Regarding #1: > My understanding is that site-locals where expected to be used with a > zone index (as we normally do for e.g. link-locals) in the case the same > prefix is employed on two different networks. > > Now, my question is: why do this in the first place? What I would expect > is that you simply use the address. Then, if the same node attaches to > two networks that employ the same prefix, that's a configuration > problem. Period. *If* in such scenario, *and for debugging purposes* you > want to be able to specify which interface to use to send packets to a > site-local address (that looks like "on-link" on two different > interfaces), then you use the zone index -- but that's for *debugging* > purposes, since having two subnets employ the same site-local prefix > would be an error. If you read RFC4007 you will *not* find that a zone index is formally equated to an interface index. The "zone" terminology is confusing since it did originally assume a nested scope model, link-local inside site-local inside global. By some magic the host was supposed to understand enough of the network topology to use a single value "zone index" to capture the topology and tell the drivers which interface to use. See diagrams at https://sites.google.com/site/bcabrc/miscellany . Slides 3 and 4 show scenarios that simply can't be captured by a one-dimensional zone index. In practice, of course, the zone index is only meaningful within the host. So the whole concept of a zone index for nested scopes was a mistake. With hindsight, we should have cleaned that up more definitively in RFC4007. (And this problem is still a problem: https://bugzilla.mozilla.org/show_bug.cgi?id=700999 was opened 9 years ago and still gets traffic despite being formally "closed" 5 years ago.) > Regarding #2: > Modulo the above, for the most part non-global addresses *are* > ambiguous. So this is kind of a feature. Yes, but not a *good* feature since it leads to the problems in my slides 3 and 4. > With the minor consideration in #1, site-locals do not seem to be a lot > different than ULAs. -- Yes, you are supposed to randomize the ULA > prefix ( which I don't when using them in labs, since I don't want > ugly-looking addresses :-) ).. but you might also argue than when using > site-locals you better made sure that you didn't employ the same > site-local prefix in to interconnected networks, anyway. But the design didn't provide for that, whereas the ULA design does (and no, using pretty ULA prefixes is not OK). RFC3513 was seriously broken, because it suggests using "the same subnet IDs for site-local and global prefixes", which doesn't make much sense and certainly doesn't provide a high probability of uniqueness. > > Am I missing something? > > > > >>> 3.2. Unique Local IPv6 Unicast Addresses (ULAs) >> ... >>> However, the only reasons for which these addresses are considered >>> to have "global scope" are: >>> >>> o given two different networks that employ ULAs, it's unlikely >>> that they will employ the same ULA prefix >> >> Not at all. The reason they formally have global scope is because >> when site-local was scrapped (as being meaningless and unenforcable, >> see RFC3879), only two scopes were left: link-local and global. >> There was no other choice. > > Why not, say, "IPv6 Private Address Space"? -- Yes, in the light of > "ipv6 is all about the global addresses", mimicking IPv4's private > addresses probably wasn't "sexy", but IMO the concept is useful, and > well understood. I think that adds confusion. They are only private because of the requirement to block them in border routers; it's not a property of the address itself. (Thumbs down to the Python ipaddress module by the way, which has invented an "is_private" property and gets "is_global" wrong for ULAs.) >> What that means is that protocols treat >> them *exactly the same* as RIR-assigned prefixes. That applies to >> all protocols: ND, RA, DHCPv6, and every routing protocol. They are >> only treated differently by policy, such as address selection policy >> or boundary router policy. > > Wouldn't this also be the case if they were redefined as "IPv6 private > address space"? i.e., from the point of routing, modulo the link-local > prefixes, you simply have prefixes that you distribute information > about. i.e. "Private address space" (i.e., non-global) shouldn't be > treated differently by routing protocols. It's true, but that's what the "global" property means, and it's different from "globally reachable". It's not ideal terminology, of course, since the design process had a false start with "site-local". Happy holidays! Brian > > > >> And, if you like, the pseudo-random >> prefix assignment mechanism is also a policy, by making prefix >> collision highly unlikely. ULA-C would be a different policy, by >> making prefix registration compulsory. > > Comment/question (rather than "objection"): since the "scope" is > essentially defined as the region of the network topology where an > address is meaningful, it would seem to me that claiming "ULAs" are > global-scope is at odds with the fact that ULAs prefixes are > locally-generated. > > Put another way: when you analyze what "scope" means, ULAs really have > nothing of "global scope". ULAs are not centrally managed, and as such > are ambiguous. > > (I guess you could argue that ULA-C could be global for some meaning of > the concept. But then I don't see much of a point for such a thing. -- > just use global addresses, and filter where appropriate.) > > > >>> o the ULA address block formally belongs to the Global Unicast >>> Address (GUA) address block >> ... >>> The ULA address block has been carved out of the GUA address >>> block, >> >> This statement seems misleading to me. GUA is not actually defined >> very well in RFC4291. True, the table in section 2.4 says "Global >> Unicast (everything else)" and none of the formal updates to RFC4291 >> change that. > > Yes, that was my rationale. > > > >> But the choice of fc00::/7 by RFC4193 makes it clear >> that these are not normal GUAs; by definition they are not assigned >> by the RIRs or announced on the public Internet. They are listed in >> the IANA Special-Purpose IP Address registry and discussed >> explicitly in RFC8190, so the claim that they are part of the GUA >> block seems very dubious. > > FWIW, I think that RFC4193 should have formally updated RFC4291 (or, > well, since probably they were published together, RFC4291 could have > marked the ULA space in the addressing architecture, and point to > RFC4193 for further details). > > BTW, there are no macros that would distinguish ULAs them from regular > global addresses: https://tools.ietf.org/html/rfc2553#section-6.7 > > > > >> (I think it's a bug in RFC4193 that it didn't make an update to >> RFC3513, the predecessor of RFC4291, which actually foresaw such a >> case: "Future specifications may redefine one or more sub-ranges of >> the global unicast space for other purposes, but unless and until >> that happens, implementations must treat all addresses that do not >> start with any of the above-listed prefixes as global unicast >> addresses.") > > Ok, it looks like we are on the same page. :-) > > > > >>> Therefore, ULAs are not globally meaningful and thus, for most (if >>> not all) practical purposes, ULAs can be considered to have non- >>> global scope. For this reason, ULAs are treated as non-global >>> scope addresses, even when from a specifications point of view >>> they have global scope. >> >> I don't accept that. I believe we've had that discussion and the >> consensus is in RFC8190 and the IANA registry already. > > Sorry: what we *meant* here is that, throughout our document, when we > refer to "non-global addresses" we are also thinking about ULAs. > > (e.g., the "possible isolation provided by the address scope" applies > (to different degrees) to both e.g. link-locals and ULAs...) > > > > >> Later in the draft you say: >> >>> In the same light, a ULA prefix generated by a local router will >>> be, by definition, provider independent. However, a router might >>> also be leased an ULA sub- prefix from its upstream, in which case >>> this prefix would be "provider dependent". >> >> Exactly. This illustrates that as far as protocols go, ULA prefixes >> behave exactly like RIR-assigned prefixes. > > Couldn't one also argue that ULAs are, e.g., "IPv6 private address > space" and that, as with the RFC1918 space, no special provisions are > needed in routing protocols -- other than one filtering prefixes > when/where deemed appropriate? > > > >> They are global in >> protocol terms, but not globally routed in operational terms. These >> are orthogonal properties. > > Sorry for insisting on this one -- I'm bringing up this issues because I > found myself trying to provide an explanation for "global in protocol > terms", without a lot of success. :-) > > It would seem to me that virtually every use of "global" for ULAs > (modulo ULA-C, I guess) is, conceptually speaking, kind of cumbersome > and incorrect. -- and creates expectations that, at the end of the day, > are probably not going to be fulfilled. > > Wouldn't the most natural thing be to flag ULAs as "IPv6 Private Address > Space", where e.g. from the point of view of protocols, the same > considerations as for RFC1918 apply (no, I wouldn't *say* this in a > spec), and we simply have the additional feature in the spec that we > recommend how to generate the ULAs prefixes to avoid possible hassles > when merging two different networks? > > Or, to put in a different way: RFC1918 is private address space, and we > don't need to call it "global" in any way to flag the fact that > addresses from that private address space are not treated in any special > way by e.g. routing protocols -- for instance, why should they? > > > Thanks! > > Regards, and Merry Christmas! > From nobody Fri Dec 25 17:04:16 2020 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 88B503A0E80; Fri, 25 Dec 2020 17:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=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=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 XBXrSySyDKeB; Fri, 25 Dec 2020 17:04:12 -0800 (PST) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 6BA6E3A0E7F; Fri, 25 Dec 2020 17:04:12 -0800 (PST) Received: by mail-pj1-x102b.google.com with SMTP id v1so2902110pjr.2; Fri, 25 Dec 2020 17:04:12 -0800 (PST) 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=qH6mWCVJrnq22fnVP6E2yAexeZQDiUlLQrAT3e0ybNY=; b=WdRHyp+2rs6i9jIPy7YgnF5R/5gBsHw3D5DTpz/DLvNGY+ayNzSHe+2ZVNamj4Ye+v hyxzVs8GjRMzqWSmV26JsGmgPjDbT6pSx5gaOpoaJfWdO6ordk8YSjQpWuoOX416WeYX s3ZDuOqs56vGjhWbNWjGcJnYDhYvxsxT7iD+T582kZubEORQZpanxJBDEw8YbrJyeQXg bG8mrB9kFcJ7zmGRYwLiJ3MgYOwRgFUlljrugzrj51WiK5onRqrdAnJ5jRhI6W70Cmus avl6CnF5R4IUvIV+DwNVtl3x5qSD6AnohtbljGBWBWgjN3xEGHBEAkYVwJRovWbhtuod n0mg== 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=qH6mWCVJrnq22fnVP6E2yAexeZQDiUlLQrAT3e0ybNY=; b=ctFKkIV2rsUmO7Q8kDlVKLc2+fgBq8cFq/0Y6wgxxAWw4eXNykAD6GsXJ7Qzzt/xy8 LXyIu9dQe86NuXmNrus2ZL34I4Ie4/QZCM8NbnJN8fMwC6ZEGIgXqo07Mw//oinR5MxY PIpzRqBUn61MIN5SQj84X6F9G8ByESK1A5y2S8TjFyEUTkMwu/+2idQ+3m8k/C3p0q2E i31YwpiI1VIX3q7hIuIYIfCsS8EtNiJhS8+s+GHDHu1KzUDkUt+h2ceYSRVfUzrAXXZ7 p+yoZiRg/b3HsFj6ql9g6ZcMWKwdt5dmHzdOGxv9lrXG8pGc9uslOY6CV4crrPlmA4cg M06w== X-Gm-Message-State: AOAM530fSlzsFwQb9dbpY9PlGF+elJPallf79NxBMXdNVnPTCes7gzk/ ilDuXM8WUSK6cCF20NaSvtYCRFHVdRlBkg== X-Google-Smtp-Source: ABdhPJyRJ/3PgYTaoAsPJxHAi79lU7cT0BIKFp0ScJyuEb/t6UO0Xy1S3ReCEMbMvjtX5N/lPuqBkQ== X-Received: by 2002:a17:902:ee02:b029:db:c0d6:57f9 with SMTP id z2-20020a170902ee02b02900dbc0d657f9mr35544207plb.65.1608944651114; Fri, 25 Dec 2020 17:04:11 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id 6sm15814181pgo.17.2020.12.25.17.04.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Dec 2020 17:04:10 -0800 (PST) To: Fernando Gont , IPv6 Operations , draft-gont-v6ops-ipv6-addressing-considerations@ietf.org References: <160770241261.18071.12524922630334294118@ietfa.amsl.com> <299f492f-4cb7-fa9d-967f-b2a5df49034e@si6networks.com> <759efdb1-a59c-788c-0c7a-5a8ca2ced904@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <870d8c92-0aab-6fcd-a945-401293b7af28@gmail.com> Date: Sat, 26 Dec 2020 14:04:05 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <759efdb1-a59c-788c-0c7a-5a8ca2ced904@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-gont-v6ops-ipv6-addressing-considerations-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Dec 2020 01:04:15 -0000 There's now a better version of my diagrams at https://www.cs.auckland.ac.nz/~brian/scope6.pdf Regards Brian On 25-Dec-20 11:15, Brian E Carpenter wrote: > Hi Fernando, > > On 24-Dec-20 18:50, Fernando Gont wrote: >> Hello, Brian, >> >> Thanks for your comments! In-line.... >> >> On 20/12/20 01:44, Brian E Carpenter wrote: >> [....] >>> >>>> 3.1. Legacy Specifications and Schemes >>> >>> I don't think that section is complete without mentioning site-local >>> and why it was scrapped (RFC3879). >> >> Will do. >> >> Comment/question (since I wasn't participating in 6man when RFC3879 was >> published, and I've never used site-locals myself): >> >> >> There seem to be two main issues with site-locals: >> >> 1) use of the zone index ("%___") >> >> 2) "ambiguitiy" of the addresses. >> >> >> Regarding #1: >> My understanding is that site-locals where expected to be used with a >> zone index (as we normally do for e.g. link-locals) in the case the same >> prefix is employed on two different networks. >> >> Now, my question is: why do this in the first place? What I would expect >> is that you simply use the address. Then, if the same node attaches to >> two networks that employ the same prefix, that's a configuration >> problem. Period. *If* in such scenario, *and for debugging purposes* you >> want to be able to specify which interface to use to send packets to a >> site-local address (that looks like "on-link" on two different >> interfaces), then you use the zone index -- but that's for *debugging* >> purposes, since having two subnets employ the same site-local prefix >> would be an error. > > If you read RFC4007 you will *not* find that a zone index is formally > equated to an interface index. The "zone" terminology is confusing since > it did originally assume a nested scope model, link-local inside site-local > inside global. By some magic the host was supposed to understand enough > of the network topology to use a single value "zone index" to capture > the topology and tell the drivers which interface to use. See diagrams > at https://sites.google.com/site/bcabrc/miscellany . > Slides 3 and 4 show scenarios that simply can't be captured > by a one-dimensional zone index. In practice, of course, the zone index > is only meaningful within the host. So the whole concept of a zone > index for nested scopes was a mistake. With hindsight, we should > have cleaned that up more definitively in RFC4007. > > (And this problem is still a problem: > https://bugzilla.mozilla.org/show_bug.cgi?id=700999 was opened > 9 years ago and still gets traffic despite being formally "closed" > 5 years ago.) > >> Regarding #2: >> Modulo the above, for the most part non-global addresses *are* >> ambiguous. So this is kind of a feature. > > Yes, but not a *good* feature since it leads to the problems > in my slides 3 and 4. > >> With the minor consideration in #1, site-locals do not seem to be a lot >> different than ULAs. -- Yes, you are supposed to randomize the ULA >> prefix ( which I don't when using them in labs, since I don't want >> ugly-looking addresses :-) ).. but you might also argue than when using >> site-locals you better made sure that you didn't employ the same >> site-local prefix in to interconnected networks, anyway. > > But the design didn't provide for that, whereas the ULA design does > (and no, using pretty ULA prefixes is not OK). > > RFC3513 was seriously broken, because it suggests using "the same > subnet IDs for site-local and global prefixes", which doesn't > make much sense and certainly doesn't provide a high probability > of uniqueness. > >> >> Am I missing something? >> >> >> >> >>>> 3.2. Unique Local IPv6 Unicast Addresses (ULAs) >>> ... >>>> However, the only reasons for which these addresses are considered >>>> to have "global scope" are: >>>> >>>> o given two different networks that employ ULAs, it's unlikely >>>> that they will employ the same ULA prefix >>> >>> Not at all. The reason they formally have global scope is because >>> when site-local was scrapped (as being meaningless and unenforcable, >>> see RFC3879), only two scopes were left: link-local and global. >>> There was no other choice. >> >> Why not, say, "IPv6 Private Address Space"? -- Yes, in the light of >> "ipv6 is all about the global addresses", mimicking IPv4's private >> addresses probably wasn't "sexy", but IMO the concept is useful, and >> well understood. > > I think that adds confusion. They are only private because of the > requirement to block them in border routers; it's not a property > of the address itself. (Thumbs down to the Python ipaddress module > by the way, which has invented an "is_private" property and gets > "is_global" wrong for ULAs.) > >>> What that means is that protocols treat >>> them *exactly the same* as RIR-assigned prefixes. That applies to >>> all protocols: ND, RA, DHCPv6, and every routing protocol. They are >>> only treated differently by policy, such as address selection policy >>> or boundary router policy. >> >> Wouldn't this also be the case if they were redefined as "IPv6 private >> address space"? i.e., from the point of routing, modulo the link-local >> prefixes, you simply have prefixes that you distribute information >> about. i.e. "Private address space" (i.e., non-global) shouldn't be >> treated differently by routing protocols. > > It's true, but that's what the "global" property means, and it's different > from "globally reachable". It's not ideal terminology, of course, since the > design process had a false start with "site-local". > > Happy holidays! > > Brian >> >> >> >>> And, if you like, the pseudo-random >>> prefix assignment mechanism is also a policy, by making prefix >>> collision highly unlikely. ULA-C would be a different policy, by >>> making prefix registration compulsory. >> >> Comment/question (rather than "objection"): since the "scope" is >> essentially defined as the region of the network topology where an >> address is meaningful, it would seem to me that claiming "ULAs" are >> global-scope is at odds with the fact that ULAs prefixes are >> locally-generated. >> >> Put another way: when you analyze what "scope" means, ULAs really have >> nothing of "global scope". ULAs are not centrally managed, and as such >> are ambiguous. >> >> (I guess you could argue that ULA-C could be global for some meaning of >> the concept. But then I don't see much of a point for such a thing. -- >> just use global addresses, and filter where appropriate.) >> >> >> >>>> o the ULA address block formally belongs to the Global Unicast >>>> Address (GUA) address block >>> ... >>>> The ULA address block has been carved out of the GUA address >>>> block, >>> >>> This statement seems misleading to me. GUA is not actually defined >>> very well in RFC4291. True, the table in section 2.4 says "Global >>> Unicast (everything else)" and none of the formal updates to RFC4291 >>> change that. >> >> Yes, that was my rationale. >> >> >> >>> But the choice of fc00::/7 by RFC4193 makes it clear >>> that these are not normal GUAs; by definition they are not assigned >>> by the RIRs or announced on the public Internet. They are listed in >>> the IANA Special-Purpose IP Address registry and discussed >>> explicitly in RFC8190, so the claim that they are part of the GUA >>> block seems very dubious. >> >> FWIW, I think that RFC4193 should have formally updated RFC4291 (or, >> well, since probably they were published together, RFC4291 could have >> marked the ULA space in the addressing architecture, and point to >> RFC4193 for further details). >> >> BTW, there are no macros that would distinguish ULAs them from regular >> global addresses: https://tools.ietf.org/html/rfc2553#section-6.7 >> >> >> >> >>> (I think it's a bug in RFC4193 that it didn't make an update to >>> RFC3513, the predecessor of RFC4291, which actually foresaw such a >>> case: "Future specifications may redefine one or more sub-ranges of >>> the global unicast space for other purposes, but unless and until >>> that happens, implementations must treat all addresses that do not >>> start with any of the above-listed prefixes as global unicast >>> addresses.") >> >> Ok, it looks like we are on the same page. :-) >> >> >> >> >>>> Therefore, ULAs are not globally meaningful and thus, for most (if >>>> not all) practical purposes, ULAs can be considered to have non- >>>> global scope. For this reason, ULAs are treated as non-global >>>> scope addresses, even when from a specifications point of view >>>> they have global scope. >>> >>> I don't accept that. I believe we've had that discussion and the >>> consensus is in RFC8190 and the IANA registry already. >> >> Sorry: what we *meant* here is that, throughout our document, when we >> refer to "non-global addresses" we are also thinking about ULAs. >> >> (e.g., the "possible isolation provided by the address scope" applies >> (to different degrees) to both e.g. link-locals and ULAs...) >> >> >> >> >>> Later in the draft you say: >>> >>>> In the same light, a ULA prefix generated by a local router will >>>> be, by definition, provider independent. However, a router might >>>> also be leased an ULA sub- prefix from its upstream, in which case >>>> this prefix would be "provider dependent". >>> >>> Exactly. This illustrates that as far as protocols go, ULA prefixes >>> behave exactly like RIR-assigned prefixes. >> >> Couldn't one also argue that ULAs are, e.g., "IPv6 private address >> space" and that, as with the RFC1918 space, no special provisions are >> needed in routing protocols -- other than one filtering prefixes >> when/where deemed appropriate? >> >> >> >>> They are global in >>> protocol terms, but not globally routed in operational terms. These >>> are orthogonal properties. >> >> Sorry for insisting on this one -- I'm bringing up this issues because I >> found myself trying to provide an explanation for "global in protocol >> terms", without a lot of success. :-) >> >> It would seem to me that virtually every use of "global" for ULAs >> (modulo ULA-C, I guess) is, conceptually speaking, kind of cumbersome >> and incorrect. -- and creates expectations that, at the end of the day, >> are probably not going to be fulfilled. >> >> Wouldn't the most natural thing be to flag ULAs as "IPv6 Private Address >> Space", where e.g. from the point of view of protocols, the same >> considerations as for RFC1918 apply (no, I wouldn't *say* this in a >> spec), and we simply have the additional feature in the spec that we >> recommend how to generate the ULAs prefixes to avoid possible hassles >> when merging two different networks? >> >> Or, to put in a different way: RFC1918 is private address space, and we >> don't need to call it "global" in any way to flag the fact that >> addresses from that private address space are not treated in any special >> way by e.g. routing protocols -- for instance, why should they? >> >> >> Thanks! >> >> Regards, and Merry Christmas! >> From nobody Tue Dec 29 07:02:00 2020 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 5C5263A1420; Tue, 29 Dec 2020 07:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=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 GAdZDzfXZi9O; Tue, 29 Dec 2020 07:01:53 -0800 (PST) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B81D3A141E; Tue, 29 Dec 2020 07:01:47 -0800 (PST) Received: from [10.0.0.134] (unknown [186.19.8.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 8D5C2280496; Tue, 29 Dec 2020 15:01:42 +0000 (UTC) To: Brian E Carpenter , IPv6 Operations , draft-gont-v6ops-ipv6-addressing-considerations@ietf.org References: <160770241261.18071.12524922630334294118@ietfa.amsl.com> <299f492f-4cb7-fa9d-967f-b2a5df49034e@si6networks.com> <759efdb1-a59c-788c-0c7a-5a8ca2ced904@gmail.com> From: Fernando Gont Message-ID: Date: Tue, 29 Dec 2020 12:00:27 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <759efdb1-a59c-788c-0c7a-5a8ca2ced904@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-gont-v6ops-ipv6-addressing-considerations-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 15:01:58 -0000 Hi, Brian, Thanks for following up! In-line..... On 24/12/20 19:15, Brian E Carpenter wrote: [....] >> >> Now, my question is: why do this in the first place? What I would expect >> is that you simply use the address. Then, if the same node attaches to >> two networks that employ the same prefix, that's a configuration >> problem. Period. *If* in such scenario, *and for debugging purposes* you >> want to be able to specify which interface to use to send packets to a >> site-local address (that looks like "on-link" on two different >> interfaces), then you use the zone index -- but that's for *debugging* >> purposes, since having two subnets employ the same site-local prefix >> would be an error. > > If you read RFC4007 I had read RFC4007 in the past -- *years* ago. So I've just given it a fresh read. Some initial questions: * Any reason why this document is a separate/stand-alone document rather than part of RFC4291 (or RFC3513)? Or, at the very least, any reasons why it does not even *update* one of those? (RFC3513, since RFC4007 obviously predates RFC4291) (particularly since it's Std Track) * Section 5 states: Each interface belongs to exactly one zone of each possible scope. Note that this means that an interface belongs to a scope zone regardless of what kind of unicast address the interface has or of which multicast groups the node joins on the interface. This would seem to imply that an interface cannot employ two different ULA prefixes? -- Why? (unless their scope is considered global, and all ULAs plus GUAs are all considered to be part of the same global scope zone) > you will *not* find that a zone index is formally > equated to an interface index. The "zone" terminology is confusing since > it did originally assume a nested scope model, link-local inside site-local > inside global. (me thinking out loud) It seems that it *cannot* be equated, since an interface may (and usually will) belong to multiple zones. So the zone index somehow ends up being the combination of "address" + "interface index", where the implementation infers the scope from the "address"? (this isn't really a "zone index", though). > By some magic the host was supposed to understand enough > of the network topology to use a single value "zone index" to capture > the topology and tell the drivers which interface to use. See diagrams > at https://sites.google.com/site/bcabrc/miscellany . > Slides 3 and 4 show scenarios that simply can't be captured > by a one-dimensional zone index. In practice, of course, the zone index > is only meaningful within the host. Isn't this the case *by definition*? > So the whole concept of a zone > index for nested scopes was a mistake. With hindsight, we should > have cleaned that up more definitively in RFC4007. You mean that it's problematic for the node to *automatically* determine which zone an address belongs to? If so, yes -- that seems unfeasible. The best you can hope is the "default zone index" (which can indeed fail), or manual specification of the "zone index". >> Regarding #2: >> Modulo the above, for the most part non-global addresses *are* >> ambiguous. So this is kind of a feature. > > Yes, but not a *good* feature since it leads to the problems > in my slides 3 and 4. But... are site-locals special in this respect? -- As with link-locals on multi-interface nodes, you either manually pick the outgoing interface (and hence the zone), or your rely on the default zone index (and cross your fingers :-) ). [....] >>>> 3.2. Unique Local IPv6 Unicast Addresses (ULAs) >>> ... >>>> However, the only reasons for which these addresses are considered >>>> to have "global scope" are: >>>> >>>> o given two different networks that employ ULAs, it's unlikely >>>> that they will employ the same ULA prefix >>> >>> Not at all. The reason they formally have global scope is because >>> when site-local was scrapped (as being meaningless and unenforcable, >>> see RFC3879), only two scopes were left: link-local and global. >>> There was no other choice. >> >> Why not, say, "IPv6 Private Address Space"? -- Yes, in the light of >> "ipv6 is all about the global addresses", mimicking IPv4's private >> addresses probably wasn't "sexy", but IMO the concept is useful, and >> well understood. > > I think that adds confusion. They are only private because of the > requirement to block them in border routers; it's not a property > of the address itself. In a way, isn't that the case for all non-global addresses? e.g. for link-locals as Destination Addresses it's kind of hardcoded. But for link-locals employed as Src Address, you also need the requirement for routers to drop the packets to prevent these addresses from leaking out of their zone. (But yes, for link-locals this check can also be hardocded). > (Thumbs down to the Python ipaddress module > by the way, which has invented an "is_private" property and gets > "is_global" wrong for ULAs.) Assuming ULAs are flagged as "global", I guess that's a consequence of RFC4291 (or it's antecessor) not being updated by the ULA spec? >>> What that means is that protocols treat >>> them *exactly the same* as RIR-assigned prefixes. That applies to >>> all protocols: ND, RA, DHCPv6, and every routing protocol. They are >>> only treated differently by policy, such as address selection policy >>> or boundary router policy. >> >> Wouldn't this also be the case if they were redefined as "IPv6 private >> address space"? i.e., from the point of routing, modulo the link-local >> prefixes, you simply have prefixes that you distribute information >> about. i.e. "Private address space" (i.e., non-global) shouldn't be >> treated differently by routing protocols. > > It's true, but that's what the "global" property means, and it's different > from "globally reachable". You mean "global" as in "global scope"? Section 4 of RFC4007 says: Every IPv6 address other than the unspecified address has a specific scope; that is, a topological span within which the address may be used as a unique identifier for an interface or set of interfaces. As you noted in a previous email, this is probably unlikely for 40-bit global IDs (but should compute the birthday problem for this case) -- this might improve with RFC7217 (assuming randomized secret_keys for the algorithm)... but you could still have manually configured IIDs. So in that sense, I wouldn't consider ULAs as "global scope", either. (must admit had to go through RFC8190 and friends a few times...) Thanks, and Happy Holidays! Regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Dec 29 12:44:41 2020 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 AA3973A09D6 for ; Tue, 29 Dec 2020 12:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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=juniper.net header.b=vqWf7UFx; dkim=pass (1024-bit key) header.d=juniper.net header.b=AC1z+3AH 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 6hRTBnF4h_YC for ; Tue, 29 Dec 2020 12:44:38 -0800 (PST) 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 3F5AF3A09CF for ; Tue, 29 Dec 2020 12:44:38 -0800 (PST) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0BTKiTLA012663; Tue, 29 Dec 2020 12:44:37 -0800 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 : mime-version; s=PPS1017; bh=sSnQmtZPSYN7Ep09V4REtnRDwYby1y/2Gj+l8OVR6W4=; b=vqWf7UFx83Bkip1Mb9Fs6ICeWUon8FTFIq0oH1frlNRMASOTh46u5grYFQY5KFT1Xtyz /DzknNm34XlSo4YdiGP3CBk0Vz5yRwqV+eqYhRkjtcpucyT84BUTE9xXmlL4Bk5K3h0u H2zy4wfKv30zIEZ1KIY+7PAecfWqISWLbNj1YHpfRhqz/AFO2Z9cGgqpfzqCzV4ghqBs t8FgaDQ+TvFCXgNLkL5u6ng2Bhd5T/0dwdopc8LleOx63hmFW1mlQ9TyN5ZFASKV4mxL vhQ/okb0m9hef7bPtkaWQ5Ue4kpQA8Yc36ZzvbiHy8O97jaEFF2SpjaC4miaTC1dpL9n 8A== Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2103.outbound.protection.outlook.com [104.47.58.103]) by mx0a-00273201.pphosted.com with ESMTP id 35q9nxabc4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 29 Dec 2020 12:44:37 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lC0EatHDzylxodtR+LNhO4i3NS7cDb/76JSwZqNznHNMxbvBGJrhFevVVZ2ivTEcQNhnl19BxUF2sQlRA/6AvzxjJdJhWi5JKzeB1qz3caBM/VI2/gU78fn+5o+3+dSgKspWd9RqBiVbY37QuvG5JGOFPaG1lb+OYhlDEdXE6JjGgmB0NbQL8n6l3CxgA628tP/pPtsRRpzDIM9to2pwG6YUUFj17WQQc5DU+TGnl63EkfHsyf/aYNoMPWnre5x/eU5+R3/WTPI8czrqlrpfL0VQlk6wohxhT+rjjRXITMdpTycj9mq3oWTPw6fGWvUt64W5oeuOsTd+aQ5NE5Cfkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sSnQmtZPSYN7Ep09V4REtnRDwYby1y/2Gj+l8OVR6W4=; b=RpSzQvkmD8IXqDe2nBNvE6PBTqhadjJ5gWN12XaC7F6EqX8Ahq9Qrb5cNJL/mQHNb8x83DIfkAS8s7gxWv+HmEI0CC7JYA/lf3c6Uxho3mnktP0BNt+01He2VxYT7AUtvim82Vjztr4UF/c/ipGnluNUmVx7MSaaEJ4J0TjUzo0OAGheBeFy7SRm4YhBwTnRqr4o+uSPNSwSF1idhH64r7RQlloCRZskp4fIREYsOLjOoNHuBXKVbY+ofDkSC7pwcU5OP5JijiZzdSrt7v1MehSFD9wKShmVdjDqfzPMu23rOTV0VKwTFdV1MMnPDHIK5uFh/bj1+qNA45lDLxLuCw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sSnQmtZPSYN7Ep09V4REtnRDwYby1y/2Gj+l8OVR6W4=; b=AC1z+3AHmJJIYCuNzU2Jyk5nbR6mrkUgyupxguJNoc3joN90G8z9fXxdjpgxSncNIuxQ+EDpxcSptMI/ntWRcjb7jv/dsYi/EgenunLZ0XKcfW5RNXqBT6C6K4A7295iV1fo50/ElBuXxR2FsdehdNhvnS15N04IqUK0eTmttaE= Received: from DM6PR05MB6348.namprd05.prod.outlook.com (2603:10b6:5:122::15) by DM6PR05MB5179.namprd05.prod.outlook.com (2603:10b6:5:77::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3721.11; Tue, 29 Dec 2020 20:44:35 +0000 Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::a435:88ed:7e2a:4fe6]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::a435:88ed:7e2a:4fe6%5]) with mapi id 15.20.3721.019; Tue, 29 Dec 2020 20:44:35 +0000 From: Ron Bonica To: "v6ops@ietf.org" , Warren Kumari Thread-Topic: WGLC draft-ietf-v6ops-cpe-slaac-renum Thread-Index: AdbUn4KQzD3Awd89TBKR+ahShiehygJg8EKg Date: Tue, 29 Dec 2020 20:44:35 +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.5.0.60 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-12-29T20:44:34Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=0bd23c93-d0f0-4d08-90f8-789a85516750; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [173.79.115.7] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: d7de085d-8c68-43eb-8558-08d8ac3a8dad x-ms-traffictypediagnostic: DM6PR05MB5179: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4941; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qrbydHv2E5HR/oUQizb6g1ZIIxLfbkruEnF/ngxi1auTlz5+mgN/90yWaIZd1oPFBbm2o9Sv4YMDOk9ZBwSqsPp6sfoh3bYw1hmiJlBAr5YTXqeW1YtBt4KuhCclYFgRMJ8GYOrpYLgsMkblzVxJnDveT+rCKmoJGGdg44hGbwK2zpE7Gd31dlcA3IlCcPOFPmbd11Odbm2+24NCJem1TFV4coM9Uq2O6go3AIecdqWQmEOInOj6Ah9z/9JBuPf+O3fGZa6v5MYsdN9W1f7IPaDVKo7Kof3FGNZSGlXs+fK/AN78/on7034WD40a7IGmnhOFqYphoY93buxyziLSiwPpWqctD5p1jFULdvMErJQgU4yoFdf1dA4fXCkMzhIPfobZlixsBOsJ1mexPGUmuQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6348.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(366004)(376002)(396003)(39860400002)(136003)(83380400001)(71200400001)(186003)(8936002)(64756008)(66946007)(76116006)(86362001)(4744005)(66556008)(66476007)(2906002)(26005)(478600001)(52536014)(6506007)(7696005)(55016002)(66446008)(5660300002)(9686003)(316002)(8676002)(33656002)(53546011)(110136005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?qPx44jEp8YdkOdt+cqy/F2mT5niaGpxF5kV2t2MllboAtAkO7QjSAnnEnqCF?= =?us-ascii?Q?j/YDdZMETDc0t7JtraDAUkKOXQ48eA4vPAv9eZS5SB+PaRqbWG5jCoTzdT2e?= =?us-ascii?Q?vEzUmvUTz1DsG/3JkET87Cw2sdsPNPBLEAtuVM3qSiy34KrK8lxs04M2l2bQ?= =?us-ascii?Q?DseRCLk4tOQjOw4+nRdw8pZcp14SveAyTnfZkxIjYiXAWDanDTHD68N+z/gx?= =?us-ascii?Q?4jFzrqTZ9T7hPFYqqnrzYKBs8zBj/kIXupq55YSdKLppsJonRqNH2K9gODMk?= =?us-ascii?Q?CDAK78fClLscney2kFNctQMiFi6dz0e2k+t7744vBYMBNK29MGQGfAAFlW0j?= =?us-ascii?Q?nKPBcGntWrP3Lp4q+EmnBRefE5nacr+OSaugYnh2D/XCJyHYZFgICAom6oNd?= =?us-ascii?Q?IdqvAmfe8mTyr9Oz8yvLofUFDtmTxld//ERkid0fmscjkY/UsjJrs5mS/klO?= =?us-ascii?Q?+jFZnl10ewrJgLOT05itYrgzug4RQC/SW5UvyZ8B5k5up0G6HFnq3UrxsmS6?= =?us-ascii?Q?bb53Xl9G62HD3jIBkbZo60xJYLF2kDDQvhFkXE0fqWk+KgelHueaz56n6BPN?= =?us-ascii?Q?xio5iazyXnSBedOBkuoJkiEuVzJlqE3R7EK0apm+vFPDKGAlcgXXqagGp/jA?= =?us-ascii?Q?Ve4ZC/7gUVuaf84Q45SgUwJd3D9/UkX2Cp+OmuzV44STFJX7/+FgWwj/FBck?= =?us-ascii?Q?rqALKbx6dEaXJNBDt+ZGt1bbv+WGy41t2FZosGfjaZzvrksxqqsI6FEAPE4l?= =?us-ascii?Q?WlJ3XnP0KZif7TDRgxib0rtdCDSidZ8iA4Ngcj6lv1CqotXq5eTrAt45VvIC?= =?us-ascii?Q?Uyqzshghbl0ud5PPk1w3QxoP0PPRsufYi3CDzHn5kWlfAFY6aX8HOccIlUNh?= =?us-ascii?Q?toVyFC8N4J/WwvReMv0GM/XV8cfBhZcFGFUEkY0Zt7fBHVZ9dEZRchM4+7eR?= =?us-ascii?Q?N2bohjk3rgIJVh6s3lyxRRNcxlTZ6ABhv+3eMznaZKc=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR05MB6348E148DF4BE8489446597BAED80DM6PR05MB6348namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR05MB6348.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d7de085d-8c68-43eb-8558-08d8ac3a8dad X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Dec 2020 20:44:35.7275 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: V5w7wqp5Zy7TKxW+tLSgqAO8kwluOCb9kqspdkIGrCOz9HmH8QHoZD0OZkBrFTdsPNJ+tuiJJKYMtOtg0jHKhQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB5179 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-29_16:2020-12-28, 2020-12-29 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 malwarescore=0 spamscore=0 adultscore=0 bulkscore=0 suspectscore=0 impostorscore=0 lowpriorityscore=0 mlxlogscore=922 clxscore=1011 mlxscore=0 priorityscore=1501 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012290127 Archived-At: Subject: Re: [v6ops] WGLC draft-ietf-v6ops-cpe-slaac-renum X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Dec 2020 20:44:40 -0000 --_000_DM6PR05MB6348E148DF4BE8489446597BAED80DM6PR05MB6348namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, This email ends the WG Last Call. Warren, The draft is back in your hands. Ron Juniper Business Use Only From: Ron Bonica Sent: Thursday, December 17, 2020 1:10 PM To: v6ops@ietf.org Subject: WGLC draft-ietf-v6ops-cpe-slaac-renum Folks, This email begins a one week last call on draft-ietf-v6ops-cpe-slaac-renum.= The scope of this last call is limited to text that has changed since the = document was sent to the IESG. = Ron Juniper Business Use Only --_000_DM6PR05MB6348E148DF4BE8489446597BAED80DM6PR05MB6348namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

This email ends the WG Last Call.

 

Warren,

 

The draft is back in your hands.

 

         &nb= sp;            =             &nb= sp;Ron

 

 

 

Juniper Business Use Only

From: Ron Bonica
Sent: Thursday, December 17, 2020 1:10 PM
To: v6ops@ietf.org
Subject: WGLC draft-ietf-v6ops-cpe-slaac-renum

 

Folks,

 

This email begins a one week last call on draft-ietf= -v6ops-cpe-slaac-renum. The scope of this last call is limited to text that= has changed since the document was sent to the IESG.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Ron

 

 

Juniper Business Use Only

--_000_DM6PR05MB6348E148DF4BE8489446597BAED80DM6PR05MB6348namp_-- From nobody Wed Dec 30 16:00:14 2020 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 4AD293A0BEE; Wed, 30 Dec 2020 16:00:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk CC: Owen DeLong , draft-ietf-v6ops-cpe-slaac-renum@ietf.org, owen@delong.com, v6ops-chairs@ietf.org, v6ops@ietf.org, warren@kumari.net Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <160937280919.30572.6826550493774973607@ietfa.amsl.com> Date: Wed, 30 Dec 2020 16:00:09 -0800 Archived-At: Subject: [v6ops] Last Call: (Improving the Reaction of Customer Edge Routers to Renumbering Events) to Best Current Practice X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 00:00:10 -0000 The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Improving the Reaction of Customer Edge Routers to Renumbering Events' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2021-01-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. This is the second IETF LC for this document -- it was originally LCed as Informational. IESG Eval suggested that it was more BCP-like, and so the document was returned to the V6OPS WG, and re-WGLCed as BCP. It is now being IETF LCed as BCP, and will then go through IESG Eval again.... and the process-elves rejoice... Abstract In scenarios where network configuration information becomes invalid without any explicit signaling of that condition (such as when a Customer Edge Router crashes and reboots without knowledge of the previously-employed configuration information), hosts on the local network will continue using stale network configuration information for an unacceptably long period of time, thus resulting in connectivity problems. This document specifies improvements to Customer Edge Routers that help mitigate the aforementioned problem for typical residential and small office scenarios. This document updates RFC7084. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc4191: Default Router Preferences and More-Specific Routes (Proposed Standard - IETF stream) rfc4861: Neighbor Discovery for IP version 6 (IPv6) (Draft Standard - IETF stream) rfc4862: IPv6 Stateless Address Autoconfiguration (Draft Standard - IETF stream) rfc8106: IPv6 Router Advertisement Options for DNS Configuration (Proposed Standard - IETF stream) rfc8415: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (Proposed Standard - IETF stream) From nobody Wed Dec 30 17:00:42 2020 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 B336A3A0CF5; Wed, 30 Dec 2020 17:00:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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 E63SAegW1j6S; Wed, 30 Dec 2020 17:00:37 -0800 (PST) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 B5C743A0CEB; Wed, 30 Dec 2020 17:00:37 -0800 (PST) Received: by mail-pj1-x102f.google.com with SMTP id b5so4589464pjl.0; Wed, 30 Dec 2020 17:00:37 -0800 (PST) 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=qeO8bzy3gZTamCq48Ofo2oUFZtBCj/JR3UmVlFSdJU0=; b=sjyx9IHYrFBckSZRg9qXeK6oos+dv+BFwBBLHXNeEIdGLAYWe2CAQhgJfD087TlB2r SZe6bxH340UmTfQ4xvHtkc4DoXlOqfRGa0yH7dHyTm1PNG9KddVn8sd0BZ4JtcQW1xlv eeKWT/kDdAa1V0/ZgvtXYzOMShbJTfZd4RNfn5lxBBpXKCC3RZhiv4+5aAPwb4Br90jL CZrsFvgBFLFmT29rgjbNyj/N20dkYWDYENEq9wOXGWuP/lUPkqjxrSI/phNp5mfxMN8Z Xcc5refiODCDUCgHeKVMcJIVPZmTcCRJ1oCfq+uJF032X/51rB/pu9XJvFzt8X3z7Yrz r60A== 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=qeO8bzy3gZTamCq48Ofo2oUFZtBCj/JR3UmVlFSdJU0=; b=ozXlaEvIy4RPl6IClqmjUa2COujiA2CfKixAh193GNFuD9Q0oHjHMHCOl3x0A31obQ z1SpxC4Fj3fjRrD4/Gra8QgoYGKsJ6EHOeFkNXXNPiPhgmnwIkhtSn42pQeae8ZnoD6v uGEZMcsDQdVZRkRGT1Sur/Qh52fNt+84mf7Bsl2m9jwWzhlkBQhewJwqR/8HrtSzngR7 f93Awie9AlomuNVt1iGhNMs6K5gbpqTVyT8hKKV7lHpUI4yTDAFy/FkL2i8jJJoguPy8 Hlysa0KLNEfAQOJS8Dh0wAuIpAbAKVd6raO+zeT5Mjx1NosutMknayaHncZD05T7cL8S tvrw== X-Gm-Message-State: AOAM533h3AYUaOVtnqvjxETJQn4XNqYtJIFMbRdARRhMu8z/JWR2hbm+ Uq+KOCgmZAdKPp9Ber5W5M2qZ/YoQ76Ksg== X-Google-Smtp-Source: ABdhPJysA+wi7rvUwq+Z33bF9n2TpcB+dRNBWhJn29MvakAWHKlhKtNcoxSj47GJMtrRvnm0NdxbWw== X-Received: by 2002:a17:90a:fd08:: with SMTP id cv8mr10768998pjb.29.1609376436721; Wed, 30 Dec 2020 17:00:36 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id h10sm40122928pfn.213.2020.12.30.17.00.34 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Dec 2020 17:00:35 -0800 (PST) To: Fernando Gont , IPv6 Operations , draft-gont-v6ops-ipv6-addressing-considerations@ietf.org References: <160770241261.18071.12524922630334294118@ietfa.amsl.com> <299f492f-4cb7-fa9d-967f-b2a5df49034e@si6networks.com> <759efdb1-a59c-788c-0c7a-5a8ca2ced904@gmail.com> From: Brian E Carpenter Message-ID: Date: Thu, 31 Dec 2020 14:00:33 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.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] I-D Action: draft-gont-v6ops-ipv6-addressing-considerations-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 01:00:40 -0000 Hi, Fernando and I have been chatting off-list, so rather than responding in detail below, here are just a few general observations: 1. We have a problem with the formal definition of "global". All it really means in the IPv6 addressing architecture is "not link-local", which is not "global" in the normal English sense. It really seems too late to change that, but it's unfortunate. 2. The "globally reachable" term added by RFC 8190 isn't perfect either. All it really means is "potentially globally reachable" because prefixes don't *have* to be advertised in BGP4. 3. If we're picky, "local" in ULA isn't perfect either, since there's nothing in the laws of physics to prevent a ULA prefix being advertised in BGP4. 4. The following table attempts to show some of the distinctions involved (simplified). View in a fixed-width font. You may not agree with it... Unicast Prefix IID Routeable Announced address assigned assigned types by by ----------------------------------------------------------- Link-local fixed host no no by RFC ULA user/RA host or yes IGP only (random) DHCPv6 GUA IANA/RIR/ host or yes IGP, ISP/user/RA DHCPv6 BGP4 by policy Regards Brian On 30-Dec-20 04:00, Fernando Gont wrote: > Hi, Brian, > > Thanks for following up! In-line..... > > On 24/12/20 19:15, Brian E Carpenter wrote: > [....] >>> >>> Now, my question is: why do this in the first place? What I would expect >>> is that you simply use the address. Then, if the same node attaches to >>> two networks that employ the same prefix, that's a configuration >>> problem. Period. *If* in such scenario, *and for debugging purposes* you >>> want to be able to specify which interface to use to send packets to a >>> site-local address (that looks like "on-link" on two different >>> interfaces), then you use the zone index -- but that's for *debugging* >>> purposes, since having two subnets employ the same site-local prefix >>> would be an error. >> >> If you read RFC4007 > > I had read RFC4007 in the past -- *years* ago. So I've just given it a > fresh read. > > Some initial questions: > > * Any reason why this document is a separate/stand-alone document rather > than part of RFC4291 (or RFC3513)? Or, at the very least, any reasons > why it does not even *update* one of those? (RFC3513, since RFC4007 > obviously predates RFC4291) (particularly since it's Std Track) > > * Section 5 states: > Each interface belongs to exactly one zone of each possible scope. > Note that this means that an interface belongs to a scope zone > regardless of what kind of unicast address the interface has or of > which multicast groups the node joins on the interface. > > This would seem to imply that an interface cannot employ two different > ULA prefixes? -- Why? (unless their scope is considered global, and all > ULAs plus GUAs are all considered to be part of the same global scope zone) > > > >> you will *not* find that a zone index is formally >> equated to an interface index. The "zone" terminology is confusing since >> it did originally assume a nested scope model, link-local inside site-local >> inside global. > > (me thinking out loud) It seems that it *cannot* be equated, since an > interface may (and usually will) belong to multiple zones. > > So the zone index somehow ends up being the combination of "address" + > "interface index", where the implementation infers the scope from the > "address"? (this isn't really a "zone index", though). > > > >> By some magic the host was supposed to understand enough >> of the network topology to use a single value "zone index" to capture >> the topology and tell the drivers which interface to use. See diagrams >> at https://sites.google.com/site/bcabrc/miscellany . >> Slides 3 and 4 show scenarios that simply can't be captured >> by a one-dimensional zone index. In practice, of course, the zone index >> is only meaningful within the host. > > Isn't this the case *by definition*? > > > >> So the whole concept of a zone >> index for nested scopes was a mistake. With hindsight, we should >> have cleaned that up more definitively in RFC4007. > > You mean that it's problematic for the node to *automatically* determine > which zone an address belongs to? > > If so, yes -- that seems unfeasible. The best you can hope is the > "default zone index" (which can indeed fail), or manual specification of > the "zone index". > > > > >>> Regarding #2: >>> Modulo the above, for the most part non-global addresses *are* >>> ambiguous. So this is kind of a feature. >> >> Yes, but not a *good* feature since it leads to the problems >> in my slides 3 and 4. > > But... are site-locals special in this respect? -- As with link-locals > on multi-interface nodes, you either manually pick the outgoing > interface (and hence the zone), or your rely on the default zone index > (and cross your fingers :-) ). > > > > [....] >>>>> 3.2. Unique Local IPv6 Unicast Addresses (ULAs) >>>> ... >>>>> However, the only reasons for which these addresses are considered >>>>> to have "global scope" are: >>>>> >>>>> o given two different networks that employ ULAs, it's unlikely >>>>> that they will employ the same ULA prefix >>>> >>>> Not at all. The reason they formally have global scope is because >>>> when site-local was scrapped (as being meaningless and unenforcable, >>>> see RFC3879), only two scopes were left: link-local and global. >>>> There was no other choice. >>> >>> Why not, say, "IPv6 Private Address Space"? -- Yes, in the light of >>> "ipv6 is all about the global addresses", mimicking IPv4's private >>> addresses probably wasn't "sexy", but IMO the concept is useful, and >>> well understood. >> >> I think that adds confusion. They are only private because of the >> requirement to block them in border routers; it's not a property >> of the address itself. > > In a way, isn't that the case for all non-global addresses? e.g. for > link-locals as Destination Addresses it's kind of hardcoded. But for > link-locals employed as Src Address, you also need the requirement for > routers to drop the packets to prevent these addresses from leaking out > of their zone. (But yes, for link-locals this check can also be hardocded). > > > >> (Thumbs down to the Python ipaddress module >> by the way, which has invented an "is_private" property and gets >> "is_global" wrong for ULAs.) > > Assuming ULAs are flagged as "global", I guess that's a consequence of > RFC4291 (or it's antecessor) not being updated by the ULA spec? > > > > > >>>> What that means is that protocols treat >>>> them *exactly the same* as RIR-assigned prefixes. That applies to >>>> all protocols: ND, RA, DHCPv6, and every routing protocol. They are >>>> only treated differently by policy, such as address selection policy >>>> or boundary router policy. >>> >>> Wouldn't this also be the case if they were redefined as "IPv6 private >>> address space"? i.e., from the point of routing, modulo the link-local >>> prefixes, you simply have prefixes that you distribute information >>> about. i.e. "Private address space" (i.e., non-global) shouldn't be >>> treated differently by routing protocols. >> >> It's true, but that's what the "global" property means, and it's different >> from "globally reachable". > > You mean "global" as in "global scope"? > > Section 4 of RFC4007 says: > Every IPv6 address other than the unspecified address has a specific > scope; that is, a topological span within which the address may be > used as a unique identifier for an interface or set of interfaces. > > As you noted in a previous email, this is probably unlikely for 40-bit > global IDs (but should compute the birthday problem for this case) -- > this might improve with RFC7217 (assuming randomized secret_keys for the > algorithm)... but you could still have manually configured IIDs. So in > that sense, I wouldn't consider ULAs as "global scope", either. > > (must admit had to go through RFC8190 and friends a few times...) > > Thanks, and Happy Holidays! > > Regards, > From nobody Thu Dec 31 02:30:18 2020 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 062053A0BF8 for ; Thu, 31 Dec 2020 02:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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=space.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 Lh4cvZGOTrrb for ; Thu, 31 Dec 2020 02:30:14 -0800 (PST) Received: from gatekeeper1-relay.space.net (gatekeeper1-relay.space.net [IPv6:2001:608:3:85::38]) (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 5BFCA3A0BF3 for ; Thu, 31 Dec 2020 02:30:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=space.net; i=@space.net; q=dns/txt; s=esa; t=1609410614; x=1640946614; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=AE2ixCYP522hmNPotdstPN+pYkzniamaKSquNlWJvZE=; b=E1JGwdgi47P96JfBU7yDTHM9QiL7KKsKAEiVvjwQWRkW0mm3iZE9Zmip +wIpVeitOCc4szViTY9PeZ97RGo9qy0x5fL3We2gCCPdHEQrAOtsUD88N ZGv+MKlquXJt095E3kGGanCIdePfHpr8Oh+/EsFoiRS1BzPB08Xn63mgz SWeEFU9xbQGq0Q6g1PQfLwdEqjPjOSlR+VQISmjidrFxzDKSPTkzkVaSI QRwBSOWeIRK8dSzLA37nxDsdUcjwZLEzDTEI3v3TRyRxP0o6FQ5kt44Oh FXpBpjSXGkKzcyKEVFMm/Vbjngv/LeI5G9hhmHdqHlycjC/Q+466FSota w==; IronPort-SDR: GoMYBeoHzaE0SEZMajjI7rtCt7AxKqMihETe/rGho3Bsbn9idwRoXh6CaO0nYBrViXySWniY0C +qqD/zY/Y3/KUVuMlzgB1xr2ZdK3lPnG09eFZNmLdOjaNhlVG9ziu8774Jk1JBVLQU4luDQinL +nyeG2AQyrNzESeqcUCBtSgdVLN1iobUK/AFMzICz8BxSA9qcYPk1KwjGDT8vCtNzH8HvF1Gi7 Ls8tMPz7kvbAZEr3n8GH6AE61iZ0pHJaWMJHrRzBtAQhRROiketpxC9Q7kwnghlqmJoM54VIzr esA= X-SpaceNet-SBRS: None Received: from mobil.space.net ([195.30.115.67]) by gatekeeper1-relay.space.net with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Dec 2020 11:30:10 +0100 X-Original-To: v6ops@ietf.org Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 6EF3C41D2F for ; Thu, 31 Dec 2020 11:30:10 +0100 (CET) X-SpaceNet-Relay: true 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 1F26E41C82; Thu, 31 Dec 2020 11:30:10 +0100 (CET) Received: by moebius4.space.net (Postfix, from userid 1007) id 1776815F74; Thu, 31 Dec 2020 11:30:10 +0100 (CET) Date: Thu, 31 Dec 2020 11:30:10 +0100 From: Gert Doering To: Brian E Carpenter Cc: Fernando Gont , IPv6 Operations , draft-gont-v6ops-ipv6-addressing-considerations@ietf.org Message-ID: <20201231103010.GL13005@Space.Net> References: <160770241261.18071.12524922630334294118@ietfa.amsl.com> <299f492f-4cb7-fa9d-967f-b2a5df49034e@si6networks.com> <759efdb1-a59c-788c-0c7a-5a8ca2ced904@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [v6ops] I-D Action: draft-gont-v6ops-ipv6-addressing-considerations-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 10:30:17 -0000 Hi, On Thu, Dec 31, 2020 at 02:00:33PM +1300, Brian E Carpenter wrote: > 4. The following table attempts to show some of the distinctions > involved (simplified). View in a fixed-width font. You may not > agree with it... > > Unicast Prefix IID Routeable Announced > address assigned assigned > types by by > ----------------------------------------------------------- > Link-local fixed host no no > by RFC > > ULA user/RA host or yes IGP only > (random) DHCPv6 > > GUA IANA/RIR/ host or yes IGP, > ISP/user/RA DHCPv6 BGP4 by policy Indeed, I am not agreeing - as there is nothing that prevents ULAs from being transported by BGP. We use ULAs for "services that must never reachable from the Internet", and our routing being what it is, everything is transported by BGP - only loopbacks in OSPF. The difference is "do we announce it to other ASes?" So maybe this should be "generally expected to be visible by other networks on the Internet" (ULA: no, GUA: yes). But that's neither precise nor does "expected" mandate anything - I might want to announce our ULA prefix to our sister company, using eBGP, and I might decide to not announce our GUA IPv6 PI /48 that we use for our backbone infra "because people are not supposed to send packets there"... 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 Thu Dec 31 11:47:38 2020 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 22A6E3A08C5; Thu, 31 Dec 2020 11:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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 XAmqHggQVNlg; Thu, 31 Dec 2020 11:47:35 -0800 (PST) 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 E15223A08BD; Thu, 31 Dec 2020 11:47:35 -0800 (PST) Received: by mail-pg1-x535.google.com with SMTP id g15so13523679pgu.9; Thu, 31 Dec 2020 11:47:35 -0800 (PST) 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=SsqagLPtKzm1ijS0nbH9eTvO6wn4Oes5xwT875AUme0=; b=mdUjE6N6zOQ1HU4cx9TSzXYd5GH8porTrxm3VEDnByCUcrIT3sacXnQVqkFDCJVmct kZY/v3T3RM7FIV/6ZXOwsIHugTM3eMa+b1srzcLup4LcO6ctPghoHlLO241Lo28ErSUc pc8FMEUDq1YcngXDao+2naqOl5tyB4vqqNnZ7j37mN/KkOeb8h/zvOLvfrrDCYvn4ZU6 s54qoGjsTCCj2FKEHlGc5XPVQlLHaMzutBqPA+ETSO2BIQqx8/2TMLWm21oIRKU8ZuKK nQEly1sSKY4/BCT959Stv7jvxNc9AS+bu0kZCtR3f+iho4HxpN7LdhU0l/6pKNq77vo6 XzKw== 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=SsqagLPtKzm1ijS0nbH9eTvO6wn4Oes5xwT875AUme0=; b=XKJOMalh7ZESO3WtuRn6Q1T3bNdN1g0zXKe15ns2V45cyJzkddNZLjLZsjHQnvkWNJ vXcSK3ps8kb8D/A5w9yuBBai7vRlHmmc+t+1bW8PsZaiKbZIP8jwGZqkXQxXV+2TiV+k xyOt/sTUxEiecs+ZEZMs07FapjblNnZxiw947+rPqR3ts7qBllaiONAhNVolLBIs1N2v Gl/gtmsaULY68waJYC4alouC6WpNYeY+AUi/N2XMVw2ASqSlUCKmwl78yj7VxizXB8IB WyC5oRNf805Ax0R6VnaKIPQLxAhQktnEnq9PEuzDHQCvI2PwfnKCOwdJIFVZ07W++CN5 Fjow== X-Gm-Message-State: AOAM532e53Crp8w1u7d0BWYEYyC/KQb1otoCpRGQgJcx+Xmm/D87lrrK OwOw9jWoE/MPQwxPKGHNP3oWNZ0ukPaceQ== X-Google-Smtp-Source: ABdhPJyVPAZm7lcGnmZAssqxYVo3JXVKaM1FTXiiVQK7YeesdN5M33aIUtapXrT7R1C5+Aia6t9Dvw== X-Received: by 2002:a65:4983:: with SMTP id r3mr58873733pgs.288.1609444054969; Thu, 31 Dec 2020 11:47:34 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id e6sm11211811pjr.34.2020.12.31.11.47.32 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Dec 2020 11:47:34 -0800 (PST) To: Gert Doering Cc: Fernando Gont , IPv6 Operations , draft-gont-v6ops-ipv6-addressing-considerations@ietf.org References: <160770241261.18071.12524922630334294118@ietfa.amsl.com> <299f492f-4cb7-fa9d-967f-b2a5df49034e@si6networks.com> <759efdb1-a59c-788c-0c7a-5a8ca2ced904@gmail.com> <20201231103010.GL13005@Space.Net> From: Brian E Carpenter Message-ID: <47fb8588-98ee-bf50-b377-921f75dc72e0@gmail.com> Date: Fri, 1 Jan 2021 08:47:31 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20201231103010.GL13005@Space.Net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] I-D Action: draft-gont-v6ops-ipv6-addressing-considerations-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Dec 2020 19:47:37 -0000 Gert, On 31-Dec-20 23:30, Gert Doering wrote: > Hi, > > On Thu, Dec 31, 2020 at 02:00:33PM +1300, Brian E Carpenter wrote: >> 4. The following table attempts to show some of the distinctions >> involved (simplified). View in a fixed-width font. You may not >> agree with it... >> >> Unicast Prefix IID Routeable Announced >> address assigned assigned >> types by by >> ----------------------------------------------------------- >> Link-local fixed host no no >> by RFC >> >> ULA user/RA host or yes IGP only >> (random) DHCPv6 >> >> GUA IANA/RIR/ host or yes IGP, >> ISP/user/RA DHCPv6 BGP4 by policy > > Indeed, I am not agreeing - as there is nothing that prevents ULAs from > being transported by BGP. Indeed, nothing in the laws of physics, but it's default-forbidden by an RFC ;-). Exactly how to express that in a short table is tricky. I think we all agree about this; what Fernando's draft shows is that it is quite hard to describe, and the word "global" is confusing. (Really for the same reason that URLs were renamed from "universal" to "uniform" in 1994. But renaming "global" at this stage seems almost impossible.) Brian > > We use ULAs for "services that must never reachable from the Internet", > and our routing being what it is, everything is transported by BGP - only > loopbacks in OSPF. The difference is "do we announce it to other ASes?" > > So maybe this should be "generally expected to be visible by other > networks on the Internet" (ULA: no, GUA: yes). > > But that's neither precise nor does "expected" mandate anything - I might > want to announce our ULA prefix to our sister company, using eBGP, and > I might decide to not announce our GUA IPv6 PI /48 that we use for our > backbone infra "because people are not supposed to send packets there"... > > Gert Doering > -- NetMaster >