From nobody Thu Oct 1 01:53: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 771B33A0E6D for ; Thu, 1 Oct 2020 01:53:29 -0700 (PDT) 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 MaYcFmGKCpyH for ; Thu, 1 Oct 2020 01:53:27 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 747813A0E6B for ; Thu, 1 Oct 2020 01:53:25 -0700 (PDT) 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 m1kNuKz-0000JoC; Thu, 1 Oct 2020 10:53:17 +0200 Message-Id: To: v6ops@ietf.org From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <159883647280.7294.15168668243468397592@ietfa.amsl.com> <3EB77F8F-C229-47CC-833D-C4B127701B10@delong.com> <151D723E-D0A6-495D-B7F7-3CC25505107D@delong.com> In-reply-to: Your message of "Wed, 30 Sep 2020 19:14:44 -0700 ." <151D723E-D0A6-495D-B7F7-3CC25505107D@delong.com> Date: Thu, 01 Oct 2020 10:53:15 +0200 Archived-At: Subject: Re: [v6ops] Genart last call review of draft-ietf-v6ops-slaac-renum-03 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, 01 Oct 2020 08:53:30 -0000 > Some routers send PIOs in RAs with a valid lifetime of 0 and some > systems erroneously process that and invalidate said prefix. This > violates RFC4862 and is a potential DOS vector. If you invalidate > the prefix, you have weaponized RAs as discussed in RFC4862. There is a proposal now in 6man to make this required host behavior. The reasoning is that with RA-guard, this does not introduce a new attack vector. Without RA-guard, there are already many DOS vectors, and the new behavior has benefits that outweigh the downside of one new vector when there are already many. > A deprecated valid prefix that actually should be invalid will > cause less suffering than a non-deprecated prefix in the same > circumstance, but the no-win situation I was describing remains. If there is only one SLAAC prefix, then deprecating that prefix is not an attack vector. If there are two (for example a global one and a ULA) then deprecating is also an attack vector. However, there are plenty of other ways to DOS hosts using RAs. From nobody Mon Oct 5 10:25:37 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 56FFC3A0F00 for ; Mon, 5 Oct 2020 10:25:36 -0700 (PDT) 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 p7uGPIVEqUtV for ; Mon, 5 Oct 2020 10:25:35 -0700 (PDT) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AFA13A0EFF for ; Mon, 5 Oct 2020 10:25:35 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id y14so4132229pfp.13 for ; Mon, 05 Oct 2020 10:25:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9LKvwTtiEFdrfWikhTBLxhsXtYxCTFeZCIuMqm8EYOc=; b=j3qnnf6FJT40DQ1uZ0UbE/Ugaf1HvkGGJxkXR3cSfnqsN7VD3pDNNUdLoRHIBg2SS3 q4sjetkRXEY+SOocd/Kte1vHjEipj6OFmO0+WOjFJYh2VnmR43wi0WxnbmA5xYjWURA4 WZDwblXzkyWVomTFe0MvLjI7mGm3LT3kGZhqvgf1kaZ/PZq8IQ2WTys7pJ/shEBOFCta j/a/LAe4qhcWRp+LIQmAKW6gGWMZagAXVflFavEOLHtODWw5uQ3xkzhN2wCIqLOPxNoB qOqZ0bqYF6OcsE/4WY+Hnk+GOWbwGH79rzQQdmTJYA2qXMVR5+qARQx9CT9+LRKlil5E 9E8Q== 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=9LKvwTtiEFdrfWikhTBLxhsXtYxCTFeZCIuMqm8EYOc=; b=ZNIZPSI5x6lrbM+wPE3PlRP8h/hxngat6/qIZMdYgWfSpZuJduioztyeP1VJp0WCB+ HhldpcIzjbxHdURPNOBMYE5hymxIe/LManzaKdD/1vFZ1b4blnMN+agLHGAHmsoZCaDZ jS514SCQelXIw6H/KkvM2B0+rB6EpD/CF7SKl29Gm+sXTvFWDx2B0aSFW+Iolnh9seeq eLERvzSh6XqlsBokoXBqmotQkFJUtkjTRZ43tucdXwOftzz9P/GtJv3mUz6cxG9pL6mO JDdoCwabr5MWdD0/IHqzuKfAPSDgBWqhbK3lQ62Et47+80GxNPBjejHUt0oyxo9z5K2/ JlmA== X-Gm-Message-State: AOAM532n1sad28yFw2ienWOTqLMpiwD4BcomfaBQ8O5cwUT4PIprwLyx dj2Aaj68VSxWSin8j2RcP5M= X-Google-Smtp-Source: ABdhPJzZFLEH42gBymFVfkgrfBBCFfrFPLPsCs7F6K4KMInsGpP2jpcZlFVn43Feor8fmDSC9Jo36w== X-Received: by 2002:a65:5784:: with SMTP id b4mr488534pgr.217.1601918734647; Mon, 05 Oct 2020 10:25:34 -0700 (PDT) Received: from ?IPv6:2600:8802:5800:16d0::149e? ([2600:8802:5800:16d0::149e]) by smtp.gmail.com with ESMTPSA id t9sm487872pfc.205.2020.10.05.10.25.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Oct 2020 10:25:34 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.52\)) From: Fred Baker In-Reply-To: <01AC459B-83A3-40AC-913B-C6D7BC88E88E@isoc.org> Date: Mon, 5 Oct 2020 10:25:32 -0700 Cc: "ietf_africa@elists.isoc.org" , IPv6 Operations Content-Transfer-Encoding: quoted-printable Message-Id: References: <01AC459B-83A3-40AC-913B-C6D7BC88E88E@isoc.org> To: Kevin Chege X-Mailer: Apple Mail (2.3654.0.3.2.52) Archived-At: Subject: [v6ops] IPv6 in Africa 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, 05 Oct 2020 17:25:36 -0000 Hello: This is an observation that I noted this morning. Among African nations, = for quite a while I have observed only Zimbabwe (which has a documented = IPv6 strategy) having IPv6 traffic reported by Google at more than 5% of = the requests sent to Google. This morning there were seven countries = that had crossed that boundary. = https://www.vyncke.org/ipv6status/compare.php?metric=3Dp&countries=3Dre,ga= ,tg,ke,zw,cg,yt Google Statistics: https://www.vyncke.org/ipv6status/project.php?metric=3Dp&country=3Dre https://www.vyncke.org/ipv6status/project.php?metric=3Dp&country=3Dzw https://www.vyncke.org/ipv6status/project.php?metric=3Dp&country=3Dga https://www.vyncke.org/ipv6status/project.php?metric=3Dp&country=3Dtg https://www.vyncke.org/ipv6status/project.php?metric=3Dp&country=3Dke https://www.vyncke.org/ipv6status/project.php?metric=3Dp&country=3Dcg APNIC statistics: https://stats.labs.apnic.net/ipv6/CC?x=3D1&s=3D1&p=3D1&w=3D30&c=3DRE https://stats.labs.apnic.net/ipv6/CC?x=3D1&s=3D1&p=3D1&w=3D30&c=3DGA https://stats.labs.apnic.net/ipv6/CC?x=3D1&s=3D1&p=3D1&w=3D30&c=3DTG https://stats.labs.apnic.net/ipv6/CC?x=3D1&s=3D1&p=3D1&w=3D30&c=3DKE https://stats.labs.apnic.net/ipv6/CC?x=3D1&s=3D1&p=3D1&w=3D30&c=3DZW https://stats.labs.apnic.net/ipv6/CC?x=3D1&s=3D1&p=3D1&w=3D30&c=3DYT https://stats.labs.apnic.net/ipv6/CC?x=3D1&s=3D1&p=3D1&w=3D30&c=3DCG From nobody Wed Oct 7 03:25:54 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 AA58F3A0870; Wed, 7 Oct 2020 03:25:46 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=gmx.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 b6rxK_rQCpdD; Wed, 7 Oct 2020 03:25:44 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 6E5883A0898; Wed, 7 Oct 2020 03:25:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1602066342; bh=fve7NsAI9YWcUvD6g0BTrbvIBk2vzVWFKsxtlvoonWs=; h=X-UI-Sender-Class:From:Subject:Date:Cc:To; b=g3wlBFy8CQSGYXYP7LjDPFQQurqLb9CzgNWxdQAa45B/i/kbINKGaC/KH4qkFn5IB BNv4b++Dm373RNd4VtNLPM1ByTk7C9Yr5xjcUDqiGegkyAnsFZrE09tNQ3TAqTjLtw 9MdMBZzokUXF23wpaGZaEOixvv1xlj56ORH0cj4Q= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.128.43] ([87.79.171.64]) by mail.gmx.com (mrgmx005 [212.227.17.184]) with ESMTPSA (Nemesis) id 1Mkpav-1knNQg437H-00mGmm; Wed, 07 Oct 2020 12:25:42 +0200 From: ianfarrer@gmx.com Content-Type: multipart/alternative; boundary="Apple-Mail=_C5BB3F12-51F9-4428-82D3-9625B9C870E2" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Message-Id: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> Date: Wed, 7 Oct 2020 12:25:41 +0200 Cc: dhcwg To: v6ops list , ipv6@ietf.org X-Mailer: Apple Mail (2.3445.104.15) X-Provags-ID: V03:K1:Tq4ZaDYRAXB4u5Ub+YO4dfxT97lgonWz0zofiWCTtwKOvSkEmLk bBdV9/3KlQX56jFbxUnLtFW6mLcoPG0M0PAO+mj7mudskULNX5rDNYUx1PG7WlStm/nDPb4 jsc4UrSFW6ojHttF82ps9VbWdCGrvevUJnWKLYTadhFDffrs9qHLipuk8HuL3GBiFEE65W1 XtqWj1ALFEJdtRFbudt6w== X-UI-Out-Filterresults: notjunk:1;V03:K0:NStZugTVbKg=:F/5+UBemrCgWNxj6zD7SOp lNvmh2HdQnM0AHfL9GGokZOQ/4cNIQXeKw2IB/ughwcJWEeOsjkTuMlrQa8WkCpOVMdDsxkR0 MlBrO8HcdwZlq4oHdgrZZpoH+NnfDtiz4zLrDzDHmn4LOUtMIVev9Gl05LK2lPFiAtKjI9Obo rjzBLxq0IOfoQE9n7uJBxKuAivNH/V7SZsXfxR5emWL1H4o/sGMkeo4hTZnrSylp5S/694NF8 dJjyAD3To5n2/5FRI8gIQHXRz9j7GdG9vaG8XNIb8XNm/JQPUFnomMUo+liF6kAFsWSAJLneM Jyk9P9vnaNU0j+c3ucUfbGVR7N5gaE7mQ61DLaNsG56O8kTFfJM9MdEXinMyo82DRgOfFzvjN dKsJbN1julUgBSDVto5aZXYPVOJgzW26AJ563ElDbHrWDWcDbiSueakljlvEQm9m9IVabD2JB 9hqtJWgFmr0crdb4rdozS24XgQvYmO6nLVXnl+WfLuANVvXS9zODTgn9ATQzYGzyi8GxKP+f9 q68Poy1fJQzLud2Oz72wn/uT9h6jMKpAkIEMJiX2P9zpmZCz/lHdre0XyIRaL4FAcYNHQ6S56 Ep2eQqGcYvEyHtkovPrsglb06uBN0geDx1U2bJFzTrNcS0UsKgAVy8fCnVVUBirYwKZSYhPOT 942b4lF0cA1cPo82azSSjP8zS3mfY+J75CZBfwC3WKoaY5seyNv1Mk1lApmyI+YD9JatBuEoj YMz7qo6EOJiTELKggzPcnbA5BQPizTRkD0HYJg/EJErBQpf7Nz0rFvDdvEQgKZuvSfUx8UXGA nW/+sm3hVaDjFxBfCvuN6Yly1rfupMHpJCemRmPkqXt/sJCm0DFOqUDn1t1i33WOsZKRJ7UwR TULCFdJxFYZI0gwug16p7vKwQrH9cFddxGbTzY8uLOhRMjnCM3CpaFP8i2DLlMYpWCQwKyWgE 6Ywdc7L17H6iB77OYSLDKzPJkwBwO+drv4sf489T294CTwQxF84T/nCiWNNAx3aFfZKX99BWl fCKongNMP/pdJo8w5/stppxXHawsRWwy2sQSp7ullipkh3FeoliGpb4AESsoBf/jMgPCuvoe4 K0sdvm5UQK62FqmWBlEU//aQ3i96SpyER8PHigsW03ZZngovrx0Q+CiSPmJ5a3RVH7uhcM1SQ eKYR6MG0w5r4mW7EZPSnR0Ox9EvXtRv42+3BSy2/BcQLKExIBhqhsJJxXcuW47wZwae39IT6K bXA2WqrYrksMCiqJSK40vwV4ki4E2gNRYa6//Xw== Archived-At: Subject: [v6ops] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Wed, 07 Oct 2020 10:25:47 -0000 --Apple-Mail=_C5BB3F12-51F9-4428-82D3-9625B9C870E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, We are currently finishing WGLC for this draft. It describes = requirements for a 'DHCPv6 Delegating Relay' - this is a router = functioning as the L3 edge and DHCPv6 relay (only) with prefix = delegation. This is a common deployment scenario, but RFC3633/8415 only = really describes PD using a Delegating Router - i.e the L3 edge also = functions as a DHCPv6 server with no relay. When the relay and server = functions are performed by separate devices a number of problems with = how relays behave have been observed, so this document addresses them. During WGLC for this, Ole raised a comment related to one of the routing = requirements:=20 R-4: If the relay has learned a route for a delegated prefix via a given interface, and receives traffic on this interface with a destination address within the delegated prefix (that is not an on-link prefix for the relay), then it MUST be dropped. This is to prevent routing loops. An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route to destination) error message MAY be sent back to the client. The ICMP policy SHOULD be configurable. The problem that this is trying to solve is: 3.5. Forwarding Loops between Client and Relay If the client loses information about a prefix that it is delegated while the lease entry and associated route is still active in the delegating relay, then the relay will forward traffic to the client which the client will return to the relay (which is the client's default gateway (learnt via an RA). The loop will continue until either the client is successfully reprovisioned via DHCP, or the = lease ages out in the relay. Ole=E2=80=99s comment: "And I would also be happy if we could have some = implementors chime in with a "we are happy and able to implement this = requirement=E2=80=9D.=E2=80=9D We would appreciate any feedback on this, especially from anyone with = experience implementing DHCPv6 relays with PD. Thanks, Ian Current draft version: = https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-pd-relay-requiremen= ts/ --Apple-Mail=_C5BB3F12-51F9-4428-82D3-9625B9C870E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

We = are currently finishing WGLC for this draft. It describes requirements = for a 'DHCPv6 Delegating Relay' - this is a router functioning as the L3 = edge and DHCPv6 relay (only) with prefix delegation. This is a common = deployment scenario, but RFC3633/8415 only really describes PD using a = Delegating Router - i.e the L3 edge also functions as a DHCPv6 server = with no relay. When the relay and server functions are performed by = separate devices a number of problems with how relays behave = have
been observed, so this document addresses = them.

During WGLC for this, Ole raised a comment related to one of = the routing requirements: 

R-4:    If the relay has = learned a route for a delegated prefix via a
      =      given interface, and receives traffic on this = interface with
        =    a destination address within the delegated prefix = (that is
           not = an on-link prefix for the relay), then it MUST be
  =          dropped.  This is to = prevent routing loops.  An ICMPv6 Type
  =          1, Code 6 (Destination = Unreachable, reject route to
        =    destination) error message MAY be sent back to the = client.
           The ICMP = policy SHOULD be configurable.

The problem that this is trying to = solve is:

3.5.  Forwarding Loops between Client and = Relay

  =  If the client loses information about a prefix that it is = delegated
   while the lease entry and = associated route is still active in the
  =  delegating relay, then the relay will forward traffic to the = client
   which the client will return to = the relay (which is the client's
  =  default gateway (learnt via an RA).  The loop will continue = until
   either the client is = successfully reprovisioned via DHCP, or the lease
   ages out in the relay.

Ole=E2=80=99s comment: = "And I would also be happy if we could have some = implementors chime in with a "we are happy and able to implement this = requirement=E2=80=9D.=E2=80=9D

We would appreciate any feedback on this, especially from = anyone with experience implementing DHCPv6 relays with = PD.

Thanks,
Ian

Current = draft version: https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-pd-relay= -requirements/


= --Apple-Mail=_C5BB3F12-51F9-4428-82D3-9625B9C870E2-- From nobody Wed Oct 7 06:51:17 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 D73883A08CB; Wed, 7 Oct 2020 06:51:07 -0700 (PDT) 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, 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=boeing.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 pAYnq9EgwuzZ; Wed, 7 Oct 2020 06:51:06 -0700 (PDT) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 C3C423A08C0; Wed, 7 Oct 2020 06:51:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 097Dp0RO017158; Wed, 7 Oct 2020 09:51:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602078663; bh=XqAnICtJQnBFKb39rCGyqCueopnwIHUVXLNizm+5B40=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=UG20sQBmxV4GMe1T98YRrJPdgXBdmdOdSoo1e52vs4g/s9kNmkHtZ7YJ60z/IIaN9 dvPkW/Hvr7isKiDCFRqy3PuPoo2wTp3WSkx9kIizwXuTFN5R5yx7AFrI2vFS/dN4x7 Yjre7qSP5vobRHEeGa2bYlNtPuw4FYHIF5quWcPFr6mLBSYUHCTBSt7FyBV5KBrSOM qpO68joZquBIleZFpRY3upmWX7tsQtfbzuz9LPUoC3dK5B/dHdlXUmoJIspxlxOASo L6kEzZJQEXEME9hoHBe0VPZXxTC1dnhQplbKxHfG8jJJwMtmplFd7fsCdnAPinG/cp YJcQo4SH3Tdig== Received: from XCH16-07-07.nos.boeing.com (xch16-07-07.nos.boeing.com [144.115.66.109]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 097Dokba015676 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 7 Oct 2020 09:50:46 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-07.nos.boeing.com (144.115.66.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Wed, 7 Oct 2020 06:50:45 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8]) by XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8%2]) with mapi id 15.01.2044.004; Wed, 7 Oct 2020 06:50:45 -0700 From: "Templin (US), Fred L" To: "ianfarrer@gmx.com" , v6ops list , "ipv6@ietf.org" CC: dhcwg Thread-Topic: [EXTERNAL] [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AQHWnJRBX3LaGeDRlkqgw1RNqcRYtKmMJ/JA Date: Wed, 7 Oct 2020 13:50:45 +0000 Message-ID: References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> In-Reply-To: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 1AA45496FF24051883B1D36DC5CC29E53495E6A35C72910E80B10830694F4BA22000:8 Content-Type: multipart/alternative; boundary="_000_bb7c15dd4ba04730bd062a03861827baboeingcom_" MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [EXTERNAL] [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Wed, 07 Oct 2020 13:51:08 -0000 --_000_bb7c15dd4ba04730bd062a03861827baboeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UgaW1wbGVtZW50IERIQ1B2NiBQRCBvbiByZWxheXMuIFRoZSByZWxheSBpcyBhbHdheXMgY28t cmVzaWRlbnQgd2l0aCB0aGUNCmRlbGVnYXRpbmcgc2VydmVyIGFuZCBiZWhhdmVzIGFjY29yZGlu ZyB0byBSRkM2MjIxLiBBcmUgd2UgY292ZXJlZD8NCg0KVGhhbmtzIC0gRnJlZA0KDQpGcm9tOiBk aGN3ZyBbbWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBpYW5mYXJy ZXJAZ214LmNvbQ0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDA3LCAyMDIwIDM6MjYgQU0NClRv OiB2Nm9wcyBsaXN0IDx2Nm9wc0BpZXRmLm9yZz47IGlwdjZAaWV0Zi5vcmcNCkNjOiBkaGN3ZyA8 ZGhjd2dAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbRVhURVJOQUxdIFtkaGN3Z10gUXVlc3Rpb24gdG8g REhDUHY2IFJlbGF5IEltcGxlbWVudG9ycyByZWdhcmRpbmcgZHJhZnQtaWV0Zi1kaGMtZGhjcHY2 LXBkLXJlbGF5LXJlcXVpcmVtZW50cw0KDQoNClRoaXMgbWVzc2FnZSB3YXMgc2VudCBmcm9tIG91 dHNpZGUgb2YgQm9laW5nLiBQbGVhc2UgZG8gbm90IGNsaWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNo bWVudHMgdW5sZXNzIHlvdSByZWNvZ25pemUgdGhlIHNlbmRlciBhbmQga25vdyB0aGF0IHRoZSBj b250ZW50IGlzIHNhZmUuDQoNCg0KDQoNCkhpLA0KDQpXZSBhcmUgY3VycmVudGx5IGZpbmlzaGlu ZyBXR0xDIGZvciB0aGlzIGRyYWZ0LiBJdCBkZXNjcmliZXMgcmVxdWlyZW1lbnRzIGZvciBhICdE SENQdjYgRGVsZWdhdGluZyBSZWxheScgLSB0aGlzIGlzIGEgcm91dGVyIGZ1bmN0aW9uaW5nIGFz IHRoZSBMMyBlZGdlIGFuZCBESENQdjYgcmVsYXkgKG9ubHkpIHdpdGggcHJlZml4IGRlbGVnYXRp b24uIFRoaXMgaXMgYSBjb21tb24gZGVwbG95bWVudCBzY2VuYXJpbywgYnV0IFJGQzM2MzMvODQx NSBvbmx5IHJlYWxseSBkZXNjcmliZXMgUEQgdXNpbmcgYSBEZWxlZ2F0aW5nIFJvdXRlciAtIGku ZSB0aGUgTDMgZWRnZSBhbHNvIGZ1bmN0aW9ucyBhcyBhIERIQ1B2NiBzZXJ2ZXIgd2l0aCBubyBy ZWxheS4gV2hlbiB0aGUgcmVsYXkgYW5kIHNlcnZlciBmdW5jdGlvbnMgYXJlIHBlcmZvcm1lZCBi eSBzZXBhcmF0ZSBkZXZpY2VzIGEgbnVtYmVyIG9mIHByb2JsZW1zIHdpdGggaG93IHJlbGF5cyBi ZWhhdmUgaGF2ZQ0KYmVlbiBvYnNlcnZlZCwgc28gdGhpcyBkb2N1bWVudCBhZGRyZXNzZXMgdGhl bS4NCg0KRHVyaW5nIFdHTEMgZm9yIHRoaXMsIE9sZSByYWlzZWQgYSBjb21tZW50IHJlbGF0ZWQg dG8gb25lIG9mIHRoZSByb3V0aW5nIHJlcXVpcmVtZW50czoNCg0KUi00OiAgICBJZiB0aGUgcmVs YXkgaGFzIGxlYXJuZWQgYSByb3V0ZSBmb3IgYSBkZWxlZ2F0ZWQgcHJlZml4IHZpYSBhDQogICAg ICAgICAgIGdpdmVuIGludGVyZmFjZSwgYW5kIHJlY2VpdmVzIHRyYWZmaWMgb24gdGhpcyBpbnRl cmZhY2Ugd2l0aA0KICAgICAgICAgICBhIGRlc3RpbmF0aW9uIGFkZHJlc3Mgd2l0aGluIHRoZSBk ZWxlZ2F0ZWQgcHJlZml4ICh0aGF0IGlzDQogICAgICAgICAgIG5vdCBhbiBvbi1saW5rIHByZWZp eCBmb3IgdGhlIHJlbGF5KSwgdGhlbiBpdCBNVVNUIGJlDQogICAgICAgICAgIGRyb3BwZWQuICBU aGlzIGlzIHRvIHByZXZlbnQgcm91dGluZyBsb29wcy4gIEFuIElDTVB2NiBUeXBlDQogICAgICAg ICAgIDEsIENvZGUgNiAoRGVzdGluYXRpb24gVW5yZWFjaGFibGUsIHJlamVjdCByb3V0ZSB0bw0K ICAgICAgICAgICBkZXN0aW5hdGlvbikgZXJyb3IgbWVzc2FnZSBNQVkgYmUgc2VudCBiYWNrIHRv IHRoZSBjbGllbnQuDQogICAgICAgICAgIFRoZSBJQ01QIHBvbGljeSBTSE9VTEQgYmUgY29uZmln dXJhYmxlLg0KDQpUaGUgcHJvYmxlbSB0aGF0IHRoaXMgaXMgdHJ5aW5nIHRvIHNvbHZlIGlzOg0K DQozLjUuICBGb3J3YXJkaW5nIExvb3BzIGJldHdlZW4gQ2xpZW50IGFuZCBSZWxheQ0KDQogICBJ ZiB0aGUgY2xpZW50IGxvc2VzIGluZm9ybWF0aW9uIGFib3V0IGEgcHJlZml4IHRoYXQgaXQgaXMg ZGVsZWdhdGVkDQogICB3aGlsZSB0aGUgbGVhc2UgZW50cnkgYW5kIGFzc29jaWF0ZWQgcm91dGUg aXMgc3RpbGwgYWN0aXZlIGluIHRoZQ0KICAgZGVsZWdhdGluZyByZWxheSwgdGhlbiB0aGUgcmVs YXkgd2lsbCBmb3J3YXJkIHRyYWZmaWMgdG8gdGhlIGNsaWVudA0KICAgd2hpY2ggdGhlIGNsaWVu dCB3aWxsIHJldHVybiB0byB0aGUgcmVsYXkgKHdoaWNoIGlzIHRoZSBjbGllbnQncw0KICAgZGVm YXVsdCBnYXRld2F5IChsZWFybnQgdmlhIGFuIFJBKS4gIFRoZSBsb29wIHdpbGwgY29udGludWUg dW50aWwNCiAgIGVpdGhlciB0aGUgY2xpZW50IGlzIHN1Y2Nlc3NmdWxseSByZXByb3Zpc2lvbmVk IHZpYSBESENQLCBvciB0aGUgbGVhc2UNCiAgIGFnZXMgb3V0IGluIHRoZSByZWxheS4NCg0KT2xl 4oCZcyBjb21tZW50OiAiQW5kIEkgd291bGQgYWxzbyBiZSBoYXBweSBpZiB3ZSBjb3VsZCBoYXZl IHNvbWUgaW1wbGVtZW50b3JzIGNoaW1lIGluIHdpdGggYSAid2UgYXJlIGhhcHB5IGFuZCBhYmxl IHRvIGltcGxlbWVudCB0aGlzIHJlcXVpcmVtZW504oCdLuKAnQ0KDQoNCldlIHdvdWxkIGFwcHJl Y2lhdGUgYW55IGZlZWRiYWNrIG9uIHRoaXMsIGVzcGVjaWFsbHkgZnJvbSBhbnlvbmUgd2l0aCBl eHBlcmllbmNlIGltcGxlbWVudGluZyBESENQdjYgcmVsYXlzIHdpdGggUEQuDQoNCg0KVGhhbmtz LA0KSWFuDQoNCg0KQ3VycmVudCBkcmFmdCB2ZXJzaW9uOiBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWRoYy1kaGNwdjYtcGQtcmVsYXktcmVxdWlyZW1lbnRzLw0K DQoNCg== --_000_bb7c15dd4ba04730bd062a03861827baboeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K c3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvbnNvbGFzIixzZXJpZjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2UgaW1wbGVtZW50IERIQ1B2NiBQRCBvbiBy ZWxheXMuIFRoZSByZWxheSBpcyBhbHdheXMgY28tcmVzaWRlbnQgd2l0aCB0aGU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+ZGVsZWdhdGluZyBzZXJ2ZXIgYW5kIGJlaGF2ZXMgYWNjb3JkaW5nIHRvIFJGQzYy MjEuIEFyZSB3ZSBjb3ZlcmVkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+VGhhbmtzIC0gRnJlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4gZGhjd2cgW21haWx0bzpkaGN3Zy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxm IE9mIDwvYj5pYW5mYXJyZXJAZ214LmNvbTxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE9j dG9iZXIgMDcsIDIwMjAgMzoyNiBBTTxicj4NCjxiPlRvOjwvYj4gdjZvcHMgbGlzdCAmbHQ7djZv cHNAaWV0Zi5vcmcmZ3Q7OyBpcHY2QGlldGYub3JnPGJyPg0KPGI+Q2M6PC9iPiBkaGN3ZyAmbHQ7 ZGhjd2dAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtFWFRFUk5BTF0gW2RoY3dn XSBRdWVzdGlvbiB0byBESENQdjYgUmVsYXkgSW1wbGVtZW50b3JzIHJlZ2FyZGluZyBkcmFmdC1p ZXRmLWRoYy1kaGNwdjYtcGQtcmVsYXktcmVxdWlyZW1lbnRzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGlu Zz0iMCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGU7cGFkZGlu ZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxl IiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgYWxpZ249ImxlZnQi IHdpZHRoPSIxMDAlIiBzdHlsZT0id2lkdGg6MTAwLjAlO21hcmdpbi1sZWZ0Oi43NXB0O21hcmdp bi1yaWdodDouNzVwdCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9ImJhY2tncm91bmQ6Izkx MEExOTtwYWRkaW5nOjUuMjVwdCAxLjVwdCA1LjI1cHQgMS41cHQiPjwvdGQ+DQo8dGQgd2lkdGg9 IjEwMCUiIHN0eWxlPSJ3aWR0aDoxMDAuMCU7YmFja2dyb3VuZDojRkRGMkY0O3BhZGRpbmc6NS4y NXB0IDMuNzVwdCA1LjI1cHQgMTEuMjVwdDt3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1l LWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9y LXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47 bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMTIxMjEi PlRoaXMgbWVzc2FnZSB3YXMgc2VudCBmcm9tIG91dHNpZGUgb2YgQm9laW5nLiBQbGVhc2UgZG8g bm90IGNsaWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdSByZWNvZ25pemUg dGhlIHNlbmRlciBhbmQga25vdyB0aGF0IHRoZSBjb250ZW50IGlzIHNhZmUuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHBy ZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+SGksPG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+V2UgYXJlIGN1 cnJlbnRseSBmaW5pc2hpbmcgV0dMQyBmb3IgdGhpcyBkcmFmdC4gSXQgZGVzY3JpYmVzIHJlcXVp cmVtZW50cyBmb3IgYSAnREhDUHY2IERlbGVnYXRpbmcgUmVsYXknIC0gdGhpcyBpcyBhIHJvdXRl ciBmdW5jdGlvbmluZyBhcyB0aGUgTDMgZWRnZSBhbmQgREhDUHY2IHJlbGF5IChvbmx5KSB3aXRo IHByZWZpeCBkZWxlZ2F0aW9uLiBUaGlzDQogaXMgYSBjb21tb24gZGVwbG95bWVudCBzY2VuYXJp bywgYnV0IFJGQzM2MzMvODQxNSBvbmx5IHJlYWxseSBkZXNjcmliZXMgUEQgdXNpbmcgYSBEZWxl Z2F0aW5nIFJvdXRlciAtIGkuZSB0aGUgTDMgZWRnZSBhbHNvIGZ1bmN0aW9ucyBhcyBhIERIQ1B2 NiBzZXJ2ZXIgd2l0aCBubyByZWxheS4gV2hlbiB0aGUgcmVsYXkgYW5kIHNlcnZlciBmdW5jdGlv bnMgYXJlIHBlcmZvcm1lZCBieSBzZXBhcmF0ZSBkZXZpY2VzIGEgbnVtYmVyIG9mIHByb2JsZW1z DQogd2l0aCBob3cgcmVsYXlzIGJlaGF2ZSBoYXZlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPmJlZW4gb2JzZXJ2ZWQsIHNvIHRoaXMgZG9jdW1lbnQgYWRkcmVzc2VzIHRoZW0uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+RHVyaW5nIFdHTEMgZm9yIHRoaXMsIE9sZSByYWlzZWQgYSBj b21tZW50IHJlbGF0ZWQgdG8gb25lIG9mIHRoZSByb3V0aW5nIHJlcXVpcmVtZW50czombmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPlItNDombmJzcDsgJm5ic3A7Jm5ic3A7SWYgdGhlIHJlbGF5IGhhcyBs ZWFybmVkIGEgcm91dGUgZm9yIGEgZGVsZWdhdGVkIHByZWZpeCB2aWEgYTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsmbmJz cDtnaXZlbiBpbnRlcmZhY2UsIGFuZCByZWNlaXZlcyB0cmFmZmljIG9uIHRoaXMgaW50ZXJmYWNl IHdpdGg8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7 YSBkZXN0aW5hdGlvbiBhZGRyZXNzIHdpdGhpbiB0aGUgZGVsZWdhdGVkIHByZWZpeCAodGhhdCBp czxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDtub3Qg YW4gb24tbGluayBwcmVmaXggZm9yIHRoZSByZWxheSksIHRoZW4gaXQgTVVTVCBiZTxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDtkcm9wcGVkLiZuYnNw OyZuYnNwO1RoaXMgaXMgdG8gcHJldmVudCByb3V0aW5nIGxvb3BzLiZuYnNwOyZuYnNwO0FuIElD TVB2NiBUeXBlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyZu YnNwOzEsIENvZGUgNiAoRGVzdGluYXRpb24gVW5yZWFjaGFibGUsIHJlamVjdCByb3V0ZSB0bzxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDtkZXN0aW5h dGlvbikgZXJyb3IgbWVzc2FnZSBNQVkgYmUgc2VudCBiYWNrIHRvIHRoZSBjbGllbnQuPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgSUNNUCBwb2xpY3kg U0hPVUxEIGJlIGNvbmZpZ3VyYWJsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlRoZSBwcm9ibGVtIHRoYXQg dGhpcyBpcyB0cnlpbmcgdG8gc29sdmUgaXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+My41LiAm bmJzcDtGb3J3YXJkaW5nIExvb3BzIGJldHdlZW4gQ2xpZW50IGFuZCBSZWxheTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+Jm5ic3A7ICZuYnNwO0lmIHRoZSBjbGllbnQgbG9zZXMgaW5mb3JtYXRpb24gYWJvdXQg YSBwcmVmaXggdGhhdCBpdCBpcyBkZWxlZ2F0ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+Jm5ic3A7ICZuYnNwO3doaWxlIHRoZSBsZWFzZSBlbnRyeSBhbmQgYXNzb2NpYXRlZCBy b3V0ZSBpcyBzdGlsbCBhY3RpdmUgaW4gdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPiZuYnNwOyAmbmJzcDtkZWxlZ2F0aW5nIHJlbGF5LCB0aGVuIHRoZSByZWxheSB3aWxsIGZv cndhcmQgdHJhZmZpYyB0byB0aGUgY2xpZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPiZuYnNwOyAmbmJzcDt3aGljaCB0aGUgY2xpZW50IHdpbGwgcmV0dXJuIHRvIHRoZSByZWxh eSAod2hpY2ggaXMgdGhlIGNsaWVudCdzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PiZuYnNwOyAmbmJzcDtkZWZhdWx0IGdhdGV3YXkgKGxlYXJudCB2aWEgYW4gUkEpLiAmbmJzcDtU aGUgbG9vcCB3aWxsIGNvbnRpbnVlIHVudGlsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPiZuYnNwOyAmbmJzcDtlaXRoZXIgdGhlIGNsaWVudCBpcyBzdWNjZXNzZnVsbHkgcmVwcm92 aXNpb25lZCB2aWEgREhDUCwgb3IgdGhlIGxlYXNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPiZuYnNwOyAmbmJzcDthZ2VzIG91dCBpbiB0aGUgcmVsYXkuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPk9sZeKAmXMgY29tbWVudDogJnF1b3Q7PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5BbmQgSSB3b3VsZCBhbHNvIGJlIGhhcHB5IGlmIHdlIGNvdWxkIGhhdmUgc29tZSBpbXBsZW1l bnRvcnMgY2hpbWUgaW4gd2l0aCBhICZxdW90O3dlIGFyZSBoYXBweSBhbmQgYWJsZSB0byBpbXBs ZW1lbnQgdGhpcyByZXF1aXJlbWVudOKAnS7igJ08L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6 YmxhY2siPldlIHdvdWxkIGFwcHJlY2lhdGUgYW55IGZlZWRiYWNrIG9uIHRoaXMsIGVzcGVjaWFs bHkgZnJvbSBhbnlvbmUgd2l0aCBleHBlcmllbmNlIGltcGxlbWVudGluZyBESENQdjYgcmVsYXlz IHdpdGggUEQuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+PGJyPg0KPGJyPg0KPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtjb2xvcjpibGFjayI+VGhhbmtzLDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPklhbjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6 YmxhY2siPkN1cnJlbnQgZHJhZnQgdmVyc2lvbjombmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWRoYy1kaGNwdjYtcGQtcmVsYXktcmVxdWly ZW1lbnRzLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1kaGMt ZGhjcHY2LXBkLXJlbGF5LXJlcXVpcmVtZW50cy88L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_bb7c15dd4ba04730bd062a03861827baboeingcom_-- From nobody Wed Oct 7 06:55:09 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 A93973A0D0E; Wed, 7 Oct 2020 06:54:58 -0700 (PDT) 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 YY0DaOJwVBjo; Wed, 7 Oct 2020 06:54:57 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC9933A0AE6; Wed, 7 Oct 2020 06:54:56 -0700 (PDT) Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79c:cebd:9724:2114:afe8:8f1c:7f2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 175684E11ACC; Wed, 7 Oct 2020 13:54:56 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 25C7540300EF; Wed, 7 Oct 2020 15:54:54 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: otroan@employees.org In-Reply-To: Date: Wed, 7 Oct 2020 15:54:54 +0200 Cc: "ianfarrer@gmx.com" , v6ops list , 6man WG , dhcwg Content-Transfer-Encoding: quoted-printable Message-Id: <275AF9E3-BD9D-4C3F-96F8-7F490A73432A@employees.org> References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> To: "Templin (US), Fred L" X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [v6ops] [dhcwg] [EXTERNAL] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Wed, 07 Oct 2020 13:55:05 -0000 > On 7 Oct 2020, at 15:50, Templin (US), Fred L = wrote: >=20 > We implement DHCPv6 PD on relays. The relay is always co-resident with = the > delegating server and behaves according to RFC6221. Are we covered? What's your experience with implementing section 3.5 / R-4? Cheers, Ole > =20 > Thanks - Fred > =20 > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of = ianfarrer@gmx.com > Sent: Wednesday, October 07, 2020 3:26 AM > To: v6ops list ; ipv6@ietf.org > Cc: dhcwg > Subject: [EXTERNAL] [dhcwg] Question to DHCPv6 Relay Implementors = regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements > =20 > This message was sent from outside of Boeing. Please do not click = links or open attachments unless you recognize the sender and know that = the content is safe. >=20 > =20 > Hi, > =20 > We are currently finishing WGLC for this draft. It describes = requirements for a 'DHCPv6 Delegating Relay' - this is a router = functioning as the L3 edge and DHCPv6 relay (only) with prefix = delegation. This is a common deployment scenario, but RFC3633/8415 only = really describes PD using a Delegating Router - i.e the L3 edge also = functions as a DHCPv6 server with no relay. When the relay and server = functions are performed by separate devices a number of problems with = how relays behave have > been observed, so this document addresses them. > =20 > During WGLC for this, Ole raised a comment related to one of the = routing requirements:=20 > =20 > R-4: If the relay has learned a route for a delegated prefix via a > given interface, and receives traffic on this interface = with > a destination address within the delegated prefix (that is > not an on-link prefix for the relay), then it MUST be > dropped. This is to prevent routing loops. An ICMPv6 Type > 1, Code 6 (Destination Unreachable, reject route to > destination) error message MAY be sent back to the client. > The ICMP policy SHOULD be configurable. > =20 > The problem that this is trying to solve is: > =20 > 3.5. Forwarding Loops between Client and Relay > =20 > If the client loses information about a prefix that it is delegated > while the lease entry and associated route is still active in the > delegating relay, then the relay will forward traffic to the client > which the client will return to the relay (which is the client's > default gateway (learnt via an RA). The loop will continue until > either the client is successfully reprovisioned via DHCP, or the = lease > ages out in the relay. > =20 > Ole=E2=80=99s comment: "And I would also be happy if we could have = some implementors chime in with a "we are happy and able to implement = this requirement=E2=80=9D.=E2=80=9D >=20 >=20 > We would appreciate any feedback on this, especially from anyone with = experience implementing DHCPv6 relays with PD. >=20 >=20 > Thanks, > Ian >=20 >=20 > Current draft version: = https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-pd-relay-requiremen= ts/ > =20 > =20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Wed Oct 7 07:27: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 C883C3A0A8E; Wed, 7 Oct 2020 07:27:05 -0700 (PDT) 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, RCVD_IN_MSPIKE_H2=-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=boeing.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 xTZUsFkVQtwh; Wed, 7 Oct 2020 07:27:04 -0700 (PDT) Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 2D23C3A0A84; Wed, 7 Oct 2020 07:27:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 097EQwGq010266; Wed, 7 Oct 2020 10:27:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602080821; bh=nAdjORCGIDxc8z64c7MJ4mPP28X3rpe8w/OAwcLdZ0o=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=EadnQ94pQIIP9UqB6OKBTMun5h5SURE4qelpXOA7sXNgQv0gm289xVKn8fi4LmYe9 eSpa/UAWgOKeq5ODSne4fiRBA5TcUGarGswMUan5/TUC8RG9HQ/39qBfidtFDBdLSD a9RMtP5aQaQhdGJJdkLQ0Hg0TsoacxIKaHZVxmW5oQsYv8rxspQvTj1qM+5hGb0FjS T/i+o00ONDp5mUFx/G9MKjojZv+JC+wJCc0a0FBApjvDpmsi5WIXh9dvFGLtC/QGpt dR7JIx56tV7jcH/1DE5+PifUnhZpp6hRfejlbKLMXLJb4ZLN6cKBlRi35/X+kbKj1r PcsGi+eDX+KHA== Received: from XCH16-07-08.nos.boeing.com (xch16-07-08.nos.boeing.com [144.115.66.110]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 097EQvam010251 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 7 Oct 2020 10:26:57 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-08.nos.boeing.com (144.115.66.110) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Wed, 7 Oct 2020 07:26:56 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8]) by XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8%2]) with mapi id 15.01.2044.004; Wed, 7 Oct 2020 07:26:56 -0700 From: "Templin (US), Fred L" To: "otroan@employees.org" CC: "ianfarrer@gmx.com" , v6ops list , "6man WG" , dhcwg Thread-Topic: [dhcwg] [EXTERNAL] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AQHWnLXoMKJ/JAitSUqS66KPREymdQ== Date: Wed, 7 Oct 2020 14:26:56 +0000 Message-ID: References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <275AF9E3-BD9D-4C3F-96F8-7F490A73432A@employees.org> In-Reply-To: <275AF9E3-BD9D-4C3F-96F8-7F490A73432A@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: C8F2271B61160DABBFBF90DCD4C30F161D779D0C4500D30EAB1943F1C082286E2000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [dhcwg] [EXTERNAL] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Wed, 07 Oct 2020 14:27:06 -0000 T2xlLCBhcmUgeW91IHRhbGtpbmcgYWJvdXQgdGhlIGFtbmVzaWFjIGNsaWVudCBjYXNlIC0gc3Vj aCBhcywgdGhlIGNsaWVudCByZWJvb3RzDQphbmQgdGhlbiBjb21lcyBiYWNrIHRvIGxpZmUgYWdh aW4gd2l0aCBubyBtZW1vcnkgb2YgaXRzIHBhc3QgbGlmZXRpbWU/IE91cg0KbGVhc2UgbGlmZXRp bWVzIGFyZSBzaG9ydCAtIGdlbmVyYWxseSBhYm91dCAzMCBzZWNvbmRzIC0gc28gYW55IHN0YWxl IGxlYXNlcw0Kc2hvdWxkIGJlIHZlcnkgdHJhbnNpZW50LiBCdXQsIG91ciByZWxheXMgYWxzbyBy ZXRhaW4ga25vd2xlZGdlIGFib3V0IHRoZQ0KY2xpZW50PC0+c2VydmVyIGludGVyYWN0aW9ucyBh bmQgaW4gc29tZSBzZW5zZSBhY3QgYXMgYSBwcm94eSBmb3IgdGhlIGNsaWVudC4NClNvLCB0aGUg cmVsYXkgaXRzZWxmIHdpbGwgY2xlYW4gdXAgYWZ0ZXIgYW4gYW1uZXNpYWMgY2xpZW50IHdoZW4g aXQgZGV0ZWN0cw0KdGhhdCB0aGUgY2xpZW50IGhhcyBzdWZmZXJlZCBhIHRyYXVtYXRpYyBldmVu dC4NCg0KRnJlZA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG90cm9h bkBlbXBsb3llZXMub3JnIFttYWlsdG86b3Ryb2FuQGVtcGxveWVlcy5vcmddDQo+IFNlbnQ6IFdl ZG5lc2RheSwgT2N0b2JlciAwNywgMjAyMCA2OjU1IEFNDQo+IFRvOiBUZW1wbGluIChVUyksIEZy ZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4NCj4gQ2M6IGlhbmZhcnJlckBnbXguY29t OyB2Nm9wcyBsaXN0IDx2Nm9wc0BpZXRmLm9yZz47IDZtYW4gV0cgPGlwdjZAaWV0Zi5vcmc+OyBk aGN3ZyA8ZGhjd2dAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbZGhjd2ddIFtFWFRFUk5BTF0g UXVlc3Rpb24gdG8gREhDUHY2IFJlbGF5IEltcGxlbWVudG9ycyByZWdhcmRpbmcgZHJhZnQtaWV0 Zi1kaGMtZGhjcHY2LXBkLXJlbGF5LXJlcXVpcmVtZW50cw0KPiANCj4gVGhpcyBtZXNzYWdlIHdh cyBzZW50IGZyb20gb3V0c2lkZSBvZiBCb2VpbmcuIFBsZWFzZSBkbyBub3QgY2xpY2sgbGlua3Mg b3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZA0K PiBrbm93IHRoYXQgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCj4gDQo+IA0KPiANCj4gPiBPbiA3IE9j dCAyMDIwLCBhdCAxNTo1MCwgVGVtcGxpbiAoVVMpLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJv ZWluZy5jb20+IHdyb3RlOg0KPiA+DQo+ID4gV2UgaW1wbGVtZW50IERIQ1B2NiBQRCBvbiByZWxh eXMuIFRoZSByZWxheSBpcyBhbHdheXMgY28tcmVzaWRlbnQgd2l0aCB0aGUNCj4gPiBkZWxlZ2F0 aW5nIHNlcnZlciBhbmQgYmVoYXZlcyBhY2NvcmRpbmcgdG8gUkZDNjIyMS4gQXJlIHdlIGNvdmVy ZWQ/DQo+IA0KPiBXaGF0J3MgeW91ciBleHBlcmllbmNlIHdpdGggaW1wbGVtZW50aW5nIHNlY3Rp b24gMy41IC8gUi00Pw0KPiANCj4gQ2hlZXJzLA0KPiBPbGUNCj4gDQo+ID4NCj4gPiBUaGFua3Mg LSBGcmVkDQo+ID4NCj4gPiBGcm9tOiBkaGN3ZyBbbWFpbHRvOmRoY3dnLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBpYW5mYXJyZXJAZ214LmNvbQ0KPiA+IFNlbnQ6IFdlZG5lc2RheSwg T2N0b2JlciAwNywgMjAyMCAzOjI2IEFNDQo+ID4gVG86IHY2b3BzIGxpc3QgPHY2b3BzQGlldGYu b3JnPjsgaXB2NkBpZXRmLm9yZw0KPiA+IENjOiBkaGN3ZyA8ZGhjd2dAaWV0Zi5vcmc+DQo+ID4g U3ViamVjdDogW0VYVEVSTkFMXSBbZGhjd2ddIFF1ZXN0aW9uIHRvIERIQ1B2NiBSZWxheSBJbXBs ZW1lbnRvcnMgcmVnYXJkaW5nIGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1wZC1yZWxheS1yZXF1aXJl bWVudHMNCj4gPg0KPiA+IFRoaXMgbWVzc2FnZSB3YXMgc2VudCBmcm9tIG91dHNpZGUgb2YgQm9l aW5nLiBQbGVhc2UgZG8gbm90IGNsaWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNz IHlvdSByZWNvZ25pemUgdGhlIHNlbmRlciBhbmQNCj4ga25vdyB0aGF0IHRoZSBjb250ZW50IGlz IHNhZmUuDQo+ID4NCj4gPg0KPiA+IEhpLA0KPiA+DQo+ID4gV2UgYXJlIGN1cnJlbnRseSBmaW5p c2hpbmcgV0dMQyBmb3IgdGhpcyBkcmFmdC4gSXQgZGVzY3JpYmVzIHJlcXVpcmVtZW50cyBmb3Ig YSAnREhDUHY2IERlbGVnYXRpbmcgUmVsYXknIC0gdGhpcyBpcyBhIHJvdXRlciBmdW5jdGlvbmlu Zw0KPiBhcyB0aGUgTDMgZWRnZSBhbmQgREhDUHY2IHJlbGF5IChvbmx5KSB3aXRoIHByZWZpeCBk ZWxlZ2F0aW9uLiBUaGlzIGlzIGEgY29tbW9uIGRlcGxveW1lbnQgc2NlbmFyaW8sIGJ1dCBSRkMz NjMzLzg0MTUgb25seSByZWFsbHkNCj4gZGVzY3JpYmVzIFBEIHVzaW5nIGEgRGVsZWdhdGluZyBS b3V0ZXIgLSBpLmUgdGhlIEwzIGVkZ2UgYWxzbyBmdW5jdGlvbnMgYXMgYSBESENQdjYgc2VydmVy IHdpdGggbm8gcmVsYXkuIFdoZW4gdGhlIHJlbGF5IGFuZCBzZXJ2ZXINCj4gZnVuY3Rpb25zIGFy ZSBwZXJmb3JtZWQgYnkgc2VwYXJhdGUgZGV2aWNlcyBhIG51bWJlciBvZiBwcm9ibGVtcyB3aXRo IGhvdyByZWxheXMgYmVoYXZlIGhhdmUNCj4gPiBiZWVuIG9ic2VydmVkLCBzbyB0aGlzIGRvY3Vt ZW50IGFkZHJlc3NlcyB0aGVtLg0KPiA+DQo+ID4gRHVyaW5nIFdHTEMgZm9yIHRoaXMsIE9sZSBy YWlzZWQgYSBjb21tZW50IHJlbGF0ZWQgdG8gb25lIG9mIHRoZSByb3V0aW5nIHJlcXVpcmVtZW50 czoNCj4gPg0KPiA+IFItNDogICAgSWYgdGhlIHJlbGF5IGhhcyBsZWFybmVkIGEgcm91dGUgZm9y IGEgZGVsZWdhdGVkIHByZWZpeCB2aWEgYQ0KPiA+ICAgICAgICAgICAgZ2l2ZW4gaW50ZXJmYWNl LCBhbmQgcmVjZWl2ZXMgdHJhZmZpYyBvbiB0aGlzIGludGVyZmFjZSB3aXRoDQo+ID4gICAgICAg ICAgICBhIGRlc3RpbmF0aW9uIGFkZHJlc3Mgd2l0aGluIHRoZSBkZWxlZ2F0ZWQgcHJlZml4ICh0 aGF0IGlzDQo+ID4gICAgICAgICAgICBub3QgYW4gb24tbGluayBwcmVmaXggZm9yIHRoZSByZWxh eSksIHRoZW4gaXQgTVVTVCBiZQ0KPiA+ICAgICAgICAgICAgZHJvcHBlZC4gIFRoaXMgaXMgdG8g cHJldmVudCByb3V0aW5nIGxvb3BzLiAgQW4gSUNNUHY2IFR5cGUNCj4gPiAgICAgICAgICAgIDEs IENvZGUgNiAoRGVzdGluYXRpb24gVW5yZWFjaGFibGUsIHJlamVjdCByb3V0ZSB0bw0KPiA+ICAg ICAgICAgICAgZGVzdGluYXRpb24pIGVycm9yIG1lc3NhZ2UgTUFZIGJlIHNlbnQgYmFjayB0byB0 aGUgY2xpZW50Lg0KPiA+ICAgICAgICAgICAgVGhlIElDTVAgcG9saWN5IFNIT1VMRCBiZSBjb25m aWd1cmFibGUuDQo+ID4NCj4gPiBUaGUgcHJvYmxlbSB0aGF0IHRoaXMgaXMgdHJ5aW5nIHRvIHNv bHZlIGlzOg0KPiA+DQo+ID4gMy41LiAgRm9yd2FyZGluZyBMb29wcyBiZXR3ZWVuIENsaWVudCBh bmQgUmVsYXkNCj4gPg0KPiA+ICAgIElmIHRoZSBjbGllbnQgbG9zZXMgaW5mb3JtYXRpb24gYWJv dXQgYSBwcmVmaXggdGhhdCBpdCBpcyBkZWxlZ2F0ZWQNCj4gPiAgICB3aGlsZSB0aGUgbGVhc2Ug ZW50cnkgYW5kIGFzc29jaWF0ZWQgcm91dGUgaXMgc3RpbGwgYWN0aXZlIGluIHRoZQ0KPiA+ICAg IGRlbGVnYXRpbmcgcmVsYXksIHRoZW4gdGhlIHJlbGF5IHdpbGwgZm9yd2FyZCB0cmFmZmljIHRv IHRoZSBjbGllbnQNCj4gPiAgICB3aGljaCB0aGUgY2xpZW50IHdpbGwgcmV0dXJuIHRvIHRoZSBy ZWxheSAod2hpY2ggaXMgdGhlIGNsaWVudCdzDQo+ID4gICAgZGVmYXVsdCBnYXRld2F5IChsZWFy bnQgdmlhIGFuIFJBKS4gIFRoZSBsb29wIHdpbGwgY29udGludWUgdW50aWwNCj4gPiAgICBlaXRo ZXIgdGhlIGNsaWVudCBpcyBzdWNjZXNzZnVsbHkgcmVwcm92aXNpb25lZCB2aWEgREhDUCwgb3Ig dGhlIGxlYXNlDQo+ID4gICAgYWdlcyBvdXQgaW4gdGhlIHJlbGF5Lg0KPiA+DQo+ID4gT2xl4oCZ cyBjb21tZW50OiAiQW5kIEkgd291bGQgYWxzbyBiZSBoYXBweSBpZiB3ZSBjb3VsZCBoYXZlIHNv bWUgaW1wbGVtZW50b3JzIGNoaW1lIGluIHdpdGggYSAid2UgYXJlIGhhcHB5IGFuZCBhYmxlIHRv DQo+IGltcGxlbWVudCB0aGlzIHJlcXVpcmVtZW504oCdLuKAnQ0KPiA+DQo+ID4NCj4gPiBXZSB3 b3VsZCBhcHByZWNpYXRlIGFueSBmZWVkYmFjayBvbiB0aGlzLCBlc3BlY2lhbGx5IGZyb20gYW55 b25lIHdpdGggZXhwZXJpZW5jZSBpbXBsZW1lbnRpbmcgREhDUHY2IHJlbGF5cyB3aXRoIFBELg0K PiA+DQo+ID4NCj4gPiBUaGFua3MsDQo+ID4gSWFuDQo+ID4NCj4gPg0KPiA+IEN1cnJlbnQgZHJh ZnQgdmVyc2lvbjogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1k aGMtZGhjcHY2LXBkLXJlbGF5LXJlcXVpcmVtZW50cy8NCj4gPg0KPiA+DQo+ID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBkaGN3ZyBtYWlsaW5n IGxpc3QNCj4gPiBkaGN3Z0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZGhjd2cNCg0K From nobody Wed Oct 7 07:39: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 837C13A09B7; Wed, 7 Oct 2020 07:39:09 -0700 (PDT) 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 8ARAiZ_cHLCZ; Wed, 7 Oct 2020 07:39:07 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D26593A09AC; Wed, 7 Oct 2020 07:39:07 -0700 (PDT) Received: from astfgl.hanazo.no (201.51-175-101.customer.lyse.net [51.175.101.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 1FB944E1352D; Wed, 7 Oct 2020 14:39:07 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 39D384030E0F; Wed, 7 Oct 2020 16:39:05 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: otroan@employees.org In-Reply-To: Date: Wed, 7 Oct 2020 16:39:05 +0200 Cc: "ianfarrer@gmx.com" , v6ops list , 6man WG , dhcwg Content-Transfer-Encoding: quoted-printable Message-Id: <872EAB12-8015-4591-A0D6-16F3623CA208@employees.org> References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <275AF9E3-BD9D-4C3F-96F8-7F490A73432A@employees.org> To: "Templin (US), Fred L" X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [v6ops] [dhcwg] [EXTERNAL] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Wed, 07 Oct 2020 14:39:10 -0000 > On 7 Oct 2020, at 16:26, Templin (US), Fred L = wrote: >=20 > Ole, are you talking about the amnesiac client case - such as, the = client reboots > and then comes back to life again with no memory of its past lifetime? = Our > lease lifetimes are short - generally about 30 seconds - so any stale = leases > should be very transient. But, our relays also retain knowledge about = the > client<->server interactions and in some sense act as a proxy for the = client. > So, the relay itself will clean up after an amnesiac client when it = detects > that the client has suffered a traumatic event. No the routing loop detection code on the relay. Cheers, Ole >=20 >> -----Original Message----- >> From: otroan@employees.org [mailto:otroan@employees.org] >> Sent: Wednesday, October 07, 2020 6:55 AM >> To: Templin (US), Fred L >> Cc: ianfarrer@gmx.com; v6ops list ; 6man WG = ; dhcwg >> Subject: Re: [dhcwg] [EXTERNAL] Question to DHCPv6 Relay Implementors = regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements >>=20 >> This message was sent from outside of Boeing. Please do not click = links or open attachments unless you recognize the sender and >> know that the content is safe. >>=20 >>=20 >>=20 >>> On 7 Oct 2020, at 15:50, Templin (US), Fred L = wrote: >>>=20 >>> We implement DHCPv6 PD on relays. The relay is always co-resident = with the >>> delegating server and behaves according to RFC6221. Are we covered? >>=20 >> What's your experience with implementing section 3.5 / R-4? >>=20 >> Cheers, >> Ole >>=20 >>>=20 >>> Thanks - Fred >>>=20 >>> From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of = ianfarrer@gmx.com >>> Sent: Wednesday, October 07, 2020 3:26 AM >>> To: v6ops list ; ipv6@ietf.org >>> Cc: dhcwg >>> Subject: [EXTERNAL] [dhcwg] Question to DHCPv6 Relay Implementors = regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements >>>=20 >>> This message was sent from outside of Boeing. Please do not click = links or open attachments unless you recognize the sender and >> know that the content is safe. >>>=20 >>>=20 >>> Hi, >>>=20 >>> We are currently finishing WGLC for this draft. It describes = requirements for a 'DHCPv6 Delegating Relay' - this is a router = functioning >> as the L3 edge and DHCPv6 relay (only) with prefix delegation. This = is a common deployment scenario, but RFC3633/8415 only really >> describes PD using a Delegating Router - i.e the L3 edge also = functions as a DHCPv6 server with no relay. When the relay and server >> functions are performed by separate devices a number of problems with = how relays behave have >>> been observed, so this document addresses them. >>>=20 >>> During WGLC for this, Ole raised a comment related to one of the = routing requirements: >>>=20 >>> R-4: If the relay has learned a route for a delegated prefix via = a >>> given interface, and receives traffic on this interface = with >>> a destination address within the delegated prefix (that is >>> not an on-link prefix for the relay), then it MUST be >>> dropped. This is to prevent routing loops. An ICMPv6 = Type >>> 1, Code 6 (Destination Unreachable, reject route to >>> destination) error message MAY be sent back to the client. >>> The ICMP policy SHOULD be configurable. >>>=20 >>> The problem that this is trying to solve is: >>>=20 >>> 3.5. Forwarding Loops between Client and Relay >>>=20 >>> If the client loses information about a prefix that it is = delegated >>> while the lease entry and associated route is still active in the >>> delegating relay, then the relay will forward traffic to the = client >>> which the client will return to the relay (which is the client's >>> default gateway (learnt via an RA). The loop will continue until >>> either the client is successfully reprovisioned via DHCP, or the = lease >>> ages out in the relay. >>>=20 >>> Ole=E2=80=99s comment: "And I would also be happy if we could have = some implementors chime in with a "we are happy and able to >> implement this requirement=E2=80=9D.=E2=80=9D >>>=20 >>>=20 >>> We would appreciate any feedback on this, especially from anyone = with experience implementing DHCPv6 relays with PD. >>>=20 >>>=20 >>> Thanks, >>> Ian >>>=20 >>>=20 >>> Current draft version: = https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-pd-relay-requiremen= ts/ >>>=20 >>>=20 >>> _______________________________________________ >>> dhcwg mailing list >>> dhcwg@ietf.org >>> https://www.ietf.org/mailman/listinfo/dhcwg >=20 From nobody Wed Oct 7 07:45:58 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 D0B323A09C1; Wed, 7 Oct 2020 07:45:53 -0700 (PDT) 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=boeing.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 hOaN8G5PKyHm; Wed, 7 Oct 2020 07:45:51 -0700 (PDT) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 B11283A09C0; Wed, 7 Oct 2020 07:45:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 097EjllG021295; Wed, 7 Oct 2020 10:45:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602081949; bh=/YmnhZASYJ8Y/ZR0krFZWLXBxCDQCPR91qBJDC4THS4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=bP2RkPvZzMwJ04mn9ZKtcY2Qct55/HKSqA2R5ojTTHFRUz8Y3sEUfk+1v74M0D8eN Z/ejoIkBRhhKkjtK8fYSvnIaTtN02+pdLG73UYoQVX4fuSpBeKAJqkKyhx9aAhTfxG iYJsF0ixgOJcjp2prOKhj2ViomTXMQfGfalN+CkAqUue/DUUPlsMiqWEYOhIsXKxuz Ucum6M3TTVAMa6JljAKwL+EiYfj5PxSxasa7QWr+K+XteJElPm8YbJ0vaXpSGxiehy bF/FYMqNEettLNubhp1NI0fG1/KGg/TdUg7wgOWvgdr+ltzCbemIZhAuEU5PEUqjkv 3lvPzJz5qjmkA== Received: from XCH16-07-12.nos.boeing.com (xch16-07-12.nos.boeing.com [144.115.66.114]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 097EjhXN020988 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 7 Oct 2020 10:45:43 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-12.nos.boeing.com (144.115.66.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Wed, 7 Oct 2020 07:45:42 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8]) by XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8%2]) with mapi id 15.01.2044.004; Wed, 7 Oct 2020 07:45:42 -0700 From: "Templin (US), Fred L" To: "otroan@employees.org" CC: dhcwg , v6ops list , 6man WG Thread-Topic: [dhcwg] [EXTERNAL] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AQHWnLXoMKJ/JAitSUqS66KPREymdamMNPsA Date: Wed, 7 Oct 2020 14:45:42 +0000 Message-ID: References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <275AF9E3-BD9D-4C3F-96F8-7F490A73432A@employees.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 5ACA1FF8082A7B4CF49EAFDA35FF20A37192BE670EC94940A0D63419B459B6092000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [dhcwg] [EXTERNAL] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Wed, 07 Oct 2020 14:45:54 -0000 QlRXLCBpZiBwZW9wbGUgaGF2ZSBjb25jZXJucyBhYm91dCB3aGF0IEkgYW0gZG9pbmcgdmlzLcOg LXZpcyBESENQdjYgUEQgdGhleQ0Kc2hvdWxkIGxvb2sgYXQgdGhlIEFFUk8gYW5kIE9NTkkgc3Bl Y3MgYW5kIGNvbW1lbnQgdGhlcmUgZGlyZWN0bHkuIFlvdSBtYXkNCmZpbmQgdGhhdCBzb21lIHRo aW5ncyB0aGF0IGFyZSBkaXNjdXNzZWQgZnVsbHkgaW4gZG9jdW1lbnQgIkEiIGFyZSBub3QgdG91 Y2hlZA0Kb24gaGFyZGx5IGF0IGFsbCBpbiBkb2N1bWVudCAiTyIgKGFuZCB2aWNlLXZlcnNhKS4g SSBhcG9sb2dpemUgZm9yIHRoYXQ7IHRoZSBsb25nDQp0ZXJtIGdvYWwgaXMgdGhhdCB0aGUgT01O SSBzcGVjIGJlY29tZXMgZnVsbHkgc2VsZi1jb250YWluZWQgd2hpbGUgdGhlIEFFUk8NCnNwZWMg ZGVwZW5kcyBub3JtYXRpdmVseSBvbiBPTU5JLiBTb21lIGRlY2sgY2hhaXJzIG1heSB5ZXQgbmVl ZCB0byBiZQ0Kc2h1ZmZsZWQgdG8gbWFrZSB0aGF0IGhhcHBlbi4NCg0KRnJlZA0KDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGlwdjYgW21haWx0bzppcHY2LWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUZW1wbGluIChVUyksIEZyZWQgTA0KPiBTZW50OiBXZWRu ZXNkYXksIE9jdG9iZXIgMDcsIDIwMjAgNzoyNyBBTQ0KPiBUbzogb3Ryb2FuQGVtcGxveWVlcy5v cmcNCj4gQ2M6IGRoY3dnIDxkaGN3Z0BpZXRmLm9yZz47IHY2b3BzIGxpc3QgPHY2b3BzQGlldGYu b3JnPjsgNm1hbiBXRyA8aXB2NkBpZXRmLm9yZz4NCj4gU3ViamVjdDogUkU6IFtkaGN3Z10gW0VY VEVSTkFMXSBRdWVzdGlvbiB0byBESENQdjYgUmVsYXkgSW1wbGVtZW50b3JzIHJlZ2FyZGluZyBk cmFmdC1pZXRmLWRoYy1kaGNwdjYtcGQtcmVsYXktcmVxdWlyZW1lbnRzDQo+IA0KPiBPbGUsIGFy ZSB5b3UgdGFsa2luZyBhYm91dCB0aGUgYW1uZXNpYWMgY2xpZW50IGNhc2UgLSBzdWNoIGFzLCB0 aGUgY2xpZW50IHJlYm9vdHMNCj4gYW5kIHRoZW4gY29tZXMgYmFjayB0byBsaWZlIGFnYWluIHdp dGggbm8gbWVtb3J5IG9mIGl0cyBwYXN0IGxpZmV0aW1lPyBPdXINCj4gbGVhc2UgbGlmZXRpbWVz IGFyZSBzaG9ydCAtIGdlbmVyYWxseSBhYm91dCAzMCBzZWNvbmRzIC0gc28gYW55IHN0YWxlIGxl YXNlcw0KPiBzaG91bGQgYmUgdmVyeSB0cmFuc2llbnQuIEJ1dCwgb3VyIHJlbGF5cyBhbHNvIHJl dGFpbiBrbm93bGVkZ2UgYWJvdXQgdGhlDQo+IGNsaWVudDwtPnNlcnZlciBpbnRlcmFjdGlvbnMg YW5kIGluIHNvbWUgc2Vuc2UgYWN0IGFzIGEgcHJveHkgZm9yIHRoZSBjbGllbnQuDQo+IFNvLCB0 aGUgcmVsYXkgaXRzZWxmIHdpbGwgY2xlYW4gdXAgYWZ0ZXIgYW4gYW1uZXNpYWMgY2xpZW50IHdo ZW4gaXQgZGV0ZWN0cw0KPiB0aGF0IHRoZSBjbGllbnQgaGFzIHN1ZmZlcmVkIGEgdHJhdW1hdGlj IGV2ZW50Lg0KPiANCj4gRnJlZA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiA+IEZyb206IG90cm9hbkBlbXBsb3llZXMub3JnIFttYWlsdG86b3Ryb2FuQGVtcGxveWVlcy5v cmddDQo+ID4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDA3LCAyMDIwIDY6NTUgQU0NCj4gPiBU bzogVGVtcGxpbiAoVVMpLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+DQo+ID4g Q2M6IGlhbmZhcnJlckBnbXguY29tOyB2Nm9wcyBsaXN0IDx2Nm9wc0BpZXRmLm9yZz47IDZtYW4g V0cgPGlwdjZAaWV0Zi5vcmc+OyBkaGN3ZyA8ZGhjd2dAaWV0Zi5vcmc+DQo+ID4gU3ViamVjdDog UmU6IFtkaGN3Z10gW0VYVEVSTkFMXSBRdWVzdGlvbiB0byBESENQdjYgUmVsYXkgSW1wbGVtZW50 b3JzIHJlZ2FyZGluZyBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtcGQtcmVsYXktcmVxdWlyZW1lbnRz DQo+ID4NCj4gPiBUaGlzIG1lc3NhZ2Ugd2FzIHNlbnQgZnJvbSBvdXRzaWRlIG9mIEJvZWluZy4g UGxlYXNlIGRvIG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3Ug cmVjb2duaXplIHRoZSBzZW5kZXIgYW5kDQo+ID4ga25vdyB0aGF0IHRoZSBjb250ZW50IGlzIHNh ZmUuDQo+ID4NCj4gPg0KPiA+DQo+ID4gPiBPbiA3IE9jdCAyMDIwLCBhdCAxNTo1MCwgVGVtcGxp biAoVVMpLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+IHdyb3RlOg0KPiA+ID4N Cj4gPiA+IFdlIGltcGxlbWVudCBESENQdjYgUEQgb24gcmVsYXlzLiBUaGUgcmVsYXkgaXMgYWx3 YXlzIGNvLXJlc2lkZW50IHdpdGggdGhlDQo+ID4gPiBkZWxlZ2F0aW5nIHNlcnZlciBhbmQgYmVo YXZlcyBhY2NvcmRpbmcgdG8gUkZDNjIyMS4gQXJlIHdlIGNvdmVyZWQ/DQo+ID4NCj4gPiBXaGF0 J3MgeW91ciBleHBlcmllbmNlIHdpdGggaW1wbGVtZW50aW5nIHNlY3Rpb24gMy41IC8gUi00Pw0K PiA+DQo+ID4gQ2hlZXJzLA0KPiA+IE9sZQ0KPiA+DQo+ID4gPg0KPiA+ID4gVGhhbmtzIC0gRnJl ZA0KPiA+ID4NCj4gPiA+IEZyb206IGRoY3dnIFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIGlhbmZhcnJlckBnbXguY29tDQo+ID4gPiBTZW50OiBXZWRuZXNkYXks IE9jdG9iZXIgMDcsIDIwMjAgMzoyNiBBTQ0KPiA+ID4gVG86IHY2b3BzIGxpc3QgPHY2b3BzQGll dGYub3JnPjsgaXB2NkBpZXRmLm9yZw0KPiA+ID4gQ2M6IGRoY3dnIDxkaGN3Z0BpZXRmLm9yZz4N Cj4gPiA+IFN1YmplY3Q6IFtFWFRFUk5BTF0gW2RoY3dnXSBRdWVzdGlvbiB0byBESENQdjYgUmVs YXkgSW1wbGVtZW50b3JzIHJlZ2FyZGluZyBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtcGQtcmVsYXkt cmVxdWlyZW1lbnRzDQo+ID4gPg0KPiA+ID4gVGhpcyBtZXNzYWdlIHdhcyBzZW50IGZyb20gb3V0 c2lkZSBvZiBCb2VpbmcuIFBsZWFzZSBkbyBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRhY2ht ZW50cyB1bmxlc3MgeW91IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZA0KPiA+IGtub3cgdGhhdCB0 aGUgY29udGVudCBpcyBzYWZlLg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBIaSwNCj4gPiA+DQo+ID4g PiBXZSBhcmUgY3VycmVudGx5IGZpbmlzaGluZyBXR0xDIGZvciB0aGlzIGRyYWZ0LiBJdCBkZXNj cmliZXMgcmVxdWlyZW1lbnRzIGZvciBhICdESENQdjYgRGVsZWdhdGluZyBSZWxheScgLSB0aGlz IGlzIGEgcm91dGVyDQo+IGZ1bmN0aW9uaW5nDQo+ID4gYXMgdGhlIEwzIGVkZ2UgYW5kIERIQ1B2 NiByZWxheSAob25seSkgd2l0aCBwcmVmaXggZGVsZWdhdGlvbi4gVGhpcyBpcyBhIGNvbW1vbiBk ZXBsb3ltZW50IHNjZW5hcmlvLCBidXQgUkZDMzYzMy84NDE1IG9ubHkgcmVhbGx5DQo+ID4gZGVz Y3JpYmVzIFBEIHVzaW5nIGEgRGVsZWdhdGluZyBSb3V0ZXIgLSBpLmUgdGhlIEwzIGVkZ2UgYWxz byBmdW5jdGlvbnMgYXMgYSBESENQdjYgc2VydmVyIHdpdGggbm8gcmVsYXkuIFdoZW4gdGhlIHJl bGF5IGFuZCBzZXJ2ZXINCj4gPiBmdW5jdGlvbnMgYXJlIHBlcmZvcm1lZCBieSBzZXBhcmF0ZSBk ZXZpY2VzIGEgbnVtYmVyIG9mIHByb2JsZW1zIHdpdGggaG93IHJlbGF5cyBiZWhhdmUgaGF2ZQ0K PiA+ID4gYmVlbiBvYnNlcnZlZCwgc28gdGhpcyBkb2N1bWVudCBhZGRyZXNzZXMgdGhlbS4NCj4g PiA+DQo+ID4gPiBEdXJpbmcgV0dMQyBmb3IgdGhpcywgT2xlIHJhaXNlZCBhIGNvbW1lbnQgcmVs YXRlZCB0byBvbmUgb2YgdGhlIHJvdXRpbmcgcmVxdWlyZW1lbnRzOg0KPiA+ID4NCj4gPiA+IFIt NDogICAgSWYgdGhlIHJlbGF5IGhhcyBsZWFybmVkIGEgcm91dGUgZm9yIGEgZGVsZWdhdGVkIHBy ZWZpeCB2aWEgYQ0KPiA+ID4gICAgICAgICAgICBnaXZlbiBpbnRlcmZhY2UsIGFuZCByZWNlaXZl cyB0cmFmZmljIG9uIHRoaXMgaW50ZXJmYWNlIHdpdGgNCj4gPiA+ICAgICAgICAgICAgYSBkZXN0 aW5hdGlvbiBhZGRyZXNzIHdpdGhpbiB0aGUgZGVsZWdhdGVkIHByZWZpeCAodGhhdCBpcw0KPiA+ ID4gICAgICAgICAgICBub3QgYW4gb24tbGluayBwcmVmaXggZm9yIHRoZSByZWxheSksIHRoZW4g aXQgTVVTVCBiZQ0KPiA+ID4gICAgICAgICAgICBkcm9wcGVkLiAgVGhpcyBpcyB0byBwcmV2ZW50 IHJvdXRpbmcgbG9vcHMuICBBbiBJQ01QdjYgVHlwZQ0KPiA+ID4gICAgICAgICAgICAxLCBDb2Rl IDYgKERlc3RpbmF0aW9uIFVucmVhY2hhYmxlLCByZWplY3Qgcm91dGUgdG8NCj4gPiA+ICAgICAg ICAgICAgZGVzdGluYXRpb24pIGVycm9yIG1lc3NhZ2UgTUFZIGJlIHNlbnQgYmFjayB0byB0aGUg Y2xpZW50Lg0KPiA+ID4gICAgICAgICAgICBUaGUgSUNNUCBwb2xpY3kgU0hPVUxEIGJlIGNvbmZp Z3VyYWJsZS4NCj4gPiA+DQo+ID4gPiBUaGUgcHJvYmxlbSB0aGF0IHRoaXMgaXMgdHJ5aW5nIHRv IHNvbHZlIGlzOg0KPiA+ID4NCj4gPiA+IDMuNS4gIEZvcndhcmRpbmcgTG9vcHMgYmV0d2VlbiBD bGllbnQgYW5kIFJlbGF5DQo+ID4gPg0KPiA+ID4gICAgSWYgdGhlIGNsaWVudCBsb3NlcyBpbmZv cm1hdGlvbiBhYm91dCBhIHByZWZpeCB0aGF0IGl0IGlzIGRlbGVnYXRlZA0KPiA+ID4gICAgd2hp bGUgdGhlIGxlYXNlIGVudHJ5IGFuZCBhc3NvY2lhdGVkIHJvdXRlIGlzIHN0aWxsIGFjdGl2ZSBp biB0aGUNCj4gPiA+ICAgIGRlbGVnYXRpbmcgcmVsYXksIHRoZW4gdGhlIHJlbGF5IHdpbGwgZm9y d2FyZCB0cmFmZmljIHRvIHRoZSBjbGllbnQNCj4gPiA+ICAgIHdoaWNoIHRoZSBjbGllbnQgd2ls bCByZXR1cm4gdG8gdGhlIHJlbGF5ICh3aGljaCBpcyB0aGUgY2xpZW50J3MNCj4gPiA+ICAgIGRl ZmF1bHQgZ2F0ZXdheSAobGVhcm50IHZpYSBhbiBSQSkuICBUaGUgbG9vcCB3aWxsIGNvbnRpbnVl IHVudGlsDQo+ID4gPiAgICBlaXRoZXIgdGhlIGNsaWVudCBpcyBzdWNjZXNzZnVsbHkgcmVwcm92 aXNpb25lZCB2aWEgREhDUCwgb3IgdGhlIGxlYXNlDQo+ID4gPiAgICBhZ2VzIG91dCBpbiB0aGUg cmVsYXkuDQo+ID4gPg0KPiA+ID4gT2xl4oCZcyBjb21tZW50OiAiQW5kIEkgd291bGQgYWxzbyBi ZSBoYXBweSBpZiB3ZSBjb3VsZCBoYXZlIHNvbWUgaW1wbGVtZW50b3JzIGNoaW1lIGluIHdpdGgg YSAid2UgYXJlIGhhcHB5IGFuZCBhYmxlIHRvDQo+ID4gaW1wbGVtZW50IHRoaXMgcmVxdWlyZW1l bnTigJ0u4oCdDQo+ID4gPg0KPiA+ID4NCj4gPiA+IFdlIHdvdWxkIGFwcHJlY2lhdGUgYW55IGZl ZWRiYWNrIG9uIHRoaXMsIGVzcGVjaWFsbHkgZnJvbSBhbnlvbmUgd2l0aCBleHBlcmllbmNlIGlt cGxlbWVudGluZyBESENQdjYgcmVsYXlzIHdpdGggUEQuDQo+ID4gPg0KPiA+ID4NCj4gPiA+IFRo YW5rcywNCj4gPiA+IElhbg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBDdXJyZW50IGRyYWZ0IHZlcnNp b246IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZGhjLWRoY3B2 Ni1wZC1yZWxheS1yZXF1aXJlbWVudHMvDQo+ID4gPg0KPiA+ID4NCj4gPiA+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBkaGN3ZyBtYWlsaW5n IGxpc3QNCj4gPiA+IGRoY3dnQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2RoY3dnDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBJRVRGIElQdjYgd29y a2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gaXB2NkBpZXRmLm9yZw0KPiBBZG1pbmlzdHJhdGl2 ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo= From nobody Wed Oct 7 07:48: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 BB6163A09C1; Wed, 7 Oct 2020 07:48:02 -0700 (PDT) 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, RCVD_IN_MSPIKE_H2=-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=boeing.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 m-DsyPsJF1-1; Wed, 7 Oct 2020 07:48:00 -0700 (PDT) Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 ABBD43A09C5; Wed, 7 Oct 2020 07:47:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 097ElpLx011347; Wed, 7 Oct 2020 10:47:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602082075; bh=DnGCuo6lkMbagomzAZ2bho7a9bhkxFYweJX3w80Rw4g=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=jIqxueTEmLcAq9ayUdJY87cdZApWBnfMJluxIBYV7Lo0Mj6RJkXdkM6CjTCSVLkmE tQ1nMpu6wQWFDZarvUXbihkPgw09QOp2SSzGDEaEE1YlcEAYq+yKhgDhWjsOU2pWI7 M7Bypul/xpos1E/SraIpUT+NSCpYJjgUleFIoy9mAUlbJLbuaOsu+Jpf32QdeeQ13n HUcy8KpR2rvxxL/0yFRBaxBn1EuOfAXSVFg8e0EPGJPLvcNMjLhe5fvyov1kCigfsQ LiXBt9MMFVGvD2nUe9FawofTNC6Zey7yLhH1ZhAp0EcD6G4QKzK7Yo4JIb3rDA4gC9 FG3bJmVw1msPQ== Received: from XCH16-07-09.nos.boeing.com (xch16-07-09.nos.boeing.com [144.115.66.111]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 097Elhul010622 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 7 Oct 2020 10:47:43 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-09.nos.boeing.com (144.115.66.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Wed, 7 Oct 2020 07:47:42 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8]) by XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8%2]) with mapi id 15.01.2044.004; Wed, 7 Oct 2020 07:47:42 -0700 From: "Templin (US), Fred L" To: "otroan@employees.org" CC: "ianfarrer@gmx.com" , v6ops list , "6man WG" , dhcwg Thread-Topic: [dhcwg] [EXTERNAL] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AQHWnLXoMKJ/JAitSUqS66KPREymdamMqyOA//+MlAA= Date: Wed, 7 Oct 2020 14:47:42 +0000 Message-ID: <59358070ef5d4eaab46578c187f71bf1@boeing.com> References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <275AF9E3-BD9D-4C3F-96F8-7F490A73432A@employees.org> <872EAB12-8015-4591-A0D6-16F3623CA208@employees.org> In-Reply-To: <872EAB12-8015-4591-A0D6-16F3623CA208@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 0E6C0F6C28150677A9AD0D30F05E4DDAC4A2FCD215079982B8D6A903892A0FD72000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [dhcwg] [EXTERNAL] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Wed, 07 Oct 2020 14:48:03 -0000 T2xlLCBJIGRvbid0IHNlZSBhIHByb2JsZW0gd2l0aCBpbXBsZW1lbnRpbmcgd2hhdCB0aGVpciBz cGVjIGNhbGxzIGZvciBpbiB0ZXJtcw0Kb2YgZHJvcHBpbmcgdGhlIGxvb3BlZCB0cmFmZmljIGlu IHRoZSByZWxheS4gSSdtIG5vdCBhcyBzdXJlIGFib3V0IHNlbmRpbmcgYmFjaw0KSUNNUHMgdGhv dWdoLCBzbyBpdCBpcyBnb29kIHRoYXQgdGhhdCBpcyBhICJNQVkiLg0KDQpGcmVkDQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogb3Ryb2FuQGVtcGxveWVlcy5vcmcgW21h aWx0bzpvdHJvYW5AZW1wbG95ZWVzLm9yZ10NCj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDA3 LCAyMDIwIDc6MzkgQU0NCj4gVG86IFRlbXBsaW4gKFVTKSwgRnJlZCBMIDxGcmVkLkwuVGVtcGxp bkBib2VpbmcuY29tPg0KPiBDYzogaWFuZmFycmVyQGdteC5jb207IHY2b3BzIGxpc3QgPHY2b3Bz QGlldGYub3JnPjsgNm1hbiBXRyA8aXB2NkBpZXRmLm9yZz47IGRoY3dnIDxkaGN3Z0BpZXRmLm9y Zz4NCj4gU3ViamVjdDogUmU6IFtkaGN3Z10gW0VYVEVSTkFMXSBRdWVzdGlvbiB0byBESENQdjYg UmVsYXkgSW1wbGVtZW50b3JzIHJlZ2FyZGluZyBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtcGQtcmVs YXktcmVxdWlyZW1lbnRzDQo+IA0KPiBUaGlzIG1lc3NhZ2Ugd2FzIHNlbnQgZnJvbSBvdXRzaWRl IG9mIEJvZWluZy4gUGxlYXNlIGRvIG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRz IHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kDQo+IGtub3cgdGhhdCB0aGUgY29u dGVudCBpcyBzYWZlLg0KPiANCj4gDQo+IA0KPiANCj4gPiBPbiA3IE9jdCAyMDIwLCBhdCAxNjoy NiwgVGVtcGxpbiAoVVMpLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+IHdyb3Rl Og0KPiA+DQo+ID4gT2xlLCBhcmUgeW91IHRhbGtpbmcgYWJvdXQgdGhlIGFtbmVzaWFjIGNsaWVu dCBjYXNlIC0gc3VjaCBhcywgdGhlIGNsaWVudCByZWJvb3RzDQo+ID4gYW5kIHRoZW4gY29tZXMg YmFjayB0byBsaWZlIGFnYWluIHdpdGggbm8gbWVtb3J5IG9mIGl0cyBwYXN0IGxpZmV0aW1lPyBP dXINCj4gPiBsZWFzZSBsaWZldGltZXMgYXJlIHNob3J0IC0gZ2VuZXJhbGx5IGFib3V0IDMwIHNl Y29uZHMgLSBzbyBhbnkgc3RhbGUgbGVhc2VzDQo+ID4gc2hvdWxkIGJlIHZlcnkgdHJhbnNpZW50 LiBCdXQsIG91ciByZWxheXMgYWxzbyByZXRhaW4ga25vd2xlZGdlIGFib3V0IHRoZQ0KPiA+IGNs aWVudDwtPnNlcnZlciBpbnRlcmFjdGlvbnMgYW5kIGluIHNvbWUgc2Vuc2UgYWN0IGFzIGEgcHJv eHkgZm9yIHRoZSBjbGllbnQuDQo+ID4gU28sIHRoZSByZWxheSBpdHNlbGYgd2lsbCBjbGVhbiB1 cCBhZnRlciBhbiBhbW5lc2lhYyBjbGllbnQgd2hlbiBpdCBkZXRlY3RzDQo+ID4gdGhhdCB0aGUg Y2xpZW50IGhhcyBzdWZmZXJlZCBhIHRyYXVtYXRpYyBldmVudC4NCj4gDQo+IE5vIHRoZSByb3V0 aW5nIGxvb3AgZGV0ZWN0aW9uIGNvZGUgb24gdGhlIHJlbGF5Lg0KPiANCj4gQ2hlZXJzLA0KPiBP bGUNCj4gDQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTog b3Ryb2FuQGVtcGxveWVlcy5vcmcgW21haWx0bzpvdHJvYW5AZW1wbG95ZWVzLm9yZ10NCj4gPj4g U2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDA3LCAyMDIwIDY6NTUgQU0NCj4gPj4gVG86IFRlbXBs aW4gKFVTKSwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0KPiA+PiBDYzogaWFu ZmFycmVyQGdteC5jb207IHY2b3BzIGxpc3QgPHY2b3BzQGlldGYub3JnPjsgNm1hbiBXRyA8aXB2 NkBpZXRmLm9yZz47IGRoY3dnIDxkaGN3Z0BpZXRmLm9yZz4NCj4gPj4gU3ViamVjdDogUmU6IFtk aGN3Z10gW0VYVEVSTkFMXSBRdWVzdGlvbiB0byBESENQdjYgUmVsYXkgSW1wbGVtZW50b3JzIHJl Z2FyZGluZyBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtcGQtcmVsYXktcmVxdWlyZW1lbnRzDQo+ID4+ DQo+ID4+IFRoaXMgbWVzc2FnZSB3YXMgc2VudCBmcm9tIG91dHNpZGUgb2YgQm9laW5nLiBQbGVh c2UgZG8gbm90IGNsaWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdSByZWNv Z25pemUgdGhlIHNlbmRlciBhbmQNCj4gPj4ga25vdyB0aGF0IHRoZSBjb250ZW50IGlzIHNhZmUu DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+PiBPbiA3IE9jdCAyMDIwLCBhdCAxNTo1MCwgVGVtcGxp biAoVVMpLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+IHdyb3RlOg0KPiA+Pj4N Cj4gPj4+IFdlIGltcGxlbWVudCBESENQdjYgUEQgb24gcmVsYXlzLiBUaGUgcmVsYXkgaXMgYWx3 YXlzIGNvLXJlc2lkZW50IHdpdGggdGhlDQo+ID4+PiBkZWxlZ2F0aW5nIHNlcnZlciBhbmQgYmVo YXZlcyBhY2NvcmRpbmcgdG8gUkZDNjIyMS4gQXJlIHdlIGNvdmVyZWQ/DQo+ID4+DQo+ID4+IFdo YXQncyB5b3VyIGV4cGVyaWVuY2Ugd2l0aCBpbXBsZW1lbnRpbmcgc2VjdGlvbiAzLjUgLyBSLTQ/ DQo+ID4+DQo+ID4+IENoZWVycywNCj4gPj4gT2xlDQo+ID4+DQo+ID4+Pg0KPiA+Pj4gVGhhbmtz IC0gRnJlZA0KPiA+Pj4NCj4gPj4+IEZyb206IGRoY3dnIFttYWlsdG86ZGhjd2ctYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIGlhbmZhcnJlckBnbXguY29tDQo+ID4+PiBTZW50OiBXZWRu ZXNkYXksIE9jdG9iZXIgMDcsIDIwMjAgMzoyNiBBTQ0KPiA+Pj4gVG86IHY2b3BzIGxpc3QgPHY2 b3BzQGlldGYub3JnPjsgaXB2NkBpZXRmLm9yZw0KPiA+Pj4gQ2M6IGRoY3dnIDxkaGN3Z0BpZXRm Lm9yZz4NCj4gPj4+IFN1YmplY3Q6IFtFWFRFUk5BTF0gW2RoY3dnXSBRdWVzdGlvbiB0byBESENQ djYgUmVsYXkgSW1wbGVtZW50b3JzIHJlZ2FyZGluZyBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtcGQt cmVsYXktcmVxdWlyZW1lbnRzDQo+ID4+Pg0KPiA+Pj4gVGhpcyBtZXNzYWdlIHdhcyBzZW50IGZy b20gb3V0c2lkZSBvZiBCb2VpbmcuIFBsZWFzZSBkbyBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBh dHRhY2htZW50cyB1bmxlc3MgeW91IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFuZA0KPiA+PiBrbm93 IHRoYXQgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gSGksDQo+ID4+ Pg0KPiA+Pj4gV2UgYXJlIGN1cnJlbnRseSBmaW5pc2hpbmcgV0dMQyBmb3IgdGhpcyBkcmFmdC4g SXQgZGVzY3JpYmVzIHJlcXVpcmVtZW50cyBmb3IgYSAnREhDUHY2IERlbGVnYXRpbmcgUmVsYXkn IC0gdGhpcyBpcyBhIHJvdXRlcg0KPiBmdW5jdGlvbmluZw0KPiA+PiBhcyB0aGUgTDMgZWRnZSBh bmQgREhDUHY2IHJlbGF5IChvbmx5KSB3aXRoIHByZWZpeCBkZWxlZ2F0aW9uLiBUaGlzIGlzIGEg Y29tbW9uIGRlcGxveW1lbnQgc2NlbmFyaW8sIGJ1dCBSRkMzNjMzLzg0MTUgb25seSByZWFsbHkN Cj4gPj4gZGVzY3JpYmVzIFBEIHVzaW5nIGEgRGVsZWdhdGluZyBSb3V0ZXIgLSBpLmUgdGhlIEwz IGVkZ2UgYWxzbyBmdW5jdGlvbnMgYXMgYSBESENQdjYgc2VydmVyIHdpdGggbm8gcmVsYXkuIFdo ZW4gdGhlIHJlbGF5IGFuZCBzZXJ2ZXINCj4gPj4gZnVuY3Rpb25zIGFyZSBwZXJmb3JtZWQgYnkg c2VwYXJhdGUgZGV2aWNlcyBhIG51bWJlciBvZiBwcm9ibGVtcyB3aXRoIGhvdyByZWxheXMgYmVo YXZlIGhhdmUNCj4gPj4+IGJlZW4gb2JzZXJ2ZWQsIHNvIHRoaXMgZG9jdW1lbnQgYWRkcmVzc2Vz IHRoZW0uDQo+ID4+Pg0KPiA+Pj4gRHVyaW5nIFdHTEMgZm9yIHRoaXMsIE9sZSByYWlzZWQgYSBj b21tZW50IHJlbGF0ZWQgdG8gb25lIG9mIHRoZSByb3V0aW5nIHJlcXVpcmVtZW50czoNCj4gPj4+ DQo+ID4+PiBSLTQ6ICAgIElmIHRoZSByZWxheSBoYXMgbGVhcm5lZCBhIHJvdXRlIGZvciBhIGRl bGVnYXRlZCBwcmVmaXggdmlhIGENCj4gPj4+ICAgICAgICAgICBnaXZlbiBpbnRlcmZhY2UsIGFu ZCByZWNlaXZlcyB0cmFmZmljIG9uIHRoaXMgaW50ZXJmYWNlIHdpdGgNCj4gPj4+ICAgICAgICAg ICBhIGRlc3RpbmF0aW9uIGFkZHJlc3Mgd2l0aGluIHRoZSBkZWxlZ2F0ZWQgcHJlZml4ICh0aGF0 IGlzDQo+ID4+PiAgICAgICAgICAgbm90IGFuIG9uLWxpbmsgcHJlZml4IGZvciB0aGUgcmVsYXkp LCB0aGVuIGl0IE1VU1QgYmUNCj4gPj4+ICAgICAgICAgICBkcm9wcGVkLiAgVGhpcyBpcyB0byBw cmV2ZW50IHJvdXRpbmcgbG9vcHMuICBBbiBJQ01QdjYgVHlwZQ0KPiA+Pj4gICAgICAgICAgIDEs IENvZGUgNiAoRGVzdGluYXRpb24gVW5yZWFjaGFibGUsIHJlamVjdCByb3V0ZSB0bw0KPiA+Pj4g ICAgICAgICAgIGRlc3RpbmF0aW9uKSBlcnJvciBtZXNzYWdlIE1BWSBiZSBzZW50IGJhY2sgdG8g dGhlIGNsaWVudC4NCj4gPj4+ICAgICAgICAgICBUaGUgSUNNUCBwb2xpY3kgU0hPVUxEIGJlIGNv bmZpZ3VyYWJsZS4NCj4gPj4+DQo+ID4+PiBUaGUgcHJvYmxlbSB0aGF0IHRoaXMgaXMgdHJ5aW5n IHRvIHNvbHZlIGlzOg0KPiA+Pj4NCj4gPj4+IDMuNS4gIEZvcndhcmRpbmcgTG9vcHMgYmV0d2Vl biBDbGllbnQgYW5kIFJlbGF5DQo+ID4+Pg0KPiA+Pj4gICBJZiB0aGUgY2xpZW50IGxvc2VzIGlu Zm9ybWF0aW9uIGFib3V0IGEgcHJlZml4IHRoYXQgaXQgaXMgZGVsZWdhdGVkDQo+ID4+PiAgIHdo aWxlIHRoZSBsZWFzZSBlbnRyeSBhbmQgYXNzb2NpYXRlZCByb3V0ZSBpcyBzdGlsbCBhY3RpdmUg aW4gdGhlDQo+ID4+PiAgIGRlbGVnYXRpbmcgcmVsYXksIHRoZW4gdGhlIHJlbGF5IHdpbGwgZm9y d2FyZCB0cmFmZmljIHRvIHRoZSBjbGllbnQNCj4gPj4+ICAgd2hpY2ggdGhlIGNsaWVudCB3aWxs IHJldHVybiB0byB0aGUgcmVsYXkgKHdoaWNoIGlzIHRoZSBjbGllbnQncw0KPiA+Pj4gICBkZWZh dWx0IGdhdGV3YXkgKGxlYXJudCB2aWEgYW4gUkEpLiAgVGhlIGxvb3Agd2lsbCBjb250aW51ZSB1 bnRpbA0KPiA+Pj4gICBlaXRoZXIgdGhlIGNsaWVudCBpcyBzdWNjZXNzZnVsbHkgcmVwcm92aXNp b25lZCB2aWEgREhDUCwgb3IgdGhlIGxlYXNlDQo+ID4+PiAgIGFnZXMgb3V0IGluIHRoZSByZWxh eS4NCj4gPj4+DQo+ID4+PiBPbGXigJlzIGNvbW1lbnQ6ICJBbmQgSSB3b3VsZCBhbHNvIGJlIGhh cHB5IGlmIHdlIGNvdWxkIGhhdmUgc29tZSBpbXBsZW1lbnRvcnMgY2hpbWUgaW4gd2l0aCBhICJ3 ZSBhcmUgaGFwcHkgYW5kIGFibGUgdG8NCj4gPj4gaW1wbGVtZW50IHRoaXMgcmVxdWlyZW1lbnTi gJ0u4oCdDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IFdlIHdvdWxkIGFwcHJlY2lhdGUgYW55IGZlZWRi YWNrIG9uIHRoaXMsIGVzcGVjaWFsbHkgZnJvbSBhbnlvbmUgd2l0aCBleHBlcmllbmNlIGltcGxl bWVudGluZyBESENQdjYgcmVsYXlzIHdpdGggUEQuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IFRoYW5r cywNCj4gPj4+IElhbg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBDdXJyZW50IGRyYWZ0IHZlcnNpb246 IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtZGhjLWRoY3B2Ni1w ZC1yZWxheS1yZXF1aXJlbWVudHMvDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+PiBkaGN3ZyBtYWlsaW5nIGxp c3QNCj4gPj4+IGRoY3dnQGlldGYub3JnDQo+ID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2RoY3dnDQo+ID4NCg0K From nobody Wed Oct 7 10:32: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 A5FDF3A0CCE; Wed, 7 Oct 2020 10:32:08 -0700 (PDT) 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, RCVD_IN_MSPIKE_H2=-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=boeing.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 rI1xbLJGugkK; Wed, 7 Oct 2020 10:32:06 -0700 (PDT) Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 A1C5E3A0CAB; Wed, 7 Oct 2020 10:32:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 097HW1Xp030443; Wed, 7 Oct 2020 13:32:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602091924; bh=XoOPlJA0eOqXV4AJuU0I6R8ay3aJokpE/7zqVbNFzxE=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=B11F4VGTBxtcGu/cn+nXhmEEP+nwmK1+92YDPAGzTT03K61W7e28E0X0pl26BPdkX 93yQ9RK4ic4aIiSoxTrNez9M7VX+VpbW2hbztxA9lR6ViQSxq/U0nYgMJkpEQoLydy KM11U6FAtW7cResvLsOcT3M6DTohI0cxRF/wgo+/j5pwT5xYnPUj3JUSMd5MRoD0vt 8ZDRJsz7geeXgi+opS3T7zbX5snL+TRT+HvtKCaKwCZkVcwouDkludcYKIvmwiceA2 7K1ycDbAfP6u0XPnsnVQ8uhawGceT5FaOtHau8yEBSfItZGw9LsalBEucCwSNhBrlt B5TequXcl1U/Q== Received: from XCH16-07-10.nos.boeing.com (xch16-07-10.nos.boeing.com [144.115.66.112]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 097HVvdN029799 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 7 Oct 2020 13:31:57 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-10.nos.boeing.com (144.115.66.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Wed, 7 Oct 2020 10:31:55 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8]) by XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8%2]) with mapi id 15.01.2044.004; Wed, 7 Oct 2020 10:31:55 -0700 From: "Templin (US), Fred L" To: "otroan@employees.org" CC: dhcwg , v6ops list , 6man WG Thread-Topic: [dhcwg] [EXTERNAL] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AQHWnLXoMKJ/JAitSUqS66KPREymdamMqyOA//+MlACAACxM0A== Date: Wed, 7 Oct 2020 17:31:55 +0000 Message-ID: <50e11f06bb764decb7b1f650e6c7728c@boeing.com> References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <275AF9E3-BD9D-4C3F-96F8-7F490A73432A@employees.org> <872EAB12-8015-4591-A0D6-16F3623CA208@employees.org> <59358070ef5d4eaab46578c187f71bf1@boeing.com> In-Reply-To: <59358070ef5d4eaab46578c187f71bf1@boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 43141DF6448E8330DA0330B932FFF517A924C930173218E882692088A887D5102000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [dhcwg] [EXTERNAL] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Wed, 07 Oct 2020 17:32:09 -0000 QW4gdXBkYXRlIGhhcyBiZWVuIHBvc3RlZCB0aGF0IGJhY2tzIGF3YXkgZnJvbSBldmVuIGRvaW5n IERIQ1B2NiByZWxheSBhdCBhbGw7DQp0aGUgZnVuY3Rpb24gd2UgYXJlIG5vdyBjYWxsaW5nIGZv ciBjb3VsZCBiZXR0ZXIgYmUgZGVzY3JpYmVkIGFzIGEgIkRIQ1B2NiBwcm94eSINCndoZXJlIGEg bWlkZGxlYm94IGFjdHMgYXMgYSBESENQdjYgY2xpZW50IG9uIGJlaGFsZiBvZiBhbm90aGVyIG5v ZGUgdGhhdCBpcyBvbmx5DQpjYXBhYmxlIG9mIHVzaW5nIElQdjYgTkQgbWVzc2FnaW5nIGFuZCBu b3QgREhDUHY2LiBUaGUgbG9vcCBwcmV2ZW50aW9uIHRlc3QNCmRpc2N1c3NlZCBpbiB0aGlzIHRo cmVhZCBpcyBzdGlsbCByZWxldmFudCwgaG93ZXZlciAtIGJ1dCB3ZSB3aWxsIG5vdCBiZSByZWZl cnJpbmcNCnRvIHdoYXQgd2UgZG8gYXMgIkRIQ1B2NiByZWxheSIgYW55IGxvbmdlci4NCg0KRnJl ZA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHY2b3BzIFttYWlsdG86 djZvcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRlbXBsaW4gKFVTKSwgRnJlZCBM DQo+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAwNywgMjAyMCA3OjQ4IEFNDQo+IFRvOiBvdHJv YW5AZW1wbG95ZWVzLm9yZw0KPiBDYzogZGhjd2cgPGRoY3dnQGlldGYub3JnPjsgdjZvcHMgbGlz dCA8djZvcHNAaWV0Zi5vcmc+OyA2bWFuIFdHIDxpcHY2QGlldGYub3JnPg0KPiBTdWJqZWN0OiBS ZTogW3Y2b3BzXSBbZGhjd2ddIFtFWFRFUk5BTF0gUXVlc3Rpb24gdG8gREhDUHY2IFJlbGF5IElt cGxlbWVudG9ycyByZWdhcmRpbmcgZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LXBkLXJlbGF5LQ0KPiBy ZXF1aXJlbWVudHMNCj4gDQo+IE9sZSwgSSBkb24ndCBzZWUgYSBwcm9ibGVtIHdpdGggaW1wbGVt ZW50aW5nIHdoYXQgdGhlaXIgc3BlYyBjYWxscyBmb3IgaW4gdGVybXMNCj4gb2YgZHJvcHBpbmcg dGhlIGxvb3BlZCB0cmFmZmljIGluIHRoZSByZWxheS4gSSdtIG5vdCBhcyBzdXJlIGFib3V0IHNl bmRpbmcgYmFjaw0KPiBJQ01QcyB0aG91Z2gsIHNvIGl0IGlzIGdvb2QgdGhhdCB0aGF0IGlzIGEg Ik1BWSIuDQo+IA0KPiBGcmVkDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4gRnJvbTogb3Ryb2FuQGVtcGxveWVlcy5vcmcgW21haWx0bzpvdHJvYW5AZW1wbG95ZWVzLm9y Z10NCj4gPiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMDcsIDIwMjAgNzozOSBBTQ0KPiA+IFRv OiBUZW1wbGluIChVUyksIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4NCj4gPiBD YzogaWFuZmFycmVyQGdteC5jb207IHY2b3BzIGxpc3QgPHY2b3BzQGlldGYub3JnPjsgNm1hbiBX RyA8aXB2NkBpZXRmLm9yZz47IGRoY3dnIDxkaGN3Z0BpZXRmLm9yZz4NCj4gPiBTdWJqZWN0OiBS ZTogW2RoY3dnXSBbRVhURVJOQUxdIFF1ZXN0aW9uIHRvIERIQ1B2NiBSZWxheSBJbXBsZW1lbnRv cnMgcmVnYXJkaW5nIGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1wZC1yZWxheS1yZXF1aXJlbWVudHMN Cj4gPg0KPiA+IFRoaXMgbWVzc2FnZSB3YXMgc2VudCBmcm9tIG91dHNpZGUgb2YgQm9laW5nLiBQ bGVhc2UgZG8gbm90IGNsaWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdSBy ZWNvZ25pemUgdGhlIHNlbmRlciBhbmQNCj4gPiBrbm93IHRoYXQgdGhlIGNvbnRlbnQgaXMgc2Fm ZS4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+ID4gT24gNyBPY3QgMjAyMCwgYXQgMTY6MjYsIFRl bXBsaW4gKFVTKSwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPiB3cm90ZToNCj4g PiA+DQo+ID4gPiBPbGUsIGFyZSB5b3UgdGFsa2luZyBhYm91dCB0aGUgYW1uZXNpYWMgY2xpZW50 IGNhc2UgLSBzdWNoIGFzLCB0aGUgY2xpZW50IHJlYm9vdHMNCj4gPiA+IGFuZCB0aGVuIGNvbWVz IGJhY2sgdG8gbGlmZSBhZ2FpbiB3aXRoIG5vIG1lbW9yeSBvZiBpdHMgcGFzdCBsaWZldGltZT8g T3VyDQo+ID4gPiBsZWFzZSBsaWZldGltZXMgYXJlIHNob3J0IC0gZ2VuZXJhbGx5IGFib3V0IDMw IHNlY29uZHMgLSBzbyBhbnkgc3RhbGUgbGVhc2VzDQo+ID4gPiBzaG91bGQgYmUgdmVyeSB0cmFu c2llbnQuIEJ1dCwgb3VyIHJlbGF5cyBhbHNvIHJldGFpbiBrbm93bGVkZ2UgYWJvdXQgdGhlDQo+ ID4gPiBjbGllbnQ8LT5zZXJ2ZXIgaW50ZXJhY3Rpb25zIGFuZCBpbiBzb21lIHNlbnNlIGFjdCBh cyBhIHByb3h5IGZvciB0aGUgY2xpZW50Lg0KPiA+ID4gU28sIHRoZSByZWxheSBpdHNlbGYgd2ls bCBjbGVhbiB1cCBhZnRlciBhbiBhbW5lc2lhYyBjbGllbnQgd2hlbiBpdCBkZXRlY3RzDQo+ID4g PiB0aGF0IHRoZSBjbGllbnQgaGFzIHN1ZmZlcmVkIGEgdHJhdW1hdGljIGV2ZW50Lg0KPiA+DQo+ ID4gTm8gdGhlIHJvdXRpbmcgbG9vcCBkZXRlY3Rpb24gY29kZSBvbiB0aGUgcmVsYXkuDQo+ID4N Cj4gPiBDaGVlcnMsDQo+ID4gT2xlDQo+ID4NCj4gPiA+DQo+ID4gPj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gPiA+PiBGcm9tOiBvdHJvYW5AZW1wbG95ZWVzLm9yZyBbbWFpbHRvOm90 cm9hbkBlbXBsb3llZXMub3JnXQ0KPiA+ID4+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAwNywg MjAyMCA2OjU1IEFNDQo+ID4gPj4gVG86IFRlbXBsaW4gKFVTKSwgRnJlZCBMIDxGcmVkLkwuVGVt cGxpbkBib2VpbmcuY29tPg0KPiA+ID4+IENjOiBpYW5mYXJyZXJAZ214LmNvbTsgdjZvcHMgbGlz dCA8djZvcHNAaWV0Zi5vcmc+OyA2bWFuIFdHIDxpcHY2QGlldGYub3JnPjsgZGhjd2cgPGRoY3dn QGlldGYub3JnPg0KPiA+ID4+IFN1YmplY3Q6IFJlOiBbZGhjd2ddIFtFWFRFUk5BTF0gUXVlc3Rp b24gdG8gREhDUHY2IFJlbGF5IEltcGxlbWVudG9ycyByZWdhcmRpbmcgZHJhZnQtaWV0Zi1kaGMt ZGhjcHY2LXBkLXJlbGF5LQ0KPiByZXF1aXJlbWVudHMNCj4gPiA+Pg0KPiA+ID4+IFRoaXMgbWVz c2FnZSB3YXMgc2VudCBmcm9tIG91dHNpZGUgb2YgQm9laW5nLiBQbGVhc2UgZG8gbm90IGNsaWNr IGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdSByZWNvZ25pemUgdGhlIHNlbmRl ciBhbmQNCj4gPiA+PiBrbm93IHRoYXQgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCj4gPiA+Pg0KPiA+ ID4+DQo+ID4gPj4NCj4gPiA+Pj4gT24gNyBPY3QgMjAyMCwgYXQgMTU6NTAsIFRlbXBsaW4gKFVT KSwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPiB3cm90ZToNCj4gPiA+Pj4NCj4g PiA+Pj4gV2UgaW1wbGVtZW50IERIQ1B2NiBQRCBvbiByZWxheXMuIFRoZSByZWxheSBpcyBhbHdh eXMgY28tcmVzaWRlbnQgd2l0aCB0aGUNCj4gPiA+Pj4gZGVsZWdhdGluZyBzZXJ2ZXIgYW5kIGJl aGF2ZXMgYWNjb3JkaW5nIHRvIFJGQzYyMjEuIEFyZSB3ZSBjb3ZlcmVkPw0KPiA+ID4+DQo+ID4g Pj4gV2hhdCdzIHlvdXIgZXhwZXJpZW5jZSB3aXRoIGltcGxlbWVudGluZyBzZWN0aW9uIDMuNSAv IFItND8NCj4gPiA+Pg0KPiA+ID4+IENoZWVycywNCj4gPiA+PiBPbGUNCj4gPiA+Pg0KPiA+ID4+ Pg0KPiA+ID4+PiBUaGFua3MgLSBGcmVkDQo+ID4gPj4+DQo+ID4gPj4+IEZyb206IGRoY3dnIFtt YWlsdG86ZGhjd2ctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGlhbmZhcnJlckBnbXgu Y29tDQo+ID4gPj4+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAwNywgMjAyMCAzOjI2IEFNDQo+ ID4gPj4+IFRvOiB2Nm9wcyBsaXN0IDx2Nm9wc0BpZXRmLm9yZz47IGlwdjZAaWV0Zi5vcmcNCj4g PiA+Pj4gQ2M6IGRoY3dnIDxkaGN3Z0BpZXRmLm9yZz4NCj4gPiA+Pj4gU3ViamVjdDogW0VYVEVS TkFMXSBbZGhjd2ddIFF1ZXN0aW9uIHRvIERIQ1B2NiBSZWxheSBJbXBsZW1lbnRvcnMgcmVnYXJk aW5nIGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1wZC1yZWxheS1yZXF1aXJlbWVudHMNCj4gPiA+Pj4N Cj4gPiA+Pj4gVGhpcyBtZXNzYWdlIHdhcyBzZW50IGZyb20gb3V0c2lkZSBvZiBCb2VpbmcuIFBs ZWFzZSBkbyBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IHJl Y29nbml6ZSB0aGUgc2VuZGVyDQo+IGFuZA0KPiA+ID4+IGtub3cgdGhhdCB0aGUgY29udGVudCBp cyBzYWZlLg0KPiA+ID4+Pg0KPiA+ID4+Pg0KPiA+ID4+PiBIaSwNCj4gPiA+Pj4NCj4gPiA+Pj4g V2UgYXJlIGN1cnJlbnRseSBmaW5pc2hpbmcgV0dMQyBmb3IgdGhpcyBkcmFmdC4gSXQgZGVzY3Jp YmVzIHJlcXVpcmVtZW50cyBmb3IgYSAnREhDUHY2IERlbGVnYXRpbmcgUmVsYXknIC0gdGhpcyBp cyBhIHJvdXRlcg0KPiA+IGZ1bmN0aW9uaW5nDQo+ID4gPj4gYXMgdGhlIEwzIGVkZ2UgYW5kIERI Q1B2NiByZWxheSAob25seSkgd2l0aCBwcmVmaXggZGVsZWdhdGlvbi4gVGhpcyBpcyBhIGNvbW1v biBkZXBsb3ltZW50IHNjZW5hcmlvLCBidXQgUkZDMzYzMy84NDE1IG9ubHkNCj4gcmVhbGx5DQo+ ID4gPj4gZGVzY3JpYmVzIFBEIHVzaW5nIGEgRGVsZWdhdGluZyBSb3V0ZXIgLSBpLmUgdGhlIEwz IGVkZ2UgYWxzbyBmdW5jdGlvbnMgYXMgYSBESENQdjYgc2VydmVyIHdpdGggbm8gcmVsYXkuIFdo ZW4gdGhlIHJlbGF5IGFuZA0KPiBzZXJ2ZXINCj4gPiA+PiBmdW5jdGlvbnMgYXJlIHBlcmZvcm1l ZCBieSBzZXBhcmF0ZSBkZXZpY2VzIGEgbnVtYmVyIG9mIHByb2JsZW1zIHdpdGggaG93IHJlbGF5 cyBiZWhhdmUgaGF2ZQ0KPiA+ID4+PiBiZWVuIG9ic2VydmVkLCBzbyB0aGlzIGRvY3VtZW50IGFk ZHJlc3NlcyB0aGVtLg0KPiA+ID4+Pg0KPiA+ID4+PiBEdXJpbmcgV0dMQyBmb3IgdGhpcywgT2xl IHJhaXNlZCBhIGNvbW1lbnQgcmVsYXRlZCB0byBvbmUgb2YgdGhlIHJvdXRpbmcgcmVxdWlyZW1l bnRzOg0KPiA+ID4+Pg0KPiA+ID4+PiBSLTQ6ICAgIElmIHRoZSByZWxheSBoYXMgbGVhcm5lZCBh IHJvdXRlIGZvciBhIGRlbGVnYXRlZCBwcmVmaXggdmlhIGENCj4gPiA+Pj4gICAgICAgICAgIGdp dmVuIGludGVyZmFjZSwgYW5kIHJlY2VpdmVzIHRyYWZmaWMgb24gdGhpcyBpbnRlcmZhY2Ugd2l0 aA0KPiA+ID4+PiAgICAgICAgICAgYSBkZXN0aW5hdGlvbiBhZGRyZXNzIHdpdGhpbiB0aGUgZGVs ZWdhdGVkIHByZWZpeCAodGhhdCBpcw0KPiA+ID4+PiAgICAgICAgICAgbm90IGFuIG9uLWxpbmsg cHJlZml4IGZvciB0aGUgcmVsYXkpLCB0aGVuIGl0IE1VU1QgYmUNCj4gPiA+Pj4gICAgICAgICAg IGRyb3BwZWQuICBUaGlzIGlzIHRvIHByZXZlbnQgcm91dGluZyBsb29wcy4gIEFuIElDTVB2NiBU eXBlDQo+ID4gPj4+ICAgICAgICAgICAxLCBDb2RlIDYgKERlc3RpbmF0aW9uIFVucmVhY2hhYmxl LCByZWplY3Qgcm91dGUgdG8NCj4gPiA+Pj4gICAgICAgICAgIGRlc3RpbmF0aW9uKSBlcnJvciBt ZXNzYWdlIE1BWSBiZSBzZW50IGJhY2sgdG8gdGhlIGNsaWVudC4NCj4gPiA+Pj4gICAgICAgICAg IFRoZSBJQ01QIHBvbGljeSBTSE9VTEQgYmUgY29uZmlndXJhYmxlLg0KPiA+ID4+Pg0KPiA+ID4+ PiBUaGUgcHJvYmxlbSB0aGF0IHRoaXMgaXMgdHJ5aW5nIHRvIHNvbHZlIGlzOg0KPiA+ID4+Pg0K PiA+ID4+PiAzLjUuICBGb3J3YXJkaW5nIExvb3BzIGJldHdlZW4gQ2xpZW50IGFuZCBSZWxheQ0K PiA+ID4+Pg0KPiA+ID4+PiAgIElmIHRoZSBjbGllbnQgbG9zZXMgaW5mb3JtYXRpb24gYWJvdXQg YSBwcmVmaXggdGhhdCBpdCBpcyBkZWxlZ2F0ZWQNCj4gPiA+Pj4gICB3aGlsZSB0aGUgbGVhc2Ug ZW50cnkgYW5kIGFzc29jaWF0ZWQgcm91dGUgaXMgc3RpbGwgYWN0aXZlIGluIHRoZQ0KPiA+ID4+ PiAgIGRlbGVnYXRpbmcgcmVsYXksIHRoZW4gdGhlIHJlbGF5IHdpbGwgZm9yd2FyZCB0cmFmZmlj IHRvIHRoZSBjbGllbnQNCj4gPiA+Pj4gICB3aGljaCB0aGUgY2xpZW50IHdpbGwgcmV0dXJuIHRv IHRoZSByZWxheSAod2hpY2ggaXMgdGhlIGNsaWVudCdzDQo+ID4gPj4+ICAgZGVmYXVsdCBnYXRl d2F5IChsZWFybnQgdmlhIGFuIFJBKS4gIFRoZSBsb29wIHdpbGwgY29udGludWUgdW50aWwNCj4g PiA+Pj4gICBlaXRoZXIgdGhlIGNsaWVudCBpcyBzdWNjZXNzZnVsbHkgcmVwcm92aXNpb25lZCB2 aWEgREhDUCwgb3IgdGhlIGxlYXNlDQo+ID4gPj4+ICAgYWdlcyBvdXQgaW4gdGhlIHJlbGF5Lg0K PiA+ID4+Pg0KPiA+ID4+PiBPbGXigJlzIGNvbW1lbnQ6ICJBbmQgSSB3b3VsZCBhbHNvIGJlIGhh cHB5IGlmIHdlIGNvdWxkIGhhdmUgc29tZSBpbXBsZW1lbnRvcnMgY2hpbWUgaW4gd2l0aCBhICJ3 ZSBhcmUgaGFwcHkgYW5kIGFibGUgdG8NCj4gPiA+PiBpbXBsZW1lbnQgdGhpcyByZXF1aXJlbWVu dOKAnS7igJ0NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4gV2Ugd291bGQgYXBwcmVjaWF0ZSBh bnkgZmVlZGJhY2sgb24gdGhpcywgZXNwZWNpYWxseSBmcm9tIGFueW9uZSB3aXRoIGV4cGVyaWVu Y2UgaW1wbGVtZW50aW5nIERIQ1B2NiByZWxheXMgd2l0aCBQRC4NCj4gPiA+Pj4NCj4gPiA+Pj4N Cj4gPiA+Pj4gVGhhbmtzLA0KPiA+ID4+PiBJYW4NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4g Q3VycmVudCBkcmFmdCB2ZXJzaW9uOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLWRoYy1kaGNwdjYtcGQtcmVsYXktcmVxdWlyZW1lbnRzLw0KPiA+ID4+Pg0KPiA+ ID4+Pg0KPiA+ID4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+ID4+PiBkaGN3ZyBtYWlsaW5nIGxpc3QNCj4gPiA+Pj4gZGhjd2dAaWV0Zi5vcmcN Cj4gPiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaGN3Zw0KPiA+ ID4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiB2Nm9wc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo= From nobody Wed Oct 7 11:24:58 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 9DB963A09E7; Wed, 7 Oct 2020 11:24:51 -0700 (PDT) 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 7aQtpoArjJ49; Wed, 7 Oct 2020 11:24:49 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51B5F3A0A07; Wed, 7 Oct 2020 11:24:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 7668B389E2; Wed, 7 Oct 2020 14:30:11 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nbBs77CnRzz8; Wed, 7 Oct 2020 14:30:10 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D3AB7389DF; Wed, 7 Oct 2020 14:30:10 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 19022F5; Wed, 7 Oct 2020 14:24:47 -0400 (EDT) From: Michael Richardson To: ianfarrer@gmx.com cc: v6ops list , ipv6@ietf.org, dhcwg In-Reply-To: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [v6ops] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Wed, 07 Oct 2020 18:24:52 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ianfarrer@gmx.com wrote: > R-4: If the relay has learned a route for a delegated prefix via a > given interface, and receives traffic on this interface with a > destination address within the delegated prefix (that is not an on-li= nk > prefix for the relay), then it MUST be dropped. This is to prevent > routing loops. An ICMPv6 Type 1, Code 6 (Destination Unreachable, > reject route to destination) error message MAY be sent back to the > client. The ICMP policy SHOULD be configurable. ... > The problem that this is trying to solve is: > 3.5. Forwarding Loops between Client and Relay > If the client loses information about a prefix that it is delegated > while the lease entry and associated route is still active in the > delegating relay, then the relay will forward traffic to the client > which the client will return to the relay (which is the client's > default gateway (learnt via an RA). The loop will continue until > either the client is successfully reprovisioned via DHCP, or the lease > ages out in the relay. I browsed through pd-relay-requirements, but I didn't know it was being worked on. (Did I fall off the dhc list again due to outsourced spam filte= r? Probably) The document was seemed clear and direct. It may be that it could explain more about the consequences of failing to take some of the advice. > Ole=E2=80=99s comment: "And I would also be happy if we could have so= me > implementors chime in with a "we are happy and able to implement this > requirement=E2=80=9D.=E2=80=9D > We would appreciate any feedback on this, especially from anyone with > experience implementing DHCPv6 relays with PD. My BMS implementation (2014-ish) had a DHCPv6 server listening per PPPoE co= nnection. BMS/PPPoE operators often don't have DHCPv6 servers, and adding one isn't something they want to do. Making Radius run is hard enough.... In that context, the client can't drop without killing the PPPoE interface, which drops the route, removing it from the IGP, etc. So despite having implemented, my experience is not particularly useful for you. But, I'm very enthusiastic to have DHCPv6-PD be incorporated into hyperviso= rs and LXD and Docker, so I hope the problem you describe will be "common". If a client goes way and does not properly restart, then the NCE entries associated with the routes will be invalid, and the traffic will be dropped. While the client is starting, the NCE entries will become valid, but the client won't have the state. The traffic will loop. This could become a serious problems, particularly if the traffic loops at very high speed, worse case, causing the client to fail again. Best case, it goes on for a few seconds, then the client perhaps a DHCPv6-P= D, gets delegated the same prefix and everything is normal again. Perhaps for this reason alone, delegated prefixes need to be stable across their lifetime. Perhaps that is obvious, but there are many flash renumbering discussions... The concerning case is, I think, that the client comes up fine, but declines to do a DHCPv6-PD for some reason. Maybe the option was turned off and the CPE device rebooted. Or maybe it won't do the PD until some event occurs, like some VM gets started. It seems to me that we need some additional protocol where the relay can be informed to blackhole the traffic by the DHCP server. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9+B+4ACgkQgItw+93Q 3WVJVAgAhblGaE4kAHtNc9tZM7E62kW+eUmEsXuwGgRKWoeeSb+U4xmlFyDQ9a58 EVyFcYuX/gBQT8XnyDwH5Gjn287KpqYc5nmxIe2va/p/1y+hxE7d+C8YFX2quJEj NUXs1+1/+3vK5+2ZydUyupLDy1jpDfdLgtMfISlnEamC+/v6J2XIwTcNJN/4WW0f dIyG99KEu9ihfIrfajqDTmSP0nKlBjVnUUlBpzsDqPb33nkbxT9GY/5i5y90phTZ BZw72CsxaLj7d0Jj5b6ARzX8s+aD7FOlbWTL9y3+L5K95zN1p96+qCwG/S8nhOMq JGJFsjm5jj3KRG5bmGBstkh01rZQnQ== =td3L -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 7 18:25: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 C45CC3A09C4; Wed, 7 Oct 2020 18:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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 ZZVpSDuHuSix; Wed, 7 Oct 2020 18:24:59 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 6A5B53A09C0; Wed, 7 Oct 2020 18:24:59 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id c2so5297829qkf.10; Wed, 07 Oct 2020 18:24:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9ltSWlSghhcJwuXvXEYO2nME0cO+xdTso/4lU+6wRpA=; b=CIS8jJ6wWNZbyjPqQrHs7I53L4I7UVEiaKfjWogLMIhe/VKn5aHi1ZPVnxNrxFD/Kg e6skIMVfBPGNwKw4cYdXgxH9//U+8BZTRAfF28z1n4FwK3UruXDP23NgT3qQqpF0Mqg9 w27QLfX+H7zyV2cdcs5K/FAZDSIijf4akLVPeLw+KVezjZ22mSODcQzrLRApO8uA/zsz ArDZ3Agt7lwSNQ3KnWtBYHzSotoui/6eS02vztLGCq/doriecDNDwTs6d9T+MCPxX2FG ttkmJYKTwH8uCEshZxVHg7J0M1bPmgtuAcOzwD1S+Sy0G8UQi/7XqewN2YGlprxsb+/a OHKg== 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=9ltSWlSghhcJwuXvXEYO2nME0cO+xdTso/4lU+6wRpA=; b=cBVsxzFyXtt9iYIgTk5hxk3gFy2WuZnGSisI5ocnAc+D84b23rbRYQybMOZd7oiJbU 2pMWaDF0miBcKu+vpBI2/ZuUfIRatN+yBBW0V0hlyqzCh8h30ZEG27ObGMhZjFWSoBPI JrAN+5NSFJmfE0laokCuZqRJumJXXo9v6GOI1hcmj5oWmuc/3DKx8Jm4Xo3wtPOljH9F 39IOP9URjN5bRCW2UNfDfkbuNqvLWtl00QW8wJi5K3jPo0SdssnhmFDbjIlZBRl20MNe 5e3WBCU4/MK3EYcYt1RbFlxwtnamQ3pKZEtXUU+95PItxl6Yk3wgqTrHCMcz1yAhyZyg NIow== X-Gm-Message-State: AOAM530TLjaPJepr3GsscHjPU8PQbeUdY1Pp8LD9cNXnv8nyolEP7A8P QN0+xOfmhKXsFhmM/kIdzBpRa2TEkYvIHp/8L//3rJHA X-Google-Smtp-Source: ABdhPJzkSB8/s7I0Dd3E+avptUjlZNqb88zS7FDRGx03Yr0LvMQfz1NviVqo401EEkZ3quolwWNyFUXbH5FUUt6m8Ns= X-Received: by 2002:a37:d41:: with SMTP id 62mr5678002qkn.444.1602120298455; Wed, 07 Oct 2020 18:24:58 -0700 (PDT) MIME-Version: 1.0 References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> In-Reply-To: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> From: Jen Linkova Date: Thu, 8 Oct 2020 12:24:45 +1100 Message-ID: To: ianfarrer@gmx.com Cc: v6ops list , 6man , dhcwg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Thu, 08 Oct 2020 01:25:01 -0000 On Wed, Oct 7, 2020 at 9:25 PM wrote: > We are currently finishing WGLC for this draft. It describes requirements= for a 'DHCPv6 Delegating Relay' - this is a router functioning as the L3 e= dge and DHCPv6 relay (only) with prefix delegation. This is a common deploy= ment scenario, but RFC3633/8415 only really describes PD using a Delegating= Router - i.e the L3 edge also functions as a DHCPv6 server with no relay. = When the relay and server functions are performed by separate devices a num= ber of problems with how relays behave have > been observed, so this document addresses them. > > During WGLC for this, Ole raised a comment related to one of the routing = requirements: > > R-4: If the relay has learned a route for a delegated prefix via a > given interface, and receives traffic on this interface with > a destination address within the delegated prefix (that is > not an on-link prefix for the relay), then it MUST be > dropped. This is to prevent routing loops. An ICMPv6 Type > 1, Code 6 (Destination Unreachable, reject route to > destination) error message MAY be sent back to the client. > The ICMP policy SHOULD be configurable. > > The problem that this is trying to solve is: > > 3.5. Forwarding Loops between Client and Relay I might be missing smth but... Let's say I have a relay and it's 'south' (client-facing) interface is connected to a switch. The client AND second device (another router or a host) are connected to the same segment. The client gets a prefix, the relay 'learned' (or shall we call it 'install'?) the route for the delegated prefix pointing to its 'south' interface with the client address as a next-hop. What would happen if the *second* device sends traffic towards the delegated prefix? As that device is usig the relay as its default gateway, the traffic would be sent there. If I read the draft correctly, instead of forwarding the traffic and maybe sending the redirect, the relay is expected to drop it? --=20 SY, Jen Linkova aka Furry From nobody Thu Oct 8 08: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 F23E73A0E28; Thu, 8 Oct 2020 08:51:59 -0700 (PDT) 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=boeing.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 KErEkKHUrAad; Thu, 8 Oct 2020 08:51:58 -0700 (PDT) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 2F2313A0E44; Thu, 8 Oct 2020 08:51:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 098FpqH5017737; Thu, 8 Oct 2020 11:51:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602172316; bh=oVcsI16Juma69mo7evob0dyQZHFzXvX3QabfoG0vMo4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=lAqHb53yfk354T/OGejRFqitztpDgA1RlrddERuiMs52c/xT0Mh5FB7H8KpSTjp3l qcEp1iSgAiqxyVtGUca37tPpnh8yZAYvpCQmZRaFeh7QkCo4in2oiYk7gzCksmoONT ce4KoGGriSiVW/M6pXpYjTkhZRxFPN7uz7enGRftLfM1dH++Xtod+Mf5M6fYGWQq0u 4bUs4Uq5/NCmm+w/Aqx7iyFb3j0MXQuu45CbFicM+Tibj8z4WIbHbch/RzGhMt6O1j K2HAFETot2ZhkKXfqEBE8WxeO/wsHbRUpBHsGc7+F5/RRJq9+05w3rM34Q+nakr0D4 kfCP7bbjStq9A== Received: from XCH16-07-09.nos.boeing.com (xch16-07-09.nos.boeing.com [144.115.66.111]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 098FpXeh015025 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 8 Oct 2020 11:51:33 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-09.nos.boeing.com (144.115.66.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Thu, 8 Oct 2020 08:51:32 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8]) by XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8%2]) with mapi id 15.01.2044.004; Thu, 8 Oct 2020 08:51:32 -0700 From: "Templin (US), Fred L" To: Jen Linkova , "ianfarrer@gmx.com" CC: dhcwg , v6ops list , 6man Thread-Topic: [EXTERNAL] Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AQHWnRHm524iPz3PtEmCznTLyJxcLqmN2bKg Date: Thu, 8 Oct 2020 15:51:32 +0000 Message-ID: References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 2B51BD98083E59DCC6C3FB1EFA0521C29C7DAD2C4299DAD804C7FDCD438389482000:8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [EXTERNAL] Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Thu, 08 Oct 2020 15:52:00 -0000 Jen, > What would happen if the *second* device sends traffic towards the > delegated prefix? As that device is usig the relay as its default > gateway, the traffic would be sent there. > If I read the draft correctly, instead of forwarding the traffic and > maybe sending the redirect, the relay is expected to drop it? The way that I interpret it, when the second device sends the traffic to the relay, the relay would still forward the traffic to the client, whic= h would then forward the traffic back to the relay, then at that point the relay would drop the traffic. Unless the second node somehow has a way of knowing that the client has entered into an amnesiac state and then does a malicious "flood-ping", we can expect applications to quickly learn that the IP addresses of the client are no longer reachable. Plus, these amnesiac conditions can be expected to be rare and transient; not steady-state. Fred > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Jen Linkova > Sent: Wednesday, October 07, 2020 6:25 PM > To: ianfarrer@gmx.com > Cc: dhcwg ; v6ops list ; 6man > Subject: [EXTERNAL] Re: [dhcwg] Question to DHCPv6 Relay Implementors reg= arding draft-ietf-dhc-dhcpv6-pd-relay-requirements >=20 > This message was sent from outside of Boeing. Please do not click links o= r open attachments unless you recognize the sender and > know that the content is safe. >=20 >=20 > On Wed, Oct 7, 2020 at 9:25 PM wrote: > > We are currently finishing WGLC for this draft. It describes requiremen= ts for a 'DHCPv6 Delegating Relay' - this is a router functioning > as the L3 edge and DHCPv6 relay (only) with prefix delegation. This is a = common deployment scenario, but RFC3633/8415 only really > describes PD using a Delegating Router - i.e the L3 edge also functions a= s a DHCPv6 server with no relay. When the relay and server > functions are performed by separate devices a number of problems with how= relays behave have > > been observed, so this document addresses them. > > > > During WGLC for this, Ole raised a comment related to one of the routin= g requirements: > > > > R-4: If the relay has learned a route for a delegated prefix via a > > given interface, and receives traffic on this interface with > > a destination address within the delegated prefix (that is > > not an on-link prefix for the relay), then it MUST be > > dropped. This is to prevent routing loops. An ICMPv6 Type > > 1, Code 6 (Destination Unreachable, reject route to > > destination) error message MAY be sent back to the client. > > The ICMP policy SHOULD be configurable. > > > > The problem that this is trying to solve is: > > > > 3.5. Forwarding Loops between Client and Relay >=20 > I might be missing smth but... > Let's say I have a relay and it's 'south' (client-facing) interface is > connected to a switch. The client AND second device (another router or > a host) are connected to the same segment. > The client gets a prefix, the relay 'learned' (or shall we call it > 'install'?) the route for the delegated prefix pointing to its 'south' > interface with the client address as a next-hop. > What would happen if the *second* device sends traffic towards the > delegated prefix? As that device is usig the relay as its default > gateway, the traffic would be sent there. > If I read the draft correctly, instead of forwarding the traffic and > maybe sending the redirect, the relay is expected to drop it? >=20 > -- > SY, Jen Linkova aka Furry >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Thu Oct 8 08:57: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 A88563A0E44; Thu, 8 Oct 2020 08:57:08 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=gmx.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 88Fpo4a1-TIV; Thu, 8 Oct 2020 08:57:07 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 753D63A0E2D; Thu, 8 Oct 2020 08:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1602172619; bh=b2UmeVdzi8ImyU0iOM7w7OnDBH7RIGTTE+Qb3MFPCiE=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=G2Qc94yL4z2Tc85JkBdfIcejKRQQ3eM5l4YiD+gHFFQIc1hBhJh9FsDJW9StVOgyz SZEgY91kxwmajWhkCqGCAuu4QX5iySFe7k3sI699IiXKMJlQ2TQjU51B9DD5Je7eOr WluXXDvClrUQF6+AeOZuPj/xyqwkAEyBRbd2HaRQ= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.128.43] ([87.79.171.64]) by mail.gmx.com (mrgmx104 [212.227.17.174]) with ESMTPSA (Nemesis) id 1MtOGU-1keVbJ1obO-00uoiy; Thu, 08 Oct 2020 17:56:59 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: ianfarrer@gmx.com In-Reply-To: <15177.1602095087@localhost> Date: Thu, 8 Oct 2020 17:56:57 +0200 Cc: v6ops list , ipv6@ietf.org, dhcwg Content-Transfer-Encoding: quoted-printable Message-Id: References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <15177.1602095087@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.104.15) X-Provags-ID: V03:K1:jrvelnOy7FV+W5phhGlFcswCfyj24jxM4TQsCokFgKBIzueRnLz vNRHKoaiuwSLeOywOwpe8sRKqnPG5DLSRg3h/uqupM70kTYxuij/i+Kq/pWaJN7iszZ48qH roFo3YFMD398P30Nte7Jg0tmuDinTBo81MeAUn5sBNqahLMtRBsI8RnYbBlDNu+aZxG0hGq o0Z2Q/A0kJK2PxMGCL/og== X-UI-Out-Filterresults: notjunk:1;V03:K0:UrPwX6t/Dk4=:+wPBqjmZY/4SW1nUHtQbsX MBj3O611UE+wd72V1SaGek0VBlhZ80r3opSEzxOEWE1p36Qvt+Bhs8aQASQOnB6J8yiQe1bzd dU2/LJPEu3wHG45xRZqMocZPsJ0mtt1/CcLu9KDHTAXKExBZfYGN5XR9i3XpnleiCnNkKgoKm zEM9VW1Iy28yqwmuU+uQGdUEGlEFO4SDSX+TQvagYwGwfsS9f6btZIJ9IbLR0iTHu2/yKD2TK 6n5Zea4wYziyhY5gYtBokuLlsekDfdv3CqymrT/nbnH7YS6c22I0+0mmbnNl/yv3x0s8zXdKq 9f0iW/kYlC6g3DDcOWlcMYWjl4AcFYg6es2iWisX2tOdWux9f2jUy6YwGbA6eJgyxKkC1SlE9 YPAgdjCYm2bHbW9O/cqqGhzGPRRftsWf6oYcBNQVBxAW0TwDNuuIa/D19zGLSC5SMafor8wzG NOChJLD/niwCJAlQlecA4yvaOp1ZkpFKhwdiDHAXVijRI4AhVyCSMmudLPUqsktK7WUvtf/40 jic1qTCMEpaRD8s/HVQy7BcT9kPz5CRXSdYKpSNpzZsILydHXxS9VBvk8KeNQ7PdWNsB1OHbG wg/97b9YJ8yDg+vsxRq+/2qHRTB8wzje5Z3FMY08GQOfC3dEUfCCfFop7Rt8vwSv1jUPG1gyL JeuV30iDns06aWc/oKtbnF9Q9gX1Svsq4Nm4qtPQJ6G8Sh+Y856H+gQ3WrUjIBVsDkrU6Qzds +FjOxwDZngK5s5/1Kw4w0C8WFggmhR7+X89BfE2ovnj4QsUCJ/B/LZlinJHN/d1lWKGVwBerj ikIHzK01T8qai1A/TuOY4UaJDPxT1VThL28b0vk+mwTU6MPWoKLvipxjPl6JXdrlaBPRmH0tW nd5Stql78xbfV/HRUfVQe5jZwTvC79wvpAcLHVFn4HWGpHollEpHatLs1uyzE/do1TiPXiN7h JMvPICi7z8uK7Nm7wmANXqrZwyCskHTNfx0EJ/Ef9dGADIrbpsD/e8cjUPfree01+bLtolUY9 G1PLlfMap6QjVP0sJvtSkmcPU2Y+twvFRn5hrThfA5cdH5U01Pnst4gTjL7uFN8NjNEWno/tZ vBTcS/WiBjyvS5z+u0PvERhcPdJBNXMh4/hV0aSirmaXPmTrmN7+piI8zdRY3N0F2TDnsAeZC pOBxvFkuCiOq5ZVxY19Obt8M3kDJXFxC/aYtA3xL5vingIeZHgWWvBry6wKfhcRrijsr7A+7f ZkfnXKOFhjT6KsfaGVxOZB09lkqStnWSzHOaEYQ== Archived-At: Subject: Re: [v6ops] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Thu, 08 Oct 2020 15:57:09 -0000 Hi Michael, Thanks for the comments. Pleased see inline below. Ian > On 7. Oct 2020, at 20:24, Michael Richardson = wrote: >=20 >=20 > ianfarrer@gmx.com wrote: >> R-4: If the relay has learned a route for a delegated prefix via a >> given interface, and receives traffic on this interface with a >> destination address within the delegated prefix (that is not an = on-link >> prefix for the relay), then it MUST be dropped. This is to prevent >> routing loops. An ICMPv6 Type 1, Code 6 (Destination Unreachable, >> reject route to destination) error message MAY be sent back to the >> client. The ICMP policy SHOULD be configurable. >=20 > ... >=20 >> The problem that this is trying to solve is: >=20 >> 3.5. Forwarding Loops between Client and Relay >=20 >> If the client loses information about a prefix that it is delegated >> while the lease entry and associated route is still active in the >> delegating relay, then the relay will forward traffic to the client >> which the client will return to the relay (which is the client's >> default gateway (learnt via an RA). The loop will continue until >> either the client is successfully reprovisioned via DHCP, or the = lease >> ages out in the relay. >=20 > I browsed through pd-relay-requirements, but I didn't know it was = being > worked on. (Did I fall off the dhc list again due to outsourced spam = filter? Probably) >=20 > The document was seemed clear and direct. > It may be that it could explain more about the consequences of failing = to > take some of the advice. >=20 >> Ole=E2=80=99s comment: "And I would also be happy if we could have = some >> implementors chime in with a "we are happy and able to implement this >> requirement=E2=80=9D.=E2=80=9D >=20 >> We would appreciate any feedback on this, especially from anyone with >> experience implementing DHCPv6 relays with PD. >=20 > My BMS implementation (2014-ish) had a DHCPv6 server listening per = PPPoE connection. > BMS/PPPoE operators often don't have DHCPv6 servers, and adding one = isn't > something they want to do. Making Radius run is hard enough.... > In that context, the client can't drop without killing the PPPoE = interface, > which drops the route, removing it from the IGP, etc. So despite = having > implemented, my experience is not particularly useful for you. >=20 > But, I'm very enthusiastic to have DHCPv6-PD be incorporated into = hypervisors > and LXD and Docker, so I hope the problem you describe will be = "common=E2=80=9D. >=20 > If a client goes way and does not properly restart, then the NCE = entries > associated with the routes will be invalid, and the traffic will be = dropped. > While the client is starting, the NCE entries will become valid, but = the > client won't have the state. The traffic will loop. > This could become a serious problems, particularly if the traffic = loops at > very high speed, worse case, causing the client to fail again. >=20 > Best case, it goes on for a few seconds, then the client perhaps a = DHCPv6-PD, > gets delegated the same prefix and everything is normal again. > Perhaps for this reason alone, delegated prefixes need to be stable = across > their lifetime. Perhaps that is obvious, but there are many flash > renumbering discussions... >=20 > The concerning case is, I think, that the client comes up fine, but = declines > to do a DHCPv6-PD for some reason. Maybe the option was turned off = and the > CPE device rebooted. Or maybe it won't do the PD until some event = occurs, > like some VM gets started. [if - We didn=E2=80=99t consider this scenario but it could certainly be = a problem here.=20 Do you think that the current problem description text and requirement=20= adequately cover this case?] >=20 > It seems to me that we need some additional protocol where the relay = can be > informed to blackhole the traffic by the DHCP server. [if - I=E2=80=99m not sure how that could work. if the relay isn=E2=80=99t= aware that the client=E2=80=99s DHCP state is out of sync with its own, how can the server know this to tell = the relay to blackhole?] >=20 > -- > Michael Richardson . o O ( IPv6 I=C3=B8T = consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide >=20 From nobody Thu Oct 8 09:16:12 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 DF5DB3A0E52; Thu, 8 Oct 2020 09:16:10 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=gmx.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 Zl_iiViBshEy; Thu, 8 Oct 2020 09:16:08 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 7FA713A0E5C; Thu, 8 Oct 2020 09:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1602173758; bh=z/YxokhOxoGZ1LQ6iYIOzazXvi13XROxeWSYBjgReQc=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=P7mZ6I3wlJ+ubyRQMue0KeL1HOZexPb98Q//M9w60zrZVCdW/Fz/uoTlaCcPcWiWo dSBIQjD8CIcOEbrU8NDZZYX4oB0xl19w+47KYQ3gwscaV3pJdJ42rIoExxpgwKZPsT cUudvrsPWN76/COdagiOCBEgW6RFVj+iRm5/dSP8= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.128.43] ([87.79.171.64]) by mail.gmx.com (mrgmx104 [212.227.17.174]) with ESMTPSA (Nemesis) id 1MJE6F-1k5zSX1ALL-00Kcyr; Thu, 08 Oct 2020 18:15:58 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: ianfarrer@gmx.com In-Reply-To: Date: Thu, 8 Oct 2020 18:15:55 +0200 Cc: Jen Linkova , dhcwg , v6ops list , 6man Content-Transfer-Encoding: quoted-printable Message-Id: References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> To: "Templin (US), Fred L" X-Mailer: Apple Mail (2.3445.104.15) X-Provags-ID: V03:K1:k5DQHcRjYSBWRLb0FA0Xo31K/gAHUKfAmzsaJI2qy8CNcmqipij kp1hn3qFN7zy/kH2/eEMVSAr/YIzOAsasxfIYNB0v4Z82CaIsk37VdKvzs+/D1zczxNDRRH Gdd44NtkV3iGoB09ceCJTwFrDf7TFjoqJgzF8D+j2UQEkjvTWZUn7BBlHiq+INVNeXhBtQl idyuw3ipgTjKvYXz8xUhw== X-UI-Out-Filterresults: notjunk:1;V03:K0:jeXRExWMa3U=:zYI9rwwgtcfAJ3qlQgD+Zb DaDdBG1rO1YbKqeXcY43AVUynJtK3mAs3XyBFtg3AXRV2LIiys1ne0x8pWiVCWMSuUain1M8z kvvVLvO8uBQsU5S+rRRow1n+qt40O7JuywPUlwHDetyT5lExX/YQgShBH3TM2OFXDomX2orwD K4TIdsRjagodmza7B/ohn/mPeVRqG/4Q3XNBNetN9P1N9ycVy54J1sRMCaJPJ3HdHx1bWM9ON iwN0Vzos7iU7pCvlRDpmAEdFilY2fyNOZcrlxbAzOCPvYwL9Lh3NGg6z6xOXuDX8d7GT37hr3 7ThIbN1+EUX6KR3y0MAatn4sb6XnoWhosTgRlkNvZSk/ylXJeHWWzI/My4MhmWpRgYnBKhMap 0hCsQzO62iB35JCYuFkUVMz4w3P7un+M7PJ0pzwPpOmMqM2nwRp6Xggvrbc1vVawg9CuYhkMm J5otqFMmcxnWZdJ+H0caC8WnHEI1T6PSQhyrTMJ4LITJlrdHBWcBjCBSo7G2+zwoU5inNTA3k FdTk0EXdZxqtFmuK8D2T7WQB6Z3HFk5qILdU1OKHQozoOobZ+0SrnQ+bCxNacPA7m2qGstt1+ H/KQUdqui+Jl/wl+lH/uov3SVWCCF/v//4u5OY66w4fIlKYQYcWwBCWsBKKKf7jl2qrtfOIhk YhDXP2wcJx3qvxntn2XFzYRb00BGKehyV2gG7JW0vfeqBwJsfILeJObcOYm4+BdAS/47Sdj76 Q7fjE332NJvmTUkTazKSY4VqIsnzcxTXP5rNKHH79OZ7jf1eX9P5KvaNp5m8lD8R6T99jl/l6 Z6AN2QniHpSIhG4sgL443CiWiK20+mofPAAt6oim+BM9f2UZIb/iJtwGpB5V8lNcrJ9h1lIV4 ncrPoTNYJfD9fTAAdIPeIYtayYU11HUEJw9/s9/qd3vp8msYHs5y8F+3KTwLZlvnQIjAEx5fb W5wX5ly91mx7vSJYhhBX5nyi9SE0TTVWpO4Ct42gpuNPWycuJXtlvqPAVx7g3ne/xIRs9K24R COeZx/WgRtyz69mhCYPO5qPNtZyGOqVDnZpwqbJlTPGV2pOkxcEAXZgERryOPEZRuW7qvYo85 NrgRZ+j0cJUtpy3ocChC0GT87qJiUeRYQsbkKhHTnKQpoW/Pv61Uey/2DyHRtuHbg/mNH04fB +Dblo8KpwnyyNqP8h0cBPCeryMctowyR86E9X6sR8OPI/R0akBQ5pgj+jXympEfZey/tbKWeT 3JUOkX5+44M2gDNdbjv+pZ0906jklbIx8EgmQAA== Archived-At: Subject: Re: [v6ops] [EXTERNAL] Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Thu, 08 Oct 2020 16:16:11 -0000 Hi Fred / Jen Please see inline below. Thanks, Ian > On 8. Oct 2020, at 17:51, Templin (US), Fred L = wrote: >=20 > Jen, >=20 >> What would happen if the *second* device sends traffic towards the >> delegated prefix? As that device is usig the relay as its default >> gateway, the traffic would be sent there. >> If I read the draft correctly, instead of forwarding the traffic and >> maybe sending the redirect, the relay is expected to drop it? >=20 > The way that I interpret it, when the second device sends the traffic > to the relay, the relay would still forward the traffic to the client, = which > would then forward the traffic back to the relay, then at that point = the > relay would drop the traffic. Unless the second node somehow has a > way of knowing that the client has entered into an amnesiac state and > then does a malicious "flood-ping", we can expect applications to = quickly > learn that the IP addresses of the client are no longer reachable. = Plus, > these amnesiac conditions can be expected to be rare and transient; > not steady-state. >=20 > Fred [if - If I understand Jen=E2=80=99s question correctly, it=E2=80=99s = related to the =E2=80=98working=E2=80=99 case. i.e. the client has completed PD, installed the routes and the relay has the relevant lease info/routes. When the second device sends via the default route with a destination = address in the delegated prefix, R-4 in it=E2=80=99s current form would cause = the traffic to be dropped. As the relay doesn=E2=80=99t forward the packet, it can=E2=80=99t send a = redirect (per RFC4681), so the second device can=E2=80=99t forward. Looking at this, I think there are deployment scenarios where R-4 = isn=E2=80=99t going to=20 work.=20 My suggestion would be to make R-4 disable-able.] >=20 >=20 >> -----Original Message----- >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Jen Linkova >> Sent: Wednesday, October 07, 2020 6:25 PM >> To: ianfarrer@gmx.com >> Cc: dhcwg ; v6ops list ; 6man = >> Subject: [EXTERNAL] Re: [dhcwg] Question to DHCPv6 Relay Implementors = regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements >>=20 >> This message was sent from outside of Boeing. Please do not click = links or open attachments unless you recognize the sender and >> know that the content is safe. >>=20 >>=20 >> On Wed, Oct 7, 2020 at 9:25 PM wrote: >>> We are currently finishing WGLC for this draft. It describes = requirements for a 'DHCPv6 Delegating Relay' - this is a router = functioning >> as the L3 edge and DHCPv6 relay (only) with prefix delegation. This = is a common deployment scenario, but RFC3633/8415 only really >> describes PD using a Delegating Router - i.e the L3 edge also = functions as a DHCPv6 server with no relay. When the relay and server >> functions are performed by separate devices a number of problems with = how relays behave have >>> been observed, so this document addresses them. >>>=20 >>> During WGLC for this, Ole raised a comment related to one of the = routing requirements: >>>=20 >>> R-4: If the relay has learned a route for a delegated prefix via = a >>> given interface, and receives traffic on this interface = with >>> a destination address within the delegated prefix (that is >>> not an on-link prefix for the relay), then it MUST be >>> dropped. This is to prevent routing loops. An ICMPv6 = Type >>> 1, Code 6 (Destination Unreachable, reject route to >>> destination) error message MAY be sent back to the client. >>> The ICMP policy SHOULD be configurable. >>>=20 >>> The problem that this is trying to solve is: >>>=20 >>> 3.5. Forwarding Loops between Client and Relay >>=20 >> I might be missing smth but... >> Let's say I have a relay and it's 'south' (client-facing) interface = is >> connected to a switch. The client AND second device (another router = or >> a host) are connected to the same segment. >> The client gets a prefix, the relay 'learned' (or shall we call it >> 'install'?) the route for the delegated prefix pointing to its = 'south' >> interface with the client address as a next-hop. >> What would happen if the *second* device sends traffic towards the >> delegated prefix? As that device is usig the relay as its default >> gateway, the traffic would be sent there. >> If I read the draft correctly, instead of forwarding the traffic and >> maybe sending the redirect, the relay is expected to drop it? >>=20 >> -- >> SY, Jen Linkova aka Furry >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 From nobody Thu Oct 8 11:20:12 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 E4BCA3A0BDA; Thu, 8 Oct 2020 11:20:03 -0700 (PDT) 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 Sy2JHW1B9-Gj; Thu, 8 Oct 2020 11:20:02 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF743A0BD9; Thu, 8 Oct 2020 11:20:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 959F2389C6; Thu, 8 Oct 2020 14:25:27 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id E1jXtybwAhEb; Thu, 8 Oct 2020 14:25:26 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C4CEA389C0; Thu, 8 Oct 2020 14:25:26 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4A03418B; Thu, 8 Oct 2020 14:19:59 -0400 (EDT) From: Michael Richardson To: ianfarrer@gmx.com, dhcwg cc: v6ops list , ipv6@ietf.org In-Reply-To: References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <15177.1602095087@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [v6ops] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Thu, 08 Oct 2020 18:20:04 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ianfarrer@gmx.com wrote: >> The concerning case is, I think, that the client comes up fine, but = declines >> to do a DHCPv6-PD for some reason. Maybe the option was turned off = and the >> CPE device rebooted. Or maybe it won't do the PD until some event = occurs, >> like some VM gets started. > [if - We didn=E2=80=99t consider this scenario but it could certainly= be a problem here. > Do you think that the current problem description text and requirement > adequately cover this case?] I'm told that the acceptable/running-code for a bunch of this stuff is that the relay snoops the DHCP reply. We were supposed to have DHCP server->rel= ay options for doing this, but they just didn't get implemented/used. I think that we are now getting bitten by this. What I would expect, in an ideal world, is that when the client does their DHCP renew, that the server would send the relay the current state. If the PD disappears from that state, then the relay knows it can blackhole the prefix. >> It seems to me that we need some additional protocol where the relay= can be >> informed to blackhole the traffic by the DHCP server. > [if - I=E2=80=99m not sure how that could work. if the relay isn=E2= =80=99t aware that the client=E2=80=99s DHCP > state is out of sync with its own, how can the server know this to te= ll the relay to > blackhole?] I think that the server knows if it's just a regular renew or an allocation of the IA_NA. Maybe we need to do something with Reconfigure, if a server notices the client didn't ask for the PD in order to check if it's still in= use. (Sorry, my DHCP terminology has bit-rotted. I'll go read the document to remember the right terminology...) =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9/WE8ACgkQgItw+93Q 3WXiqQgAghNa6atgexg+yccJAajKXmF48uMDc1tHatX08SYZ+cxqRFK0R6ONySBU jTRjfYe+YoDsZLdaricM9LpnEtxS20SEODSUW5/nBX2aQn/82X6f/P/8YHZ9EC6Y qqhzAwDYTvfqFXs9Slnj1POI3KufHX268hKAjl9NxuwOX3goj4ogn4z5bcjkfAFk iWJUvmCRAGRIrlgqH2WUvGD8a6gf5ERHjIDA8i3RYjTMyhlSnb9zS+IkSZVWxCqE GVElJa9MUJ6Ffnln1wy3d+ULneihowqC71zhNQV1/VR4YlF4cnaX85YpJyk9Gv3+ weTsT5hXWbLh1kE/sKPZ7G3sBkHfaQ== =/2L2 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 8 14:19: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 736DF3A0DCA; Thu, 8 Oct 2020 14:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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.001, RCVD_IN_MSPIKE_WL=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=cm5kdcnC; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ax54wx/e Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuSx4xyFkeDj; Thu, 8 Oct 2020 14:18:51 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 518453A0DAD; Thu, 8 Oct 2020 14:18:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8396; q=dns/txt; s=iport; t=1602191924; x=1603401524; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=MarrT1lXeAkuVbZHcrgXsZrAyIc+jRY655fHjVn0gvs=; b=cm5kdcnCUwXBg0YII/3gZujF7vLBQUfATPgFkpgDsx12DiWupcv33cPn rHxGpCIWlLWJFoc+8D80bQAUewu7vJxSiyzNctQ8vPDv/dbHbJVF3xX6u GiachNO9cHBGSR6rR+keHPUP0BOQp5VZm+phiLk0ibZgHQ21RqAmaqVxH g=; IronPort-PHdr: =?us-ascii?q?9a23=3AnmP32hfhdMrP/jRyGffYIu1ilGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQBdfU7uICgO3T4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS8n7dxvZpXjhpTIXEw?= =?us-ascii?q?/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DYBQD9gH9f/4kNJK1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgU+BUlEHcFkvLAqEM4NGA41RmHuBQoERA1ULAQEBDQEBGAs?= =?us-ascii?q?KAgQBAYRKAheBcwIlOBMCAwEBCwEBBQEBAQIBBgRthVwMhXIBAQEBAgEBARA?= =?us-ascii?q?REQwBASwLAQQHBAIBCBEEAQEBAgIfBAMCAgIlCxQBCAgCBA4FCBqDBYJLAw4?= =?us-ascii?q?gAQ6eKQKBOYgsNXaBMoMBAQEFgTMBg2gYghADBoEOKoJyg22CRIQSG4IAgRF?= =?us-ascii?q?Dgk0+ghpCAQGBICcaBTOCXTOCLZAigyKSJWCRFAqCaJsJgxOKBoU/igmET5M?= =?us-ascii?q?boB0CBAIEBQIOAQEFgWsjgVdwFTuCaVAXAg2OHzeDOoUUhUJ0AjUCBgEJAQE?= =?us-ascii?q?DCXyMOwGBEAEB?= X-IronPort-AV: E=Sophos;i="5.77,352,1596499200"; d="scan'208";a="557625360" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Oct 2020 21:18:43 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 098LIhKh028983 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 8 Oct 2020 21:18:43 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 8 Oct 2020 16:18:42 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 8 Oct 2020 16:18:42 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 8 Oct 2020 16:18:42 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ObjKcNnnhohB1qXLb2VP5JTELs8kq/tZGgxfEv+l2zZe2RorsYU/hDqP7ZQhnEWqEAtuJ4DpudS5ZfrgsagCMh/n0ijXZo29BlmbYV3kiYP1uXDDxVDNwTO8RksxI7P6ytGqE7SKSs/RbwqPOn/lHF7g7dNxJvo39icYtjCukohi+NqAEm0MGeuGEUUCLKc7V+mXAhiBc8ymD8HmFz/dW+pXWXVEgDmDCfppERiw0KwTOnRgKvAYW90tdEh1Mxxh6A0K1i2ITUPjTNxGIwGvW/bQzJD+sjKJicthL3vvCQZmvwl1NsqYJrg/fRN9qibzTEzDN/2gtJWHo8LHFa+xpw== 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=MarrT1lXeAkuVbZHcrgXsZrAyIc+jRY655fHjVn0gvs=; b=HZAWAAbFhacep52F+T44mfVtEHzhD/Qw3SJKVmeO0fOjnmfMZ5GIgkhHDpaPnV69NvBYiI1d2PDXNNo0IAy7l2judu0fW6mB4Ca1JEidX5B0RaZL2rD3ZvAntC6mQ2+9b+fqsKRlenYyR6IK5wHz79df6e6WHrfSiwONY6kfR494aG7x5wSZYeUo5wmD+Lc2TpJ+XX9RuQHym5GvJYXuGSB9N7vLjGQxL2ekQeEg+A3sX/vfXMfSQ24SpNKjpSH6JwjxxLWF0xLScxKM8JLVtIoGhlfyl41amS7MTMRDFvK4rmOMurCuNtKPUpLpPP2Cac4Sl42YexsWEVADtcu+EQ== 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=MarrT1lXeAkuVbZHcrgXsZrAyIc+jRY655fHjVn0gvs=; b=ax54wx/eTCbMu9DG5Nx/jpa360MuoKsm2pi6JKim/UCf5/b5qsMEA27fifncXQ9I5gKXMHd5LTj4IkD3udPrvmX1bLO6q3q4ENc+jrf3uf8eIW3YvVqmmrQh25jC+bM0HH2iyYnIxBU8Ufj+ar1aDG/AJVvlYajRKBFGirpMlGc= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN6PR1101MB2212.namprd11.prod.outlook.com (2603:10b6:405:52::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.21; Thu, 8 Oct 2020 21:18:41 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::2180:35e4:fe29:e470]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::2180:35e4:fe29:e470%3]) with mapi id 15.20.3455.024; Thu, 8 Oct 2020 21:18:41 +0000 From: "Bernie Volz (volz)" To: "ianfarrer@gmx.com" , "Templin (US), Fred L" CC: dhcwg , 6man , v6ops list Thread-Topic: [v6ops] [EXTERNAL] Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AQHWnY5pT1BZPqcqAkuJPITGjT8WRqmONFtw Date: Thu, 8 Oct 2020 21:18:41 +0000 Message-ID: References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmx.com; dkim=none (message not signed) header.d=none;gmx.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [24.233.121.124] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 435acfb5-036d-4342-0551-08d86bcfbb02 x-ms-traffictypediagnostic: BN6PR1101MB2212: 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: 5G2fCQ/KvpFbPejz4n+agM0xze8WUSEx1r1c3q6/lcE9d04DpWBgNPHl7+7LfQ9WL3QF/lNHl9zKuUywSrEMzN3jh6iLmGYzlYD8D8gVUURNgxsi/nDkfUdQyrA9CxhcebotXqQ7VSK+UpqPdYASxg1Ppyb1FHpiv24LxGNCxnmhdTYE4Uu/9fFh7A+/Bc+rvbzyJbGhma+2T1Q/YSVmQJATLpVnBY6CBKg1FoERGkCPPabS0DclAJSKnRUZFcbAvLugPcUX9bfC0P4AFV7BmEF0KDhepuGiY4BXifr2Gu2xjIAWgJpb5KncDY85EJVShFj2FiDRnE1ZHOv2rgjZrj2NiKRUsSxAK6OPgxIrbWpIarTB7v15Bdjs3/zWQH1fAuhAqvwDr1buo8UMAtk5E6b4ni9ivm66OiqTIn+2XWXHNvVoNnIk/SLUIpV0ZhpDPRHBfravGs1bpC1mMoL/pA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2547.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(376002)(366004)(346002)(39860400002)(136003)(53546011)(52536014)(66946007)(5660300002)(6506007)(71200400001)(76116006)(8936002)(66476007)(66556008)(64756008)(8676002)(66446008)(83080400001)(478600001)(966005)(83380400001)(66574015)(7696005)(2906002)(55016002)(110136005)(54906003)(86362001)(186003)(26005)(4326008)(9686003)(316002)(33656002)(518174003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 2zVWTW9WEOee+xffPBNSZ9cqJV6M68VRp1V62VDizccbXmlakHuipd6MxTEDRNLuVi6voYON/mTpIMiirh85u18HM5zChxXH3iG/1e2ls2QjxrjTkZKqRZSpzL4SuXSaPInvqW0L8TMuTlKbywemUtH+0DeKbWjNy8yoBc+d7k6KEzSaHeRsvOHC/W5/Mna7wFjgIAXeEIxAgOPq8IH+okchI/EPNOy5UrWB0evseuq063lbsuGXE5OyfIZvCVSfVgpVMvynCq2DUcwPBJRiPYX8Btn8YvwD9IaLK5iOrSqYuCbPTFKbc4tXSf7gU0mh5KQwui3Kf82qyMyEJ/HXl1E+j0IwS4d7dBqIuF7kdJB/b5NSaNcEAawyDSOxEKfqRNtmfNjFMbXHG2uI653HNerMGRxPLl5meILQhAUNNEKrQmlgFCaPkFcAnEwoTYenLCNvcZ1HRYpNOzS5ejhYiUbXioPz/xD2P+oOihqpSjN944ZSuzraPCWvn2Xq0Z/lpgGnRo/4zIHmqvr0+z5dBSU1KDY+0LX2EQQcGY6D65ED3cVJcnh9LJy62gYmm6eyveGWeQn5sRV/YU+bZ+CVrGchkVZHMaZ87oviH42VsV8rF6Cz/x9yOzaljvFwwLBuQCZB4vL1FcgAj42HBA6J/Q== 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: BN7PR11MB2547.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 435acfb5-036d-4342-0551-08d86bcfbb02 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2020 21:18:41.1719 (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: KnKVdmoBjjuM21njnOzzIpoTsiZyd8vQe/mvtB4vfMkJzH9Sdxvra4oXzPHidzpo X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1101MB2212 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [v6ops] [EXTERNAL] Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Thu, 08 Oct 2020 21:18:54 -0000 SXMgdGhpcyBhIG1vZGVsIHdoZXJlIGluIHlvdXIgRmlndXJlIDEsIHlvdSBoYXZlIGEgc3dpdGNo IGJldHdlZW4gdGhlIFBEIENsaWVudCBhbmQgRGVsZWdhdGluZyBSZWxheSBhbmQgeW91IG1pZ2h0 IGhhdmUgb3RoZXIgZGV2aWNlcyBvZmYgdGhhdCBzd2l0Y2g/DQoNCkluIHRoYXQgY2FzZSwgd2h5 IHdvdWxkIGFueSBvZiB0aGUgZGV2aWNlcyBvZmYgdGhhdCBzd2l0Y2ggYmUgdXNpbmcgdGhlIHBy ZWZpeCBnaXZlbiB0aGUgUEQgQ2xpZW50PyBIb3cgd291bGQgdGhleSBsZWFybiB0aGlzPyBJIGRv bid0IHRoaW5rIHRoZSBQRCBDbGllbnQgbm9yIERlbGVnYXRpbmcgUmVsYXkgc2hvdWxkIGJlIGRv aW5nIFJBcyB3aXRoIHRoZSBQRCBwcmVmaXggaW4gdGhlbSAob3IgYSBzdWItcHJlZml4KS4NCg0K SWYgdGhlIFBEIENsaWVudCBpcyBkb2luZyB0aGF0LCB0aGVuIGFueSBkZXZpY2VzIG9mZiB0aGUg c3dpdGNoIHdvdWxkIGJlIHVzaW5nIGl0IGFzIHRoZSBkZWZhdWx0IHJvdXRlciBmb3IgdGhhdCBw cmVmaXggYW5kIG5vdCB0aGUgZGVsZWdhdGluZyByZWxheT8gQW5kLCBoZW5jZSBubyB0cmFmZmlj IHNob3VsZCBiZSBkb2luZyB0byB0aGUgZGVsZWdhdGluZyByZWxheSB3aXRoIHRoZSBQRCBkZXN0 aW5hdGlvbiBhZGRyZXNzLg0KDQpPciwgZG8gSSBoYXZlIHRoaXMgbW9kZWwgd3Jvbmc/DQoNCi0g QmVybmllDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiB2Nm9wcyA8djZvcHMt Ym91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIGlhbmZhcnJlckBnbXguY29tDQpTZW50OiBU aHVyc2RheSwgT2N0b2JlciA4LCAyMDIwIDEyOjE2IFBNDQpUbzogVGVtcGxpbiAoVVMpLCBGcmVk IEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+DQpDYzogZGhjd2cgPGRoY3dnQGlldGYub3Jn PjsgNm1hbiA8aXB2NkBpZXRmLm9yZz47IHY2b3BzIGxpc3QgPHY2b3BzQGlldGYub3JnPg0KU3Vi amVjdDogUmU6IFt2Nm9wc10gW0VYVEVSTkFMXSBSZTogW2RoY3dnXSBRdWVzdGlvbiB0byBESENQ djYgUmVsYXkgSW1wbGVtZW50b3JzIHJlZ2FyZGluZyBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtcGQt cmVsYXktcmVxdWlyZW1lbnRzDQoNCkhpIEZyZWQgLyBKZW4NCg0KUGxlYXNlIHNlZSBpbmxpbmUg YmVsb3cuDQoNClRoYW5rcywNCklhbg0KDQo+IE9uIDguIE9jdCAyMDIwLCBhdCAxNzo1MSwgVGVt cGxpbiAoVVMpLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+IHdyb3RlOg0KPiAN Cj4gSmVuLA0KPiANCj4+IFdoYXQgd291bGQgaGFwcGVuIGlmIHRoZSAqc2Vjb25kKiBkZXZpY2Ug c2VuZHMgdHJhZmZpYyB0b3dhcmRzIHRoZSANCj4+IGRlbGVnYXRlZCBwcmVmaXg/IEFzIHRoYXQg ZGV2aWNlIGlzIHVzaWcgdGhlIHJlbGF5IGFzIGl0cyBkZWZhdWx0IA0KPj4gZ2F0ZXdheSwgdGhl IHRyYWZmaWMgd291bGQgYmUgc2VudCB0aGVyZS4NCj4+IElmIEkgcmVhZCB0aGUgZHJhZnQgY29y cmVjdGx5LCBpbnN0ZWFkIG9mIGZvcndhcmRpbmcgdGhlIHRyYWZmaWMgYW5kIA0KPj4gbWF5YmUg c2VuZGluZyB0aGUgcmVkaXJlY3QsIHRoZSByZWxheSBpcyBleHBlY3RlZCB0byBkcm9wIGl0Pw0K PiANCj4gVGhlIHdheSB0aGF0IEkgaW50ZXJwcmV0IGl0LCB3aGVuIHRoZSBzZWNvbmQgZGV2aWNl IHNlbmRzIHRoZSB0cmFmZmljIA0KPiB0byB0aGUgcmVsYXksIHRoZSByZWxheSB3b3VsZCBzdGls bCBmb3J3YXJkIHRoZSB0cmFmZmljIHRvIHRoZSBjbGllbnQsIA0KPiB3aGljaCB3b3VsZCB0aGVu IGZvcndhcmQgdGhlIHRyYWZmaWMgYmFjayB0byB0aGUgcmVsYXksIHRoZW4gYXQgdGhhdCANCj4g cG9pbnQgdGhlIHJlbGF5IHdvdWxkIGRyb3AgdGhlIHRyYWZmaWMuIFVubGVzcyB0aGUgc2Vjb25k IG5vZGUgc29tZWhvdyANCj4gaGFzIGEgd2F5IG9mIGtub3dpbmcgdGhhdCB0aGUgY2xpZW50IGhh cyBlbnRlcmVkIGludG8gYW4gYW1uZXNpYWMgDQo+IHN0YXRlIGFuZCB0aGVuIGRvZXMgYSBtYWxp Y2lvdXMgImZsb29kLXBpbmciLCB3ZSBjYW4gZXhwZWN0IA0KPiBhcHBsaWNhdGlvbnMgdG8gcXVp Y2tseSBsZWFybiB0aGF0IHRoZSBJUCBhZGRyZXNzZXMgb2YgdGhlIGNsaWVudCBhcmUgDQo+IG5v IGxvbmdlciByZWFjaGFibGUuIFBsdXMsIHRoZXNlIGFtbmVzaWFjIGNvbmRpdGlvbnMgY2FuIGJl IGV4cGVjdGVkIA0KPiB0byBiZSByYXJlIGFuZCB0cmFuc2llbnQ7IG5vdCBzdGVhZHktc3RhdGUu DQo+IA0KPiBGcmVkDQoNCltpZiAtIElmIEkgdW5kZXJzdGFuZCBKZW7igJlzIHF1ZXN0aW9uIGNv cnJlY3RseSwgaXTigJlzIHJlbGF0ZWQgdG8gdGhlIOKAmHdvcmtpbmfigJkgY2FzZS4NCmkuZS4g dGhlIGNsaWVudCBoYXMgY29tcGxldGVkIFBELCBpbnN0YWxsZWQgdGhlIHJvdXRlcyBhbmQgdGhl IHJlbGF5IGhhcyB0aGUgcmVsZXZhbnQgbGVhc2UgaW5mby9yb3V0ZXMuDQoNCldoZW4gdGhlIHNl Y29uZCBkZXZpY2Ugc2VuZHMgdmlhIHRoZSBkZWZhdWx0IHJvdXRlIHdpdGggYSBkZXN0aW5hdGlv biBhZGRyZXNzIGluIHRoZSBkZWxlZ2F0ZWQgcHJlZml4LCBSLTQgaW4gaXTigJlzIGN1cnJlbnQg Zm9ybSB3b3VsZCBjYXVzZSB0aGUgdHJhZmZpYyB0byBiZSBkcm9wcGVkLg0KQXMgdGhlIHJlbGF5 IGRvZXNu4oCZdCBmb3J3YXJkIHRoZSBwYWNrZXQsIGl0IGNhbuKAmXQgc2VuZCBhIHJlZGlyZWN0 IChwZXIgUkZDNDY4MSksIHNvIHRoZSBzZWNvbmQgZGV2aWNlIGNhbuKAmXQgZm9yd2FyZC4NCg0K TG9va2luZyBhdCB0aGlzLCBJIHRoaW5rIHRoZXJlIGFyZSBkZXBsb3ltZW50IHNjZW5hcmlvcyB3 aGVyZSBSLTQgaXNu4oCZdCBnb2luZyB0byB3b3JrLiANCg0KTXkgc3VnZ2VzdGlvbiB3b3VsZCBi ZSB0byBtYWtlIFItNCBkaXNhYmxlLWFibGUuXQ0KDQoNCg0KPiANCj4gDQo+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEplbiBMaW5rb3ZhDQo+PiBTZW50OiBXZWRuZXNkYXksIE9jdG9i ZXIgMDcsIDIwMjAgNjoyNSBQTQ0KPj4gVG86IGlhbmZhcnJlckBnbXguY29tDQo+PiBDYzogZGhj d2cgPGRoY3dnQGlldGYub3JnPjsgdjZvcHMgbGlzdCA8djZvcHNAaWV0Zi5vcmc+OyA2bWFuIA0K Pj4gPGlwdjZAaWV0Zi5vcmc+DQo+PiBTdWJqZWN0OiBbRVhURVJOQUxdIFJlOiBbZGhjd2ddIFF1 ZXN0aW9uIHRvIERIQ1B2NiBSZWxheSBJbXBsZW1lbnRvcnMgDQo+PiByZWdhcmRpbmcgZHJhZnQt aWV0Zi1kaGMtZGhjcHY2LXBkLXJlbGF5LXJlcXVpcmVtZW50cw0KPj4gDQo+PiBUaGlzIG1lc3Nh Z2Ugd2FzIHNlbnQgZnJvbSBvdXRzaWRlIG9mIEJvZWluZy4gUGxlYXNlIGRvIG5vdCBjbGljayAN Cj4+IGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdSByZWNvZ25pemUgdGhlIHNl bmRlciBhbmQga25vdyB0aGF0IHRoZSBjb250ZW50IGlzIHNhZmUuDQo+PiANCj4+IA0KPj4gT24g V2VkLCBPY3QgNywgMjAyMCBhdCA5OjI1IFBNIDxpYW5mYXJyZXJAZ214LmNvbT4gd3JvdGU6DQo+ Pj4gV2UgYXJlIGN1cnJlbnRseSBmaW5pc2hpbmcgV0dMQyBmb3IgdGhpcyBkcmFmdC4gSXQgZGVz Y3JpYmVzIA0KPj4+IHJlcXVpcmVtZW50cyBmb3IgYSAnREhDUHY2IERlbGVnYXRpbmcgUmVsYXkn IC0gdGhpcyBpcyBhIHJvdXRlciANCj4+PiBmdW5jdGlvbmluZw0KPj4gYXMgdGhlIEwzIGVkZ2Ug YW5kIERIQ1B2NiByZWxheSAob25seSkgd2l0aCBwcmVmaXggZGVsZWdhdGlvbi4gVGhpcyANCj4+ IGlzIGEgY29tbW9uIGRlcGxveW1lbnQgc2NlbmFyaW8sIGJ1dCBSRkMzNjMzLzg0MTUgb25seSBy ZWFsbHkgDQo+PiBkZXNjcmliZXMgUEQgdXNpbmcgYSBEZWxlZ2F0aW5nIFJvdXRlciAtIGkuZSB0 aGUgTDMgZWRnZSBhbHNvIA0KPj4gZnVuY3Rpb25zIGFzIGEgREhDUHY2IHNlcnZlciB3aXRoIG5v IHJlbGF5LiBXaGVuIHRoZSByZWxheSBhbmQgc2VydmVyIA0KPj4gZnVuY3Rpb25zIGFyZSBwZXJm b3JtZWQgYnkgc2VwYXJhdGUgZGV2aWNlcyBhIG51bWJlciBvZiBwcm9ibGVtcyB3aXRoIA0KPj4g aG93IHJlbGF5cyBiZWhhdmUgaGF2ZQ0KPj4+IGJlZW4gb2JzZXJ2ZWQsIHNvIHRoaXMgZG9jdW1l bnQgYWRkcmVzc2VzIHRoZW0uDQo+Pj4gDQo+Pj4gRHVyaW5nIFdHTEMgZm9yIHRoaXMsIE9sZSBy YWlzZWQgYSBjb21tZW50IHJlbGF0ZWQgdG8gb25lIG9mIHRoZSByb3V0aW5nIHJlcXVpcmVtZW50 czoNCj4+PiANCj4+PiBSLTQ6ICAgIElmIHRoZSByZWxheSBoYXMgbGVhcm5lZCBhIHJvdXRlIGZv ciBhIGRlbGVnYXRlZCBwcmVmaXggdmlhIGENCj4+PiAgICAgICAgICAgZ2l2ZW4gaW50ZXJmYWNl LCBhbmQgcmVjZWl2ZXMgdHJhZmZpYyBvbiB0aGlzIGludGVyZmFjZSB3aXRoDQo+Pj4gICAgICAg ICAgIGEgZGVzdGluYXRpb24gYWRkcmVzcyB3aXRoaW4gdGhlIGRlbGVnYXRlZCBwcmVmaXggKHRo YXQgaXMNCj4+PiAgICAgICAgICAgbm90IGFuIG9uLWxpbmsgcHJlZml4IGZvciB0aGUgcmVsYXkp LCB0aGVuIGl0IE1VU1QgYmUNCj4+PiAgICAgICAgICAgZHJvcHBlZC4gIFRoaXMgaXMgdG8gcHJl dmVudCByb3V0aW5nIGxvb3BzLiAgQW4gSUNNUHY2IFR5cGUNCj4+PiAgICAgICAgICAgMSwgQ29k ZSA2IChEZXN0aW5hdGlvbiBVbnJlYWNoYWJsZSwgcmVqZWN0IHJvdXRlIHRvDQo+Pj4gICAgICAg ICAgIGRlc3RpbmF0aW9uKSBlcnJvciBtZXNzYWdlIE1BWSBiZSBzZW50IGJhY2sgdG8gdGhlIGNs aWVudC4NCj4+PiAgICAgICAgICAgVGhlIElDTVAgcG9saWN5IFNIT1VMRCBiZSBjb25maWd1cmFi bGUuDQo+Pj4gDQo+Pj4gVGhlIHByb2JsZW0gdGhhdCB0aGlzIGlzIHRyeWluZyB0byBzb2x2ZSBp czoNCj4+PiANCj4+PiAzLjUuICBGb3J3YXJkaW5nIExvb3BzIGJldHdlZW4gQ2xpZW50IGFuZCBS ZWxheQ0KPj4gDQo+PiBJIG1pZ2h0IGJlIG1pc3Npbmcgc210aCBidXQuLi4NCj4+IExldCdzIHNh eSBJIGhhdmUgYSByZWxheSBhbmQgaXQncyAnc291dGgnIChjbGllbnQtZmFjaW5nKSBpbnRlcmZh Y2UgDQo+PiBpcyBjb25uZWN0ZWQgdG8gYSBzd2l0Y2guIFRoZSBjbGllbnQgQU5EIHNlY29uZCBk ZXZpY2UgKGFub3RoZXIgDQo+PiByb3V0ZXIgb3IgYSBob3N0KSBhcmUgY29ubmVjdGVkIHRvIHRo ZSBzYW1lIHNlZ21lbnQuDQo+PiBUaGUgY2xpZW50IGdldHMgYSBwcmVmaXgsIHRoZSByZWxheSAn bGVhcm5lZCcgKG9yIHNoYWxsIHdlIGNhbGwgaXQNCj4+ICdpbnN0YWxsJz8pIHRoZSByb3V0ZSBm b3IgdGhlIGRlbGVnYXRlZCBwcmVmaXggcG9pbnRpbmcgdG8gaXRzICdzb3V0aCcNCj4+IGludGVy ZmFjZSB3aXRoIHRoZSBjbGllbnQgYWRkcmVzcyBhcyBhIG5leHQtaG9wLg0KPj4gV2hhdCB3b3Vs ZCBoYXBwZW4gaWYgdGhlICpzZWNvbmQqIGRldmljZSBzZW5kcyB0cmFmZmljIHRvd2FyZHMgdGhl IA0KPj4gZGVsZWdhdGVkIHByZWZpeD8gQXMgdGhhdCBkZXZpY2UgaXMgdXNpZyB0aGUgcmVsYXkg YXMgaXRzIGRlZmF1bHQgDQo+PiBnYXRld2F5LCB0aGUgdHJhZmZpYyB3b3VsZCBiZSBzZW50IHRo ZXJlLg0KPj4gSWYgSSByZWFkIHRoZSBkcmFmdCBjb3JyZWN0bHksIGluc3RlYWQgb2YgZm9yd2Fy ZGluZyB0aGUgdHJhZmZpYyBhbmQgDQo+PiBtYXliZSBzZW5kaW5nIHRoZSByZWRpcmVjdCwgdGhl IHJlbGF5IGlzIGV4cGVjdGVkIHRvIGRyb3AgaXQ/DQo+PiANCj4+IC0tDQo+PiBTWSwgSmVuIExp bmtvdmEgYWthIEZ1cnJ5DQo+PiANCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiBJRVRGIElQdjYgd29ya2lu ZyBncm91cCBtYWlsaW5nIGxpc3QNCj4+IGlwdjZAaWV0Zi5vcmcNCj4+IEFkbWluaXN0cmF0aXZl IFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+IA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KdjZvcHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K From nobody Thu Oct 8 14:54: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 E4EAC3A0E7F; Thu, 8 Oct 2020 14:54:46 -0700 (PDT) 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=boeing.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 1fwnt8km6HDF; Thu, 8 Oct 2020 14:54:44 -0700 (PDT) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 B11C73A0E4B; Thu, 8 Oct 2020 14:54:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 098LseRo025985; Thu, 8 Oct 2020 17:54:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602194083; bh=Z28rkMXwBQtnPt9F48YZWbk3Q52VlXlE+Djx8k7MGxA=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=W5h121wDIjNqT9pYHqOj6MwQx3/agIOt/iwEEM6q+x8EhGvJfDfCg9Pn5nT9RqrYm FP08dQKl853CaJtKnKLZAJ9XubrIIC8gbGhX/EFel9mytfDkpWwW81T0sm2HXI1Og0 hMiKJzYZGIztISJx0PR29qmcKJqyVoaRWvh/78vnRvEIi7lA4BfEo2hsdLd2NBmy6r 4Oh0jOtS6+W3HIkPtM1FclrnYfeRNv+xbe45/MVE5MdjQ5D0dDDMtRRb3c93mwf8B+ u+K16vCmTCs1zcIr16T+GQFgtxS/Nyh7TfdvwQ+nd+kX8P/rfhPwDsqdBY4LQxF+rm E45ijujEqJ26w== Received: from XCH16-07-07.nos.boeing.com (xch16-07-07.nos.boeing.com [144.115.66.109]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 098LsXvq025651 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 8 Oct 2020 17:54:33 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-07.nos.boeing.com (144.115.66.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Thu, 8 Oct 2020 14:54:32 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8]) by XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8%2]) with mapi id 15.01.2044.004; Thu, 8 Oct 2020 14:54:32 -0700 From: "Templin (US), Fred L" To: "Bernie Volz (volz)" , "ianfarrer@gmx.com" CC: dhcwg , 6man , v6ops list Thread-Topic: [v6ops] [EXTERNAL] Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AQHWnRHm524iPz3PtEmCznTLyJxcLqmONFtwgAAJLjA= Date: Thu, 8 Oct 2020 21:54:32 +0000 Message-ID: References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 26504EF9C1F1CFE14608028B54EBA4933616F180CEF16C0BF2B6CDAD59DAF1012000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [EXTERNAL] Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Thu, 08 Oct 2020 21:54:47 -0000 QmVybmllLA0KDQpMZXQncyBzYXkgdHdvIGNsaWVudHMgQSBhbmQgQiBhcmUgY29ubmVjdGVkIHRv IGEgc3dpdGNoIHdoaWNoIGlzIHRoZW4gY29ubmVjdGVkIHRvDQpyZWxheSBSLiBDbGllbnRzIEEg YW5kIEIgcmVjZWl2ZSBQRHMgZnJvbSB0aGUgREhDUHY2IHNlcnZpY2UgdGhhdCBhcmUgcmVsYXll ZCBieQ0KUiwgYW5kIFIgZXN0YWJsaXNoZXMgcm91dGVzIGZvciB0aGUgZGVsZWdhdGVkIHByZWZp eGVzIEEgYW5kIEIuIEEgYW5kIEIgYm90aCByZWdhcmQNClIgYXMgYSBkZWZhdWx0IHJvdXRlci4N Cg0KTm93LCBzdXBwb3NlIHR3byB0aGluZ3M6DQoNCi0gY2xpZW50IEIgZGlzY292ZXJzIHRocm91 Z2ggc29tZSBtZWFucyAoZS5nLiwgRE5TKSB0aGUgSVAgYWRkcmVzcyBvZiBhIHNlcnZpY2UNCiAg IGVuZHBvaW50IHdpdGhpbiBwcmVmaXggQQ0KLSBjbGllbnQgQSBzb21laG93ICJmb3JnZXRzIiB0 aGF0IGl0IHJlY2VpdmVkIHRoZSBwcmVmaXggZGVsZWdhdGlvbiBBDQoNCk5vdywgY2xpZW50IEIg c2VuZHMgcGFja2V0cyBkZXN0aW5lZCB0byBhbiBhZGRyZXNzIGluIEEgdG8gUiwgYW5kIFIgZm9y d2FyZHMgdGhlDQpwYWNrZXRzIHRvIGNsaWVudCBBIHNpbmNlIGl0IHN0aWxsIGhhcyBhIHJvdXRl IGZvciBBLiBXaGVuIHRoZSBwYWNrZXRzIGFycml2ZSBhdCBBLA0KaG93ZXZlciwgQSBmb3J3YXJk cyB0aGVtIGJhY2sgdG8gUiBzaW5jZSBpdCBoYXMgImZvcmdvdHRlbiIgdGhhdCBpdCBob2xkcyB0 aGUNCnByZWZpeCBBLiBXaGVuIFIgcmVjZWl2ZXMgdGhlIHBhY2tldHMgZnJvbSBBIHdpdGggZGVz dGluYXRpb24gYWRkcmVzcyBhbHNvDQpmcm9tIHByZWZpeCBBLCBpdCBtdXN0IGRyb3AgdGhlbSBp bnN0ZWFkIG9mIGZvcndhcmRpbmcgdGhlbSBiYWNrIHRvIEEgdG8NCmF2b2lkIGxvb3BpbmcuDQoN Ck5vdGU6IElmIFIgaGFkIHNlbnQgYSBSZWRpcmVjdCB0byBCLCB0aGUgc2FtZSBzY2VuYXJpbyB3 b3VsZCBwbGF5IG91dCBleGNlcHQNCnRoYXQgQiB3b3VsZCBzZW5kIGl0cyBzdWJzZXF1ZW50IHBh Y2tldHMgZGlyZWN0bHkgdG8gQS4gQnV0IHRoZW4sIEEgd291bGQgYWdhaW4NCnN0aWxsIGZvcndh cmQgdGhlbSB0byBSIHdoaWNoIG11c3QgZHJvcCBpbnN0ZWFkIG9mIGZvcndhcmRpbmcgYmFjayB0 byBBLg0KDQpGcmVkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVy bmllIFZvbHogKHZvbHopIFttYWlsdG86dm9sekBjaXNjby5jb21dDQo+IFNlbnQ6IFRodXJzZGF5 LCBPY3RvYmVyIDA4LCAyMDIwIDI6MTkgUE0NCj4gVG86IGlhbmZhcnJlckBnbXguY29tOyBUZW1w bGluIChVUyksIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4NCj4gQ2M6IGRoY3dn IDxkaGN3Z0BpZXRmLm9yZz47IDZtYW4gPGlwdjZAaWV0Zi5vcmc+OyB2Nm9wcyBsaXN0IDx2Nm9w c0BpZXRmLm9yZz4NCj4gU3ViamVjdDogUkU6IFt2Nm9wc10gW0VYVEVSTkFMXSBSZTogW2RoY3dn XSBRdWVzdGlvbiB0byBESENQdjYgUmVsYXkgSW1wbGVtZW50b3JzIHJlZ2FyZGluZyBkcmFmdC1p ZXRmLWRoYy1kaGNwdjYtcGQtcmVsYXktDQo+IHJlcXVpcmVtZW50cw0KPiANCj4gDQo+IElzIHRo aXMgYSBtb2RlbCB3aGVyZSBpbiB5b3VyIEZpZ3VyZSAxLCB5b3UgaGF2ZSBhIHN3aXRjaCBiZXR3 ZWVuIHRoZSBQRCBDbGllbnQgYW5kIERlbGVnYXRpbmcgUmVsYXkgYW5kIHlvdSBtaWdodCBoYXZl IG90aGVyDQo+IGRldmljZXMgb2ZmIHRoYXQgc3dpdGNoPw0KPiANCj4gSW4gdGhhdCBjYXNlLCB3 aHkgd291bGQgYW55IG9mIHRoZSBkZXZpY2VzIG9mZiB0aGF0IHN3aXRjaCBiZSB1c2luZyB0aGUg cHJlZml4IGdpdmVuIHRoZSBQRCBDbGllbnQ/IEhvdyB3b3VsZCB0aGV5IGxlYXJuIHRoaXM/IEkg ZG9uJ3QNCj4gdGhpbmsgdGhlIFBEIENsaWVudCBub3IgRGVsZWdhdGluZyBSZWxheSBzaG91bGQg YmUgZG9pbmcgUkFzIHdpdGggdGhlIFBEIHByZWZpeCBpbiB0aGVtIChvciBhIHN1Yi1wcmVmaXgp Lg0KPiANCj4gSWYgdGhlIFBEIENsaWVudCBpcyBkb2luZyB0aGF0LCB0aGVuIGFueSBkZXZpY2Vz IG9mZiB0aGUgc3dpdGNoIHdvdWxkIGJlIHVzaW5nIGl0IGFzIHRoZSBkZWZhdWx0IHJvdXRlciBm b3IgdGhhdCBwcmVmaXggYW5kIG5vdCB0aGUNCj4gZGVsZWdhdGluZyByZWxheT8gQW5kLCBoZW5j ZSBubyB0cmFmZmljIHNob3VsZCBiZSBkb2luZyB0byB0aGUgZGVsZWdhdGluZyByZWxheSB3aXRo IHRoZSBQRCBkZXN0aW5hdGlvbiBhZGRyZXNzLg0KPiANCj4gT3IsIGRvIEkgaGF2ZSB0aGlzIG1v ZGVsIHdyb25nPw0KPiANCj4gLSBCZXJuaWUNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IHY2b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2Yg aWFuZmFycmVyQGdteC5jb20NCj4gU2VudDogVGh1cnNkYXksIE9jdG9iZXIgOCwgMjAyMCAxMjox NiBQTQ0KPiBUbzogVGVtcGxpbiAoVVMpLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5j b20+DQo+IENjOiBkaGN3ZyA8ZGhjd2dAaWV0Zi5vcmc+OyA2bWFuIDxpcHY2QGlldGYub3JnPjsg djZvcHMgbGlzdCA8djZvcHNAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbdjZvcHNdIFtFWFRF Uk5BTF0gUmU6IFtkaGN3Z10gUXVlc3Rpb24gdG8gREhDUHY2IFJlbGF5IEltcGxlbWVudG9ycyBy ZWdhcmRpbmcgZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LXBkLXJlbGF5LQ0KPiByZXF1aXJlbWVudHMN Cj4gDQo+IEhpIEZyZWQgLyBKZW4NCj4gDQo+IFBsZWFzZSBzZWUgaW5saW5lIGJlbG93Lg0KPiAN Cj4gVGhhbmtzLA0KPiBJYW4NCj4gDQo+ID4gT24gOC4gT2N0IDIwMjAsIGF0IDE3OjUxLCBUZW1w bGluIChVUyksIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4gd3JvdGU6DQo+ID4N Cj4gPiBKZW4sDQo+ID4NCj4gPj4gV2hhdCB3b3VsZCBoYXBwZW4gaWYgdGhlICpzZWNvbmQqIGRl dmljZSBzZW5kcyB0cmFmZmljIHRvd2FyZHMgdGhlDQo+ID4+IGRlbGVnYXRlZCBwcmVmaXg/IEFz IHRoYXQgZGV2aWNlIGlzIHVzaWcgdGhlIHJlbGF5IGFzIGl0cyBkZWZhdWx0DQo+ID4+IGdhdGV3 YXksIHRoZSB0cmFmZmljIHdvdWxkIGJlIHNlbnQgdGhlcmUuDQo+ID4+IElmIEkgcmVhZCB0aGUg ZHJhZnQgY29ycmVjdGx5LCBpbnN0ZWFkIG9mIGZvcndhcmRpbmcgdGhlIHRyYWZmaWMgYW5kDQo+ ID4+IG1heWJlIHNlbmRpbmcgdGhlIHJlZGlyZWN0LCB0aGUgcmVsYXkgaXMgZXhwZWN0ZWQgdG8g ZHJvcCBpdD8NCj4gPg0KPiA+IFRoZSB3YXkgdGhhdCBJIGludGVycHJldCBpdCwgd2hlbiB0aGUg c2Vjb25kIGRldmljZSBzZW5kcyB0aGUgdHJhZmZpYw0KPiA+IHRvIHRoZSByZWxheSwgdGhlIHJl bGF5IHdvdWxkIHN0aWxsIGZvcndhcmQgdGhlIHRyYWZmaWMgdG8gdGhlIGNsaWVudCwNCj4gPiB3 aGljaCB3b3VsZCB0aGVuIGZvcndhcmQgdGhlIHRyYWZmaWMgYmFjayB0byB0aGUgcmVsYXksIHRo ZW4gYXQgdGhhdA0KPiA+IHBvaW50IHRoZSByZWxheSB3b3VsZCBkcm9wIHRoZSB0cmFmZmljLiBV bmxlc3MgdGhlIHNlY29uZCBub2RlIHNvbWVob3cNCj4gPiBoYXMgYSB3YXkgb2Yga25vd2luZyB0 aGF0IHRoZSBjbGllbnQgaGFzIGVudGVyZWQgaW50byBhbiBhbW5lc2lhYw0KPiA+IHN0YXRlIGFu ZCB0aGVuIGRvZXMgYSBtYWxpY2lvdXMgImZsb29kLXBpbmciLCB3ZSBjYW4gZXhwZWN0DQo+ID4g YXBwbGljYXRpb25zIHRvIHF1aWNrbHkgbGVhcm4gdGhhdCB0aGUgSVAgYWRkcmVzc2VzIG9mIHRo ZSBjbGllbnQgYXJlDQo+ID4gbm8gbG9uZ2VyIHJlYWNoYWJsZS4gUGx1cywgdGhlc2UgYW1uZXNp YWMgY29uZGl0aW9ucyBjYW4gYmUgZXhwZWN0ZWQNCj4gPiB0byBiZSByYXJlIGFuZCB0cmFuc2ll bnQ7IG5vdCBzdGVhZHktc3RhdGUuDQo+ID4NCj4gPiBGcmVkDQo+IA0KPiBbaWYgLSBJZiBJIHVu ZGVyc3RhbmQgSmVu4oCZcyBxdWVzdGlvbiBjb3JyZWN0bHksIGl04oCZcyByZWxhdGVkIHRvIHRo ZSDigJh3b3JraW5n4oCZIGNhc2UuDQo+IGkuZS4gdGhlIGNsaWVudCBoYXMgY29tcGxldGVkIFBE LCBpbnN0YWxsZWQgdGhlIHJvdXRlcyBhbmQgdGhlIHJlbGF5IGhhcyB0aGUgcmVsZXZhbnQgbGVh c2UgaW5mby9yb3V0ZXMuDQo+IA0KPiBXaGVuIHRoZSBzZWNvbmQgZGV2aWNlIHNlbmRzIHZpYSB0 aGUgZGVmYXVsdCByb3V0ZSB3aXRoIGEgZGVzdGluYXRpb24gYWRkcmVzcyBpbiB0aGUgZGVsZWdh dGVkIHByZWZpeCwgUi00IGluIGl04oCZcyBjdXJyZW50IGZvcm0gd291bGQNCj4gY2F1c2UgdGhl IHRyYWZmaWMgdG8gYmUgZHJvcHBlZC4NCj4gQXMgdGhlIHJlbGF5IGRvZXNu4oCZdCBmb3J3YXJk IHRoZSBwYWNrZXQsIGl0IGNhbuKAmXQgc2VuZCBhIHJlZGlyZWN0IChwZXIgUkZDNDY4MSksIHNv IHRoZSBzZWNvbmQgZGV2aWNlIGNhbuKAmXQgZm9yd2FyZC4NCj4gDQo+IExvb2tpbmcgYXQgdGhp cywgSSB0aGluayB0aGVyZSBhcmUgZGVwbG95bWVudCBzY2VuYXJpb3Mgd2hlcmUgUi00IGlzbuKA mXQgZ29pbmcgdG8gd29yay4NCj4gDQo+IE15IHN1Z2dlc3Rpb24gd291bGQgYmUgdG8gbWFrZSBS LTQgZGlzYWJsZS1hYmxlLl0NCj4gDQo+IA0KPiANCj4gPg0KPiA+DQo+ID4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IGlwdjYgW21haWx0bzppcHY2LWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBKZW4gTGlua292YQ0KPiA+PiBTZW50OiBXZWRuZXNkYXksIE9j dG9iZXIgMDcsIDIwMjAgNjoyNSBQTQ0KPiA+PiBUbzogaWFuZmFycmVyQGdteC5jb20NCj4gPj4g Q2M6IGRoY3dnIDxkaGN3Z0BpZXRmLm9yZz47IHY2b3BzIGxpc3QgPHY2b3BzQGlldGYub3JnPjsg Nm1hbg0KPiA+PiA8aXB2NkBpZXRmLm9yZz4NCj4gPj4gU3ViamVjdDogW0VYVEVSTkFMXSBSZTog W2RoY3dnXSBRdWVzdGlvbiB0byBESENQdjYgUmVsYXkgSW1wbGVtZW50b3JzDQo+ID4+IHJlZ2Fy ZGluZyBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtcGQtcmVsYXktcmVxdWlyZW1lbnRzDQo+ID4+DQo+ ID4+IFRoaXMgbWVzc2FnZSB3YXMgc2VudCBmcm9tIG91dHNpZGUgb2YgQm9laW5nLiBQbGVhc2Ug ZG8gbm90IGNsaWNrDQo+ID4+IGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdSBy ZWNvZ25pemUgdGhlIHNlbmRlciBhbmQga25vdyB0aGF0IHRoZSBjb250ZW50IGlzIHNhZmUuDQo+ ID4+DQo+ID4+DQo+ID4+IE9uIFdlZCwgT2N0IDcsIDIwMjAgYXQgOToyNSBQTSA8aWFuZmFycmVy QGdteC5jb20+IHdyb3RlOg0KPiA+Pj4gV2UgYXJlIGN1cnJlbnRseSBmaW5pc2hpbmcgV0dMQyBm b3IgdGhpcyBkcmFmdC4gSXQgZGVzY3JpYmVzDQo+ID4+PiByZXF1aXJlbWVudHMgZm9yIGEgJ0RI Q1B2NiBEZWxlZ2F0aW5nIFJlbGF5JyAtIHRoaXMgaXMgYSByb3V0ZXINCj4gPj4+IGZ1bmN0aW9u aW5nDQo+ID4+IGFzIHRoZSBMMyBlZGdlIGFuZCBESENQdjYgcmVsYXkgKG9ubHkpIHdpdGggcHJl Zml4IGRlbGVnYXRpb24uIFRoaXMNCj4gPj4gaXMgYSBjb21tb24gZGVwbG95bWVudCBzY2VuYXJp bywgYnV0IFJGQzM2MzMvODQxNSBvbmx5IHJlYWxseQ0KPiA+PiBkZXNjcmliZXMgUEQgdXNpbmcg YSBEZWxlZ2F0aW5nIFJvdXRlciAtIGkuZSB0aGUgTDMgZWRnZSBhbHNvDQo+ID4+IGZ1bmN0aW9u cyBhcyBhIERIQ1B2NiBzZXJ2ZXIgd2l0aCBubyByZWxheS4gV2hlbiB0aGUgcmVsYXkgYW5kIHNl cnZlcg0KPiA+PiBmdW5jdGlvbnMgYXJlIHBlcmZvcm1lZCBieSBzZXBhcmF0ZSBkZXZpY2VzIGEg bnVtYmVyIG9mIHByb2JsZW1zIHdpdGgNCj4gPj4gaG93IHJlbGF5cyBiZWhhdmUgaGF2ZQ0KPiA+ Pj4gYmVlbiBvYnNlcnZlZCwgc28gdGhpcyBkb2N1bWVudCBhZGRyZXNzZXMgdGhlbS4NCj4gPj4+ DQo+ID4+PiBEdXJpbmcgV0dMQyBmb3IgdGhpcywgT2xlIHJhaXNlZCBhIGNvbW1lbnQgcmVsYXRl ZCB0byBvbmUgb2YgdGhlIHJvdXRpbmcgcmVxdWlyZW1lbnRzOg0KPiA+Pj4NCj4gPj4+IFItNDog ICAgSWYgdGhlIHJlbGF5IGhhcyBsZWFybmVkIGEgcm91dGUgZm9yIGEgZGVsZWdhdGVkIHByZWZp eCB2aWEgYQ0KPiA+Pj4gICAgICAgICAgIGdpdmVuIGludGVyZmFjZSwgYW5kIHJlY2VpdmVzIHRy YWZmaWMgb24gdGhpcyBpbnRlcmZhY2Ugd2l0aA0KPiA+Pj4gICAgICAgICAgIGEgZGVzdGluYXRp b24gYWRkcmVzcyB3aXRoaW4gdGhlIGRlbGVnYXRlZCBwcmVmaXggKHRoYXQgaXMNCj4gPj4+ICAg ICAgICAgICBub3QgYW4gb24tbGluayBwcmVmaXggZm9yIHRoZSByZWxheSksIHRoZW4gaXQgTVVT VCBiZQ0KPiA+Pj4gICAgICAgICAgIGRyb3BwZWQuICBUaGlzIGlzIHRvIHByZXZlbnQgcm91dGlu ZyBsb29wcy4gIEFuIElDTVB2NiBUeXBlDQo+ID4+PiAgICAgICAgICAgMSwgQ29kZSA2IChEZXN0 aW5hdGlvbiBVbnJlYWNoYWJsZSwgcmVqZWN0IHJvdXRlIHRvDQo+ID4+PiAgICAgICAgICAgZGVz dGluYXRpb24pIGVycm9yIG1lc3NhZ2UgTUFZIGJlIHNlbnQgYmFjayB0byB0aGUgY2xpZW50Lg0K PiA+Pj4gICAgICAgICAgIFRoZSBJQ01QIHBvbGljeSBTSE9VTEQgYmUgY29uZmlndXJhYmxlLg0K PiA+Pj4NCj4gPj4+IFRoZSBwcm9ibGVtIHRoYXQgdGhpcyBpcyB0cnlpbmcgdG8gc29sdmUgaXM6 DQo+ID4+Pg0KPiA+Pj4gMy41LiAgRm9yd2FyZGluZyBMb29wcyBiZXR3ZWVuIENsaWVudCBhbmQg UmVsYXkNCj4gPj4NCj4gPj4gSSBtaWdodCBiZSBtaXNzaW5nIHNtdGggYnV0Li4uDQo+ID4+IExl dCdzIHNheSBJIGhhdmUgYSByZWxheSBhbmQgaXQncyAnc291dGgnIChjbGllbnQtZmFjaW5nKSBp bnRlcmZhY2UNCj4gPj4gaXMgY29ubmVjdGVkIHRvIGEgc3dpdGNoLiBUaGUgY2xpZW50IEFORCBz ZWNvbmQgZGV2aWNlIChhbm90aGVyDQo+ID4+IHJvdXRlciBvciBhIGhvc3QpIGFyZSBjb25uZWN0 ZWQgdG8gdGhlIHNhbWUgc2VnbWVudC4NCj4gPj4gVGhlIGNsaWVudCBnZXRzIGEgcHJlZml4LCB0 aGUgcmVsYXkgJ2xlYXJuZWQnIChvciBzaGFsbCB3ZSBjYWxsIGl0DQo+ID4+ICdpbnN0YWxsJz8p IHRoZSByb3V0ZSBmb3IgdGhlIGRlbGVnYXRlZCBwcmVmaXggcG9pbnRpbmcgdG8gaXRzICdzb3V0 aCcNCj4gPj4gaW50ZXJmYWNlIHdpdGggdGhlIGNsaWVudCBhZGRyZXNzIGFzIGEgbmV4dC1ob3Au DQo+ID4+IFdoYXQgd291bGQgaGFwcGVuIGlmIHRoZSAqc2Vjb25kKiBkZXZpY2Ugc2VuZHMgdHJh ZmZpYyB0b3dhcmRzIHRoZQ0KPiA+PiBkZWxlZ2F0ZWQgcHJlZml4PyBBcyB0aGF0IGRldmljZSBp cyB1c2lnIHRoZSByZWxheSBhcyBpdHMgZGVmYXVsdA0KPiA+PiBnYXRld2F5LCB0aGUgdHJhZmZp YyB3b3VsZCBiZSBzZW50IHRoZXJlLg0KPiA+PiBJZiBJIHJlYWQgdGhlIGRyYWZ0IGNvcnJlY3Rs eSwgaW5zdGVhZCBvZiBmb3J3YXJkaW5nIHRoZSB0cmFmZmljIGFuZA0KPiA+PiBtYXliZSBzZW5k aW5nIHRoZSByZWRpcmVjdCwgdGhlIHJlbGF5IGlzIGV4cGVjdGVkIHRvIGRyb3AgaXQ/DQo+ID4+ DQo+ID4+IC0tDQo+ID4+IFNZLCBKZW4gTGlua292YSBha2EgRnVycnkNCj4gPj4NCj4gPj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gPj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+ID4+ IGlwdjZAaWV0Zi5vcmcNCj4gPj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+DQo+ IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2 Nm9wcyBtYWlsaW5nIGxpc3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0K From nobody Thu Oct 8 15:00:57 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 450443A0EDA; Thu, 8 Oct 2020 15:00:47 -0700 (PDT) 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 fS9OFhu7Eohl; Thu, 8 Oct 2020 15:00:46 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 779F73A12C8; Thu, 8 Oct 2020 14:59:59 -0700 (PDT) Received: from [192.168.10.181] (201.51-175-101.customer.lyse.net [51.175.101.201]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 063614E11B2E; Thu, 8 Oct 2020 21:59:57 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ole Troan Mime-Version: 1.0 (1.0) Date: Thu, 8 Oct 2020 23:59:40 +0200 Message-Id: <6373DDB1-753B-4E15-8097-9ED03F1BFC19@employees.org> References: Cc: "Bernie Volz (volz)" , ianfarrer@gmx.com, dhcwg , v6ops list , 6man In-Reply-To: To: "Templin (US), Fred L" X-Mailer: iPhone Mail (18A393) Archived-At: Subject: Re: [v6ops] [EXTERNAL] Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Thu, 08 Oct 2020 22:00:47 -0000 > On 8 Oct 2020, at 23:55, Templin (US), Fred L w= rote: >=20 > Now, client B sends packets destined to an address in A to R, and R forwar= ds the > packets to client A since it still has a route for A. When the packets arr= ive at A, > however, A forwards them back to R since it has "forgotten" that it holds t= he > prefix A. When R receives the packets from A with destination address also= > from prefix A, it must drop them instead of forwarding them back to A to > avoid looping. This is indeed what the requirement in the draft says.=20 This isn=E2=80=99t quite obvious how to implement, which why I brought up th= e question if anyone had implemented this. And if it=E2=80=99s supported in h= w etc.=20 Ole= From nobody Thu Oct 8 15:08: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 99C013A0ED9; Thu, 8 Oct 2020 15:08:53 -0700 (PDT) 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, RCVD_IN_MSPIKE_H2=-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=boeing.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 vfuGzXEdDH4e; Thu, 8 Oct 2020 15:08:52 -0700 (PDT) Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 1EC023A0D0B; Thu, 8 Oct 2020 15:08:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 098M8nhv018770; Thu, 8 Oct 2020 18:08:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602194930; bh=t5e3y7MGk7jGLZJ6Y6p905pbMhkMe271JPWELBuxyp4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=LcqJLbuZ+i1ACNr3o9xNdrF7RQdtgZX5w6++umgJOpwKNYN8W8+ctNfv+XIIBKt6O 82SzMiCDTpQ3x1YmP7ZVrzrTFb03ACqwXsFF8ihLSFAkn74YN/fAStzR73elpR4DRh h+5ar+tzwtOVrWgbIj/dYoXXiOsLDy6ZvTyYADI9qJfU6IWpEaf+EbIISygNnKFPSv 2qN9OvqSBXobCZFfaybrp6qLSQgVvMbDHXUAPTxq84+V2gsgpr0FMJSHU8bK7w8FW6 uEdSpy8BEiWYnakDnRBXymDqmp9nGhM+gcC058e48mDluUN58gwjI5ZQDMPz7V9Iar xe4VQTnw8gz+Q== Received: from XCH16-07-11.nos.boeing.com (xch16-07-11.nos.boeing.com [144.115.66.113]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 098M8cJK017700 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 8 Oct 2020 18:08:38 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-11.nos.boeing.com (144.115.66.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Thu, 8 Oct 2020 15:08:37 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8]) by XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8%2]) with mapi id 15.01.2044.004; Thu, 8 Oct 2020 15:08:37 -0700 From: "Templin (US), Fred L" To: Ole Troan CC: "Bernie Volz (volz)" , "ianfarrer@gmx.com" , dhcwg , v6ops list , 6man Thread-Topic: [v6ops] [EXTERNAL] Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AQHWnRHm524iPz3PtEmCznTLyJxcLqmONFtwgAAJLjCAAHpQAP//i44Q Date: Thu, 8 Oct 2020 22:08:37 +0000 Message-ID: <5b45336f7d9d489bb13a3559fd0a6b10@boeing.com> References: <6373DDB1-753B-4E15-8097-9ED03F1BFC19@employees.org> In-Reply-To: <6373DDB1-753B-4E15-8097-9ED03F1BFC19@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: B7FD0597B6672F08934C80883DA8D9A6BE8FC2E9E88F71C828BFA02D29FB5A932000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [EXTERNAL] Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Thu, 08 Oct 2020 22:08:54 -0000 T2xlLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE9sZSBUcm9hbiBb bWFpbHRvOm90cm9hbkBlbXBsb3llZXMub3JnXQ0KPiBTZW50OiBUaHVyc2RheSwgT2N0b2JlciAw OCwgMjAyMCAzOjAwIFBNDQo+IFRvOiBUZW1wbGluIChVUyksIEZyZWQgTCA8RnJlZC5MLlRlbXBs aW5AYm9laW5nLmNvbT4NCj4gQ2M6IEJlcm5pZSBWb2x6ICh2b2x6KSA8dm9sekBjaXNjby5jb20+ OyBpYW5mYXJyZXJAZ214LmNvbTsgZGhjd2cgPGRoY3dnQGlldGYub3JnPjsgdjZvcHMgbGlzdCA8 djZvcHNAaWV0Zi5vcmc+OyA2bWFuDQo+IDxpcHY2QGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTog W3Y2b3BzXSBbRVhURVJOQUxdIFJlOiBbZGhjd2ddIFF1ZXN0aW9uIHRvIERIQ1B2NiBSZWxheSBJ bXBsZW1lbnRvcnMgcmVnYXJkaW5nIGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1wZC1yZWxheS0NCj4g cmVxdWlyZW1lbnRzDQo+IA0KPiANCj4gPiBPbiA4IE9jdCAyMDIwLCBhdCAyMzo1NSwgVGVtcGxp biAoVVMpLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+IHdyb3RlOg0KPiA+DQo+ ID4gTm93LCBjbGllbnQgQiBzZW5kcyBwYWNrZXRzIGRlc3RpbmVkIHRvIGFuIGFkZHJlc3MgaW4g QSB0byBSLCBhbmQgUiBmb3J3YXJkcyB0aGUNCj4gPiBwYWNrZXRzIHRvIGNsaWVudCBBIHNpbmNl IGl0IHN0aWxsIGhhcyBhIHJvdXRlIGZvciBBLiBXaGVuIHRoZSBwYWNrZXRzIGFycml2ZSBhdCBB LA0KPiA+IGhvd2V2ZXIsIEEgZm9yd2FyZHMgdGhlbSBiYWNrIHRvIFIgc2luY2UgaXQgaGFzICJm b3Jnb3R0ZW4iIHRoYXQgaXQgaG9sZHMgdGhlDQo+ID4gcHJlZml4IEEuIFdoZW4gUiByZWNlaXZl cyB0aGUgcGFja2V0cyBmcm9tIEEgd2l0aCBkZXN0aW5hdGlvbiBhZGRyZXNzIGFsc28NCj4gPiBm cm9tIHByZWZpeCBBLCBpdCBtdXN0IGRyb3AgdGhlbSBpbnN0ZWFkIG9mIGZvcndhcmRpbmcgdGhl bSBiYWNrIHRvIEEgdG8NCj4gPiBhdm9pZCBsb29waW5nLg0KPiANCj4gVGhpcyBpcyBpbmRlZWQg d2hhdCB0aGUgcmVxdWlyZW1lbnQgaW4gdGhlIGRyYWZ0IHNheXMuDQo+IFRoaXMgaXNu4oCZdCBx dWl0ZSBvYnZpb3VzIGhvdyB0byBpbXBsZW1lbnQsIHdoaWNoIHdoeSBJIGJyb3VnaHQgdXAgdGhl IHF1ZXN0aW9uIGlmIGFueW9uZSBoYWQgaW1wbGVtZW50ZWQgdGhpcy4gQW5kIGlmIGl04oCZcyBz dXBwb3J0ZWQNCj4gaW4gaHcgZXRjLg0KDQpJIGNhbiB0ZWxsIHlvdSBob3cgd2Ugd2lsbCBkbyBp dCBpbiBBRVJPL09NTkkuIFIgd2lsbCBoYXZlIGFuIE9NTkkgaW50ZXJmYWNlDQpuZWlnaGJvciBj YWNoZSBlbnRyeSAoTkNFKSBmb3IgQSB0aGF0IGxpbmtzIHRoZSBwcmVmaXggQSB3aXRoIHRoZSBs aW5rLWxheWVyDQphZGRyZXNzIG9mIEEuIFRoZW4sIHdoZW4gUiByZWNlaXZlcyBhIHBhY2tldCBm cm9tIEEncyBsaW5rLWxheWVyIGFkZHJlc3MgaXQNCmNvbnN1bHRzIGl0cyBOQ0UgdG8gc2VlIHRo YXQgQSBpcyB0aGUgaG9sZGVyIG9mIHByZWZpeCBBIGFuZCB0aGVyZWZvcmUgbm90IGENCnZhbGlk IHNvdXJjZSBvZiBwYWNrZXRzIHdpdGggZGVzdGluYXRpb24gYWRkcmVzcyBpbiBBLiBXZSB3aWxs IGhhdmUgdGhpcyBpbg0Kb3VyIGNvZGUgc29vbiAtIHRoYW5rcyBmb3IgdGhlIGNhdGNoIQ0KDQpG cmVkDQoNCj4gT2xlPQ0KDQo= From nobody Thu Oct 8 17:00: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 D30093A1059; Thu, 8 Oct 2020 17:00:00 -0700 (PDT) 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, RCVD_IN_MSPIKE_H2=-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=boeing.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 WFxAc6mt9axN; Thu, 8 Oct 2020 16:59:59 -0700 (PDT) Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 56D383A1058; Thu, 8 Oct 2020 16:59:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 098Nxuo3002159; Thu, 8 Oct 2020 19:59:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602201597; bh=ndlaZAw3AZz400IuhkSf2qttVQXBf833P6TuZvVZBJM=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=c9GkpSEdZpk6pmIiCTbr2ueI0xlMjK/AWpPpJuhzlNUUPvIkbZV4e2kN+wAJt2zGh Si8tGV2IY1HplAKr8Gurl7cWwRwcz40JZZebdcZVsDXYr0cXT3tI0C/LAg2ibtKZ/D mG+PHmF4UOZPDzxNY7DrMdXzqocz+wQk+KZNrhAwxjmatnSi0WeMLQQVAEmrdMTncy hovX3/dAhwpeoVRBwCqPlzPvpa4DCDRcfbeGlysh6fL1x4vHk/Y87AyNtGRWh6/ldr DWrrUw/XLJsWsDP2lnDM/aT/lwI8Mc8s+YY9UovSJJZJqKdK34RLR00KzFWwIfQNEL W2QTGN6/Ol+xw== Received: from XCH16-07-12.nos.boeing.com (xch16-07-12.nos.boeing.com [144.115.66.114]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 098NxsQE002049 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 8 Oct 2020 19:59:54 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-12.nos.boeing.com (144.115.66.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Thu, 8 Oct 2020 16:59:52 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8]) by XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8%2]) with mapi id 15.01.2044.004; Thu, 8 Oct 2020 16:59:52 -0700 From: "Templin (US), Fred L" To: Ole Troan CC: dhcwg , v6ops list , 6man Thread-Topic: [v6ops] [EXTERNAL] Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AQHWnRHm524iPz3PtEmCznTLyJxcLqmONFtwgAAJLjCAAHpQAP//i44QgAAdLpA= Date: Thu, 8 Oct 2020 23:59:52 +0000 Message-ID: <66fcc6c4c1d243108b6b2eb19719324c@boeing.com> References: <6373DDB1-753B-4E15-8097-9ED03F1BFC19@employees.org> <5b45336f7d9d489bb13a3559fd0a6b10@boeing.com> In-Reply-To: <5b45336f7d9d489bb13a3559fd0a6b10@boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 0314717583B03532B26E80B6A6DD482505929F3EF6037FB1F353B4B2079845302000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [EXTERNAL] Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Fri, 09 Oct 2020 00:00:01 -0000 T2xlLA0KDQo+IEkgY2FuIHRlbGwgeW91IGhvdyB3ZSB3aWxsIGRvIGl0IGluIEFFUk8vT01OSS4g UiB3aWxsIGhhdmUgYW4gT01OSSBpbnRlcmZhY2UNCj4gbmVpZ2hib3IgY2FjaGUgZW50cnkgKE5D RSkgZm9yIEEgdGhhdCBsaW5rcyB0aGUgcHJlZml4IEEgd2l0aCB0aGUgbGluay1sYXllcg0KPiBh ZGRyZXNzIG9mIEEuIFRoZW4sIHdoZW4gUiByZWNlaXZlcyBhIHBhY2tldCBmcm9tIEEncyBsaW5r LWxheWVyIGFkZHJlc3MgaXQNCj4gY29uc3VsdHMgaXRzIE5DRSB0byBzZWUgdGhhdCBBIGlzIHRo ZSBob2xkZXIgb2YgcHJlZml4IEEgYW5kIHRoZXJlZm9yZSBub3QgYQ0KPiB2YWxpZCBzb3VyY2Ug b2YgcGFja2V0cyB3aXRoIGRlc3RpbmF0aW9uIGFkZHJlc3MgaW4gQS4gV2Ugd2lsbCBoYXZlIHRo aXMgaW4NCj4gb3VyIGNvZGUgc29vbiAtIHRoYW5rcyBmb3IgdGhlIGNhdGNoIQ0KDQpPbiBmdXJ0 aGVyIHRob3VnaHQsIHRoaXMgaXMgY29tcGxpY2F0ZWQgYnkgdGhlIG11bHRpbGluayBuYXR1cmUg b2YgT01OSSBzaW5jZSB0aGUNCk9NTkkgbmVpZ2hib3IgY291bGQgaGF2ZSBtdWx0aXBsZSBsaW5r LWxheWVyIGFkZHJlc3Nlcy4gUiB3b3VsZCB0aGVuIGhhdmUgdG8NCnZlcnkgY2FyZWZ1bGx5IGNo ZWNrIHRoYXQsIGlmIGEgcGFja2V0IHdpdGggSVB2NiBkZXN0aW5hdGlvbiBhZGRyZXNzICdBJyBh cnJpdmVkDQpmcm9tIGxpbmstbGF5ZXIgYWRkcmVzcyAnYTEnLCB0aGF0IGl0IG5vdCBiZSBmb3J3 YXJkZWQgYmFjayB2aWEgbGluay1sYXllciBhZGRyZXNzDQonYTEnIG5vciBhbnkgb3RoZXIgbGlu ay1sYXllciBhZGRyZXNzZXMgJ2EyJywgJ2EzJywgJ2E0JywgZXRjLiBJdCBnZXRzIG1lc3N5IHF1 aWNrbHkuDQoNClNvLCB3aHkgbm90IGZpeCB0aGUgcHJvYmxlbSBhdCB0aGUgY2xpZW50IGluc3Rl YWQgb2YgYXQgdGhlIHJlbGF5PyBUaGUgY2xpZW50IGNvdWxkDQpoYXZlIGEgc2ltcGxlIGNoZWNr IHRvIG1ha2Ugc3VyZSBpdCBkb2VzIG5vdCBmb3J3YXJkIGEgcGFja2V0IG91dCB0aGUgc2FtZQ0K aW50ZXJmYWNlIHRoYXQgaXQgYXJyaXZlZCBvbiBkdWUgdG8gYSBkZWZhdWx0IHJvdXRlLiBUaGF0 IHdheSwgdGhlIHJlbGF5IHdvdWxkDQpuZXZlciBzZWUgYSBwYWNrZXQgb3JpZ2luYXRpbmcgZnJv bSBub2RlIEEgd2l0aCBhIGRlc3RpbmF0aW9uIGFkZHJlc3MgQS4NCihCVFcsIGl0IHNob3VsZCBi ZSBPSyBmb3IgdGhlIGNsaWVudCB0byBmb3J3YXJkIGEgcGFja2V0IG91dCB0aGUgc2FtZSBpbnRl cmZhY2UNCml0IGFycml2ZWQgb24gZHVlIHRvICBhIG1vcmUtc3BlY2lmaWMgcm91dGUgLSBidXQg bm90IGR1ZSB0byBhIGRlZmF1bHQgcm91dGUuKQ0KDQpGcmVkDQoNCg0K From nobody Thu Oct 8 17:52: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 8A9CD3A0BF2; Thu, 8 Oct 2020 17:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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.001, RCVD_IN_MSPIKE_WL=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=gR8CZP+U; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=FpgvSDrg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOFpYkmxYyB1; Thu, 8 Oct 2020 17:52:15 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB8E23A0A7E; Thu, 8 Oct 2020 17:52:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12526; q=dns/txt; s=iport; t=1602204735; x=1603414335; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NAbZQA1X2iwWhr1163BsOX5VwDWt9NWCI+qF4vuXX08=; b=gR8CZP+UiKx39MSVD1nleHsxqjeexqA22vE3yvIPZSz1oxLl1nWHlXGZ b1Y3mzKi9yotLiuXN3MxpE/of98sa9lvRsvGqnYoInoBauEzV/8Z+3j3i gTQl+EUO978mfzyu9rMji0g1+NJ3iIpVPIY/j4ohdyPLJOwe6aYfyBtsg M=; IronPort-PHdr: =?us-ascii?q?9a23=3AwcUU3hUZ2PA35CutEBEOeyMgjMzV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyDuf1Bm6zdtKWzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutaFjC5Ha16G1aFh?= =?us-ascii?q?D2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw?= =?us-ascii?q?=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPBQASs39f/4MNJK1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgU+BUlEHcFkvLAqEM4NGA41SmHuBQoERA1ULAQEBDQEBGAs?= =?us-ascii?q?KAgQBAYRKAheBcwIlOBMCAwEBCwEBBQEBAQIBBgRthS8IJQyFcgEBAQMBAQE?= =?us-ascii?q?QEREMAQEsCwEEBwQCAQgRBAEBAQICHwQDAgICJQsUAQgIAgQOBSJEgkABgks?= =?us-ascii?q?DDiABDp4VAoE5iCw1doEygwEBAQWBMwGDcBiCEAMGgQ4qgnKDbYJEhBIbggC?= =?us-ascii?q?BESccgU9+PoIaQgEBgSAnGAczgl0zgi2PfiQHgxuSJZF0CoJommcDH4MTiga?= =?us-ascii?q?FP4oJhE+zOAIEAgQFAg4BAQWBayOBV3AVOyoBgj5QFwINil6DQQwXFIM6hRS?= =?us-ascii?q?FQnQCNQIGAQkBAQMJfIw7AYEQAQE?= X-IronPort-AV: E=Sophos;i="5.77,353,1596499200"; d="scan'208";a="742713711" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Oct 2020 00:52:13 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 0990qD1u028074 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 9 Oct 2020 00:52:13 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 8 Oct 2020 19:52:12 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 8 Oct 2020 20:52:12 -0400 Received: from NAM12-DM6-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; Thu, 8 Oct 2020 20:52:12 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZIC3aCNFO8naPM2uPwdmmL4ZCQxAVBydNuNjetFPqh/3/y/C++4uqdB4h58hD242HUEKfTXswryS64+8sR16Vnp71XhLjMiiZfP1UCUXEVmdybmt5vl4QbSrDQXK+0fz0XMXXyL0GnVp8cU+rhFNOaQKp5zhsYXj6yVFbk1AmXD1/WKCuf56l7mA17Irdw/UtEX9aX8961Ao0FJ8KhungpRSY+LmCf8u/13ftd0UkKaj1Y+KO4M8uaLYkohowyy15e0CbOwv1zXN1ghRkSYuncAEUvHrkAK4pvPJkMrLD4ZtTtB/X9b5JymVYrakDLDeGxfjGlilsnK3q+883wH7mA== 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=NAbZQA1X2iwWhr1163BsOX5VwDWt9NWCI+qF4vuXX08=; b=lijTqf9FkY7Vse2Lp4razmeucVPETQfmAhwC0lCsQnMSuQXFaiDuVmgjEW2nQuYDQw7LkfeW1yHpURByvvnGuZwVudPxtfNYDUq8NVjI7s/McRRUzqV43lCyFfgOK17A50wjOa5r5wt8v/814g5JF9wVcoCj4UL5jSDgfRDt3Egt0c3/1Hk4+1yb/uEz8O4gpRfUWrp7yG2GorFCesbu4sUX/Qfq/4EMdDyhRtub+lU6ls+ZpdtsWqZwue7TCkjgkZZCfV+9n8SZBctaFFJ2mLiubwl1ZjIwQDaOlMDlfIlBXqP/gAHKQGKRt9hxUA8kjHcX5qU1zM+VToIOCU6kKQ== 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=NAbZQA1X2iwWhr1163BsOX5VwDWt9NWCI+qF4vuXX08=; b=FpgvSDrgGdA/yQ2vfu281+Co1fSVEiHsRQtAMfRMk6O+x2+NAQvMexu6xUB2lANYkyOH9IWaKwy8HQFxcoAfqJf2QlUAaY7nmKCCh+49G5gAkMTC8jrqxo8LFdW5hSX9fIXgsFChz59jd7PU72LhO+5f5sPbuvu9vQHnofi90ns= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN6PR11MB1713.namprd11.prod.outlook.com (2603:10b6:404:3c::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.21; Fri, 9 Oct 2020 00:52:10 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::2180:35e4:fe29:e470]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::2180:35e4:fe29:e470%3]) with mapi id 15.20.3455.024; Fri, 9 Oct 2020 00:52:10 +0000 From: "Bernie Volz (volz)" To: "Templin (US), Fred L" CC: "ianfarrer@gmx.com" , dhcwg , 6man , v6ops list Thread-Topic: [v6ops] [EXTERNAL] Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AQHWnY5pT1BZPqcqAkuJPITGjT8WRqmONFtwgAALvQCAADGh6A== Date: Fri, 9 Oct 2020 00:52:10 +0000 Message-ID: References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmx.com; dkim=none (message not signed) header.d=none;gmx.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [24.233.121.124] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6f76fd7a-f523-42db-5ff8-08d86bed8e02 x-ms-traffictypediagnostic: BN6PR11MB1713: 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: N26+O9VD4NrObSLjIVfPjJEXfDbwDwfe1UJn374AJtluP35s4bMyrIl5M1r25OT6DRbp+87Bk5dXTU9ZqJSgPAmoRstS5qwhoqNYM+qs+B+yjOMcRiKXVPaJXKpWkVF/hCqaKSFXoxbaodWX0I6//rZ7AwupuqETKHbDHTt6JiytvYd+i4/VR5fkjIoTuDJJs1shT1gwzK8Rdm5J8QNMYEF/T5eUAoSkGrNxuvgTTJT+8CS8ywzrGAJBeocTs1N+pNiScxmTnJjK8Klbwy06Vr1TWKD4pssNPgR407vQq3HD2IZPvneRnRhkDP/KUekwjy1nQ1oTsDNeYWtpKwAK8tySogedsnp3+FIZhetYMVwD/RBqpB6KaLf5vqWsqcoNeBD2XskWMokvhX8GvavF9vOOS01Iw2fAhlCE9i2IhKiDdvpvG7rmcxnXAKs5gFtZHcRKu3GsAfDXZ5jSm5bTng== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2547.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(346002)(366004)(136003)(396003)(39860400002)(6512007)(33656002)(54906003)(83080400001)(2616005)(64756008)(66446008)(66556008)(91956017)(66476007)(186003)(26005)(71200400001)(66946007)(4326008)(5660300002)(76116006)(8676002)(66574015)(316002)(53546011)(6506007)(2906002)(8936002)(478600001)(6916009)(83380400001)(36756003)(86362001)(966005)(6486002)(518174003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 6FEcrcWRHUwEqubwWefsRJgqV4IE/Dr9sL8U1cSMjpZsc3hKdmZ0RVzPVSF3dGbuOcl0KZ45nOf3Mj9aq5pWOr+9CTZAs/pfFB71PjE3SEQ4D+nZJkgGfPdgQ7ZTlOQ/eDlFpEMpVZ7vRdczVQUAne4/V5DYbmfvGGlXnkwRHerMarov2d+DlbRFl++c2o+FQcx2Q25hS3mOOQ+LG1jji74CCKClphz6TRBRouA0WMC9KuUILixmGZxftNfoTPdscATIxSaTux9ZeJ/EB3G0lICmD1poUVfEjX6kqsd5yeu25m+JXfbh+EpuHWl/IhDi2uE4BTMZfQMRfJ6TJ5YX1uGDE4r7ZuaX4j0prUKmJoiYijNZR8/7jFYj3js7qf/BbKoga8BZxJYhdQUVHLQU0keDhP0TSTRepjNG2kVQ7HYZg6d1e2Pj2VkoNf8S8h3lN/5LFGDvedOk5gCg/idu5P5a3uO4LZvUNoFJyPPehFUgIyEiIU4vjwfzP/YL5ZHQVner18SH5gymdqUuVGCkvv6ecQa/6raBBYZfRf779FJWBOLkalGO0tWrM9qzh3oFs7GJt76mH0kpC1xIM6toYY7aBfraxC8I9NUea2Y01PeNVjdNcVlUllxPBaW4EnGQ8G/h7z0JssutBwDuVxX7Hw== 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: BN7PR11MB2547.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6f76fd7a-f523-42db-5ff8-08d86bed8e02 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2020 00:52:10.5397 (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: EL7ZqwE31th6ngjuQzWNctUHW0GGuiwe86Cigl6zOIjQ9R9U69Ki3qNkFfPLBbrt X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1713 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [v6ops] [EXTERNAL] Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Fri, 09 Oct 2020 00:52:20 -0000 QW5kIG9mIGNvdXJzZSBjb25uZWN0aXZpdHkgaXMgbm90IGdvaW5nIHRvIHdvcmsgZXZlbiBpZiBS LTQgcnVsZSB3ZXJlIG5vdCBpbXBsZW1lbnRlZCwgYW5kIHNlZW1zIGJlc3QgdG8gZHJvcCBwYWNr ZXQgZWFybHk/DQoNCklmIHlvdSB0YWtlIFBEIG91dCBvZiB0aGUgcGljdHVyZSBhbmQgZGlkIHRo aXMgc2FtZSAobWlzKWNvbmZpZ3VyYXRpb24sIHdoYXQgd291bGQgaGFwcGVuPyBJIHdhcyBhc2tp bmcgZWFybGllciBhYm91dCB0aGlzIGlzc3VlIGFzIHRvIHdoYXQgaGFwcGVucyB3aXRoIOKAnG5v cm1hbOKAnSByb3V0aW5nIGFuZCB3aHkgdGhpcyBuZWVkcyB0byBkbyBtb3JlIG9yIGJldHRlcj8N Cg0KUGVyaGFwcyB0aGUgbWlzc2luZyBwaWVjZSBvZiB0aGUgcnVsZSBpcyBkb27igJl0IHNlbmQg aXQgYmFjayB0byB3aGVyZSBpdCBjYW1lIGZyb20sIGJhc2VkIG9uIGxpbmsgbGF5ZXIgYWRkcmVz c2VzIChvciBsaW5rIGlmIHBvaW50LXRvLXBvaW50KS4gQnV0IHRoYXQgc2VlbXMgbW9yZSBsaWtl IGEgc3RhbmRhcmQgcm91dGluZyBydWxlPw0KDQpJdCBhbHNvIHNlZW1zIG9kZCB0aGF0IHRoZSBy dWxlIHNheXM6DQogICAgICAgICBBbiBJQ01QdjYgVHlwZQ0KICAgICAgICAgMSwgQ29kZSA2IChE ZXN0aW5hdGlvbiBVbnJlYWNoYWJsZSwgcmVqZWN0IHJvdXRlIHRvDQogICAgICAgICBkZXN0aW5h dGlvbikgZXJyb3IgbWVzc2FnZSBNQVkgYmUgc2VudCBiYWNrIHRvIHRoZSBjbGllbnQuDQoNClNo b3VsZG7igJl0IHRoZSBJQ01QdjYgYmUgc2VudCB0byB0aGUgc2VuZGVyPyBJbiB0aGUgc2NlbmFy aW8gSmVuIGFuZCB5b3UgYXJlIGRpc2N1c3NpbmcsIHRoZXJlIGFyZSB0d28gY2xpZW50cz8gU28s IHdoaWNoIGNsaWVudCBtYXkgdGhlIElDTVB2NiBiZSBzZW50IHRvPw0KDQpBbmQsIHBlcmhhcHMg aWYgdGhlcmUgaXMgb25seSDigJx0aGUgY2xpZW504oCdLCBJYW7igJlzIGNhc2UgaXMgZGlmZmVy ZW50Pw0KDQotIEJlcm5pZQ0KDQo+IE9uIE9jdCA4LCAyMDIwLCBhdCA1OjU0IFBNLCBUZW1wbGlu IChVUyksIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4gd3JvdGU6DQo+IA0KPiDv u79CZXJuaWUsDQo+IA0KPiBMZXQncyBzYXkgdHdvIGNsaWVudHMgQSBhbmQgQiBhcmUgY29ubmVj dGVkIHRvIGEgc3dpdGNoIHdoaWNoIGlzIHRoZW4gY29ubmVjdGVkIHRvDQo+IHJlbGF5IFIuIENs aWVudHMgQSBhbmQgQiByZWNlaXZlIFBEcyBmcm9tIHRoZSBESENQdjYgc2VydmljZSB0aGF0IGFy ZSByZWxheWVkIGJ5DQo+IFIsIGFuZCBSIGVzdGFibGlzaGVzIHJvdXRlcyBmb3IgdGhlIGRlbGVn YXRlZCBwcmVmaXhlcyBBIGFuZCBCLiBBIGFuZCBCIGJvdGggcmVnYXJkDQo+IFIgYXMgYSBkZWZh dWx0IHJvdXRlci4NCj4gDQo+IE5vdywgc3VwcG9zZSB0d28gdGhpbmdzOg0KPiANCj4gLSBjbGll bnQgQiBkaXNjb3ZlcnMgdGhyb3VnaCBzb21lIG1lYW5zIChlLmcuLCBETlMpIHRoZSBJUCBhZGRy ZXNzIG9mIGEgc2VydmljZQ0KPiAgIGVuZHBvaW50IHdpdGhpbiBwcmVmaXggQQ0KPiAtIGNsaWVu dCBBIHNvbWVob3cgImZvcmdldHMiIHRoYXQgaXQgcmVjZWl2ZWQgdGhlIHByZWZpeCBkZWxlZ2F0 aW9uIEENCj4gDQo+IE5vdywgY2xpZW50IEIgc2VuZHMgcGFja2V0cyBkZXN0aW5lZCB0byBhbiBh ZGRyZXNzIGluIEEgdG8gUiwgYW5kIFIgZm9yd2FyZHMgdGhlDQo+IHBhY2tldHMgdG8gY2xpZW50 IEEgc2luY2UgaXQgc3RpbGwgaGFzIGEgcm91dGUgZm9yIEEuIFdoZW4gdGhlIHBhY2tldHMgYXJy aXZlIGF0IEEsDQo+IGhvd2V2ZXIsIEEgZm9yd2FyZHMgdGhlbSBiYWNrIHRvIFIgc2luY2UgaXQg aGFzICJmb3Jnb3R0ZW4iIHRoYXQgaXQgaG9sZHMgdGhlDQo+IHByZWZpeCBBLiBXaGVuIFIgcmVj ZWl2ZXMgdGhlIHBhY2tldHMgZnJvbSBBIHdpdGggZGVzdGluYXRpb24gYWRkcmVzcyBhbHNvDQo+ IGZyb20gcHJlZml4IEEsIGl0IG11c3QgZHJvcCB0aGVtIGluc3RlYWQgb2YgZm9yd2FyZGluZyB0 aGVtIGJhY2sgdG8gQSB0bw0KPiBhdm9pZCBsb29waW5nLg0KPiANCj4gTm90ZTogSWYgUiBoYWQg c2VudCBhIFJlZGlyZWN0IHRvIEIsIHRoZSBzYW1lIHNjZW5hcmlvIHdvdWxkIHBsYXkgb3V0IGV4 Y2VwdA0KPiB0aGF0IEIgd291bGQgc2VuZCBpdHMgc3Vic2VxdWVudCBwYWNrZXRzIGRpcmVjdGx5 IHRvIEEuIEJ1dCB0aGVuLCBBIHdvdWxkIGFnYWluDQo+IHN0aWxsIGZvcndhcmQgdGhlbSB0byBS IHdoaWNoIG11c3QgZHJvcCBpbnN0ZWFkIG9mIGZvcndhcmRpbmcgYmFjayB0byBBLg0KPiANCj4g RnJlZA0KPiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBCZXJuaWUg Vm9seiAodm9seikgW21haWx0bzp2b2x6QGNpc2NvLmNvbV0NCj4+IFNlbnQ6IFRodXJzZGF5LCBP Y3RvYmVyIDA4LCAyMDIwIDI6MTkgUE0NCj4+IFRvOiBpYW5mYXJyZXJAZ214LmNvbTsgVGVtcGxp biAoVVMpLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+DQo+PiBDYzogZGhjd2cg PGRoY3dnQGlldGYub3JnPjsgNm1hbiA8aXB2NkBpZXRmLm9yZz47IHY2b3BzIGxpc3QgPHY2b3Bz QGlldGYub3JnPg0KPj4gU3ViamVjdDogUkU6IFt2Nm9wc10gW0VYVEVSTkFMXSBSZTogW2RoY3dn XSBRdWVzdGlvbiB0byBESENQdjYgUmVsYXkgSW1wbGVtZW50b3JzIHJlZ2FyZGluZyBkcmFmdC1p ZXRmLWRoYy1kaGNwdjYtcGQtcmVsYXktDQo+PiByZXF1aXJlbWVudHMNCj4+IA0KPj4gDQo+PiBJ cyB0aGlzIGEgbW9kZWwgd2hlcmUgaW4geW91ciBGaWd1cmUgMSwgeW91IGhhdmUgYSBzd2l0Y2gg YmV0d2VlbiB0aGUgUEQgQ2xpZW50IGFuZCBEZWxlZ2F0aW5nIFJlbGF5IGFuZCB5b3UgbWlnaHQg aGF2ZSBvdGhlcg0KPj4gZGV2aWNlcyBvZmYgdGhhdCBzd2l0Y2g/DQo+PiANCj4+IEluIHRoYXQg Y2FzZSwgd2h5IHdvdWxkIGFueSBvZiB0aGUgZGV2aWNlcyBvZmYgdGhhdCBzd2l0Y2ggYmUgdXNp bmcgdGhlIHByZWZpeCBnaXZlbiB0aGUgUEQgQ2xpZW50PyBIb3cgd291bGQgdGhleSBsZWFybiB0 aGlzPyBJIGRvbid0DQo+PiB0aGluayB0aGUgUEQgQ2xpZW50IG5vciBEZWxlZ2F0aW5nIFJlbGF5 IHNob3VsZCBiZSBkb2luZyBSQXMgd2l0aCB0aGUgUEQgcHJlZml4IGluIHRoZW0gKG9yIGEgc3Vi LXByZWZpeCkuDQo+PiANCj4+IElmIHRoZSBQRCBDbGllbnQgaXMgZG9pbmcgdGhhdCwgdGhlbiBh bnkgZGV2aWNlcyBvZmYgdGhlIHN3aXRjaCB3b3VsZCBiZSB1c2luZyBpdCBhcyB0aGUgZGVmYXVs dCByb3V0ZXIgZm9yIHRoYXQgcHJlZml4IGFuZCBub3QgdGhlDQo+PiBkZWxlZ2F0aW5nIHJlbGF5 PyBBbmQsIGhlbmNlIG5vIHRyYWZmaWMgc2hvdWxkIGJlIGRvaW5nIHRvIHRoZSBkZWxlZ2F0aW5n IHJlbGF5IHdpdGggdGhlIFBEIGRlc3RpbmF0aW9uIGFkZHJlc3MuDQo+PiANCj4+IE9yLCBkbyBJ IGhhdmUgdGhpcyBtb2RlbCB3cm9uZz8NCj4+IA0KPj4gLSBCZXJuaWUNCj4+IA0KPj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IHY2b3BzIDx2Nm9wcy1ib3VuY2VzQGlldGYu b3JnPiBPbiBCZWhhbGYgT2YgaWFuZmFycmVyQGdteC5jb20NCj4+IFNlbnQ6IFRodXJzZGF5LCBP Y3RvYmVyIDgsIDIwMjAgMTI6MTYgUE0NCj4+IFRvOiBUZW1wbGluIChVUyksIEZyZWQgTCA8RnJl ZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4NCj4+IENjOiBkaGN3ZyA8ZGhjd2dAaWV0Zi5vcmc+OyA2 bWFuIDxpcHY2QGlldGYub3JnPjsgdjZvcHMgbGlzdCA8djZvcHNAaWV0Zi5vcmc+DQo+PiBTdWJq ZWN0OiBSZTogW3Y2b3BzXSBbRVhURVJOQUxdIFJlOiBbZGhjd2ddIFF1ZXN0aW9uIHRvIERIQ1B2 NiBSZWxheSBJbXBsZW1lbnRvcnMgcmVnYXJkaW5nIGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1wZC1y ZWxheS0NCj4+IHJlcXVpcmVtZW50cw0KPj4gDQo+PiBIaSBGcmVkIC8gSmVuDQo+PiANCj4+IFBs ZWFzZSBzZWUgaW5saW5lIGJlbG93Lg0KPj4gDQo+PiBUaGFua3MsDQo+PiBJYW4NCj4+IA0KPj4+ PiBPbiA4LiBPY3QgMjAyMCwgYXQgMTc6NTEsIFRlbXBsaW4gKFVTKSwgRnJlZCBMIDxGcmVkLkwu VGVtcGxpbkBib2VpbmcuY29tPiB3cm90ZToNCj4+PiANCj4+PiBKZW4sDQo+Pj4gDQo+Pj4+IFdo YXQgd291bGQgaGFwcGVuIGlmIHRoZSAqc2Vjb25kKiBkZXZpY2Ugc2VuZHMgdHJhZmZpYyB0b3dh cmRzIHRoZQ0KPj4+PiBkZWxlZ2F0ZWQgcHJlZml4PyBBcyB0aGF0IGRldmljZSBpcyB1c2lnIHRo ZSByZWxheSBhcyBpdHMgZGVmYXVsdA0KPj4+PiBnYXRld2F5LCB0aGUgdHJhZmZpYyB3b3VsZCBi ZSBzZW50IHRoZXJlLg0KPj4+PiBJZiBJIHJlYWQgdGhlIGRyYWZ0IGNvcnJlY3RseSwgaW5zdGVh ZCBvZiBmb3J3YXJkaW5nIHRoZSB0cmFmZmljIGFuZA0KPj4+PiBtYXliZSBzZW5kaW5nIHRoZSBy ZWRpcmVjdCwgdGhlIHJlbGF5IGlzIGV4cGVjdGVkIHRvIGRyb3AgaXQ/DQo+Pj4gDQo+Pj4gVGhl IHdheSB0aGF0IEkgaW50ZXJwcmV0IGl0LCB3aGVuIHRoZSBzZWNvbmQgZGV2aWNlIHNlbmRzIHRo ZSB0cmFmZmljDQo+Pj4gdG8gdGhlIHJlbGF5LCB0aGUgcmVsYXkgd291bGQgc3RpbGwgZm9yd2Fy ZCB0aGUgdHJhZmZpYyB0byB0aGUgY2xpZW50LA0KPj4+IHdoaWNoIHdvdWxkIHRoZW4gZm9yd2Fy ZCB0aGUgdHJhZmZpYyBiYWNrIHRvIHRoZSByZWxheSwgdGhlbiBhdCB0aGF0DQo+Pj4gcG9pbnQg dGhlIHJlbGF5IHdvdWxkIGRyb3AgdGhlIHRyYWZmaWMuIFVubGVzcyB0aGUgc2Vjb25kIG5vZGUg c29tZWhvdw0KPj4+IGhhcyBhIHdheSBvZiBrbm93aW5nIHRoYXQgdGhlIGNsaWVudCBoYXMgZW50 ZXJlZCBpbnRvIGFuIGFtbmVzaWFjDQo+Pj4gc3RhdGUgYW5kIHRoZW4gZG9lcyBhIG1hbGljaW91 cyAiZmxvb2QtcGluZyIsIHdlIGNhbiBleHBlY3QNCj4+PiBhcHBsaWNhdGlvbnMgdG8gcXVpY2ts eSBsZWFybiB0aGF0IHRoZSBJUCBhZGRyZXNzZXMgb2YgdGhlIGNsaWVudCBhcmUNCj4+PiBubyBs b25nZXIgcmVhY2hhYmxlLiBQbHVzLCB0aGVzZSBhbW5lc2lhYyBjb25kaXRpb25zIGNhbiBiZSBl eHBlY3RlZA0KPj4+IHRvIGJlIHJhcmUgYW5kIHRyYW5zaWVudDsgbm90IHN0ZWFkeS1zdGF0ZS4N Cj4+PiANCj4+PiBGcmVkDQo+PiANCj4+IFtpZiAtIElmIEkgdW5kZXJzdGFuZCBKZW7igJlzIHF1 ZXN0aW9uIGNvcnJlY3RseSwgaXTigJlzIHJlbGF0ZWQgdG8gdGhlIOKAmHdvcmtpbmfigJkgY2Fz ZS4NCj4+IGkuZS4gdGhlIGNsaWVudCBoYXMgY29tcGxldGVkIFBELCBpbnN0YWxsZWQgdGhlIHJv dXRlcyBhbmQgdGhlIHJlbGF5IGhhcyB0aGUgcmVsZXZhbnQgbGVhc2UgaW5mby9yb3V0ZXMuDQo+ PiANCj4+IFdoZW4gdGhlIHNlY29uZCBkZXZpY2Ugc2VuZHMgdmlhIHRoZSBkZWZhdWx0IHJvdXRl IHdpdGggYSBkZXN0aW5hdGlvbiBhZGRyZXNzIGluIHRoZSBkZWxlZ2F0ZWQgcHJlZml4LCBSLTQg aW4gaXTigJlzIGN1cnJlbnQgZm9ybSB3b3VsZA0KPj4gY2F1c2UgdGhlIHRyYWZmaWMgdG8gYmUg ZHJvcHBlZC4NCj4+IEFzIHRoZSByZWxheSBkb2VzbuKAmXQgZm9yd2FyZCB0aGUgcGFja2V0LCBp dCBjYW7igJl0IHNlbmQgYSByZWRpcmVjdCAocGVyIFJGQzQ2ODEpLCBzbyB0aGUgc2Vjb25kIGRl dmljZSBjYW7igJl0IGZvcndhcmQuDQo+PiANCj4+IExvb2tpbmcgYXQgdGhpcywgSSB0aGluayB0 aGVyZSBhcmUgZGVwbG95bWVudCBzY2VuYXJpb3Mgd2hlcmUgUi00IGlzbuKAmXQgZ29pbmcgdG8g d29yay4NCj4+IA0KPj4gTXkgc3VnZ2VzdGlvbiB3b3VsZCBiZSB0byBtYWtlIFItNCBkaXNhYmxl LWFibGUuXQ0KPj4gDQo+PiANCj4+IA0KPj4+IA0KPj4+IA0KPj4+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBpcHY2IFttYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgSmVuIExpbmtvdmENCj4+Pj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVy IDA3LCAyMDIwIDY6MjUgUE0NCj4+Pj4gVG86IGlhbmZhcnJlckBnbXguY29tDQo+Pj4+IENjOiBk aGN3ZyA8ZGhjd2dAaWV0Zi5vcmc+OyB2Nm9wcyBsaXN0IDx2Nm9wc0BpZXRmLm9yZz47IDZtYW4N Cj4+Pj4gPGlwdjZAaWV0Zi5vcmc+DQo+Pj4+IFN1YmplY3Q6IFtFWFRFUk5BTF0gUmU6IFtkaGN3 Z10gUXVlc3Rpb24gdG8gREhDUHY2IFJlbGF5IEltcGxlbWVudG9ycw0KPj4+PiByZWdhcmRpbmcg ZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LXBkLXJlbGF5LXJlcXVpcmVtZW50cw0KPj4+PiANCj4+Pj4g VGhpcyBtZXNzYWdlIHdhcyBzZW50IGZyb20gb3V0c2lkZSBvZiBCb2VpbmcuIFBsZWFzZSBkbyBu b3QgY2xpY2sNCj4+Pj4gbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IHJlY29n bml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoYXQgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCj4+Pj4g DQo+Pj4+IA0KPj4+PiBPbiBXZWQsIE9jdCA3LCAyMDIwIGF0IDk6MjUgUE0gPGlhbmZhcnJlckBn bXguY29tPiB3cm90ZToNCj4+Pj4+IFdlIGFyZSBjdXJyZW50bHkgZmluaXNoaW5nIFdHTEMgZm9y IHRoaXMgZHJhZnQuIEl0IGRlc2NyaWJlcw0KPj4+Pj4gcmVxdWlyZW1lbnRzIGZvciBhICdESENQ djYgRGVsZWdhdGluZyBSZWxheScgLSB0aGlzIGlzIGEgcm91dGVyDQo+Pj4+PiBmdW5jdGlvbmlu Zw0KPj4+PiBhcyB0aGUgTDMgZWRnZSBhbmQgREhDUHY2IHJlbGF5IChvbmx5KSB3aXRoIHByZWZp eCBkZWxlZ2F0aW9uLiBUaGlzDQo+Pj4+IGlzIGEgY29tbW9uIGRlcGxveW1lbnQgc2NlbmFyaW8s IGJ1dCBSRkMzNjMzLzg0MTUgb25seSByZWFsbHkNCj4+Pj4gZGVzY3JpYmVzIFBEIHVzaW5nIGEg RGVsZWdhdGluZyBSb3V0ZXIgLSBpLmUgdGhlIEwzIGVkZ2UgYWxzbw0KPj4+PiBmdW5jdGlvbnMg YXMgYSBESENQdjYgc2VydmVyIHdpdGggbm8gcmVsYXkuIFdoZW4gdGhlIHJlbGF5IGFuZCBzZXJ2 ZXINCj4+Pj4gZnVuY3Rpb25zIGFyZSBwZXJmb3JtZWQgYnkgc2VwYXJhdGUgZGV2aWNlcyBhIG51 bWJlciBvZiBwcm9ibGVtcyB3aXRoDQo+Pj4+IGhvdyByZWxheXMgYmVoYXZlIGhhdmUNCj4+Pj4+ IGJlZW4gb2JzZXJ2ZWQsIHNvIHRoaXMgZG9jdW1lbnQgYWRkcmVzc2VzIHRoZW0uDQo+Pj4+PiAN Cj4+Pj4+IER1cmluZyBXR0xDIGZvciB0aGlzLCBPbGUgcmFpc2VkIGEgY29tbWVudCByZWxhdGVk IHRvIG9uZSBvZiB0aGUgcm91dGluZyByZXF1aXJlbWVudHM6DQo+Pj4+PiANCj4+Pj4+IFItNDog ICAgSWYgdGhlIHJlbGF5IGhhcyBsZWFybmVkIGEgcm91dGUgZm9yIGEgZGVsZWdhdGVkIHByZWZp eCB2aWEgYQ0KPj4+Pj4gICAgICAgICAgZ2l2ZW4gaW50ZXJmYWNlLCBhbmQgcmVjZWl2ZXMgdHJh ZmZpYyBvbiB0aGlzIGludGVyZmFjZSB3aXRoDQo+Pj4+PiAgICAgICAgICBhIGRlc3RpbmF0aW9u IGFkZHJlc3Mgd2l0aGluIHRoZSBkZWxlZ2F0ZWQgcHJlZml4ICh0aGF0IGlzDQo+Pj4+PiAgICAg ICAgICBub3QgYW4gb24tbGluayBwcmVmaXggZm9yIHRoZSByZWxheSksIHRoZW4gaXQgTVVTVCBi ZQ0KPj4+Pj4gICAgICAgICAgZHJvcHBlZC4gIFRoaXMgaXMgdG8gcHJldmVudCByb3V0aW5nIGxv b3BzLiAgQW4gSUNNUHY2IFR5cGUNCj4+Pj4+ICAgICAgICAgIDEsIENvZGUgNiAoRGVzdGluYXRp b24gVW5yZWFjaGFibGUsIHJlamVjdCByb3V0ZSB0bw0KPj4+Pj4gICAgICAgICAgZGVzdGluYXRp b24pIGVycm9yIG1lc3NhZ2UgTUFZIGJlIHNlbnQgYmFjayB0byB0aGUgY2xpZW50Lg0KPj4+Pj4g ICAgICAgICAgVGhlIElDTVAgcG9saWN5IFNIT1VMRCBiZSBjb25maWd1cmFibGUuDQo+Pj4+PiAN Cj4+Pj4+IFRoZSBwcm9ibGVtIHRoYXQgdGhpcyBpcyB0cnlpbmcgdG8gc29sdmUgaXM6DQo+Pj4+ PiANCj4+Pj4+IDMuNS4gIEZvcndhcmRpbmcgTG9vcHMgYmV0d2VlbiBDbGllbnQgYW5kIFJlbGF5 DQo+Pj4+IA0KPj4+PiBJIG1pZ2h0IGJlIG1pc3Npbmcgc210aCBidXQuLi4NCj4+Pj4gTGV0J3Mg c2F5IEkgaGF2ZSBhIHJlbGF5IGFuZCBpdCdzICdzb3V0aCcgKGNsaWVudC1mYWNpbmcpIGludGVy ZmFjZQ0KPj4+PiBpcyBjb25uZWN0ZWQgdG8gYSBzd2l0Y2guIFRoZSBjbGllbnQgQU5EIHNlY29u ZCBkZXZpY2UgKGFub3RoZXINCj4+Pj4gcm91dGVyIG9yIGEgaG9zdCkgYXJlIGNvbm5lY3RlZCB0 byB0aGUgc2FtZSBzZWdtZW50Lg0KPj4+PiBUaGUgY2xpZW50IGdldHMgYSBwcmVmaXgsIHRoZSBy ZWxheSAnbGVhcm5lZCcgKG9yIHNoYWxsIHdlIGNhbGwgaXQNCj4+Pj4gJ2luc3RhbGwnPykgdGhl IHJvdXRlIGZvciB0aGUgZGVsZWdhdGVkIHByZWZpeCBwb2ludGluZyB0byBpdHMgJ3NvdXRoJw0K Pj4+PiBpbnRlcmZhY2Ugd2l0aCB0aGUgY2xpZW50IGFkZHJlc3MgYXMgYSBuZXh0LWhvcC4NCj4+ Pj4gV2hhdCB3b3VsZCBoYXBwZW4gaWYgdGhlICpzZWNvbmQqIGRldmljZSBzZW5kcyB0cmFmZmlj IHRvd2FyZHMgdGhlDQo+Pj4+IGRlbGVnYXRlZCBwcmVmaXg/IEFzIHRoYXQgZGV2aWNlIGlzIHVz aWcgdGhlIHJlbGF5IGFzIGl0cyBkZWZhdWx0DQo+Pj4+IGdhdGV3YXksIHRoZSB0cmFmZmljIHdv dWxkIGJlIHNlbnQgdGhlcmUuDQo+Pj4+IElmIEkgcmVhZCB0aGUgZHJhZnQgY29ycmVjdGx5LCBp bnN0ZWFkIG9mIGZvcndhcmRpbmcgdGhlIHRyYWZmaWMgYW5kDQo+Pj4+IG1heWJlIHNlbmRpbmcg dGhlIHJlZGlyZWN0LCB0aGUgcmVsYXkgaXMgZXhwZWN0ZWQgdG8gZHJvcCBpdD8NCj4+Pj4gDQo+ Pj4+IC0tDQo+Pj4+IFNZLCBKZW4gTGlua292YSBha2EgRnVycnkNCj4+Pj4gDQo+Pj4+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+Pj4+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPj4+PiBp cHY2QGlldGYub3JnDQo+Pj4+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiANCj4+ IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ IHY2b3BzIG1haWxpbmcgbGlzdA0KPj4gdjZvcHNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== From nobody Thu Oct 8 18:09: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 561443A10FB; Thu, 8 Oct 2020 18:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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 LXn1J6Cv3FXi; Thu, 8 Oct 2020 18:09:18 -0700 (PDT) Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) (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 F2DEA3A0E17; Thu, 8 Oct 2020 18:09:17 -0700 (PDT) Received: by mail-qk1-x743.google.com with SMTP id s7so9005133qkh.11; Thu, 08 Oct 2020 18:09:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ylCPku13r0j9UqhPi+igQ9MBe3gd7DlsX+BTIcjL2iI=; b=myiJT//7f3GLIdss8abvwnKr1edKm/IMB10Rb+NkbtVKGUtQqKwO1gFlxCJFyoHRTN ajXWgrdpN6/7pAFCsHw6TtJuSrNmflanDn/4+HMzWeXNDAaJFNUrncDjw2HPFrvPkqka ejMD+r7HglJBGZXD1s3ZIyQJkAOYmko33qaCPqpRwpZE5dNVhyKSm//fxw9ozDuQ7fRV xPj4Nkfztw2jfZT6Geq1mS1zHjCIngENEJwPjrrEubm21UwYbLPdnwb2EfsasLD4DlSg xbvZxBXa/l0e1Z0pJux/dl7GC8eoBNUc72WSecTVfDyigQIxC0mIv4GY8J+nVSpPoEe0 TYbg== 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=ylCPku13r0j9UqhPi+igQ9MBe3gd7DlsX+BTIcjL2iI=; b=LUhR+SH9Fl2jwlkzGrEC+496j06WShOpdglUyXiAUpmpVRilcvdbcGcT7+w4Bdvxwu XN0agitRHM5M0xsSnD+idRVYTGR0oEG4xLkpzdUPj2RpT8/Wy5p1bkqWXCBo18KU6pnh yxoIwIgMq52jcCjgU75xiWc2WLlt15UdQ2Ci1f0uR5aiUtMcFY75Oqoz9O/yuVFZBLZX ao/X77+PDUv7p9R5+ilkDYO5gV6i3m+ogijwQ4/X171zwH1HkOU4lt7aH9iRb9BN7u2z Qx9M8yqvQbM/w2jdfqcSo41zHlUWqtlw47Dfi3QDj/8oXPb7wV38SAbyO/37suUsLvyv bPhQ== X-Gm-Message-State: AOAM530IhLgi0C6WAsTyi/8QhN0m/mq31Z9HlmUK+3lH6RVdkZADQK4M 2EOCbynmPe/cHe9hzur1kzwJ6qfJt/dqSVU6/gY= X-Google-Smtp-Source: ABdhPJysip0ptA/Ilf8YtNiw0ESd++TqCvxJJiOnl/ZUvgOvAXFat44CRTcnvhg0wlKEXhOy5iBaOsJFQG9anfjsNok= X-Received: by 2002:a37:849:: with SMTP id 70mr11367189qki.332.1602205756844; Thu, 08 Oct 2020 18:09:16 -0700 (PDT) MIME-Version: 1.0 References: <6373DDB1-753B-4E15-8097-9ED03F1BFC19@employees.org> In-Reply-To: <6373DDB1-753B-4E15-8097-9ED03F1BFC19@employees.org> From: Jen Linkova Date: Fri, 9 Oct 2020 12:09:05 +1100 Message-ID: To: Ole Troan Cc: "Templin (US), Fred L" , dhcwg , v6ops list , 6man , "Bernie Volz (volz)" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] [EXTERNAL] Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Fri, 09 Oct 2020 01:09:20 -0000 On Fri, Oct 9, 2020 at 9:01 AM Ole Troan wrote: > > On 8 Oct 2020, at 23:55, Templin (US), Fred L wrote: > > > > Now, client B sends packets destined to an address in A to R, and R for= wards the > > packets to client A since it still has a route for A. When the packets = arrive at A, > > however, A forwards them back to R since it has "forgotten" that it hol= ds the > > prefix A. When R receives the packets from A with destination address a= lso > > from prefix A, it must drop them instead of forwarding them back to A t= o > > avoid looping. > > This is indeed what the requirement in the draft says. Well, then I should say that the requirement is not clear and open to misinterpretation. I read it as: - the client B sends a packet with the destination address in A to R. When R receives it, it finds out that the both conditions from R4 are met: 1) a route for a delegated prefix points to this interface 2) the receives traffic (from the device B) on this interface with a destination address within the delegated prefix. So the traffic will be dropped right away, not after it went to the client A (and back, if A forgot about the delegation). I read Ian's response as he confirmed my interpretation and the traffic will be dropped. It looks to me like R4 assumes that all links are p2p, and 'receiving a traffic from an interface the client is connected to' =3D=3D 'receiving a traffic from the client'. > This isn=E2=80=99t quite obvious how to implement, which why I brought up= the question if anyone had implemented this. And if it=E2=80=99s supported= in hw etc. What you and Fred described does look like a hard thing to implement, while the way I read R4 seems to be very easy to do (kind of URPF, basically) but, as discussed, might break working scenarios. --=20 SY, Jen Linkova aka Furry From nobody Thu Oct 8 18:34:20 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 EF1B83A118B; Thu, 8 Oct 2020 18:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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 0ndUx8tYzLFC; Thu, 8 Oct 2020 18:34:09 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 7A4A03A1190; Thu, 8 Oct 2020 18:33:37 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id d20so9099485qka.5; Thu, 08 Oct 2020 18:33:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LFQ/wft4XptRkyxud8OhaWMv6uY8xoQyZl61oXm5bxA=; b=Y+XV/hQhs74rKdWy2F7H4xdVgRmt4/YjDDA+0+Aygad08+uI+kyxkvU1+iDUQScR97 k3TI6D3xmBOdIUCKwv8pLoo5P+/ZqOhLTL8a+Oj4T3imrcf89pi9CKzIvJPtQca0Y20M FTDtpMiVovkK1m00fMqhYGttXririielVBBc2YGRtIwQnXYw8rws4Ltat8GGADj4tWiD UZqhYAtGWwvp1VqGKpjQeVq2ZRnF1uL7Vr6FqTs0PZyo9hhceJnvJLUyHen61dUXLs5z 8aIyg5iWnW0dpcRA9NjP/Adw/p7IYmPNWe4I96cmDxyD4cdiess2HHe52vSR0ykUyZLq c1LQ== 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=LFQ/wft4XptRkyxud8OhaWMv6uY8xoQyZl61oXm5bxA=; b=pBF97/JEMJOEPkyhBxLYaxP4Y59boYz8TAYt2sOeyJIXUuVR3pHXk2ynSomZGgvGPH Q8dCNk3n1IImv1tc5R0MHOHf8MmTk2V2tFaZ9h/f2ho7IVzwhCv7te2A5SPmYgxOX0Vr 7E4K6lUoENKY3/wRxW8G+lyf5KaRX06olKTwBIwnan4hRkPkAw8ccog+QZkb3V2d32ZR nqJhUOkgI+knvW2A5SyXX7boocN4m4HXQcy3sq9SE6PgotQNxuCxH2vJlmuN39XNc1Ri CNKjG+vCvS3FXSvmXV/6pKltRVjooNxdghjXwePb2X31hJJ3iigFtnGaYqVMXvVa8F5D pzdQ== X-Gm-Message-State: AOAM5328eFwKzS6xxXAgTh+rA7aIWOpC0eo9YdSizt+/PTslbo5oX+qP mK2DFJ8HsPIiD1HIJUblShw5vy9SYJmzM3CDxfA= X-Google-Smtp-Source: ABdhPJwOD1pPO3Ez5dcaBkdWevjQL+4UiPmvoTPmQTLMm/SNQqUaKkKJW4xzM3gxLhkZjX7lLTHXv4tiRFUy3+sICP8= X-Received: by 2002:a37:a74e:: with SMTP id q75mr3837880qke.277.1602207215913; Thu, 08 Oct 2020 18:33:35 -0700 (PDT) MIME-Version: 1.0 References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> In-Reply-To: From: Jen Linkova Date: Fri, 9 Oct 2020 12:33:24 +1100 Message-ID: To: "Bernie Volz (volz)" Cc: "Templin (US), Fred L" , dhcwg , v6ops list , 6man Content-Type: multipart/mixed; boundary="000000000000f63ef405b132ef25" Archived-At: Subject: Re: [v6ops] [dhcwg] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Fri, 09 Oct 2020 01:34:12 -0000 --000000000000f63ef405b132ef25 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 9, 2020 at 11:52 AM Bernie Volz (volz) wrote: > > And of course connectivity is not going to work even if R-4 rule were not= implemented, and seems best to drop packet early? > > If you take PD out of the picture and did this same (mis)configuration, w= hat would happen? I was asking earlier about this issue as to what happens = with =E2=80=9Cnormal=E2=80=9D routing and why this needs to do more or bett= er? I think there is confusion re: the scenario we are talking about. I've attached the diagram for the case which concerns me. So: - The Relay R has an interface eth0 connected to a switch S. - Devices A and B are connected to the same switch and using R as a default gateway. - The prefix 2001:db8::/56 was delegated to a client A via the relay R. - R installs a route for 2001:db8::/56 towards A via eth0. - The device B (which has an address NOT from the delegated prefix, but from another /64 assigned to that common link, let's sat 2001:db8:cafe::/64) sends a packet to an address from the delegated prefix (e.g. 2001:db8::42). Why? Well, maybe that address was dynamically put in DNS. Or discovered by some other means. - As R is a default router for B (and B has no idea that the shortest path to 2001:db8::/56 is via A, not R), the packets are sent to R. - R receives them and checks the routing table. It finds that that packet needs to be sent back to eth0 towards A. What I'd expect to happen (with DHCP-PD or without - e.g. if R has a static route towards A, not a dynamic route produced by PD): - the packet is sent to A. Well, if A does not have a route to 2001:db8::42 then indeed a routing loop might happen. But if A does have a route, the packet will be delivered. What seems to be required by R4: - R detects that the packet is received via eth0 and needs to be sent back to eth0. R4 seems to require such packets to be dropped. So if B would never be able to communicate to any address in the delegated prefix, right? Am I missing anything? > Perhaps the missing piece of the rule is don=E2=80=99t send it back to wh= ere it came from, based on link layer addresses (or link if point-to-point)= . Yes. If R4 was saying 'drop the packet if it comes from the same link-layer address you are going to send it back' - it would make total sense. But I don't think routers do *that*. >But that seems more like a standard routing rule? > > It also seems odd that the rule says: > An ICMPv6 Type > 1, Code 6 (Destination Unreachable, reject route to > destination) error message MAY be sent back to the client. > > Shouldn=E2=80=99t the ICMPv6 be sent to the sender? In the scenario Jen a= nd you are discussing, there are two clients? So, which client may the ICMP= v6 be sent to? > > And, perhaps if there is only =E2=80=9Cthe client=E2=80=9D, Ian=E2=80=99s= case is different? > > - Bernie > > > On Oct 8, 2020, at 5:54 PM, Templin (US), Fred L wrote: > > > > =EF=BB=BFBernie, > > > > Let's say two clients A and B are connected to a switch which is then c= onnected to > > relay R. Clients A and B receive PDs from the DHCPv6 service that are r= elayed by > > R, and R establishes routes for the delegated prefixes A and B. A and B= both regard > > R as a default router. > > > > Now, suppose two things: > > > > - client B discovers through some means (e.g., DNS) the IP address of a= service > > endpoint within prefix A > > - client A somehow "forgets" that it received the prefix delegation A > > > > Now, client B sends packets destined to an address in A to R, and R for= wards the > > packets to client A since it still has a route for A. When the packets = arrive at A, > > however, A forwards them back to R since it has "forgotten" that it hol= ds the > > prefix A. When R receives the packets from A with destination address a= lso > > from prefix A, it must drop them instead of forwarding them back to A t= o > > avoid looping. > > > > Note: If R had sent a Redirect to B, the same scenario would play out e= xcept > > that B would send its subsequent packets directly to A. But then, A wou= ld again > > still forward them to R which must drop instead of forwarding back to A= . > > > > Fred > > > >> -----Original Message----- > >> From: Bernie Volz (volz) [mailto:volz@cisco.com] > >> Sent: Thursday, October 08, 2020 2:19 PM > >> To: ianfarrer@gmx.com; Templin (US), Fred L > >> Cc: dhcwg ; 6man ; v6ops list > >> Subject: RE: [v6ops] [EXTERNAL] Re: [dhcwg] Question to DHCPv6 Relay I= mplementors regarding draft-ietf-dhc-dhcpv6-pd-relay- > >> requirements > >> > >> > >> Is this a model where in your Figure 1, you have a switch between the = PD Client and Delegating Relay and you might have other > >> devices off that switch? > >> > >> In that case, why would any of the devices off that switch be using th= e prefix given the PD Client? How would they learn this? I don't > >> think the PD Client nor Delegating Relay should be doing RAs with the = PD prefix in them (or a sub-prefix). > >> > >> If the PD Client is doing that, then any devices off the switch would = be using it as the default router for that prefix and not the > >> delegating relay? And, hence no traffic should be doing to the delegat= ing relay with the PD destination address. > >> > >> Or, do I have this model wrong? > >> > >> - Bernie > >> > >> -----Original Message----- > >> From: v6ops On Behalf Of ianfarrer@gmx.com > >> Sent: Thursday, October 8, 2020 12:16 PM > >> To: Templin (US), Fred L > >> Cc: dhcwg ; 6man ; v6ops list > >> Subject: Re: [v6ops] [EXTERNAL] Re: [dhcwg] Question to DHCPv6 Relay I= mplementors regarding draft-ietf-dhc-dhcpv6-pd-relay- > >> requirements > >> > >> Hi Fred / Jen > >> > >> Please see inline below. > >> > >> Thanks, > >> Ian > >> > >>>> On 8. Oct 2020, at 17:51, Templin (US), Fred L wrote: > >>> > >>> Jen, > >>> > >>>> What would happen if the *second* device sends traffic towards the > >>>> delegated prefix? As that device is usig the relay as its default > >>>> gateway, the traffic would be sent there. > >>>> If I read the draft correctly, instead of forwarding the traffic and > >>>> maybe sending the redirect, the relay is expected to drop it? > >>> > >>> The way that I interpret it, when the second device sends the traffic > >>> to the relay, the relay would still forward the traffic to the client= , > >>> which would then forward the traffic back to the relay, then at that > >>> point the relay would drop the traffic. Unless the second node someho= w > >>> has a way of knowing that the client has entered into an amnesiac > >>> state and then does a malicious "flood-ping", we can expect > >>> applications to quickly learn that the IP addresses of the client are > >>> no longer reachable. Plus, these amnesiac conditions can be expected > >>> to be rare and transient; not steady-state. > >>> > >>> Fred > >> > >> [if - If I understand Jen=E2=80=99s question correctly, it=E2=80=99s r= elated to the =E2=80=98working=E2=80=99 case. > >> i.e. the client has completed PD, installed the routes and the relay h= as the relevant lease info/routes. > >> > >> When the second device sends via the default route with a destination = address in the delegated prefix, R-4 in it=E2=80=99s current form would > >> cause the traffic to be dropped. > >> As the relay doesn=E2=80=99t forward the packet, it can=E2=80=99t send= a redirect (per RFC4681), so the second device can=E2=80=99t forward. > >> > >> Looking at this, I think there are deployment scenarios where R-4 isn= =E2=80=99t going to work. > >> > >> My suggestion would be to make R-4 disable-able.] > >> > >> > >> > >>> > >>> > >>>> -----Original Message----- > >>>> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Jen Linkova > >>>> Sent: Wednesday, October 07, 2020 6:25 PM > >>>> To: ianfarrer@gmx.com > >>>> Cc: dhcwg ; v6ops list ; 6man > >>>> > >>>> Subject: [EXTERNAL] Re: [dhcwg] Question to DHCPv6 Relay Implementor= s > >>>> regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements > >>>> > >>>> This message was sent from outside of Boeing. Please do not click > >>>> links or open attachments unless you recognize the sender and know t= hat the content is safe. > >>>> > >>>> > >>>> On Wed, Oct 7, 2020 at 9:25 PM wrote: > >>>>> We are currently finishing WGLC for this draft. It describes > >>>>> requirements for a 'DHCPv6 Delegating Relay' - this is a router > >>>>> functioning > >>>> as the L3 edge and DHCPv6 relay (only) with prefix delegation. This > >>>> is a common deployment scenario, but RFC3633/8415 only really > >>>> describes PD using a Delegating Router - i.e the L3 edge also > >>>> functions as a DHCPv6 server with no relay. When the relay and serve= r > >>>> functions are performed by separate devices a number of problems wit= h > >>>> how relays behave have > >>>>> been observed, so this document addresses them. > >>>>> > >>>>> During WGLC for this, Ole raised a comment related to one of the ro= uting requirements: > >>>>> > >>>>> R-4: If the relay has learned a route for a delegated prefix via= a > >>>>> given interface, and receives traffic on this interface wi= th > >>>>> a destination address within the delegated prefix (that is > >>>>> not an on-link prefix for the relay), then it MUST be > >>>>> dropped. This is to prevent routing loops. An ICMPv6 Typ= e > >>>>> 1, Code 6 (Destination Unreachable, reject route to > >>>>> destination) error message MAY be sent back to the client. > >>>>> The ICMP policy SHOULD be configurable. > >>>>> > >>>>> The problem that this is trying to solve is: > >>>>> > >>>>> 3.5. Forwarding Loops between Client and Relay > >>>> > >>>> I might be missing smth but... > >>>> Let's say I have a relay and it's 'south' (client-facing) interface > >>>> is connected to a switch. The client AND second device (another > >>>> router or a host) are connected to the same segment. > >>>> The client gets a prefix, the relay 'learned' (or shall we call it > >>>> 'install'?) the route for the delegated prefix pointing to its 'sout= h' > >>>> interface with the client address as a next-hop. > >>>> What would happen if the *second* device sends traffic towards the > >>>> delegated prefix? As that device is usig the relay as its default > >>>> gateway, the traffic would be sent there. > >>>> If I read the draft correctly, instead of forwarding the traffic and > >>>> maybe sending the redirect, the relay is expected to drop it? > >>>> > >>>> -- > >>>> SY, Jen Linkova aka Furry > >>>> > >>>> -------------------------------------------------------------------- > >>>> IETF IPv6 working group mailing list > >>>> ipv6@ietf.org > >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>>> -------------------------------------------------------------------- > >>> > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --=20 SY, Jen Linkova aka Furry --000000000000f63ef405b132ef25 Content-Type: image/png; name="pd-r4.png" Content-Disposition: attachment; filename="pd-r4.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kg1kaeir0 iVBORw0KGgoAAAANSUhEUgAAA8AAAALQCAYAAABfdxm0AACAAElEQVR42uzdD5RdWV0n+t3d1d3p dDWkmwIykIHCiUOQLA1jwDzNaDSOQcO8sIxOq1HjTMYVfJHJaNDGF5ZpaDSMYYzzghMguIIvjNEJ GJjgi5J+r2aM2GLUIBEzUGqhUYMELLTQAgrnvrPDPumdk3PuvVWpSm7d+/ms9Vudun/P3fdP3+/d /0IAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAABhwq4t6pKijRZ0p6mJRk0W1lFK3vOJ7b6Koc0UdKmpbUSM+pgAAYO5Gi3rsjnDHH90X 7rv8svCy3/+p8FPn3x3e/ZEL4cLlyTDZaoWWUuoWV/HemxkP45d+LfzaR38s/NjvvDC88EN3hbv+ tni/nixqg48uAADo3rKi9g+FocnvCd/zB78bfvfvhA6lerumw3TrjeGNf/FgePBKEYb/R/jiqA0A AKCNbcWX50/8y/Av/+RyuCxYKLXIaibMtA6Hw1P3h/v/ZigM/UTxnh7ysQYAANeLX5L3PxQe+uTv hd/7giCh1OKuK+FK6+vC1/310rA0zhNe7iMOAAC+aPiucNevrAlr/tK8XqX6qx4Nj07HOfzF+3yV jzoAAAbd0FAYet+3hW+7HIdOCgxK9V/9XPi5GIKvCMEAAAy6gy8OLxZ+lerzekt4y2eXhqUfC19c 5A4AAAbOjmeEZ1yZClMCglIDUK8Mr/zbe8O97/bRBwDAoFl+T7jnUxfCBcFAqQHaKum54bmfLt7/ W30EAgAwSA7/m/Bv/kwoUGqw6vHweGtpWPrnwfZIAAAMiFX3hHv+xorPSg1mrQlr9AIDADAwjrwm vOZjgoBSg1nvDO9sPS087bd9FAIA0O+G7gx3fupSuCQIKDXAc4HvC/d9tvg8GPGRCABAP9v4rPCs PxEClBrs+ubwzX8XDIMGAKDPHdgddn9UAFBqsOsN4Q2tfxz+8c/7SAQAoJ+N/Ur4lcsCgFKDXe8N 722tCCt+z0ciAAD97OLFcPELAoBSg11xD/Cnh6d/wkciAAD9bGoqTAkASg14TYSJ1oPhwUkfiQAA 9DNf/pVSrbgP+NKw9HM+EgEAEICVUn1f8fPARyIAAAKwUkoABgAAAVgpJQADAIAArJQSgGExGipq WDMAgACslBKA58OyojYUta6o0RQ4BsHy9LjXdxGw4mV2FbW7qI0d2mhFUduK2lvUw0WNdHEsm4va sQCPcVNRY0VtyR7z4aLWzuG24uNalV4vtzL8xuOfTK/NaHV63tak08palU5f0eb2lhS1s6iVi+D1 GV9nj6Tn60hRe7I2GHSPFXUxfWbN5nNua3pfbuvwOgFAAFZK9XEAPpfus6zpok6n0NePYog4WXnM U0Xtrwm2K2vap5W+fK+qCWvxNmZq2nNnw7HE4H0su+x8Kx/nmfT3ofT34VncRgwLlyqP6UwK0wtt e3afq9MPBa0OdbnhtuIPEWfTZS70+Gt0X8Njm0nP4UL8SFW2z/nU1r1sIrXHsS4vvzO9D6tteWCA fvADEICVUgJw+fnTpo6EWzP8dGP6gnpkge9nUwq7TY/3cCUQXKoE2alK0Mp7dw9VbutK5e9tlWNZ lYJYawED8Fi63ZOVv/d1ef1dbdrq/C38ceZs+ntFFwH4VM3tLE8/WrRm+fjrbEmvhcML+LiPZiFt ouYHiOMLcJ9bs9vf2wPfiw6mdn64zetirMvw2+59+ZivoAACsFJqMANwDHA70hf7yez0s7eglyTv 8VqygPdT9gLFIBuHlMYe3g1ZOJrJ7v9odkyPZKdvr7RZSLeRt9doOj3e/ng6fbLyY8ITNeFtvpU9 ZUfnEIBHsvY6nQL7ihQYyuNdyFECa7P72ZpOW5addjBcPwR6NNQPNx+u/NCwf57C6fQtCMAT2Wkr K6+Z+W774fQD1Mlwa3r3u33tnmrzw06nALw8ew3H9/ia7PSz2Xt+MQyJBxCAlVIC8DwH4O2V8HMm O2/3At33UKo8AK8M3c2bnYuD6Qt+dYjngez+l6WgVw5lrhtmeSIL0kvCk0ONJ2uOfVOo7wXemYLZ WJcBeG0Kn7P5sj5RCerVADwcmuf05sONN2anjza8Zsrnc09oHvIdlXOpO/2oUobAy9ll8/vem36w 2ZdC7faGH0+OztPruDyG/AeA4QV6re6rCcAh/QiR/yjTj8p2Pp+F3JHKc1ued6LDbe3P2mtN5byV QS8wgACslBKAM8NZgKrOmSwXEzqRvqAeCNcvKrMuhcEzlevFnrxLKYguT+GmaSjreLi+x3RLCppj 2X3OR89NfhyX0mnb23xxLsNreX58rNOVoFn9Ql+G6cNtws6lDsdZ9lKfariPXeHJns6Z1PaTlcBb BuDYo3u20tbV539Ddv6e7PRHstO3VK7zcHZe3UJb67PzN7d5rCuzNnuk4ZjqaiJcv1DUmnB9b/3a VLMd1j8arh8VUa0LlUAf2+VIau+jYXaLNbULwHn77erytnam26kusjaSju9Eej+X890PNrxHHkuv qbH02OaykNpoet+OZfe9LWu7reHGOfStcOOIi3xkQ7nQ20R6HvLXcfl+ONNwPBdC90OpARCAlVJ9 HoBDeLIXeKLyZfhCqF98qAwfeS9Z3sN4PLu9NR3CzEx4snftaMNlphoCarfWhOvnhpZh60B2+3Wq 4bD898MNl5/Igme3YafpuThdE35PdGjLXZUA3FT7Kj9yXKqEvPFw/UJg1R7XdZUfBuqCbVN4zpXP 92Tl9fNwqF+QLH8On8guf6zyesr/fSx033u7tkO7TafjHMpe49XX8pY5BODL6bW2Ib02r2T31+0w 5dPhxp70aG92fKsqf4dKmG8K/7PpUV8fmuffH6087qYaq7yfmn5AW1f5bGvq4R3r8r0HgACslOrz ALy68kX+dE0QK8PHqSxcnKwJMHVfOMezwLQ9XL8q85502rqsBytf4Cj+vT+073XtpBx2nYei41lA ONrhi/GGSq9U+e8NHQLw2E0E4BWpXarbt+Ttcyz1om2vhMLtNQF4LAXKePlzWVDLV7fe1CaMNG3b tLlD2NsYnpzTW2dV9rxU5yrvqbz2Vte0Y95rP9khUJ0P3c9v35Aec3VqwPbs/vZWfhA6mR3D5dD9 /PZOQXA2W2btCDfOpQ7Zjxvnau4z/0FjJvsx6GDl9dbtQmDD2f1dSe20q/K6K3902ZrOm8ie5+2p llfeT/kIhgPZZ8Ijlc+2fQIwgACslBKAqwH4SvoiWO2luRyeHGq8vhK2SvuzL7LDWa/TRMMXzmoQ zIccjzaEx9MprGwL1/dE7pzl410ZnpxDWH6xrw4nPdQQ4PMQl/eudtsDfPQmAnCTc6F+ZeDV4ca5 x2X7V1fbXpY97/uz0y5VwuKZ0H5l6/lwsk1g3JoFnmoP6GjlOVlReQ3vSiF2S+WHgIdneXxNr9Xh LOxeDE8Os85/RNg8TwH4UrhxG64mS7LjOp39SFF9Dg+GG0c9PJGdtq6mnbd3eQy7ss+H1enYj2bh erzmOsfbvC/yAPxE1tbl6QdmGYDPBwAEYKXUwG+DNJO+pOY9jvnQ5hUNgTAOFz0xywC8JdQPnc2H zJ4M1w95nAn1e/e2s6JyGyfDjT2qIVw/z7Wu1y7vBes0L3NJdv6BeQ7AQ6F5SHEeVDZU2r8uEJwK 188xztsgn4ebD2W9NM+vxQ1dhKvlobknNQ88a9vcVh74ZzuCoCkAb2z4YSB/jvbMMgDnQ6C3huuH dE+E7nuUD2TvmRXZc53/yFAd9TAS6lfOrntddfujxnj241g+tL4uzB/tIgBPh+vXAaj+0HSlw3Pc bl49AAKwUqrPA/B0uHFe495KwCy/lF5pE1zWtPny2hSANzR8qd4Q6udbHgpzWwDrSJdhZFNov91M GUSmUvtcDs09vBtC+x7TbgPw+vTDwuZKoG8KI6OheQh0NwH4VKhfAC2E64d9L6+EvQOpnZvC2f7Q PP/2iVC/qFQ38jnlOys/nmxvE6KOzvJ+toXr587WBeM1De+x2QbgiQ4BfGuXt5evHn2k4YeN6nt2 tKH9lmenb+ry/uvmnp9Lx9/0PHcTgE83nF6OhihHLDzR8GPYfG2NBYAArJRapHOAN4Xr5+OWwwNH s/BSt7jVznD9EOjHQv0iUrMNwPmiSpfTF/ZlN/FYJ0PzYlS54ewHgRM1wbI872QlWE+HG3uUT4Ub F/WaSwAuv8xfrJxeHku1d3nlLALwiux2Hqtcti48HAz1IwHWdwj7o23CYD4KoGkO8fL0o8zaNj9K xFqdnsOZhrZZlp032y1wml6rmxqOf9UcAmPTa2JJuL5nfvMsjrva8zpVeS9VA2ceEKsjG8q263Yu 8lj2HjgZutvD+FDDj23tfrw4X/l8ydtqXc0PMbdiP2sABGCl1CJYBGtDuH4RpXIecD7M82T6cv9w eHKoYRksd1Rud0O63MQsA3A+f/FC+sI/mo4l3sd4OrbZPtZy/93z6ZgmUo/UroaQdzzd9/Zw/fzD 8ljXhOvnM25Pl88XEqt+WV+T7uN8FkiOhOZVrY82/KiQB78D4cl5ruNtAvDFFEA3hOvnVOdDSg9n oWVXCpRD6TVQPt+XZhFwqz8s7G0IL+3mYx7O2mBrur/V4fpVwsdqfjSYDE8umLWk8rzMdouiptdq /tgupttdnz2uyTD7RbCupNf5/vTeykdpnAuz6yXfWgnABxteX3novpK9X8pVrreEJ4ePd9t7/lj2 WtqXPjdGU/scT6dXe+nzvbm7DcAnK6/LkXD9ImS70o8QhyrtCIAArJQawAD8SE1YycNVOY/uVGje kmh1FoTa7efZbQAO6Ytxu9uazdzZ6dB+caF8/9rhyo8A1TrQ8CW/ri6GG3t/m267aT7i8vQcVHsR q/Oa221v1G4bpJlw/ZDaVaF525q6y5e2pbZp2mt3S3hyH+hSp57j/HXS7rWQb8VV3u5MdrwT4fqV oY/M4f2yrc1rdU+bY9s+i/votAjWqTD7kRD5UP1yLnCnAPxI6Lz9UzfbMS3r8F6qG859NFy/QnTd +7jde3BZ9nzNdPGZBYAArJQakAB8PoWCNW2+jD+R9ZQNh+tXcC17PavDCHdkPUjlF9nyC3h1CPKa Nl/My+BztnKf8ZgPN1y+yY4UHk6nx5DXyRQwhypf3A9VQlPsDdvZJhxdqBzjkVA/9HlbOpaxrM6E 7hcWqobg45X2OZce13QWmvemL/1nKz8GnG243zXhxpWfy9veOI+vwb3Z66hTr+amcH3vdvm6OdHw Wqjbx3am5rnu1oZQP4Q4D8FTldfAbFcq3xhu3Lf4Qnq938xw3XI15qMN7TRd+VFgKIXK/PFcSW1X vpe7PZ5l6YePK5Xn4myoH/L+WGjeOuxEuHEbrPyHlKnKe25jup88+MbbWBkAEICVUgMXgOdqJIWB NR16nUZTDafeol3hxq2OQnhye5R2lqTrrrhNj7fbIaxLGkLvQivbp9vewdEuH9Nwen7WLtDjGgnN c3ubrAlPrpC8rIt2iSFoewpbN/sY1nQIT8PpB6N1s3jN1LXJQrzWl83xdbUmPT/ljwbLO7z3O/1g U34mtPvsWD+H413T8PlS3ubyAIAArJQSgAEAQABWSgnAAAAgAKummg7TrXPhXGsqTGkPJQADAIAA PD81GSZ77pjWhXVXg8zKsFIbKwEYAAAE4JuriTDRGg2j11aTXBFWtFaH1a2Xhpe2/n34963Hw+Ot mTBzO0PM1YrHqY2VAAwAAALwnCsGsNBhT8/YA/uL4RcF4D5sYwEYAAAE4IGpl4WXdQxnZcXLXgqX BOA+amMBGAAABOCBqe8L33ctfMV/vyO8o/Wm8KarvZZrwpobAtrysLz1RHjilgfgxbwQVi+3sQAM AAAC8EAOgX5FeMUN58dVmL8xfON1AW04DLfOh/O3NABrYyUAAwCAAHxT9Wh49Fro+o7wHY2Xe3N4 c2soDF27bFzUaSF7ZeMWSP0SgHu1jQVgAAAQgAeq3h7efi1wbQgb2l72neGd1wW014fXL+jKyf0S gHu1jQVgAAAQgAXgNvWD4QevW7m4m/u4EC5cnfca7yv+Nw757bTtz1wCcOw1jrdd3lfT/cT9eMfC 2NXLd9tOl8Pl1nvDe+e0XdGtaGMlAAMAIACrDhV7GMuw9fLw8ln3zF4JVxov+6vhV1urwqra1Y5H wkjr1eHVjUN8ZxOA4zHEebbLwrLa+3lVeNW144wBNu7BG8+L8267aaMYmOPevSGt0txLbawEYAAA BGDVZcUQGrIVijtdPgbI0MX2RD8TfqarbX/Wh/W1vardBuCz4ezVVZM73U8MsDFIxp7c/PS4GvNs 2igG+l5pYyUAAwAgAKs5btETF2vqdPk82Ma5qnU9uHEeax7g4lY/8bbfFt7Wek14zQ0rHv9i+MW2 ATiG16bwG1dLzm8r3vYbwxuvLihV3X/33eHdV6+X33/sNY6huN3Q5yVhyaza6Fa0sRKAAQAQgNUs K85JLcNWDKjtLht7S/MFmuqG88bhwnHYcXmZODS5roc3Do9uFwrzABxXQ66efylcuu5+Yi9wDMTV odEh21aoPI7xMH5dqP3u8N1dbWEUrxMf3+1uYyUAAwCAL/5zqHyObgyldYE29tDmIa4MlBfDxRsu /4bwhmuXaZov+3h4/OriTuXlYo/nbANw3qsae3HrjuWJ8MS1y8R5v03BNlbdnrvxsec9zPE6vdDG SgAGAABf/OdQeS9qHKocQ1isODe3XPipWjFwVntb68Je7GnNz4shM/Zohsrc3Lpe1XjdpgAchyXn vaRx1eemRbhCw+rL1aHNdasz52E+3t9c5+LOdxsrARgAAHzxn3tQ6Lri/NmmIJgPOc5XWK4LvmUY rIbksuI2RU0BON9WqK53uG4ucl3AjatD58cT7zNfiCoPp+2GSd/KNlYCMAAACMALGM5iT2kMgJ16 JOPQ5pANa46BsjqsN6S9bWOIbbenbh6AY1BuGr7cblhyfht1Wx7Fnud866Q8JFcX8qobIn072lgJ wAAAIADPQziLval14SwO/41zbtutllztma0b2huHR3cKvnXhtdp7m8//jSs+N91GPge4afuhuABX qOkFjsOTy9NeGl7aM22sBGAAABCA5yGcxWG3cUhy3Le2bm/d2FsatxfqJgCHylDncguibivO673Z AJwvpNW0IFe1FzgO1Y69vaFhaPTtbmMlAAMAgAA8x8pXOc6D3nSYvjqMuS6kxTAZ5/tWbyuG3Pxy MbjONTzmYboagPMh0HEeb9NtxJ7m0GYOcN2+u+Vly3+vDWt7qo2VAAwAAALwHCsfklsXVqfC1NXe ynzV5ZDm8Va36Ml7XGNw7Gaoc+yB/bbwbTfsBdwuAMe9crsJtrHKcBlXYm66TAyidSE01mx7rhe6 jZUADAAAAvAChbN8Jed8795YMTRWA1oMvuX5MdjGcNd0m3G+a1ycqrz8pXCpdgui6grMF8KF647j XDhXe/vxcnnva7uFrKq9wGUA7SbE3+o2VgIwAAD44j+HivNzy7AVV3Fud9kYZqvbGcWAlu/jGwNe 3pMZz39NeM3VPXljkIurHL8tvK31HeE7rtuHN/bQxp7YusWp6hawyo873ke8/TKsxp7oGKDz8Bs6 rBgdr1sNn/M1F3e+21gJwAAA4Iv/HCqf7xqHHXdzner+udVhwrE3tTqct13F8Fvd/qdTAI6Xn819 1IXsasVhyHnobHfZ293GSgAGAEAAVrOsOLw4zGGv2zLkrg6ra3snY09w3vPZFEhj0Ku7fj7PN/bm 1h3De8N7r95G0+3H+//F8ItXt18qT4v7+zb1AOdDlV8fXt/zbawEYAAABGA1i4pDbuNWQp2G5tZV XKW40xzZGPhikHtFeMXVntxYMdDG+2t33Xhcceh07JVtN484BsM4pDrebuxpjRVDddwDOJ9rHPf1 jUGyaWXlGIzLkBqHZs/nCswL3cZKAAYAQABWquuKAbkMwDGsaxMBGAAABGDVd1VdVTr+rV0EYAAA EIBV39UPhh+8Fn7XhXXaRAAGAAABWPVfxZWel4Vls16lWQnAAAAgAKtFVXF7oZAtftVuwS0lAAMA gACsFm3F1aPLAPzy8HJtIgADAIAArPqz4rZJZQB+R3iHNhGAAQBAAFb9OwQ6zgGOQTjOB9YmAjAA AAjASikBGAAABGCllAAMAAACsFJKAAYAAAFYKSUAAwCAAKyUEoABAEAAVkoJwAAACMBKKQEYAAAE YKWUAAwAAAKwUkoABgAAAVgpJQADAIAArJQSgAEAQABWSgnAAAAgACulBGAAABCAlVICMAAACMBK KQEYAAABWCk1mDUVplr3hns/7yMRAIB+Nj0dpgUApQa8xsN462nhaZ/ykQgAQD8bj198BQClBrvG wlhrNIx+1EciAAD9bOx94X2fEgCUGux6R3hHa1VY9T98JAIA0M8O7wv7/kIAUGqw69HwaOsF4QU/ 7yMRAIB+tvn54fl/JgAoNdj1kvCSL9wf7t/oIxEAgH62ZCgMTV0JV4QApQa04vt/SVgyU3weDPlI BACgr90Z7nzHoXBoShBQajDrbeFtreeH57/fpyEAAINg3bKw7G9th6TU4NVMmGk9LzzvC88Iz/gm H4UAAAyE+8J973o0PDotECg1WPX28PbWc8NzP+JTEACAQbJyOAz/7aVwSShQaoB6f0fD6OctfgUA wMBZEpbs+4rwFZ+JX4qFA6X6v3aH3f/wrPCssz79AAAYSE8JT3nPd4Xv+nvhQKn+rneGd7YeDA9e Kd72y3zyAQAwqIYfCA/84b6w7x+EBKX6sy6EC63hMDxdvN/X+MgDAGDQLX9qeOr/3Ba2TRsOrVR/ 1VgYuxp+7wv3/SsfdQAA8EXDD4YHT70ovOjvLYylVH/U8XD8C0vCkqni/b3eRxwAAFRTcBh+7VPC Uz7zuvC6GfsEK7U4azyMt74mfM1fLw1LP1a8rVf5ZAMAgGYrY2/wQ+Ghz7w5vLl1JVwRKpRaJMF3 V9g1eU+452+K9/GeooZ8nAEAQHfWPRAeeGfxZfrvXhRe9MmfCj81E+cTxi/ZeoeVur01FaZaF8PF 1uPh8darw6s//uzw7I/fG+79q+J9e7Co5T6+AABgbpYUtbmow0vD0ifuC/dduivc9fni75ZS6vZU 8R78+yLw/vHd4e6x4u8DwTxfAACAq/Z1CFT7NBEAAAACMAAAAAjAAAAAIAADAACAAAwAAADzbXeH AHyoh441Hsv5olbP0+2tKmpDUWvCF1c0BwAAoI9t7xCAj/bIcS7Ljmn/TdxODLqxV/ty5XFOFXW4 qBEvCQAAAAF4ocRQuqqLy03d5DHFEP1Eh8c7UdSolwUAAIAAvBDOp/va2uFyE+lyZ+ZwH0PpeuXj ulDUzvDFIdAPF3UqO+98ujwAAAAC8Lwq7+t4lwH4xBzuY2d2PycaAu7e7DK7vTQAAAAE4Pl2Jd3X WJcBeLbHFMNuOec33sZwm8tdyC4HAABAH9ncIQCfvgXHMLHAAXhL9nh2dLjsnuyya7w8AAAA+seG DgF4rMvbiQtZbSvqYAqoj4Uvzq2t6219ON1uHPJ8pKjJ8GSv6/F0Xqy9DQE4XwV6JN1eDK5bQ/12 RofS9aZD5+2O1maPfZeXBwAAMBBaobWsqH5fDGk+AvDGoi41XH8yBePchQ73mdfymgActzEaSv+d rlw+Hsdo5f7KlZ/PdvFYRrLbOuBdAAAADEL43VzUqQF4qDcbgOP1Z8L1KyjH64xnp8Xz822Odqfz p2vubyoF3VgnK/dVBuDYu3yizTEfabje0a6f/t7aAxkAAGBBgu9wUYeKahW1TwBuG4DjcOKy5zcu MrW2cv6a7Px2qyo/EWY3B/hydnyxVzcOfV4fnuxZHheAAQAA2offdUVNpPAbaxAWQbqZALwru9y6 ynnLijqcnf9wm9sZS5c512UAbtrOaHd23nwE4EPeFQAAQL8F36GiDhQ1k4Xf8QF5+Ks6BOB27XA2 XeZkJfg+Ep5c2KrspR3qIgB32nooD8AXw40LWuVbOg3VXO9YF+2xPLuNfd4dAABAP4XfNUWdz4Jv WQcHpAlGOwTgdqG0nPsbhyCPpMCYB984x3d/6Lzy8okuA/CV7LY31pyfB+DRmqDezSJY+SrQO7xD AACAfgi+sdd3T6XXN6/1AnDHUJrPlZ2uBN/4A8LyLo/haJcBuLz9Mw3nNwXg8vYnuziWdsO6AQAA Fl34HS3qiYbgG+vKADXHfATgfMujx2YRfGcbUDstTrW9IbzuzE7vNK/7dOh+z2AAAICeDr+7ippq E35jHRGAZxWA46rMe8IX5//OxZFQv3jVbAPwluwyW7LTV2SntxvavjI8Oaz7jHcLAACwWIPviriv b4fgW9YmAbirAFxucXS4w32sDl9ctOqRhvP3zVMAXpddZmflvDPhyZ7dul7guGjW6ez6W71rAACA xRh+txY12WX4jb3DgzT0dahDAG4XSvPgGldYXlE5fzh8cSGpct/epl7V/bMMwPsbzh/JLnOgJhyX vbtxiPv2dHzR2kr4fcK7BgAAWGzBd1lRJ7oMvmUdG8immlsAjj8UnK1cNvb0xm2NLlROjz2vTT3r R7u4r9XZZfa0uVy5CvWpmvN2d/FYY1hf6d0DAAAspvC7uahLswy/sbYJwF0H4Cj2oh4KT/auViue fjIF2NAhAF9uc5nRdFux2i1kVfbkNg3d3hae7JGu1plw/erRAAAAPR18h4s6NIfgG2s6Xl8AnlUA Lo2kcPlYCrT7098rurhuHJ4ce5I77bsbw+mqLm5rrMNtxZ7r2Bsd5yTHYdxxvrBeXwAAYFGF33VF Tcwx/MY6PbBNd/MBGAAAgFsQfIeKOlDUzE2E31g7BrYJBWAAAIBFEYAP3WTwLWtkQJtwokMAHvUq AwAA6I0APDQPIfjsADehAAwAALDIgvD2tJDVXALwHgFYAAYAAFhMIXjtHLc/GuRVgAVgAACARRqC lxf1B7MIv+cHvMkEYAAAgEUagLfOckXoxwa8ycY7BGB75AIAAPRg+N0wh+2Q1gx4s411CMAbvLIA AAB6K/wuq5n/G8Pwj7aZFzyh5QRgAACAxRaAj9SE363pvDgveKwmAB/UcgIwAADAYgq/G2rC7YHK Zer2C16v9QRgAACAxRJ+l8ShzJVgezGe3nD5cr/gK1pPAAYAAFhMAfhQzdDndR2uE/cL3qf1rjrd IQBv0kQAAAC3P/xurBn6fEjLzMrRDgF4uyYCAAC4veF3pGZ15zgUeljrCMAAAAD9FIBPzHboMwIw AADAYgu/22uGPj+mZQRgAACAfgq/K4qarITfJ+I2R1pHAAYAAOinADxWCb9TRa3SMnN2qEMA3qWJ AAAAbn343VUz9FlAuzn7OgRg20UBAADc4vA7mnp78/A7pmUEYAAAgH4Kv0NFna2E3zgPeFTrCMAA AAD9FID31Ax9tjiTAAwAANBX4Xd1UdOV8HtKywjAAAAA/RR+49Dn85XweyVuhaR15s2eDgH4oCYC AABY+AB8oGbo81YtM6+2dwjARzURAADAwobfjTXh95iWEYABAAD6KfyOFHW5En4nilqmdQRgAACA fgrApyrhd6ao9VpGAAYAAOin8Lu7ZujzY1pGAAYAAOin8LumZsujs3E1aK2zYLZ0CMC2nAIAAJjn 8LukqAuV8DtZ1KjWWVAbOgTgMU0EAAAwvwH4cM3Q54e1jAAMAADQT+F3S034PaJlBGAAAIB+Cr8r irpSCb/jRQ1rHQEYAACgX8LvUFFjNVserdE6AjAAAEA/BeBHaoY+79Eyt9TqDgH4oiYCAAC4ufC7 NvX25uH3jJa55UY7BOAJTQQAADD38Duc5vnm4TfOA16udQRgAACAfgrAx2qGPm/WMgIwAABAP4Xf h2vC7yEtIwADAAD0U/gdLWqyEn4vFLVE6wjAAAAA/RJ+45ZHZyvhd7qo1VrntlrSIQDPaCIAAIDZ BeDHaoY+79IyPfL0tC8AAAC6DL/ra7Y8OqVlBGAAAIB+Cr/LipqohN/LRY1oHQEYAACgnwLw8Zqh zxu1jAAMAADQT+F3R034PaBlBGAAAAqHQ2u0qA2x3hJa64+G1rKFvs9bcR+32qOhNVS03/6i9nhV cZvC78qipirh93xcDVrr9JxLHQLwqCYCAGgTYt8cWg8X4Wt7XsVpW1K4HW0IbBNFtSo1U9TJuuvM h+K2d6b7ONJPz8GR0FpXtuHPhtZyr0pucfiNWx6dq4TfGIZXaZ2eNCEAAwDMPVRO1QTZurr41tBa U4bmDpedigF6Po+zuO/d5e0X/z7cT89BbNfysS3UjwdVMWi/RcDhiwF4f83Q5x1aRgAGAOjHADzR ZQBuFaH2kXSd9eVpWaAaLoLc1hiU03nTRZhbPd/ht6iz8b766TnIf1C4VQG4uK/J2Jt+q+6Png2/ G2vC7wktIwADAPSlo6G1JM3lHY3/zgLxwSLwbixqR/HvfTH8lsEzzfm9LgDnQbg4/Vw6//jNHl/s Se7n8HsbA3D5o8bD3gUDG35HirpUCb/x72VaRwAGABgI2ZDo7W0CWxmApxpuY3M6//I8BMOpNOz5 xKN9uiDP7QzA7Z5n+j4An6yE35miNmiZRR+AV2oiAIB5DEZZAJ7ocP5keVpc6Cn2MLe535Fq725x 2ul0O+fmI/ymHu5j5VDum2ijkW4Xq4r3GXvS448CTeG2UwBOQ87PtZtXHVfHjtdt10MebyfON67M 4d4Tn5v4nL0ttHxxHpzwu7Nm6PNjWmZRGOsQgP2IAQDQbbDLgtiGuQbgGDDT8Non0u3ubbd4VZwr nFZ3vlgJfeUw3bXz8fjSatdXe6ZjYIxDu4u6kO57PP7dFLTT0O59lTnTl+NQ8dhuDfe3MV0mn0t9 oTrsuF0ATu1Q9sqfrnnONmdDzssaj89B/liK03Z1M887hmHvhL4Pv6trtjx6wpZHAjAAwECpBLEN bYLy9hRoxxrC7GS+aFYZiOPpdb3AxemH0vmXstOOlWEuBc+LeYiMoXq284Fjb2c5dLs8xpo6VnO9 VR0WC7tUDc5pa6OZ7P4mKguKbazc/g0BuBJ+p6qLinUKtfkPDsW/t3URgGfma+Eyejb8Lkn7+1a3 PBrVOgIwAIAAXCMtjHW1hzdbGGt1EbIeywLbxfK8IgyuKMNgXCk6v620p/CVdJ39Wbib7GZrpqbe 13bBvdKDuz/te3wqO319dp3YK36pDKFxRerYe5yGUx+pC8Cpt7gMvGePpkWF4m3FUBpXyM57WvNF xcoAnMLvlSxAr688B2uzgH0ktnHZ1ukHh3jedOXxj6Qh0BvKnunisgfi0Of03I94F/R9AD5YM/R5 m5YRgAEABODmILmvQzC9UN1jtgyY8b+V07dUw1/qRc57MsdSb+f2tCXS2XY9tk2K627Krncy70FO QfxCtee0OL6j5bZO1RCawuwNjylrn8tHu1hRtxqA09Dpqabwm+7jdLk4WH56Gtp9qDoHu+b6ZUDf 55U/MOF3U034Pa5lBGAAAAG4TQBOPb21Q4Hj0OS6Yc5Z0J3JexpjEK3Ob81WkY4Bb1PDMRwub+9o l9u25EGz7DGthML96fzz6e+RrJd1b81jOpoC8NFKkL6cjn33bI8rHcNM1lZ14ffaXO1y4arY5unH gSvZbe1sE4AvCMADFX6XF3WlEn4nWn24rdgAONMhAG/SRAAA8xiAs17RQ+UKwp2276kLhnEl5Szs bc7C2fZO2yh1u2BX5TqrOqy2fN39VvYgHukmAOdbRLVb9bpNAK7W9prj3JwPr049zvmQ8fGmHw6y HxDGBOCBCsCna7Y8suDZ4nS0QwC2tRkAQDdSSJ1NAJ5VeMp6WM+l2ykXxxqvrFi8vd0+w9nlZrWX bRfbDV2bI1z5+1LD/R+pBuByoa3qsOhZBuAz2TDvqepw8uy4JtLQ7PJ65+Mc6262jMoC8H6v/L4P v7trhj7v1TICMADAwOsmVN5EAM57YFeXi0tVhwqnObBXL9c0vDkP6/mKyt0G4LqtleKQ4bwHuIsA vK8mAN9wWhdhdGu+L288LS0cVvbqns97k6uLeaUwu3k2z0UZgGdznCzK8LumqOlK+B2z5ZEADABA FoDbDaGdawBO130iWyirHCq8rHIMI1lQ3dJwnOvbzeftFIDrerjL+cjl9k75EOi6LZeywHwyO21X vgdyl21eO+S7MgT7YM3pk3VzhCuPd3PDfR4XgPs+/A4XdbESfidbXb5fEIABAPpaXFApC8C706rJ MZxtz/eHvZkAnIXGG4Jd5XLnyiBZHdIb/856MLsOmnkArvZwV47r6uJRaY7ydT2zuWwxsCvlMVZ6 mR9uaOOD+bDmbCj4RE07HKyG9rTNUtk7fKhuyHO6n4vpuVzT9COGANzXAfhwzdDnrVpGAAYAGFgp +E10se/uVNkLejMBOC3aNF1dxbjmuDZnQfJUHLKcwuX6cguguIBWtwtg1QTgsgd1orJy8vk8UMZt hsr7ioG3/FGgsm/wdT3V2QrVrdTTujPtnXws2w/5cPZY9zUF4LTf8MXqXOm04nMrmwt8MN3O/vTj QLm42KW63utsWyoBuD/D79aa8Hu4hw85vq7je/nAfUvv/62i/vTuu+/5uw5BT6mOFV9H9w8/5eMP jjz9N+65Z0mc+77SJwQADHYAPtMh+JZ1MQtfh2ezzU/NfR6vbn3UcLmDbY5nJobK2dxvTQBuVULs E7HXN79O6gW+2HCd8ey8a48lzU8+1ua+zuXBv1w4Kw4LbzjufJGsVVnQ3l1ZBKtaJ5tW5y570N/a 26GIuYXfFWmocx5+L/bolkfxM2X7nXfe+VcrnvO8v/y+H3jkk4ePva/1rjMfbj3+Ox9vfeCjn1Xq piq+jt7+y+9vveHQ8da//LbtX7h3yX1fGHnGsz5YvO7W+7QAgAEUe1ZTz+HeIgxtiz2sMTSV1bBf 7ki87M/O8Qt1CpVXt1DqIixvTj2+ZS/teOy1zIdkzyUAx+HJKUBefeztFtJKvbA7Y29wCo7Hy9WW 42NJp+2vCZmbUti/kILysbo5uWlI8966hbkqIXlP3XORju1w6pk/Eh9Xp22pUo/0xXb3yaIMv0Np kavqlkdrevBwR++4444PPmd05ceOvvP9nxPW1K2osxc+3Xr1697UeuApT50pgvB7itehvbABgP7U aRsk6IMAvLdm6PPuHjzU9Xfedddf/sAPvfZPhDJ1u3qGX7b1ez+/9P4H4uKDq3x6AAACMCyu8Lsu 9fbm4fd0Dx7qyjjk+af+83/9M0FM3e764b1vbN239P5PFa9Lq6MDAAIwLJLwu6yoiUr4vdyqzGnv AUvuuOOOP9j1qp/4sPCleqVe+aM/OXP//Q/8YTAcGgAQgGFRBODjNUOfN/Xgoe5+zvO+9ILQpXqt vvYbNn/6zjuHXuvTBAAQgKG3w+/2mvB7sAcPdfiOO+745PH3/t4VgUv1WsWVx++5596/LV6ny3yq AAB9Ia7mHLc6itsQxX9rEfog/K4saqoSfs+3evP1/fCzn/O888KW6tX6mq//5jgXeLtPFgAA6L3w G7c8OlcJvzEM9+qKtsde8cOv/T1BS/Vq/fh/eFvrKU958Bd8ugAAQO8F4AM1Q5939vAhj5/4tQt/ I2ipXq1j7/lA68GHnvEnPl0AAKC3wu+mmvB7oscPe/q/f/CTgpbq2Xr32EdaDzxl2V/7hAEAuMV+ NrSGj4TWusOhtSHWW3p3WCu3PvyOpC2O8vAbt0Dq9cV7hCzV0/X473y8de+S+z7rUwYA6OugWYTL kYW47bjQ1ltDa1Nx+9urlYLt6qM1oaW4zu5ytepKjcfretYGPgCfroTfmaLWL4ZDF7JUr9fVtxgA MHChcHkRtPYXdTELX1NFMBsr/rurX1ZQTuH3QlGTCxGC3xxaBxqCbLWuxMuW1yv+Pt3h8scfDa0h r9SBDL+7a4Y+71sshy9gKQEYAOgpRbjaGcNuhwB2qE8e6/HyMRXhfusC3P6eLgPw1d7d8nrph4ZW EYp3lKfF3uLi76P99hwwq/C7JvX25uH3bGvx/BgiYCkBGADoqUB4sAxYab/c7UUYWxPnnxZ/byn+ uy+GsKI2LvbHGgNvHkCLvx9biPuJvelFeB1Nveq70v1dKtpwbTqGPaldN1YDcN1w5zSEOp43cyS0 VnjVDkz4HS5qvBJ+J1uL6zUgYCkBGADomfC7OQuE+3vt+OJc2fkaeh2HO8dhx3kALgLoqVvQxvuq vb0N4bwxAKfbuZCO+WGv3IEJwEdrhj5vWWwPQ8BSAjAA0CsB+Ew34Ww2Ys9nXOwpzrVtE2yXxN7P GMDj5esu87bQWpmGZU/MRwjOhhLPFGHzRNkrewva+FDqbR67mQCceudbFsQamPD7cE34PbwYH4qA pQRgAKBXAvB4ClXn53DdOLR3OobdFGgfiYEy62G9XLfacep1vlKZC3u+Oh83bQNU9tSuvclQviHv 6a70fI8sZBuXwbtTAI5BP14uHmvNDwbLYlun413vldv34Xe0qKlK+L3QWpwL0QlYSgAGAHpDZYGl M3EBphiw0vzV4S6veywG2LpFnqrDdVOv70y5wnQlMF8X/tKQ5cl0uTmH1Lhycray9dXe5HTb5TFu uRVtPNcAHI8/67G+bCXovg+/Q0Wdq4Tf6aJWL9aHJGApARgA6AlpkaaLbVYpjuftq+vJrYTnWBeK oLYthstsOO/e8vKpF7MMvCfLgB0vn25rOi6+VTm+4br7no18f924P28WOMcXciGs7P7L1Z2PdgjA M+lyG8t2ib3i2dBn838HIwDvrxn6vHMxPyQBSwnAAEDPSD2iu+KCUKkX8kpNEI7BdVVTAI49lHnP ZBn6YvjMTnusvK1OvcvzJetFvnqMZag+Elrrsl7rMz0SgNttlxTD8S6v1r4Pvxtrwu/Jxf6wBCwl AAMAPS2GxDhPNoXia73BecjNAvBENdCmlY8vHk7DNlPInrzVizjlWzylBb8u1ITLyVsRgOP+w02X iUPOG4Jv7BU/Ue0Zpy/D7/KiLlfC76XWTY6AEIDVQtTbf/n9re9/5Wuu/lcABgD6Slrcquzp3VoN wN0MIY5Dj9NtXDl6ixbySXOTW93U4QWcX9nNHOBKAF4V5wHH0Ht0cS56xNwC8OlK+J1p9ceCZwJj n9XZC59uPfCUZVdD49Oe/kwBGADoL2kRqXJY9L5qsMtPaxNG9+bDkG9RAJ6sDuNOi0ntifNs0/zn ct7tjtsZgOMq1+VxesUNZPh9pGbo875+eXhC4+zrl37191ur17ykNfolz2/99FtP9lwAToHxav0/ 7/9TARgA6C9x9eGbDMD7upkHm0tbK8UFoMZnuxBWCrfT2SrVIw3HdT6F0wXbX7XLHuANAvDAht+1 qbc3D79jrf5Z7VugnUN9w0u/9VrA/EfPfm5XQ5JvZVBe9uDTrh1fPwyDFoABoM+9LbRWxvmwRTg7 0Omy2fDl61ZRnmUA3jPbBaeOhNaKuqHXXQb2/fmQ4jaXO5IuM94jAfiKV+dAhd9lRU1Uwu+Volb0 08MUaGdf3/qd338tYP7TF3xF28v+3H/99dZddw1dveyrX/emW3J8X/GVX33t+A4fe58ADAD0trid ThYQa1cXjkOf077AU+ly5xsWweoYgOMc23ZhNs53Lc47FIN5JaDOzHbhrHzBrbiIV4egvD3bYmjt QrR1tofvuRh0U9tvj+1QtmcWgCe8OgcqAB+vGfq8ud8epkA7+/rvH/xk6zu+75Wtl33r97TedebD bS/74//hbdfC6P/2td90S47vn33V1wrAAMDikfbkvZyvkJwWu4qBcFcMo2lLpPL8iWo4nU0ATmHz WLalz/EYrlPAPp7NxT1QuY8dqZd2pNvHlofaGCw7XHak6b7nKg6/TkO3JzotvlVuEyUAD2T43VkT fg/240MVaBe28gAc5wzfivuM9yMAAwCLShwaHHslO+0/m4LuDQF0tgE4ba10sum+YmiM4XEeHte+ TkOOGx7HvOy3Wuldb9u2ZW946gG/utWUV+ZAhN/VRU1Vwu/5Vn+u+r2og9GpX//j1mvfeLSn57nG 4wuzmC88HxXvp7zPd499RAAGABaP1PsY58yejqExVdx7dveRNnMRU0/xeFxReZYBcUvq9b2Y6lg+ t/hmpcWzHu42TKdgviduRTQf959Wzd6TgviuNIc6bm00WlZ13+SyXez3OxDhd0kKu3n4jWF4Zb8+ 5MUWhuKqxnt/4s2tl3z1N1ybWxv/e+w9H+jJ4409sGUYjUOTb+ZxdxtmBWAAAKCbAHy4Zujz9n5+ yIulp/cVP/Ro6wWrv/K6LX7yikON81WX43zbLd/+r1u/efEzN9xePG37zh+5uppz0zZB8fZiyM5v t6w47/f7X/ma1luP/383nPfNW77z6vHcc++Sq0E0H44c9+fNw2kM7vHy7R7763/m2HW3EW83Hlf8 ESBuedQpAMe2y49716tef3Xucqwf2fczrcd/5+MCMABAr+py+HIr7Y08kWrSNkZ0EX631ITfY/3+ sHs5+JRBtezpbVfbdvzQtevF8FueXrf9UAx+5fkxJNfddwyrZUj9tQ/8xXXnxZWfyzBaDZCdjrOu qrdfVlxoq931nrH82bXDv/MAXC7a9e3f/QO17fi0pz+z40JeAjAAQO8H4NrSgjSE39GiJivhd7xV MxxeAL51FcNpXfBbveYlV3uE/83/8WO1KyzHHtLy9Njj2W6boLhnbvX8X3jv717Xa1s9P4bG0DDE OL/vbqppWHQ87mpQjcE73+M3VuwVbxeAY/jNH29dxZ5wARgAoAc1zdGN4vzifC5vXWlBasLvUFFn K+F3pjUYc757NvTE/XPzkBaDaBx2XB3SG2p6cvPgXO3hjb2t1Z7Q/DZjxf16y/O+7hv/96ZA1jjH Nt5ePP43/fzpq0E9D9txTnC8Tll1Q7RjAM+PMd5Gfrl42+Ww6Lrwmgfgsrc6D9zxh4N4vZANq647 DgEYAAD6LwDvrxn6vHtQHn6vhp4YdkPW+9m0mFMMmTGwxp7Out7T9V//LY2rMpd14D+fuO4y/2Lz v7p23g/vfWPbAJzfb13F4w6zXAU638f3W7/z+2svE4dev+HQ8dr7zwNwWfctHb7aVvnw8vxyvTwM WgAGAID5Cb8bU29vHn5PDVIT9GroiYs0hawXdzY9lDHQhqwHND8v9uhWw2F1mHQeDKurS8ce5Py6 nY4lD8DdXD5fNToG/7ksUlUNwLE3uW7Brjzo9/J+wQIwAADcfPgdKepyJfxeatXsqy0A3/rKhw6H NEw3zneNi111Cmu/9Ku/XzvHN66aHHtCy9PjbcZ/xyBYF1jr5gd3Ov9mA3A+NLmu93kuATj2pnf6 kUEABgCA/g7Ap2vm/W4YtGbo5f1+88WmqrXiuf/k6nDmptWjQ80w5bxnOK4u/U/+6Qtv6CWO2w6V l8mDcb7FUpjFkOYYursNwHlAr1thei4BOP67abukPADH4dQCMAAA9Gf4faRm3u++QWyKXl79N/ae xhBahsK6iufXDY+OATlUhjGXe/TGIcFxoaqytzWGzfJ6cc5tqNlbuG6IcrdzevPjbTeUOw/X1bnL cw3AMdA3XS7eR7vHKgADALfU0dBaphXa+9nQWj7XdoqrQj8aWkOzfE6WxPtciMfyltBaVdS+6mrV R0Jr3dtCa2U/PFdv6YHhxUXQXVcz7zeuAj00gG+hng7Aec9oDJ5xrm4MbeXQ5dBmq6M83MWe37x3 tVw5OfYCl5eJw6bjaeXqyrFiL/R8B+CmxbxixV7Y8nJxpeb5CMDt7i8fbh33RhaAAYDb5s2htbEI C9NFjRf/3hGDVz+G17eG1mPFYzxX1ERRZ2MA7BSSYkAsLnOkqMlsj994/X2d2qm4v03pfmbS9eJ/ z8bTOx1vuu7leJ2F+HGiuP3D6Zj2Za+Dtem0MzfzQ0px/T3FbZ0q7mOs+PfJ4r+7b+UPLMV9H83a e1W7y8awX1zmYFHn0/N6prj+I/NxvEXIXVbURCX8XilqxYB+1CyKAFy3zVB1L99qz2qcK1ye/+9e /Ybrhj+Xqz7v/Yk3X3daDLyhzf66cw3A+ZZG7QJp7IUNHebtdlNxy6hu7i8fAn0zgVsABgDmMzCU FYPXnoXqfczFXtHY6/joAvaIFY9lZ1FTlcdY1pWi1jdcb30l+FbrbNM+wcV5+9tcrxVDVpvnY0cW mlsL8YNEcbunawLwI/G0IrCeuIkfUq40POZLt6JnOYbt/H4Pt5lnW5y/N2/n6vF2Cs9dBOCTNUOf Nw3wR82iDMDlNkD50Og4fDg/P5/L++3f/QPXhj/nYTnfazguupVvkdQUCOcSgLvtkY0rNZeXi8d7 k4Gx4/3lPeAxDAvAAEAvBeCyZuJ5Cxlcsp7IPQsUfg9We25TwDyWhZ/Jak9w6vmdzELyruK01bGX NPUkl9c93hC4r4Xk4vJb0+1tjj2M2Xmbqz8G1D0XC9QuZ6vtnnrEYzg/Otvbi22T/cgQb3tXUdvT bU7dbM9yl49pVRrJ0DYAx3aOIT+73MUY/tPr4mQeguf640MRdHfVhN+DA/5R07OhJ4bTTotAxV7a 0LCKcb4S9Eu++huuheXv+L5XXrtMXByrvEwcDpz3iMb7r7vPX3jv795UAG633248nnJ4d/xvu/Ba zpGuW+Cq2wAchz3nbSQAAwC3PQDHYatFbcnCUVnT7XosbzK0HC/vewEe15bsMRyv9tamHsvy/O2V YH4iC7+raoL7tuy613qQ09zTMjifrOvZjo81nT+en58CWN4DuZABeKL6uG8mAJfBMQ57rj7mvK0W aih0vM80vL2V/8hQF4BTOC/b+VD1eFNwb6XHM+se2yLorilquhJ+zw3ovN+eD8DlQlQxOL7p50/X zgl+9evedN3Q4up+vbHqVpGu9hSXK0HH+3rG8mdf23+3m22N5hKAO203lIfwOB+5nJucVwzRZY92 vEw1BIeaFbDr6qffevK6VbUFYADgtgfgGF7K02JwyIJaOWz3VNOQ3ybx8vG2mnrS6u67IWCNzHaY dOx1TUF2Z5vbLYPO7vK0NC+0NhhXjv2JdJlj1RAZQ3BT2Es9lWWbbszvN95m6o3c0ikAx9uf69Dx MgDH+5mnADyVrvtw3fNQPpY43L3uNdL0uoqvm25Cc9bu0/nz1xCAV6W5yduaXjfZ62LbLMPvcFHj lfA72aosNiYA907lC1HFir23cauif/ZVX3u117e6KnQMsXW3U4bEdpfLV30uK542nwE4n5PbKQDH +c15cI8hP/bOxiHZcV5wXNwrD/6hslhXDMch2zu53X3ll43VtF2SAAwA3JYAnAfhtEBQq6mHry7Q xCCUhhlP1YTEGEDWZwE1Bqcn4jDaeH/VOcFxCHEajj2vvcRp2G6rJgjuLXth2z3Wcs5snDOdXfdi Om1/h8B2IV3uYMP529sF4NhGaRj2uW4ea3H5FXmQLHup84BYF4Bjj3Z8njqF0HY9ppUfFNbXhM14 LJerITj16k6kYc2N83GL+1yTDUnfkx/P4TnstZsWICtfF2tnGYCP1Qx9ftinTO8G4Hxxqk4Vw2W1 V7esfOGr0LBadD6ntwyc7YYpx2HZ5TDlfP/gbufkxoDbzfDvdnsg58f6w3vf2DiPePWal8wqnDcN +xaAAYDbGoCj2AtXmZt6qCmUpV7juoWFLqRgMtJm4aG8DmaBZPdCDAfO5ntO53OAy57vOD+5w/U3 Z8c7klZAbuzprFz3eLrs6YbnpBwOPdNw/sPlfTUtVpbC5fHKAmAX048aV//O53fnATjd/rnKc3K6 aT541qN8Kv/RoDKveboapFN4rQ2r8XWX3feuptdm9qPD+fK+5xqA0/GWPftXZtPDXgTd7TXh97BP mN4OwGWQq+vtDFnvZhwu3G6Oa1zsqhzWHHtrm+YUx6AYsgWzOh1bHJYde2PbBeW6IdCzGWb8ax/4 i6uPr7rlU/nYt3z7v64dHh0fc3wM8THFNux0P/neyHW3JwADAD0RgKuXS5ddUzlvSyXYzsTby7ek SYFlWYeVlcvbfywP1um2L8zH460J9PsrYW48nb6z3e2k4yqD1mj+d6eh4sX9H0iXPdcQKMshvRN1 56de1am6ntN0/fVtVr7On6eRmvucbvPcTNX1isae1+wy4+nvvdlc49oQG489rTo+dbhmmHAK4TP5 UPGGdpzJX5NzCcBp5EI+7L/rhdmKoLu6qKlK+L3Q6sMtxfoxAOcLQ8Ve2rhFUFkx2LWb21oN0nFI c7twF4cQx0Ww4uW6vd3ZVAzpcSumbgNz9fHHubpxwapyO6f5PMb4o0C87V7t/RWAAUAAbgor122V k4aqXi4DUgo/I1ngjaeN57cTA1yaZ1wG0fNpCPRoQxAamY/tgNLw6/P5Ks01iyBNdJr/G+VzRdNx b+i2pzoLmxcazj9YDg1vE+SX1YXfykJcZ+JxpWNdVVnButVwTOXzuC8+T7Hd07Dgsqd1vO65aLP1 00y7ubTxMTQNsU49vCMN7b8hu499lWOZVQBOP16MZz/AdL0VVAy5RZ2vhN8Yhlf7dFlcAVgpARgA BOBqyCnnx06VwbEyx3NzQ8BZMpcgOJ/S6r/TWcg5XDfEtdsAXO0BnmUA3t+uzbMfBk7O4XGWWz+d aViFupy7PN3wXIzXDXWO84jLYF0NtDW9p5P5StZpJfEd8/VcppA/UR36PNsAnH68yfcDjv/dN8uh z4drhj5v98kiACsBGABY5AE43zqo7KlNwejaXN84RzhtfTPSRVhrO9R3nsLScGV/14l229tkwWpn t22RerrXd7vdTxZwa+cAx+cinX9kDgH4ct2CU6UsqE/UBeN2q0Bn4fp45bqn8h8WysefhsaPZ4tK 3fSCUCm05lt1HUyLhl2tfNulOH88/lBR9wNMDNFZO1997Xaau10Tfh+uCb/HfaoIwEoABgD6IwCv rQbgFIyO1wx9jb2th9rNh40hcyEDcAq/F/MFvDrNz83CVaeVnMtjn6r+EHC4w/DXMng1LbSVBbN9 swy/I+UxNPViNgXgcuXpdgE4rch9tdc1O21NFnB31AXN7EeFi/Pwet3RxSJq1Trb5pjiEO3HZrul VNzaKG1xlIffuAXSsE8VAVgJwABAjwfgbrYZyvenrfbwxuHP6bYuVMNHmyHQ2xcyAMeAWYacbnsf s+uc7hA2j1QXsioXnmo35zX1YE5V9x+u3Pb5uQTgbF7yRJvL3EwALrcIGs+ut6d6Ws31dje9bmYr bV91Mv1IcDEF2bwu1QTgI5XjOZENzd446yRXPIdFnauE3+lWZXE4BGAlAAMAPSbOFe0UfLLLHusU dtLlRrIVehu3sckC8FTTbaWe1YlOgbQq9f5Op8d2YBbtce2YmoJ7vvBXftvxGKv7HrcJkTespp1d pm0PcBpyHcPf+fwYswA83UUP8MxsA3AWdk/X/BBwvJvHXF3kLL3+Juq2c4o99nE+8WyHJrebA1wZ sr9nLu+ZIugerBn6vNuniQCsBGAAoMeVYatTAE49b+ViQXu7DCKn262qm8/XbLqNvNe5aR/aDkEv 7su7YhbhaSRbLGtPw2V21e35mw3Pna5bzTpd92yn4cDZnNojDT8KrMtC3PrK7bfthc7nLs8mAKcV mcfTZR6phNS2PeaV9lpRCfKNw6ezYcqH5isAZ3soT89lZfEi6G6pCb8nfZIIwEoABgD6JACnOZPl XNrJfJGnGIZiNayofLrd8Oq8Z7BD8L4hbHYRgsqe3Mls26WH0+m70gJcu+rm62a9mtPVla3j31nI HKsJieUiVOfzsJd6jQ9lwXVnmwBczss+EYN0Nail56MMjlsajn2yumdvasuLdYt1ZQH4ieoPBrE3 PRs2PJn31mahf6Zu4a30uM+ly1yqaesr1VCdndf16IRuA3C2knkM16viZdIPMdvTUO34uthZ9wNG w7zfiVaHRc8QgJUADAD0WABOQWRXCgWjaTjt+hQYrtRtdVQZThp7B4+nvWaPVPZV3d0hpLY6BJr9 cajxbBYqynuXO1X1+FLP5ERldevjlfnNMQSvqjnWzVlP+XQKcSezYFy7RVHqmZ1qOMaLNSH5kbTi 8pLK/Y9k9zWTepP3pwA7nd9uHv7z5yItDDUWg2e63pWmlZxTW5XzbqfjMcXLpB83duX7Ltf1Sqfn 6VjdEOjUJsfeOsu5tR16gB/p8nUR22BrFn7r5v3OtCo/MiAAKwEYAOhh2bzejoGgYZjq8Q7XO90U XLuZAzxXKcBXA+W1xZJS8L/cNNQ57W98ruExjb+5TfBJw7YnG657vG4l6g6rG1+a5XO6qrL6dV7n sx8n1tf8YDDTcL3JpoXE0v2Ntzn+6U7bSs3za3qyaSuoNHw8f4wz2etiPL0ubtjv2LxfAVgJwABA H0jDdjen4cp14SeGyGPttvZJPcUHU3iYiMNo0zDezV2E1POzXe14No8t3ke7OcBNc3WzYBp7Ifem xxOHx27upic69Yxujz3XaWXpPZ22R4q9oGXve14/O4etdeIxpp7Yw+nYD5XHnsL9zvxxpGHOcQjw qviYY09+6gGO19/RaW/j2NZpiPmR+DpIdSL2uNb17i6kGHJjeG16nuJjTe26vKnt8tdMEXQ3mfcr AKv+rv/+wU+27r7n3s97qwLAAInBIPZsxqGjaRGpVVqFgU5tRRAu6op5vzdt+jcvfkbQUj1b7zrz 4daDDz3jircqAACDGn7jvN+zNfN+12mdWZt499hHBC3Vs3X42Ptay5/1jz/irQoAwKAG4P01Q58f 0TJzcuLVr3vTJUFL9Wq94oceba18/upf8lYFAGAQw2/dvN/TWmbOtn/Zl7/4DwQt1av1wi9/8ReW LLl/o7cqAACDFn7r5v1eKmpE68zZyF13DU2d+vU/FrZUz9Xbf/n9reEHlv198Tod8lYFAGCQwm/T vN/1Wuem7fuar//mPxW4VK/VP3vJP/9fz3/hmh/1FgUAYNACsHm/C2fZXXcNXX7jW971OaFL9Ur9 yL6faT1z+bP/Kuj9BQBgwMKveb8Lb+299y399LH3fED4Ure9/tPPnWo9+LSnf/apT33GP/HWBABg kMKveb+3ztYlS+//m59+60khTN222vsTb249ddlDn3/B6jWbvSUBABik8Gve7623dsl9Sz/5zVu+ 63MWxlK3sn7pV3+/tf7rv6W1/NnP+fTzV3/Vl3srAgAwaAHYvN/bY9lDD40cuHfJfZ/9F9/y7f/r tW882nr32Edav3nxM4Kamrc6e+HTrXed+fDVHt8YfB94yrKZr/yqr/vZ4vW3xFsQAIBBC7/m/d5+ I8ufteIHn/O8L/3AQ097+mfuvvuef7j61Cg1D7XkvqX/8PRnPuvvVr/oq37/JV/9DfGHrWFvOQAA BjH8mvfLYjLWIeyNaSIAAKAu/MZ5v+fM+0UABgAA+j0AHzTvFwEYAADo9/C7pSb8ntIyCMAAAEA/ hd/RoiYr4XeiqGVaBwEYAADol/DbNO93rdZBAAYAAPopAB+uGfq8W8sgAAMAAP0Ufh+uCb8ntQwC MAAA0E/hd2VRU5XwO27eLwIwAADQT+F3SVHnK+F3uqg1WgcBGAAA6KcAfLRm6PNOLYMADAAA9FP4 3V4Tfo9rGQRgAACgn8Lvmpp5vxeLGtY6CMAAAEC/hN/htMhVHn5jGF6tdRCAAQCAfgrAJ2uGPm/T MgjAAABAP4XfPTXh97CWQQAGAAD6KfyuL2qmEn7Pxa2QtA4CMAAA0C/hd3lRlyvhd7KoUa2DAAwA APRL+B0q6kzN0OdNWgcBGAAA6KcA/FhN+H1MyyAAAwAA/RR+N9WE39gbPKR1EIABAIB+Cb+jaZ5v Hn7jPODlWgcBGAAA6JfwuySt8JyH37gC9HqtgwAMAAD0UwA+UjP0eY+WQQAGAAD6KfzuqAm/J7UM AjAAANBP4XdtUdOV8Dte1LDWQQAGAAD6JfyOFDVRCb9TRa3WOgjAAjAAAPRL+B1K2xtVhz4/rHUQ gAVgAADopwD8WE34PaBlEIAFYAAA6Kfwu6Um/I7FXuGbuNklRcUtk3YXtU+pRVATHQLwhDZSA1jx M3xtUUP+bwkA9EP4XZnm+ebh93JRy2/iZtcUdbFDmFBKKbV46omiRv1fEwBYzOF3uKgLlfA7U9S6 m7jZuFp0p540pZRSizME6wkGABZtAD5eM/R5103e7FZfEpVSqm9rrf97AgCLMfzuqQm/R+fhpvf5 gqiUUn1bu/0fFABYbOF3YxrqnIff83FItACslFKqTe3zf1EAYDGF39GirlTC72RcDGue7kIAVkop ARgA4LaH3+HU01td9GrTPN6NAKyUUgIwAMBtD8B1i17tnee76RSAx4J9NVVv138o6l3ptfpLRf2E NlEDVGMCMADQD+F3b034PbEAd9UpAPvyBNC7fIYDAIs+/G5awEWvfHkCEIABAHoi/K5Ki1zl4Tcu gjXqyxMAPsMBgH4Jv3HRq4s1i15t9OUJAJ/hAEA/BeBTNfN+d/vyBIDPcACgn8Lvvprwe9SXJwB8 hgMA/RR+t9WE33NFLfHlCQCf4QBAv4Tf9UVNV8Lv5aJW+PIEgM9wAKBfwu9oCrt5+I1heJ0vTwD4 DAcA+iX81q34HGubL08A+AwHAPol/A4VdaYm/N6OLyq+PAEIwAAACxaAD9eE32O+PAHgMxwA6Kfw u7sm/J69RSs++/IEIAADANyS8Lu1qJlK+J0oarkvTwD4DAcA+iX8xu2OpirhN/69ypcnAHyGAwD9 En5X1YTf2BO8yZcnAHyGAwD9En7r9vqNtd2XJwB8hgMA/RJ+lzfs9fuIL08A+AwHAG5FMI2LUW2J +/HehvB70JcnAHyGAwC3KgCPpTB6vqhltzD8nvDlCQCf4QDArQzAh7JQenKeb3tZUefqwu9C9jj7 8gQgAPsMBwDqQuquhViQqk3P7+keDb++PAEIwABAnwfgnZWAemEebnO0IfyeLWrYlycAfIYDALcj AMee2ulKUN14E7e3umGro14Pv748AQjAAMAAhODj87FAVXG9zUVNNcz5HV4ETeHLE4AADAD0eQBe VwmsM3EY8yxv45F0vcWy4JUvTwACMAAwoCH4QiW4HuryeiNpYatW3T6/iyj8+vIEIAADAAMSgHfU 9AKv7nCdbUVdqQm+8bo7fXkCwGc4APSnlUXtKepoUWeKuljUZIf/GfdMDYWh1ngYvy7IXgwXiwS8 +obLbgwbW2fD2boe39ZkmLx6/mJ53KpvK773Joo6V1QczbCtqBEfUyywZUWtL2prUbuK2p/+nzC2 2P6foNRNfvZOpNf9qaIOFLUzvTeGfUwALP4vO3uLOh/uvvvjYePGJ8JP/uRvhXe964PhQx/68zA5 +dn6kcG9WVvfeeOJU8Ot1pF/22rte7TVOvjvi1C8qvkGxja0WisuLZ7Hq/q4Jidb4Y/+6HI4c+Zj 4cd//EJ40Ys+EoaGpor6b8X7dYOPLubRiqJ2xy/7d95559887aFlF57/paO/vXHDi5/4/u/71vfv f+0rf/s9v/TTH/rQE7/455OXxmZaf/s7LaX6tSb/bOyz4x88eSnWf/uln/7wWw+95rf+7fe+/P/9 yhe94NcfGL7/Q8X7ZCoF430pEAOwSMR5rTvCnXf+VRF6PxQef/xSvwSHGHZne6XpJa3WI29otYZm BC/VwzU93QqHDk2FZzzj0+H++3+reA+v9lHGHK0uf/y86647/3r9V685919+7vUfnv7EbwpBSrWp 6U+8f+oXfu715zZvWj+2ZMm9f1K8h8bTe2nUxwpA71pVBN/fDV/yJX8afv/3/7bfQkIMsSe+rfsr nHx5q7VyXLhSi6hmZlrhyJF/CMuW/X146KH/mH7Qgm5sjqH3vvvuvfQtm77mtx9/z+FLQo1Sc69f P33kIxv++Vf+xl133fmJ4r11sqg1PmYAesv6cPfdnwxvecun+jkgxBAce3Qnl9VfYGao1Tr+Ha3W 2nPClFrEdeVKK7z0pZ8Pz3zmHxbv7eU+3mhjbVFjT33K/R/75f/yxgnBRal57hm+8v6ZH/7BbR/I gvAqHzsAt9/WsHTpp8P73ve5QQkIyyZbrS3vbrUee80X5wDH2vzeVmt4SnhSfVSvf30rPPTQp33h okZc3PD43XcPffKn9//wxZm//oCwotSCDpH+zdar/t33XIhTC4r33mNFLfExBHC7fv2/777PhPPn hQWl+rHe/vZWePDBKSGYJK5UezD2Ru36/m//A3N7lbq19Zfjv/rZl6x94R/ccccdHwsWywK45UbC 8PAnwnvfKyQo1c/1tre1wjOf+cnwxdXdGVyjxZfuD379P//KD1/+6K9ZtVmp21jvesdPffyee+7+ VPG+fMRHE8Ct8tBD7w8/8iOfExCUGoB61ata4XnP+w0ffANr/Z133vkXr9v7io8KH0r1Rl26+Csz X/K8Z//pHXfc8avBPsIAC+y++741fNmXffbqqrHCgVKDsVXSC17whfCc53yvD8CBsz3OO/yVd/6n y0KHUr1Vcf79d377S//s7rvvitsmWbQQYME84xmXwrvfLRQoNUj1+OOtq3sF2x5pUMTn+cADw/df +vC5E38nbCjVu/XavTv/qgjBE8F6DQAL4LnP/a6wevXnBQKlBrC+5mv+V3jxi3/AB+FAhN+TL3j+ 8z46eWlMwFBqEdR//ulXf3po6K7LQjDAfHve88b1/io1oPXOd7bCl33Zx3wQ9r1DX7bqS8Ztb6TU 4gvB9957zx8Hw6EB5s1wGB6euTofUBhQajDnAj/lKf8QXvhCX676146nPnD/n09d/nWBQqlFWHt/ ZMdf33PP3R8MFsYCmJfe338bXvYyIUCpQa6XvzzWj/lA7Esb7r576JMf/b1fNudXqUVc3/tdmyfv uWfopI80gJu1Zs1vhDe/WQBQapDrDW9ohW/6pvf7QOw7K++8886/+rWTb/qEAKHU4q7pT/xm60tG V0wW7+udPtoAbsbzn/+nYWxMAFBqkOu9722FF7/4sg/EvjJ8xx13/MF//Mkf+mPhQan+qIu/887W /fcv+Zvi/b3aRxzAXD396VNhYkIAUGqQ68KFVnje86Z9IPaVo5s3rf9DoUGp/qq3/l97P//AA/d/ yEccwFzdc88/WABLqQGv+CPYihUzPhD7xuo479d2R0r1Z3356i+dKt7n233UAcyNL/9KDXpNTn5x JWj6xanX7X3FRwUFpfqzzv2P/7u1dOm9ny7e68t83AEIwEqpuVT8LKAfbFi6dMmf2+9Xqf6u7d/1 sumnPnD/fh95AAKwUkoAHmTn33740QkBQan+rvEPnmwtXbrk7/QCAwjASikBeFBtW/7MkT8SDpQa jPq2l3/j5576wAM/6qMPQABWSgnAg2bojjvu+KPH33P4kmCg1GDU+d/4hdb9S69uizTkIxBAAFZK CcCDZOMzn/6QbY+UGrB6yVe+8LPF+3+zj0AAAVgpJQAPkoM7d2w9LxAoNVj15p/5P1ujz/lH7/MR CCAAK6UE4EFy6X/+3i//tUCg1GDVlYnHW0vvW/K54jNgiY9BAAH4/2/vbqAuLev73t8DAwzM8HYg yFF0jUoRKUmJogdTjCRYQxJtOQEjjVpJMBaNicQYQnKg4lGiiVjJCsdgQiM1nIhKFxbB6umYqS8R LbZqsJ26qJmkYx0KCknQTBSTfZ7fA9d4zcV9730/M8+8PfvzXeu3HJ5nv9z3vfds57v//+t/iQgB ngdOX7v20D8nAyLzmR/6wdMfOvTQg3/CRyEAEGARIcDzwBv/6Qt/5DNEQGQ+c/VVl0xOOvEJN/ko BAACLCIEeB7Y9LF/97tfJQIi85k7Pvquyf9+/LFf9VEIAARYRAjwSufEgw5afQ8JEJnfPHT/ZyaH HnrIdxY+D47ykQgABFhECPBK5kWnnPzET5MAkfnOD/7Dp0WAf8RHIgAQYBEhwCuZ15zz3B+4gwCI zHcuvui8yRMe95hf9ZEIAARYRAjwSubN//xnzlMBFjEIa/L3T3nSzT4SAYAAiwgBXsn8wdt+/Rc/ SwBE5ju3vf+aTIL+Ex+JAECARYQAr2Q2fvB9b/9vBEBkvrPx9ndO/t6TnrDZRyIAEGARIcArmbs3 ffbmrQRAZL6z+Yu3To4+6ogHfCQCAAEWEQK8knnwwa0fJwAiBHjyPcce/aCPRAAgwCJCgFf0Z7h/ /IvIA1s2Tg47dM23fCQCAAEWEQJMgEVkxcfnOAAQYBEhwARYRAgwAIAAiwgBJsAiQoABgADL7syD D066O++cdNu2uRZCgEGARYQAAwABXqGJ9J5wwsP/J/Xc57oeQoBBgEWEAAMAAd7PpPYTn5h0N9ww 6W68cdLdcceku/baSXfiiZPu+ut3vO3mzeX/oCbd6tXDj3n33ZPuLW95uFLsGo/PQw9Nuvvucx0I MAEWEQIMACDAy97KfOWVk+6oo74rtW2OP35YgIeu/datk27duu9K8uc+51qPfT3OPPPha3bbba4H ASbAIkKAAQAEeFkSKU2Fd0h86zzwQL8Ar1nT/9ipJtf3T1V5f7gmqXyfdtqke/7z98765pe85LvX 7KyzvEcJMAEWEQIMACDAu5wIaqnQ1u3M69c/nPy5/l2kt0+Ac9uhNt4IXG5z8sn7T0vvhRd+99zS Dr4nnzvPV1/zvD7eqwSYAIsIAQYAEOBdyF13PVp+L7744bblcpsPf3jXBLi+bWR4f7k2tQBffvme e94tW/rb0Ddt8n4lwARYRAgwAIAA71RSiY201lXfm27qv+055zx8m4hZ1qaWn2eo1VgB3t9SC3D+ vKeeNy3Xfa3nN9/sPUuACbCIEGAAAAFeFtEakt8ykClrdzPNuf75xo37lgCncr1c63UvueS753bZ ZXvm+PMa1K/Jscfu+WMgwCDAIkKAAYAAr6i0a0wz/XlnHmesAKf1eSliGtGODOY4kwykmnX/N73p u+uM69tmwNerX/3wOuRI/3XX9bdiZ4unSG+uRZ7z3HO/e27589VXP/z7tIjnuepW8OVIhotlynZ5 zuyrnOcs/51j994lwARYRAgwAIAAL1G06spixHBn1+aOEeCsM07rdKZEb9gwe/Jytv7pawHO/V/+ 8uEhWmXQVpJ1y/lZZLYd4pVccMGjp2CPmYBdZ7knM0es63PNlwC5XnU12PuXABNgESHAAAACvIRE CmvR2pVKZi3Ap58+vTKbRGCHHitrXPtktU0qvPVWTH0CnApu3cLclyLJRbz3pgBnLXV97qUin/Mc GkAmBJgAiwgBBgD/ePKP/8n0tbz1hOGdbX3uE+AhIayFe2iYVCuA2ZM4a14jsrl/2n/r37/lLdMF ODJei2NamNP6fMYZwzKeNc75WW6bxzrhhO/eNq3J55//cCt1ziHV2nY99K6kPq62hfvUU8et0xYC TIBFhAADAAGWZp1rkamIcF8ldXcKcJ9wp/26lryIZt9637Qpp2Kd27zkJeOmJ7eTrbPncfndaadN P7cI856YAt2ux841rX+fcy2/S1Xb+5gAE2ARIcAAAAK8xMnPqWLu6uONEeB6bWufAKf1uZbSvvXI kd+6StongnUFuCQSW98mYl1XdceKabtmeDkr8vXgq1rs87u0Zue5y+9zDbyPCTABFhECDAAgwCNS tz/Xa2B3NrfdNluA6/10WyFN6mnL7ZCstBnn/nX787p1/WthWwHOFOVhMZrMfK/UArzcA6/6quM5 x6yXjgTXFfF2ENjODiwjwCDAIkKAAYAAz022bNlRplJhXM723SFJjIjWw6na30do2ynSfeJbbpP1 wn3P00pjqsa7IsBZE7y7BDgSm2tRzn0pGTp/IcAEWEQIMAAQYOmZdLxcW+qMaROuK7OpGNe/SyW3 /C4DpiKtdUW4ble+5prpewFHjmcJa6R/rACPae/e2dTri2clr1W9bdW113ovE2ACLCIEGABAgKem HgA1a/3rzgjw0KCoWoDbAU/tPsI7I759ld0M++q7TS3cSxHgoS2edjaZYj0ku1mnndbofFlQ9jx+ 3ev61wkLASbAIkKAAYAAy4gW6CJXY7JpU//tx2xxNFaA62QbpMj1Uta71vfP8S6nANft2cu99jfr sjMILK/PmHbsbJPk/UyACbCIEGAAAAGekXri8NVXj5tSnL1xSzV269blFeC0PNdCminQH/jA0gc9 tWI7bXunsV8C1Me2nALc7sWc1u9Z97nrrp3/8oIAgwCLCAEGAAI8l6lbaTOAaahSWlqm27bkVCqH BHhI5GoBbodgpbW57O17wgnjBnNFjiPbeb4iykup7NaDp6YNlKofczkFOC3d9bFm4NeY+9XHPdTi LQSYAIsIAQYAAiyPJBXcuvqYNaeR0rLGNkIZ8T3//Ee3Jac62wpqqQ4P7fE7S4CT+rnOPHN6dTPP nzWwbUV5KQJcT4u+6aZxArxcQ8OStHeXx83Ar7H3O+ecHa+T9zMBJsAiQoABwD+e/ON/RlLF7dtf NlXOdtuhesJzX3W23uN3SIBz32kCnCp0Xd2MoF9yycNDoNL6m+nVWQMb2a7lPcdc1s2m5XmsAGfI VLld9t2dtu557GOOTfZerh+zbQmfllR96/tOWzMs/uFEgEWEAAMAAZZKpoZkt53C3CetSxHg+jZD jxUpL63QYxJhbtux69+nejt0zGmdLreLVI8ZgrVcFeCLL975rZUi+fU1mva6iH84EWARIcAAQICl GfKUtto+EU6785jth1KpLffJ8Kq+26SSm8ptWn/bIVrt8dTt0kPiG4nsE9xMR85tcj7T2qgz/GvW 4K5226jlajku20blGDds2LXtk5ZSPSbAIMAiQoABgADLI5XFyFQS6VvKhOEIbQZrpZV4qZObh5Kh UNde+3ClNoKalH1xpwl5jj+3nVUZzeOnsh0pnyahOZ+s0Y2457mX84uHacPHZiVfNOR18t4lwARY ZL/Ilk0fmmz+4q2LeXDrx10TAgwABFhECDAIcF8euv8zkwtf/ILJySetn1z5q6+YbL37I67LfpDL L71octr3nTRZvfrAR3Uznf79p0yu+Y1fmmy791OuFQEGAAIsIgSYAEvJm6541Q7ytGbNwZNLXvVT K0qEL3vthYuiGDG8b/OG/f58PvfJPxw1z2L9Ex472Xj7O73PCTAAEGARIcAEWJJUf/vkKSL8khf9 2H4vUBH5+rze8oaf3+9fs7wm3cihjhH/m//gN73XCTAAEGARIcAEWIYEuM6ppzx5cuP1b9wvzy9r Yo868vDt57ISZPC291+z/XzOeMb3Th7YsnHx52l5vvNj755cfNF5O7RG588qwQQYAAiwiBBgAkyA KwHOn1/9ip9crP72iXBkK+23+2PLcKTw+muvWBGv2Q3XXbn9NTnr2U/vvc0nPnL95PjHHLP9dlkv 7P1OgAGAAIsIASbABPgRScoQrPws62Tz52OPOaq3NXqliORKFuAiwfVrt+mzN7t+BBgACLCIEGAC TIBrAS5JS22mCdeVxJIMynL99r4An/PcH5h62wz+Kre96V2/7voRYAAgwCJCgAkwAe4eaYEeWkeb bXfaLXf2hARnj9u9cV1SBc+62VRNs1XUvvSapQI/6zUrOfNZp22/7f66jpsAAwABFhECDAK8LInE jpWprKXN1jq1BF979aWjnucD73nb5Pxzz168f0Q6/5vq5Ot+4aWD64ovOP95i8+R/x2zL25um8nV 7e9SxR67tdPdn79l8twfeuYO57hu7WGLxz5mkFSeo+zRmxbyDOA68UmPn5z7/LMWxXU59uZNpX7M axZxrweA3fHRd3nPE2AAIMAiQoAJ8PxmrEzVgnfySet3WBM8bW1pqsfPP+fZMydNZ6/eVt7q32/+ 4q1Tj6muTtd7/dYTk2edX9bMRnanHWdkfKgiHMmvhbMb2Jt3V9fi1q9ZZHvodtdd82s7vE55Lbzn CTAAEGARIcAEmACPFODSllwPyEp1c6gCWbfglmpqJLBvwFYEsr5/pk6X373pilcNHs/VV12y/XaR 86H1sqnsDj1GBLs+pohsBkzl+FupjVT3bU3Utoif8Ljjtle865/v6kTml7/s3MF12yUbbn3HDjI/ 9rUlwAAAAiwiBJgAE+AmGahUS11ah9vbpKpbi29ktK6e5j7ZdqncJm3GQ2td00Y8dCzZp7jc7i1v +PlBAZ52fnXbc8S7bpfOMaeNOiKbtNXo3LaW5FS86+uRtufsP5xzKLe569PvXZZ12/UXAznOVLHb vZ1zbHtrLTUBBgACLCIEGAR4vxfgpBa6VjwjXGU/4UhjxKzvMSKG5XbtROO07NZVzL41rFk/XH6f 52nX+dbV4aHzS+W53CZV4CFZTOtyXyt2LfGR374W6bRl5/y6ZViPm8p0Wz3vq6iXLx6Grj0B9jkO AARYRAgwASbAI5MBVt1AG3QZSpXkdn3Dptq1wVmzOq3dN6I5bYhXW0Fuz6/vOJK0JJfbLHWP40h6 EfjIZivgkeGcVy2oaY3elcnSbVv5tOSajBn+RYABAARYRAgwASbAI/ejbde1Fqlsq7KpouZ52nWx Q5OeUymtq5y1OKa1uBbLvinNF1903tT1svXjZ73uUsW0rh7Xgp5jy/Wpq+TdI+3IuzqNuZ3EPSt5 zrHTugkwAIAAiwgBJsArNnUVt6/COlaAI2W1/HXN4Km0KqdK3MrZ8Y85ZmbVtV7jWw/Kqtch5zaz 1sv2SWC9TnnaoK2h1PdPq3HOPeuFc1591dhp06x3RoCzt28GcCW5NmlFT2W9VKXr9G0RRYABAARY RAgwAZ6b1II4NFF4KBHKct+sS60nKnfVmth2X93ukTbgiOKYfXHrdbx1m3O9Fravfbo9vwh7+/t6 Xe7ODKaqHz9t3+1a3FS6I/5Dex3vTOp10UNC/cCWjb0irhJMgAGAAIsIASbABHgnBDgVxb7qcSqh 3UA7blqC22nQs5IBUqVlOpXNyF1aqbuqxXdIpGcJcN2ivDPXr0/ui/jmufumYy+TuM3cH7lU4+vX aVe3YCLAAECARYQAgwDvt0lFdWcEOBJaVyIzzblvMnMtXu0+v0tJ3T6dlul68vLQcKsxAly3E+/q cRVBz2Cu3Tl4aikC3K5TrlvVCbDPcQAgwCJCgAnwXKVuI17KGth67XDafusKbOS4q9b4brj1HaMe My3IQ23ItcRFpustlqZJ4CwBriu4O9MCXU+hzsCtVKtn3SfX6sO3/Pao9u9dFeAMBqu/qBgaNkaA AQAEWEQIMAGeKwHuE8ShvXvrKc59leMznvG9OwxqmvWYmYycx0zu/Ni7H/X7tEwPDZYa2+Ld7lXc btc0a0hUxL6d4ByRLfc//ftPWbzNtMfIeZSqcbt11HIKcH6eKnn9OkWE0zrufU+AAYAAiwgBJsAq wCMqwBmiVEvVySet761kRnprUUt1dMumDz3qdhGySGhdpcxE41lV566avLwra5wjivXE5BxnK7E5 v9w3a427ZpBUhDbXoKtajFOtbtc4Z7/g/LzewzfCvKsCnPPPOaTSm9bwVKTrfY27qjW7blMXAgwA BFhECDABnmsB7h6Z2hyRilCVRGYjn+2etpHWaW3DabfteoZg5TmTdmJyEkEcGpCV5+qadcXLMeQr leH2vFKdzX1TYS7iWxLJrO+finUt8OUxUgXPeeY4232P899Dor8UAR6TSPmu7j1MgAGAAIvIvObB ByfdYYf9rY9DArwSUk8IXkrSjjyr+hqRrdfITksqlJHsWetiUzXtZmx9NLRV07QW77oVelqyZrhv nW8kuB6oNS0R4lnXblpaIR9KtppKVX9n1xoTYABA1x144N91Dz1EAETmOXffPenWr/+2D0QCvBKS 1tzsF9vXNjuUVHb72pmHkqnQaS1uK8iR3lRI8/xjpyankpnKceRuzH0i4alo3/SuX59521S724p4 qdZmv+BZU6wjmpHyPEZbEY4cv/xl544eCDYtqci3FeVcy7Rip3KdiraKLwEGgOXhuOO+0W3eTABE 5jkbN06600//Cx+IBHilJXJ22WsvXGxDjrCVpOqaVuBUU5civkNCmjWru3OboF1Nji3DrVIxTpvy mMnOQ/sX51x3RwU265Tz2Lvr8QkwAOBhnvKUr3af+AQBEJnn3HjjpHve8/7cByIBFhECDAArm6c9 7fPdDTcQAJF5zpVXTroXvvA/+kAkwCJCgAFgZfPDP3xld8EFBEBknnPGGZPuV37lMh+IBFhECDAA rHSO7Y444m8NwhKZ09x336Rbu/bvuve9b52PQwIsIgQYAFY+J554T7dhAxEQmcdcf/2kO/vsLT4I CbCIEGAAmA+e/ewrurPOIgIi85Z0fpx4ovZnAiwiBBgA5orV3fHH/9XiViikQGR+kgF4T3/6Az4C CbCIEGAAmC+e9rRLu+c85+9IgcicVX9/+qf/uQ9AAiwiBBgA5q8KfMIJX+muuYYYiMxDLrlk0j3z mX/qo48AiwgBBoB5ZX139NHbujvuIAciKzk33zzpTjjhr7unP/1YH3sEWEQIMADML49//LndYx7z 7W7LFpIgshJz112T7uijv9OdddZZPvAI8P6ea37jlybnn3v25O7P30KAljEfvuW3J9dd82tzdc55 D1179aWTK3/1FYu569PvJcAAMEcSfEV33HF/s/gPZcIgsnKSQXdHHfVQ94xnvNIHHQHelUSOjjry 8Mm5zz9r8rlP/uFeOYYtmz5U/sE/d7K2OxPxK9d18xdvXfHn++DWj08uOP9528+55Jzn/sCjbnvf 5g37tBgTYADYFQ499Ce7deu2mQwtskJy002T7ogjvtU98Yn/yAccAd6VbPrszY+ShQjEnhaD295/ zfbnT8WSvC5P3vKGn1+8pmvWHLziz/Wh+z8zOfNZpz3q/Xzikx7/qPfUnR9792Td2sMWf3/DdVcS YABYoZzZrV379e788x/stm4lECL7Y+6+e9KdffbfdMccc8/C3+mTfawR4F3NTe/69UcJQ0lkImK6 J0Ut2Xr3R/ZrEUul9bTvO2mxor63jyXHkGt6xjO+dy5a6Mt76KxnP31qN8Nlr71w+23TKk2AAWDl sq5bs+bN3bp1f9VdeeU2a4NF9iPx/cVf/HZ3+OEPLsjv5V0mvYMAL7N4vuRFP7ZYKWxF+PnnPHu3 S2lpW00r9v4uYm+64lXbr90DWzbu1WM59pijFo/jklf91IqW3233fmpy/GOOWTzXfPmQ/57V+ZC2 6FyXVI4JMACsfE7sDjro97uDD/7L7uSTt3ZXXfUXi+3R+Uf2tm1kQ2Rv5sEHJ92mTZNuw4ZJ9/rX f7Nbv/7r3WGHfa079NBrF/7uHu/jiwAvZy588QsW/6G9evWBi/8d0Y0UtCIcubjjo+/abccRaSlV 5/1dxvJFQrlue1OuUokux5FK/0oW4A+8523bz3Xj7e80BRoAMEiqSGcv5Le7NWv+eCH/ozvggG91 A+1wIrIHsnr1tgXZ3bzw9/FjC//91i7LF0CAd1PSGpvnPfmk9Tv8PCIcOY4Yl/dm1kzujiFZkcQi 3K9+xU/u9+KS9tu+a7qnc/Mf/Ob21y5DxlayAL/8ZeduX++7J593d3ZGEGAAAAAQ4N3UIju0XjVV 30hFEan1T3jsqLbeiHIELMljTGtJrScVT5sAHVHO8KI8Zip++fPOVFiX2pac48vzJX2TlHN+2Won w5RybCc87rjt627zs/wu61Onbe9Uzi2V2jxPrt/Yc8vtcvtUPpNyfq/7hZduf82WuoVQzqG9X849 mXZcee5WCjNtOdcl7fbXX3vF1PunNTnnn+vwiY9cvzjVecwx51hzrhdfdN7oadFDx58uhLx20547 5/DcH3rm4nPurnXyBBgAAAAEeBmTf+wX8YwsTatypZpZbjttPWmEr8hInaztjQDNqlRGAvtkI4OK yhrPOhH4SNUsGU+FsBb57pF26wjXkOBEWovM1qkHLEXs+9ZN96WvIpznyXUpX0R0Tdv5tAnFEbTL L73oUffN8US6i6BlffXOtHDnNYsMRyrr58jP+76oyPspXQJJji2y3HYRJH3vg0xpLm3w7bmkK6CV 5kj11Vddsvj4dct5jjPHV1/z3LYd/JZj6hsMduP1b9x+36EvhXJuZbhYtxunlhNgAAAAEOBlTCqX 3ci9dyMzRfTyv61U1G2o0xLBaO8XiSu/b6tuEZ/zzz175uP2SUgeq6xxHkqEKSLVVkD7ZKwV+nL7 PknuS46lPb4iqdOSSmjfvsn1lxLTstR9lcsXGDnHVl7rtJXPeh1uBLxsMzTrOtTTm4eSqc31fcZc t+6Rte1t5T1D3fK7U095cq/E19c159R+GXT6958y6osjAgwAAADsQwKc6mL5h/yGW98x8/alpbbr GaoU4emqadKlQhpRzvOU6m0rP/VWPX2tuqk+lsdNJbDITAQwld9S7cvzt3JZ9oSNBOW+pRU7v8vx l6pmZLduwa0rzTmX0mqd3xWpq6uHecycb65hXRlMO3JpG+5rnS6Vyxxfrm25Tc4tUlieqz23WtKK wOf5c/88ZyuHS1233YprrkdehxxHkcckU5SHvsjoqgniqfDnfVC+KKjblOuKa447r1Gudc4x8lnO M1X3vvdMXv9yvPnfvL9yHDnWTOPuG9xWXvd8sTLUMVDEP10Dpfqcxyrvjfx+d2+fRIABAABAgJcx tdCOGZKUSmRXVfjKzyOIRRgiHe39UiksVcVW5pLSmty2nKaq202pYkaeisy0bdCl8ptqdd9U4EhN keciZBHjciw5n1byI9/djKpqGYCVKuHYAVXt8+TYcj7l3NqqeTm3HGvfEKbcv5xHpHCp2wnVApv3 SLt+O5XTIt99Ulqet60Ql9+VinuOvbwGOae2zTnCWSrx+bJg1tCxMRPE8z5vj6Mv9RcvEd18iVM6 ICLBe2LSNAEGAAAAAV7G1FW0pW6rU4tsEZC2SheBLb/rHlmP2Q6gqtchp3LXtzVSLT+RpFQG6xbl iE8tabPEuW3/joy2Xwj0tWrX1coMxmp/nypn+SKgPZchQa2rofl5nqMIZjm3WgxTnexGbPdTBG6W iI99jfsEvH2/luPONWjbtvP65OcR41LFryc3169fvlCpZTrCOW2AWKnKjtnruP7iYdr1i5zXLf/1 e3jasRBgAAAAYB8V4FKVbcV1zLTmUj2rhaxMLk61rF1Dm3bTvmplXVWu11sWiY00pWoXQUolrh1k FRlr1w2XrZ3q1uahdcd5/Nw/j19aadO223efrEPtplRVU8kdI1dFwiJWuSZ5/rQ818PDclyR2Pbc itjOqnaWazB2KnLf61G+GBgjwHndZ8l/adMuXxYUsSyve/63/sKknOc04cz1KbedNjCs7Xoor/u0 29Zt/eXvyVIniBNgAAAAYB8Q4LryOqZylqQttxW8IpKRzUz3rdfPRjLq9cB9qQcg1aJTJCvS0U46 jjhF7PrEqK5g5rGHnrcIetadljbtbmDwUUmmKXfN+t86WWdcznvatk/lcVLljFTXU4vL1OMh6SuS PO3c6nW809p8Z0l830Tu+vizprfvy5G+oV1D68/zuvZ9sZEvIca0GecYl/K8ZX30tC9HSgW4rCHv lrBOngADAAAA+6AA5x/z3RIqZ0kRgkhLacvNIKSuZ0JyxK6v4jtUTWyrqnUbcFe1wmaNcd8E6j6B GxLvDLNqJbmu9g1V+Up1Mq2706qus+Sqb5uonFu+QJhWYazX507beqde5zok80OJMJf7Dl3n9suD dgL0tNen/bKga7Y8yhcbQ1tTzXq9x7zfyhcp07aGypcPfRO287Od2XeaAAMAAAB7WYDryuuYKcF1 hbReG1rLXKp4qeZNq34OyVTb0ltPIs5tIuljHjeCXO7XN3m5nr6clCnBQ+ta+4Z1Da2NLVOOh/aP bYdBdY+s0Y3EjRGruro9TWzrLzeWOgG6tFgPrQuvB4HVA88i790S1pPXX5yM+WJj1us9ZthX3fUw 9BqmolxPes6a7LoSPLSXNQEGAAAA9mEBrrfgmSWW9dZAkby6SlkqZUNbytRrNdNqXYtbvW40FcH6 9u2E5mmPm/uW9tQiYklfJbHe+inSVMSzFuAhGZ02yboW23arp/b6lnNu97bta8PN+ZfW3nq9a992 Uu1a5W5kVbSvyj1UxS7tz2Vt9tj28DZlO6V8ATBL/nO9h7YcKu/jWVX3dr16X9dDvoiot1Qq76m0 d5fXLD8fMzGdAAMAAAD7kACXFuNZ4hBpqCtibettLdJ9k5OLQJeKX902WwtJu41REbG+7XTqal0E qhbwoUp1qXoXkema4V+R825Ke3HEvQxtGmqBLtJeT14urdW1wJVjriWr79zKa1Q/X2mz7nomVeeL iba1eKnvi9IinOeuv0BIdbbeGqhdN17OaZqYD+0ZnC8t+iQ4olneX6m+9z1O+/pPS92m3a4Xrr80 yPu9nfJd/35WhZ8AAwAAAPuYAHfVoKrITIQrLbZJ/vGfaliqerUw9g1eSgtxfZsIdSbtRvwiY/Va 3tyultl6qFY7cKneyqh7pLJYHjdCWK/RjEiWVuZ6i6Ek4h0pK8eR+5W263pacd02HAmMlKVKmHNu hyENfWlQTzDOMdZtvnUlu1632j3S/h3ByrnlWOvjz7nVbcy1xBXZzn0iZXXb+M4IcCS3vX8es12z 3G47Vbesj20RTmW6Pt48R94vuQZ5P9ai3w1sZ5XXunwpMVSVH7O+OY9dv7Z9VfNU3+vrMG0NNgEG AAAA9jEBrqV1ViIqQ9Xdsq1PvVdqXyKHRVLbqmvdilwnVdNZxxnxa1ud899lPW4rrrV4tRJT2nj7 kqpgLaZ961Vbse2qtdHteuSI4phz61vHXLd5dz2DpIqw11Oax6TeG3koqbS22wft7NCtVGHr6d59 yWs2JJv18Q51CfStF273Ri7V6L5zq5Op1H1faBBgAAAAYB8X4FRc84/4aeIaUcxtxqx5jFhGMFL1 TJU1yZ9TmWvbSetqZgSnbX9uhy5FUMrjppKb9aN5rmn7w6ZCmQpuJDuJpEeya2lqZSe/TzUwsh55 TEtznjfyn8cra6FTCRwSpUhwqpe5Tdq9pw0Fy/Gn8pvbRZJzbpHeCO7QAK+6fTxV5shc7pvjzP3y OkTO87v2C4dZqSuheaxUZPO4ud45zqHHy7FG5nNtljrIKm3bqbLnOXL+OZdcjzzfrG2NSnv5mD19 SxU3EttO2s7rPnZYWHmPL3VtNQEGAAAA9qIA11IQEc0/7CMUSUQo8rGUac77S0q1r60CLuV6rcTr Ulfk86XIUu8bIRwjocuZVGy7ket/98cQYAAAABBg2elEXMtAr3oLH9lxa6IxE5X3haTanMr+nhZv AgwAAAAQ4P2m+puW2T3Rwrq/pXw5kLXQrgcBBgAAAAjwPpys7exbO5vKb73tTruFjzx87bpq/a9r QoABAAAAAryPJm2wpYKZ4V0ZqJRhVpmIXG+3k/9eqS2zu5J6OFjail0TAgwAAAAQ4H14PWjfPrhd tQdxphqT3/5kYna5Vu22UkKAAQAAAAK8jyXrerOlUiZZX/jiFywmf842Rkvdnmfekq2qMvwqXxK4 HgQYAAAAIMAiQoABAAAAAiwiBBgAAAAgwCJCgAEAAAACPM+55673Tf7D779m8t8/8Ts7/Pyhr31q svnT/2rxf+ftmnzr3o9Pbvy1501+66efOvnq599DgAEAAAACvPfyja9smNx58+sn77niRye/++pn Tm543VmTD//2z4yWla996QOLt4/gXPljR0/+xY8csfjnP/q9V0+2bd048/65zcf/9WsXn/uqcx8z +bUfPmTythc/eXLLW164+Niz7v+3D3xmsuG6iydvfMGxi8/9F3/6ob1yHf/qzz+y+PyXPWf14jnk uhYBzPnk5xHBXX2e+//7Byef+sPLJh9820sm7/+//8nk/3vHz042/dFvLV6HffH99fu/+OzFc0/y mpZrkvdH3ms5h2nJNct74wu3vXnU833u1jdN3nzeYye/8cLHj3r/EGAAAABgDgQ4EhJxvfwfHbZd UNr8m6t+YlCs8vNITGRv6P6RkHv/678ZPIb/8u//5aK4Dt0/x3bXh986Vb6vveh7d7jPtOfbnfn0 ey/f4TiK/OcalZ/lS4ZdEezcf+haRbL31rkP5T/d8oYdjjGinp/nC4+h8xjK2//ZSTO/CMmXAvV9 cu0JMAAAADDnAvzlP/7dRTkdIx63X/OyXtlIZW6suPRJ9Cdv/OVR909Vta3k5fEiUa2857/31jWt 5TTXtvz8ulc+ffvPc84789gR21THZ12rPO++0madLwDqY373r5w9+GXBzr4P6y6G61/zrB1un+fe W90ABBgAAAAEeB9J2mfbqm1alyO0kbj8uRXQ9jH+7W9e8CjZSPUtYpPflVbgkrSl1vdPJbD+fY7n va9/weKxpZ25lfO6chr5TetsnySlGry3rmvabstx1K3OdYX7Sx+7dqda1OvHTtISnPbgXIf2tSxV 1r2dvI71FxNp3S6/S8t9fcxpmc859SVdCO37p/1yoLSY19Xwfan9mQADAACAAO+l1HIaeUqbaF01 TKtt25Y8TV5T4WzX+qbCXN8m60Drx68lO/Lcrjduq4c55lJFzoCpoSphWWO6p5NKY30cpdIbea1/ Xkvg2NRtvXm92gFbrUymMr6332O5HnV1PuuUp32BUtZLL0dlPO+1tPcbggUAAAAQ4O1DiVJdGxp0 lbblWlDr6utbL1i//Xf585Bs1FW5+jFSuayFbugY2vWc5XaRyCLxOYf6NqkgL3VdbdaptlK51GSd cn0cf37nDYs/z+TnaZX0WckXE/UXFqmSt7fJdamfO0I89Fg5zgyTGjMwKxXUXJtyLktJ3R6f1779 giQV3/oLlBzblv/8B4vPV5KJ2rMq423lN6K9rw4DI8AAAAAgwHtxANbQ7yI87SCsesJu/btpLb1t m3KpDNYtu5HcsUOlUlWu5SeC1opnJGop05TrSvQY0ctzprqbaxKRz/GnIp71qX3V6voc0p6d446k l4nbeYwI69C63UjgLMHPz4auU536y4K0J087z4h7eZ3yv/miYOx1bTsE2vblyHC7brltmS95xytO G3zuerp0kmttGyQAAACAAC9pH9u6pbSt0NYDnWZN5W0nFrcTkZNpQ4raCcJ9Ylc/Xo51KQOg2sfP f09r6c0Qp2nTquv1uX1V7LSVD03cHpqW3VZ3U/EsldF8iZF251oeU5Hvq4C2LdoR77Hrd5MI8djB V/V65fpa1JO/lzr9uX1d27bvsk44x533RL4Y2dm2agIMAAAAzIEAp5LYVuLqCm1bucsWStMer644 ptKan6WiV1f3pt2/leW+6m4t2bOEfJYAD20hNHYCc991aauU0xJxbFuFI7N9zx0RbmU6XwAMVeRb Af4Pv/+aqdemXqOb5xm7prZub8/9+gZRta3t075M6Kt8RwVmrOQAAA5ESURBVIbHvB55nDzXvtIS TYABAABAgPeBpPW3FtN6knEtD21r66xpw/X6zLT/RlzGtj/3DUpq5bBdS7rUPXZTIYyg5jGGqr9p v21lK6Kd50pFuE/WUuEs9+/baiqim7W8ub7t/fu+VGjbzoe2ippVpU2bdo49/ztLCiOuqfbnfTF2 cnXbjj605VO7bjfvibzW9RcQbYW3HqLWtnzPyqxqNwEGAAAA5kCAI4BpHW2FoUyGbm+fdtux7cup GLYtqmOHNfW1W0caZ020nlXV3JnUw5zSwtzKYNYRtxOzy3Vpr0FkuB1AFelrW5j7KuHtVkd9ab+w 2NNTn+vr0Nf63DcVO+c+NICsHsRW76tcf+kxNrMGahFgAAAAYAULcKqUrbgVcRmShboiGyGb9vjt NkipsLYV5KFhTX3Tj/uqu5HPocrrciQt12Mq3nXbb67p0Prdvgp2X6W7/l0qwu1rFAHMdk/tfs3T qq67O9e/5lk7tLsPfTmSLwXK+y6V9WlV67qFvghwKtPt/tW5RnmtIv95/HxJ0VaZ99Z1IcAAAAAg wHs52Sqmb03prFbXWvTqityY54istmtu+9aHlrR7/fZVi1uhHlrDu7Opq+PT1iunvbuvVTfV3jHX q70uQ18iRPbymPWa7HYwV17HPf1+ajsD6mMcqhbny4qhLwRK6rb8SH9fa/TQ5O56+6kxU68JMAAA ALACBTiVsLbdOXIwpnV2KQJc7xVc5KUVvUjx0P3bQUl9FcX6XLKWdrmvVX0Okbyh29WV6npdc129 zZZQY16Teq/gehupnF9fZT6vWz11ua0g7+6kyl23Zy/Xetuh/Y/r7aaSoeFcbXdAX0s/AQYAAABW sABnoFM9dCmCMa0NeZoA16I2q/25rM1thzkNVe8iP2PWk6YNuJXspax/LpXboccfs0VSO125nlZc rx+OuI3ZLzmtxKVVuBbLafevW4WHBDjXKo+XKvK0yntpMy7yX+8B3fc61a3G+VJk7LTopU7oLnsJ 1+/BabLfvgczoIsAAwAAAHMkwG31bKlS0O4NW+8PXFck6+FVEe6Id19b6tDQqrZ9emhtb/08kc1d OZe2Gp1jrn8/VAFuW7XrNvJ6iNOn33v54ATuPtFrr9VQW3Gud70WuG+IVrsWedawsFRbx0hm/X6K XA99odHuE5xznDaUqp28nT+XfYDHCnB9uxzbvrAnMAEGAAAAAd6Dqat1+XMGB0XYUm3L2spIYZIq Zt962nbNbda71q3TkZR2qnS9rU9b1UyVt21tznHUt0mVduh86ipxBkktpfrYilRfO3bdghsJa2+T Smm9/reeNpzrUp9Hn8BGcmvRy2tSrmdbAR1aw9puCZRK76xq6rR27rEV5cjuUra0asU217ZPmHNN 2wFW9ZcH7cCwvsdI9Xd3tGUTYAAAAGA/EuClbh3Ttr9GcNvJw2l7jWBkSnPffrmlctfX7lsGO+W+ eYxWfCJJdZU5AhXpnrYl0NhhR3X1sq9q2rYwl2ONYOY5ch59x1EqjRHh9ne5HhG4PHc9Nbmca76Q GJpAneeKZOYLiwhe/jf/XR9DHqOvvbmuUuf2fZX7OvVgrdKS3Vad69cqa5DHfPnQiniuZ9bm5ouV VIXzfmv3RW4r+20bfY6jfFmTY8hz1F9c5M/T1poTYAAAAIAAb08rsO3E36FEhvtkrB2aNJTcpm3R bgdj9SWSOXY9dGQ2QjokSJHYVshmZUjUpmVoL9yl7Hfbd73avYTzJcPQnrt1IpSR0VTv+1qH26rz 2O2ncs1rOZ2VVKJbsc5/923/NHRNlntrLAIMAAAA7CcC3E4LnpWhwUt9e9PWSXW0rPvtS0Rtmgil Itu3P+wY+R4aVrUr+yVPO9ah9bdjvyhIC/XQetiIaFsVH5L+Metvlyt1pT/V4qVez1lfKkRc894b mkyex5j1JUpel6F9mwkwAAAAMAcCnOpZ2meTtNiWymeqfPlzSX4/q002v4+kpCU5lbqIUFqD6zbe WdXADGPK/XL/tNqmGhtpmbYlU6rK5RzazJpuvCvTszOYK8cYyY20ZlBU1vWmQp7f5djr9cy51qlY JxH+/D7nmfvnf1N9nrXvcmk7z7rofKmQdvPIeNY+R3pT0Z11vZY7dRt837roMYnw5/rVXx5EaHNO +XJlzOuY17segla3Y+d9Oe0LGAIMAAAAzIEAiyxHIrCptC/H2toI9a7IaqZK53jyxcu+KL0EGAAA AARYROYuBBgAAAAEWEQIMAAAAECARYQAAwAAAARYRAgwAAAAQIBFhAADAAAABFhECDAAAABAgEWE AAMAAAAEWEQIMAAAAECARYQAAwAAgACLCAEmwAAAACDAIkKAAQAAAAIsIgQYAAAAIMAiQoABAAAA AiwiBBgAAAAgwCJCgAEAAAACLCIEGAAAACDAIkKAAQAAAAIsIgQYAAAABFhECDAAAABAgEWEAAMA AAAEWEQIMAAAAECARYQAAwAAAARYRAgwAAAAQIBFhAADAAAABFhECDAAAABAgEWEAAMAAAAEWEQI MAAAAAiwiBBgAAAAgACLyErNg1s/PjnkkIO/7SMRAAAAK5lt2+79FAEQmfPc/flbJt9z7NEP+EgE AADASmbzl7/wb+8nACLznY23v3Py5PUnfNlHIgAAAFYyG2+/+bf+lACIzHduvP6Nk1Of+uQ/9pEI AACAlcx7/p+3XfYnBEBkvnP1VZdMTj3lyTf5SAQAAMBK5q2/8MoL/iMBEJnvvO4XXjp56lOe9Bs+ EgEAALCS+aUX/OgP3kEAROY7F774BZPjjzvmlT4SAQAAsJJ58ff/g6eoAIvMeX7wHz7tbxc+D87y kQgAAICVzKmHHbbmKwRAZL5z1JGHP7TweXCCj0QAAACsaFatWvVn/+XO93+TBIjMZz7xkesnj3vs cff4NAQAAMA88PZXXnT+F4iAyHzm8ksvmjz1KU+83kchAAAA5oEzj/ueo+0FLDKnOfmk9d9e+Bw4 w0chAAAA5oHVq1at+tqWTbc/RAZE5iubv3jr5Mgj1n7TxyAAAADmid+74tKXf4kQiMxXrr360snf e/ITbvcRCAAAgHnix5/0xMf9N0IgMl/54ec84zuHHnrwT/gIBAAAwDyx5sADD/jqn9xx09+QApH5 yN2fv2Wybu1h2xb+/q/zEQgAAIB54+dOPeXJXyYGIvORf/ZPf/w7xx37v73VRx8AAADmkdUHHHDA lzfc+o4HyYHIys7nPvmHkyMOP+wbC3/v1/joAwAAwLxy3vGPOfZ/EgSRlZ3nn/Psbx9z9JGX+cgD AADAXHPggas+c/21l99LEkRWZu782LsnRx6x7uud6i8AAADQnXn4urX3bbv3U2RBZAXmWc/8vr8+ /PDDXu6jDgAAAHiYW1776p/SCi2ywnLb+6+ZHHH42nsW/o6v9jEHAAAAPMzxq1cfuPUD73nbX5IG kRW37dEZPuIAAACAHTn94IMP+vqf3HHTd8iDyP6dB7d+fPKk9Y/7xkEHHfizPtoAAACAfl50xOFr v7b17o+QCJH9e+rzN444Yu2NPtIAAACA6bz+5JPWb33o/s8QCZH9MFf9i5/71rp1h32hs+4XAAAA mM2qVatuPu+fnP1VMiGyf2XDre+YHHroIfct/DU+wScZAAAAMI51Bx20+s5zn3/WPSrBIvtHPvi+ a76zdu2av1z4+3uWjzAAAABgiRKcSvBTT3riPdYEi+zbefubX/vgmjWH3NuZ+AwAAADsEq8/8oh1 pkOL7INJh8bPvOQf33/IIQd/eeHv6nofVwAAAMCu86I1aw6+/9ab/uU20iGy72x19AP/x/fds3r1 6j9a+Du6zscUAAAAsHycvnr1gVt/+TUvvW/bvZ8iICJ7MZs+e/PkcY897p4DDzzgnZ1pzwAAAMBu 4fgFCb41LdE3XHflN4mIyJ7NfZs3TF78kz/6lYW/hw8s/H28yEcSAAAAsPs5M1OiU4H66G3XfYuY iOzepOvi9Zf97P88+OCDMuX57Qs5yscQAAAAsGc576CDDtz8tNNO/oohWSK7Jzf+3hv/1xGHr71n 1apVH1j4O3eijx0AAABg75H1hz930EGr7znl5Cf92Zuv/Ln7tmz6EHER2YX850/+v9965UXn/+mR R6z7XwccsOoLnb19AQAAgH2KNQv58YX83oEHHnD/CY877iuve81L/8ddn34voREZkY/9u9/96xf+ n8/ddPi6tVsPOOCAbGv0xoWc6aMFAAAA2LdZ/cg/3N++evWBW4468vB7n3Pm07/00gt+/O7Lf/mi P/vX73zD1zfe/s7J5i/eOjFRWuZp26K7P3/L5KMf/J2//p23/+o9l17ysi9HeJ95+t//0po1h9y7 atWqzy/8nfm/FnKajxAAAABg/+XUhbx4Ib+0kLcu5D0L2Rg5PuCAA7618OeJyErPwnv9m49Udjcu 5F0LefNCXrOQ8zprewEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgRfD/A78CI6ckj2QFAAAA AElFTkSuQmCC --000000000000f63ef405b132ef25-- From nobody Thu Oct 8 18:50: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 21A9E3A1258; Thu, 8 Oct 2020 18:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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 e0CUvZ00SVEr; Thu, 8 Oct 2020 18:50:13 -0700 (PDT) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (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 C4AEB3A1257; Thu, 8 Oct 2020 18:50:12 -0700 (PDT) Received: by mail-qt1-x841.google.com with SMTP id z33so2958296qth.8; Thu, 08 Oct 2020 18:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=OdisY4lM7E/UzCy6px0wbnUAxaXK+2Ioy/S+bcu4fJs=; b=LAhDqr6vt6IKO+kDHJueqMS04t+gKOWgg4az43KGe/bRP0P8KFeq+VdN/RrFMKP3nR ndpfrDEO0XqHchJLEZYTk86aKJQZjzCAENmHhf92OCvEKdHUH+0DU5WuIONWl5ZfOn/f V4l31BQWbeWDrQ2CZ0CzKpKe33oTez303DEnn/rR+rMZu8DVy96QTQt2W+u61nWH60im n73WyuiG4GP8OrhUCMZOHZnBnRJGAWi/1D4hY5Cue7TjsZjeMywiV0a4SaOYe9Y+/wDz 4Lw9EgoeVepkKJYhQUEzH7pAG0sJ5DcpHG6iBWGHBRvCYpDAaCZjpsH+rYrkA8gPMx4q Hmmg== 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=OdisY4lM7E/UzCy6px0wbnUAxaXK+2Ioy/S+bcu4fJs=; b=IB1qpqCJBO2+n0vY0d8KFGQ3gocgmOZez1FHqQ6pzQHzTCl0jbyko+xKqjOlJBd3Iv z46XKxmr0HPt3yVYVjOuT49IEt/3johWCHYQlIDJ28JyuBbmf7938/BNcjb9AI4jZ3N6 KKD7Y//oYS8jyZICZX6S6I+bLba5AY5V1TbwNUZ4PpCbP/L3EV/uY8aysVItly5bp+uW vGhNUnAqYlrpguQjTQ3odfIyh6J4N8fwX46afKrhkvOizTmakYHIbBSeNAjLue657jve G4j53DSdyEomkXcTCr0NTw/5hPO4R9kvZX7uoNRXhQ5n1NW1cZAkwOY2mGux+Umjo5ze AO1Q== X-Gm-Message-State: AOAM533fRu1FTy0ebArutGDWkf8Avaws7vzU9HrZenNKDt/eU2cuygon RH6MkPYbRyOrcSSou6d5FQScGM0kXkqF0FR7Hjg= X-Google-Smtp-Source: ABdhPJxbyfZW9CYb8v4vYM09+1mRULPjsnxXlf/mOwbJkEPdJQh+hRoui5UA8NU7ARjWOTcDKFUAmRE7+3RraXsXK4o= X-Received: by 2002:ac8:1923:: with SMTP id t32mr151648qtj.384.1602208211683; Thu, 08 Oct 2020 18:50:11 -0700 (PDT) MIME-Version: 1.0 References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> In-Reply-To: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> From: Jen Linkova Date: Fri, 9 Oct 2020 12:50:00 +1100 Message-ID: To: ianfarrer@gmx.com Cc: v6ops list , 6man , dhcwg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Fri, 09 Oct 2020 01:50:16 -0000 Actually it looks like this requirement is another piece of the 'renumbering from one PD prefix to another' puzzle. SLAAC renumbering drafts are solving the issue of 'a DHCP-PD client forgot about the prefix but connected downstream hosts are not aware the prefix is not in use'. This requirement is about 'a DHCP-PD client forgot about the prefix and the upstream router/relay is not aware the prefix is not in use'. Maybe it's dumb idea but is there any way DHCP-PD can be improved to help 'amnesiac' clients with 'total recall'(c) and signal the prefix disappearance both downstream (via prefix deprecation) and upstream (sonehow)? On Wed, Oct 7, 2020 at 9:25 PM wrote: > > Hi, > > We are currently finishing WGLC for this draft. It describes requirements= for a 'DHCPv6 Delegating Relay' - this is a router functioning as the L3 e= dge and DHCPv6 relay (only) with prefix delegation. This is a common deploy= ment scenario, but RFC3633/8415 only really describes PD using a Delegating= Router - i.e the L3 edge also functions as a DHCPv6 server with no relay. = When the relay and server functions are performed by separate devices a num= ber of problems with how relays behave have > been observed, so this document addresses them. > > During WGLC for this, Ole raised a comment related to one of the routing = requirements: > > R-4: If the relay has learned a route for a delegated prefix via a > given interface, and receives traffic on this interface with > a destination address within the delegated prefix (that is > not an on-link prefix for the relay), then it MUST be > dropped. This is to prevent routing loops. An ICMPv6 Type > 1, Code 6 (Destination Unreachable, reject route to > destination) error message MAY be sent back to the client. > The ICMP policy SHOULD be configurable. > > The problem that this is trying to solve is: > > 3.5. Forwarding Loops between Client and Relay > > If the client loses information about a prefix that it is delegated > while the lease entry and associated route is still active in the > delegating relay, then the relay will forward traffic to the client > which the client will return to the relay (which is the client's > default gateway (learnt via an RA). The loop will continue until > either the client is successfully reprovisioned via DHCP, or the lease > ages out in the relay. > > Ole=E2=80=99s comment: "And I would also be happy if we could have some i= mplementors chime in with a "we are happy and able to implement this requir= ement=E2=80=9D.=E2=80=9D > > We would appreciate any feedback on this, especially from anyone with exp= erience implementing DHCPv6 relays with PD. > > Thanks, > Ian > > Current draft version: https://datatracker.ietf.org/doc/draft-ietf-dhc-dh= cpv6-pd-relay-requirements/ > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --=20 SY, Jen Linkova aka Furry From nobody Fri Oct 9 00:37: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 5B6BD3A0CF4; Fri, 9 Oct 2020 00:37:22 -0700 (PDT) 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, SPF_NONE=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=mork.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 CtpxZwz8gidb; Fri, 9 Oct 2020 00:37:20 -0700 (PDT) Received: from canardo.mork.no (canardo.mork.no [IPv6:2001:4641::1]) (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 1A7143A0B41; Fri, 9 Oct 2020 00:37:18 -0700 (PDT) Received: from miraculix.mork.no (miraculix.mork.no [IPv6:2001:4641:0:2:7627:374e:db74:e353]) (authenticated bits=0) by canardo.mork.no (8.15.2/8.15.2) with ESMTPSA id 0997apjn026280 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 9 Oct 2020 09:36:53 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mork.no; s=b; t=1602229014; bh=fw5we2dqpCxHT2H2nRqU6czmDXUvGhbLb0zf+LTBGTQ=; h=From:To:Cc:Subject:References:Date:Message-ID:From; b=EKLVBFmzzyD21SM/AGtiEFihqLAcVxSL9sfTy8RCHREe7dV6zPH1Mtw5TyHBJW3BM SZupNdp90xw8/2PSXgEatD2YrWkbxLajWWkHLFENoDNratvdSBrSC4P59bhC5Dvmqz /zN2NeCrNupHtU8kG+QkpLfB4zemofLnZA8X3OXI= Received: from bjorn by miraculix.mork.no with local (Exim 4.94) (envelope-from ) id 1kQmxP-001CDJ-9p; Fri, 09 Oct 2020 09:36:51 +0200 From: =?utf-8?Q?Bj=C3=B8rn_Mork?= To: Ole Troan Cc: "Templin \(US\)\, Fred L" , dhcwg , v6ops list , 6man , "Bernie Volz \(volz\)" Organization: m References: <6373DDB1-753B-4E15-8097-9ED03F1BFC19@employees.org> Date: Fri, 09 Oct 2020 09:36:51 +0200 In-Reply-To: <6373DDB1-753B-4E15-8097-9ED03F1BFC19@employees.org> (Ole Troan's message of "Thu, 8 Oct 2020 23:59:40 +0200") Message-ID: <87h7r3hmuk.fsf@miraculix.mork.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.102.4 at canardo X-Virus-Status: Clean Archived-At: Subject: Re: [v6ops] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Fri, 09 Oct 2020 07:37:23 -0000 Ole Troan writes: >> On 8 Oct 2020, at 23:55, Templin (US), Fred L wrote: >>=20 >> Now, client B sends packets destined to an address in A to R, and R forw= ards the >> packets to client A since it still has a route for A. When the packets a= rrive at A, >> however, A forwards them back to R since it has "forgotten" that it hold= s the >> prefix A. When R receives the packets from A with destination address al= so >> from prefix A, it must drop them instead of forwarding them back to A to >> avoid looping. > > This is indeed what the requirement in the draft says.=20 > > This isn=E2=80=99t quite obvious how to implement, which why I brought up= the > question if anyone had implemented this. And if it=E2=80=99s supported in= hw > etc. I don't know anything about hardware implementations or scaling in general, but this seems easy to implement using the Linux kernel routing facilities: ip -6 rule add pref 1234 iif if_A to prefix_A blackhole where 'if_A' is the interface connecting A to R and 'prefix_A' is the prefix assigned to A. Bj=C3=B8rn From nobody Fri Oct 9 00:43: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 5EA033A0B59; Fri, 9 Oct 2020 00:43:13 -0700 (PDT) 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 PiaR3EE1JDy0; Fri, 9 Oct 2020 00:43:12 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26E993A0B5F; Fri, 9 Oct 2020 00:43:11 -0700 (PDT) Received: from [IPv6:2a02:2121:341:3cd5:595d:f1ae:ca64:910e] (unknown [IPv6:2a02:2121:341:3cd5:595d:f1ae:ca64:910e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 2A0814E11AEC; Fri, 9 Oct 2020 07:43:10 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ole Troan Mime-Version: 1.0 (1.0) Date: Fri, 9 Oct 2020 09:43:07 +0200 Message-Id: <36C7513E-BDF1-4189-89F6-5BB46797FB99@employees.org> References: <87h7r3hmuk.fsf@miraculix.mork.no> Cc: "Templin (US), Fred L" , dhcwg , v6ops list , 6man , "Bernie Volz (volz)" In-Reply-To: <87h7r3hmuk.fsf@miraculix.mork.no> To: =?utf-8?Q?Bj=C3=B8rn_Mork?= X-Mailer: iPhone Mail (18A393) Archived-At: Subject: Re: [v6ops] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Fri, 09 Oct 2020 07:43:13 -0000 > On 9 Oct 2020, at 09:37, Bj=C3=B8rn Mork wrote: >=20 > I don't know anything about hardware implementations or scaling in > general, but this seems easy to implement using the Linux kernel routing > facilities: >=20 > ip -6 rule add pref 1234 iif if_A to prefix_A blackhole >=20 > where 'if_A' is the interface connecting A to R and 'prefix_A' is the > prefix assigned to A. I think the premise here is that it=E2=80=99s a multiaccess interface. So wo= uldn=E2=80=99t that rule break traffic from B to A? If the premise here is t= hat both customer A and B are on the same interface.=20 If it was one l3 interface per customer then sure it=E2=80=99s easy.=20 Cheers=20 Ole= From nobody Fri Oct 9 01:03: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 A57373A0D35; Fri, 9 Oct 2020 01:01:55 -0700 (PDT) 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, SPF_NONE=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=mork.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 wKxMwBDZUfIp; Fri, 9 Oct 2020 01:01:54 -0700 (PDT) Received: from canardo.mork.no (canardo.mork.no [IPv6:2001:4641::1]) (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 34E673A0D34; Fri, 9 Oct 2020 01:01:52 -0700 (PDT) Received: from miraculix.mork.no (miraculix.mork.no [IPv6:2001:4641:0:2:7627:374e:db74:e353]) (authenticated bits=0) by canardo.mork.no (8.15.2/8.15.2) with ESMTPSA id 09981W03008331 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 9 Oct 2020 10:01:32 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mork.no; s=b; t=1602230492; bh=m/5q1qUCsk0PjQwzbcRdAezawqqazdkr7QFGGYDs3oY=; h=From:To:Cc:Subject:References:Date:Message-ID:From; b=kSCvxXHwuBHhPkv2IzT5Yn34iQIKbs856EWusLIEI5N6IzXQHwQC6DPqBtQeWMz4z ovnXYtpyPLIaf0rgw0g1Juf96zVzyhr26EaMw6xKt2s3HEWjn1TvYCIgrrKw4xVILP MGS3iiKEnwQ4w8Rg4hVO1WIpeUrPeYDWwmDtRvGU= Received: from bjorn by miraculix.mork.no with local (Exim 4.94) (envelope-from ) id 1kQnLH-001CFy-Fe; Fri, 09 Oct 2020 10:01:31 +0200 From: =?utf-8?Q?Bj=C3=B8rn_Mork?= To: Ole Troan Cc: "Templin \(US\)\, Fred L" , dhcwg , v6ops list , 6man , "Bernie Volz \(volz\)" Organization: m References: <87h7r3hmuk.fsf@miraculix.mork.no> <36C7513E-BDF1-4189-89F6-5BB46797FB99@employees.org> Date: Fri, 09 Oct 2020 10:01:31 +0200 In-Reply-To: <36C7513E-BDF1-4189-89F6-5BB46797FB99@employees.org> (Ole Troan's message of "Fri, 9 Oct 2020 09:43:07 +0200") Message-ID: <875z7jhlpg.fsf@miraculix.mork.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: clamav-milter 0.102.4 at canardo X-Virus-Status: Clean Archived-At: Subject: Re: [v6ops] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Fri, 09 Oct 2020 08:01:56 -0000 Ole Troan writes: >> On 9 Oct 2020, at 09:37, Bj=C3=B8rn Mork wrote: >>=20 >> I don't know anything about hardware implementations or scaling in >> general, but this seems easy to implement using the Linux kernel routing >> facilities: >>=20 >> ip -6 rule add pref 1234 iif if_A to prefix_A blackhole >>=20 >> where 'if_A' is the interface connecting A to R and 'prefix_A' is the >> prefix assigned to A. > > I think the premise here is that it=E2=80=99s a multiaccess interface. So > wouldn=E2=80=99t that rule break traffic from B to A? If the premise here= is > that both customer A and B are on the same interface. > > If it was one l3 interface per customer then sure it=E2=80=99s easy.=20 Right. The requirement is impossible with that premise. So that surely cannot be the intention? I agree that this should be clarified. Bj=C3=B8rn From nobody Fri Oct 9 02:01: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 678F33A0DAD; Fri, 9 Oct 2020 02:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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 bRrf6b-PyS4e; Fri, 9 Oct 2020 02:01:21 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 3061D3A0DAA; Fri, 9 Oct 2020 02:01:21 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id s4so9835297qkf.7; Fri, 09 Oct 2020 02:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Mlv+UozuaxkAeEWE3LzRgc1uEK2+N7WSoPfluCbzm3k=; b=WeHkZZZaHehXNAA7jkQ3G2GRXa6+nRtCKLogp1kD2YIhvWBUOFVY52mu7Mlhl7TOBm 2vDcC8i+xY9KrLCz0Lc09VGQ98RTnklDNTy7NZ7wRj6KMAOuntf2Ubr8oPKRRGV+pWLa EXlUdxQrdQ9JtKrif9VbMOeaHwRVX5PAwv/J8is9M7dtt3ntFi3XiTXuP2Rit+GHnTCg algvUNvfEFGa5kpJCyAN9xV6IbGlnJVq2m5ZHyC6pVf7qNmdPcJRM7H6xuQsLsAJ6jIM /DTnZmtyn41YwVwYEE9mIHZsrsygJQxx5oHKJQ0rgCp3L+tQCteW3TTIaXTWZRxGYZCG p/9w== 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=Mlv+UozuaxkAeEWE3LzRgc1uEK2+N7WSoPfluCbzm3k=; b=r+tgarhZuwjZSkTuj/9rgrb4fR3Gge24W6hxIvb4WSRdAUaehLtBbBZZnQ7tRLNpJr impQEpCtN26Ww253atXrU+FwDrZ5/itdTRc+slgb0UrnbTYRYxtS70cgqPg5kVWDx1JB VhJ12ArjJQud7l4T3YL268xhOZo90tbtowHreuftfit4vOSLeMKPaiAcNnJb8zG+4R5p L2UyW+pHSCYcbj05dyeiFC9v7i6ij9EgLv6kHFwZf4NdlUPURtimzMkvIwLzHx+/y1tZ KAwVj875N29FKWWLn/Et8NtLQQm7gYrkjzuiwLXiXdVHBJSsfXlxKVHd6fqtuzlglgRo qTJw== X-Gm-Message-State: AOAM5339NadKql76/vHRAACxVN+LZ/4VVcrifgCEEvpYNjOS8C0RtDEk I3AN02t9MyFXLOBMjUHt1/A/xqhr3/AnbJuh1JlOyG/c X-Google-Smtp-Source: ABdhPJyG2sa3jXF0IIZkpxFNcaHYNgpsuKcrkZ6YOeXzPEiyeY4/5vN+cF2PhDDZ2Wc2pEHNVEIladu3i4bGIiZ0gxA= X-Received: by 2002:a37:a74e:: with SMTP id q75mr5034809qke.277.1602234080013; Fri, 09 Oct 2020 02:01:20 -0700 (PDT) MIME-Version: 1.0 References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> In-Reply-To: From: Jen Linkova Date: Fri, 9 Oct 2020 20:01:08 +1100 Message-ID: To: ianfarrer@gmx.com Cc: "Templin (US), Fred L" , dhcwg , v6ops list , 6man Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] [EXTERNAL] Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Fri, 09 Oct 2020 09:01:23 -0000 On Fri, Oct 9, 2020 at 3:16 AM wrote: > [if - If I understand Jen=E2=80=99s question correctly, it=E2=80=99s rela= ted to the =E2=80=98working=E2=80=99 case. > i.e. the client has completed PD, installed the routes and the relay has > the relevant lease info/routes. Yes, that's exactly what I meant. > When the second device sends via the default route with a destination add= ress > in the delegated prefix, R-4 in it=E2=80=99s current form would cause the= traffic to be dropped. > As the relay doesn=E2=80=99t forward the packet, it can=E2=80=99t send a = redirect (per RFC4681), so > the second device can=E2=80=99t forward. > > Looking at this, I think there are deployment scenarios where R-4 isn=E2= =80=99t going to > work. > > My suggestion would be to make R-4 disable-able.] Maybe 'on by default' for p2p links and 'off by default & enable-able' for multiaccess segments? > >> -----Original Message----- > >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Jen Linkova > >> Sent: Wednesday, October 07, 2020 6:25 PM > >> To: ianfarrer@gmx.com > >> Cc: dhcwg ; v6ops list ; 6man > >> Subject: [EXTERNAL] Re: [dhcwg] Question to DHCPv6 Relay Implementors = regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements > >> > >> This message was sent from outside of Boeing. Please do not click link= s or open attachments unless you recognize the sender and > >> know that the content is safe. > >> > >> > >> On Wed, Oct 7, 2020 at 9:25 PM wrote: > >>> We are currently finishing WGLC for this draft. It describes requirem= ents for a 'DHCPv6 Delegating Relay' - this is a router functioning > >> as the L3 edge and DHCPv6 relay (only) with prefix delegation. This is= a common deployment scenario, but RFC3633/8415 only really > >> describes PD using a Delegating Router - i.e the L3 edge also function= s as a DHCPv6 server with no relay. When the relay and server > >> functions are performed by separate devices a number of problems with = how relays behave have > >>> been observed, so this document addresses them. > >>> > >>> During WGLC for this, Ole raised a comment related to one of the rout= ing requirements: > >>> > >>> R-4: If the relay has learned a route for a delegated prefix via a > >>> given interface, and receives traffic on this interface wit= h > >>> a destination address within the delegated prefix (that is > >>> not an on-link prefix for the relay), then it MUST be > >>> dropped. This is to prevent routing loops. An ICMPv6 Type > >>> 1, Code 6 (Destination Unreachable, reject route to > >>> destination) error message MAY be sent back to the client. > >>> The ICMP policy SHOULD be configurable. > >>> > >>> The problem that this is trying to solve is: > >>> > >>> 3.5. Forwarding Loops between Client and Relay > >> > >> I might be missing smth but... > >> Let's say I have a relay and it's 'south' (client-facing) interface is > >> connected to a switch. The client AND second device (another router or > >> a host) are connected to the same segment. > >> The client gets a prefix, the relay 'learned' (or shall we call it > >> 'install'?) the route for the delegated prefix pointing to its 'south' > >> interface with the client address as a next-hop. > >> What would happen if the *second* device sends traffic towards the > >> delegated prefix? As that device is usig the relay as its default > >> gateway, the traffic would be sent there. > >> If I read the draft correctly, instead of forwarding the traffic and > >> maybe sending the redirect, the relay is expected to drop it? > >> > >> -- > >> SY, Jen Linkova aka Furry > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > > > --=20 SY, Jen Linkova aka Furry From nobody Fri Oct 9 02:57:37 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 35E153A0E31; Fri, 9 Oct 2020 02:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 3GoomeKFAMLb; Fri, 9 Oct 2020 02:57:28 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 9DF6A3A0DD6; Fri, 9 Oct 2020 02:57:28 -0700 (PDT) Received: from lhreml713-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 264F0410555E5A7260D2; Fri, 9 Oct 2020 10:57:27 +0100 (IST) Received: from msceml704-chm.china.huawei.com (10.219.141.143) by lhreml713-chm.china.huawei.com (10.201.108.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 9 Oct 2020 10:57:26 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml704-chm.china.huawei.com (10.219.141.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 9 Oct 2020 12:57:26 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Fri, 9 Oct 2020 12:57:26 +0300 From: Vasilenko Eduard To: "ianfarrer@gmx.com" CC: dhcwg , v6ops list , 6man Thread-Topic: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AQHWnRHqdjfsc/ji5E+iSV9wwVVFbKmPA3rQ Date: Fri, 9 Oct 2020 09:57:26 +0000 Message-ID: References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.194.210] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Fri, 09 Oct 2020 09:57:30 -0000 Hi all, I believe that the current text behind requirement "R-4" is not accurate. it is not possible to install the route to just multi-access interface (Eth= ernet). Any vendor software would refuse to do it for the good reason. In that case, it should be not interface, but "next hop" (MAC address shoul= d be included). IMHO: requirement should be improved: "Interface" should be replaced by "ne= xt-hop" Then it would be the real challenge to check that traffic has been received= from specific MAC. It is not uRPF check, because RFP is about IP addresses only. Moreover, filtering should be done on the "destination IP" & "source MAC" (= logical "AND") I did google a little - I have found no vendors implemented RPF check at MA= C layer. Hence, this requirement is the strong new feature request. Probably, it would be ignored by vendors anyway. IMHO: if you could correct it to "nex-hop" then you would keep this "good w= ish" in the document. Just change "MUST" to "MAY". PS: Yea, DHCP is not routing protocol:-( Eduard > -----Original Message----- > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Jen Linkova > Sent: 8 =CF=CB=D4=D1=C2=D2=D1 2020 =C7. 4:25 > To: ianfarrer@gmx.com > Cc: dhcwg ; v6ops list ; 6man > > Subject: Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding draf= t- > ietf-dhc-dhcpv6-pd-relay-requirements >=20 > On Wed, Oct 7, 2020 at 9:25 PM wrote: > > We are currently finishing WGLC for this draft. It describes > > requirements for a 'DHCPv6 Delegating Relay' - this is a router functio= ning as > the L3 edge and DHCPv6 relay (only) with prefix delegation. This is a com= mon > deployment scenario, but RFC3633/8415 only really describes PD using a > Delegating Router - i.e the L3 edge also functions as a DHCPv6 server wit= h no > relay. When the relay and server functions are performed by separate devi= ces a > number of problems with how relays behave have been observed, so this > document addresses them. > > > > During WGLC for this, Ole raised a comment related to one of the routin= g > requirements: > > > > R-4: If the relay has learned a route for a delegated prefix via a > > given interface, and receives traffic on this interface with > > a destination address within the delegated prefix (that is > > not an on-link prefix for the relay), then it MUST be > > dropped. This is to prevent routing loops. An ICMPv6 Type > > 1, Code 6 (Destination Unreachable, reject route to > > destination) error message MAY be sent back to the client. > > The ICMP policy SHOULD be configurable. > > > > The problem that this is trying to solve is: > > > > 3.5. Forwarding Loops between Client and Relay >=20 > I might be missing smth but... > Let's say I have a relay and it's 'south' (client-facing) interface is co= nnected to a > switch. The client AND second device (another router or a host) are conne= cted > to the same segment. > The client gets a prefix, the relay 'learned' (or shall we call it > 'install'?) the route for the delegated prefix pointing to its 'south' > interface with the client address as a next-hop. > What would happen if the *second* device sends traffic towards the delega= ted > prefix? As that device is usig the relay as its default gateway, the traf= fic would > be sent there. > If I read the draft correctly, instead of forwarding the traffic and mayb= e sending > the redirect, the relay is expected to drop it? >=20 > -- > SY, Jen Linkova aka Furry >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri Oct 9 03:09: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 BE2023A0E3F; Fri, 9 Oct 2020 03:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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 bheCIfGVVmDI; Fri, 9 Oct 2020 03:09:43 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 58B653A0E3D; Fri, 9 Oct 2020 03:09:43 -0700 (PDT) Received: from lhreml740-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 0DB6349D08BDAC5C8173; Fri, 9 Oct 2020 11:09:42 +0100 (IST) Received: from msceml701-chm.china.huawei.com (10.219.141.159) by lhreml740-chm.china.huawei.com (10.201.108.190) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 9 Oct 2020 11:09:41 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml701-chm.china.huawei.com (10.219.141.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 9 Oct 2020 13:09:41 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Fri, 9 Oct 2020 13:09:41 +0300 From: Vasilenko Eduard To: Jen Linkova , "ianfarrer@gmx.com" CC: dhcwg , v6ops list , 6man Thread-Topic: [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AQHWnd5/djfsc/ji5E+iSV9wwVVFbKmPC3GQ Date: Fri, 9 Oct 2020 10:09:41 +0000 Message-ID: References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.194.210] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Fri, 09 Oct 2020 10:09:46 -0000 V2VsbCwgdGhlIHJvb3QgY2F1c2UgaXMgdGhlIHNhbWUuDQpCdXQgdGhpcyBpcyBub3QgcmVsYXRl ZCB0byBjdXJyZW50ICJyZW51bWJlcmluZyIsIGJlY2F1c2UgY3VycmVudCBkcmFmdCBpcyBjb25j ZW50cmF0ZWQgb24gTkQgZml4ZXMgKDFzdCBob3ApLg0KV2UgaGF2ZSB0aGUgZGlzY3Vzc2lvbiBo ZXJlIGFib3V0IGNoYWxsZW5nZXMgaW4gY29udmVydGluZyBESENQIGludG8gcm91dGluZyBwcm90 b2NvbC4gUHJlZml4IGRpc3RyaWJ1dGlvbiBvbiB0aGUgd2lkZSBzY2FsZSB3YXMgYWx3YXlzICJ0 aGUgcm91dGluZyIuDQpEaWZmZXJlbnQgbmV0d29yayBsYXllcnMsIGRpZmZlcmVudCBwdXJwb3Nl LCBkaWZmZXJlbnQgcHJvdG9jb2xzIC0gaXQgc2hvdWxkIGJlIGRpc2N1c3NlZCBpbiBkaWZmZXJl bnQgc3RhbmRhcmRzLCBkZXNwaXRlIHRoZSBjb21tb24gcm9vdCBjYXVzZS4NCkVkLw0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpcHY2IFttYWlsdG86aXB2Ni1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmVuIExpbmtvdmENCj4gU2VudDogOSDQvtC60YLRj9Cx 0YDRjyAyMDIwINCzLiA0OjUwDQo+IFRvOiBpYW5mYXJyZXJAZ214LmNvbQ0KPiBDYzogZGhjd2cg PGRoY3dnQGlldGYub3JnPjsgdjZvcHMgbGlzdCA8djZvcHNAaWV0Zi5vcmc+OyA2bWFuDQo+IDxp cHY2QGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW2RoY3dnXSBRdWVzdGlvbiB0byBESENQdjYg UmVsYXkgSW1wbGVtZW50b3JzIHJlZ2FyZGluZyBkcmFmdC0NCj4gaWV0Zi1kaGMtZGhjcHY2LXBk LXJlbGF5LXJlcXVpcmVtZW50cw0KPiANCj4gQWN0dWFsbHkgaXQgbG9va3MgbGlrZSB0aGlzIHJl cXVpcmVtZW50IGlzIGFub3RoZXIgcGllY2Ugb2YgdGhlICdyZW51bWJlcmluZyBmcm9tDQo+IG9u ZSBQRCBwcmVmaXggdG8gYW5vdGhlcicgcHV6emxlLg0KPiBTTEFBQyByZW51bWJlcmluZyBkcmFm dHMgYXJlIHNvbHZpbmcgdGhlIGlzc3VlIG9mICdhIERIQ1AtUEQgY2xpZW50IGZvcmdvdA0KPiBh Ym91dCB0aGUgcHJlZml4IGJ1dCBjb25uZWN0ZWQgZG93bnN0cmVhbSBob3N0cyBhcmUgbm90IGF3 YXJlIHRoZSBwcmVmaXggaXMNCj4gbm90IGluIHVzZScuDQo+IFRoaXMgcmVxdWlyZW1lbnQgaXMg YWJvdXQgJ2EgREhDUC1QRCBjbGllbnQgZm9yZ290IGFib3V0IHRoZSBwcmVmaXggYW5kIHRoZQ0K PiB1cHN0cmVhbSByb3V0ZXIvcmVsYXkgaXMgbm90IGF3YXJlIHRoZSBwcmVmaXggaXMgbm90IGlu IHVzZScuDQo+IA0KPiBNYXliZSBpdCdzIGR1bWIgaWRlYSBidXQgaXMgdGhlcmUgYW55IHdheSBE SENQLVBEIGNhbiBiZSBpbXByb3ZlZCB0byBoZWxwDQo+ICdhbW5lc2lhYycgY2xpZW50cyB3aXRo ICd0b3RhbCByZWNhbGwnKGMpIGFuZCBzaWduYWwgdGhlIHByZWZpeCBkaXNhcHBlYXJhbmNlIGJv dGgNCj4gZG93bnN0cmVhbSAodmlhIHByZWZpeCBkZXByZWNhdGlvbikgYW5kIHVwc3RyZWFtIChz b25laG93KT8NCj4gDQo+IE9uIFdlZCwgT2N0IDcsIDIwMjAgYXQgOToyNSBQTSA8aWFuZmFycmVy QGdteC5jb20+IHdyb3RlOg0KPiA+DQo+ID4gSGksDQo+ID4NCj4gPiBXZSBhcmUgY3VycmVudGx5 IGZpbmlzaGluZyBXR0xDIGZvciB0aGlzIGRyYWZ0LiBJdCBkZXNjcmliZXMNCj4gPiByZXF1aXJl bWVudHMgZm9yIGEgJ0RIQ1B2NiBEZWxlZ2F0aW5nIFJlbGF5JyAtIHRoaXMgaXMgYSByb3V0ZXIg ZnVuY3Rpb25pbmcgYXMNCj4gdGhlIEwzIGVkZ2UgYW5kIERIQ1B2NiByZWxheSAob25seSkgd2l0 aCBwcmVmaXggZGVsZWdhdGlvbi4gVGhpcyBpcyBhIGNvbW1vbg0KPiBkZXBsb3ltZW50IHNjZW5h cmlvLCBidXQgUkZDMzYzMy84NDE1IG9ubHkgcmVhbGx5IGRlc2NyaWJlcyBQRCB1c2luZyBhDQo+ IERlbGVnYXRpbmcgUm91dGVyIC0gaS5lIHRoZSBMMyBlZGdlIGFsc28gZnVuY3Rpb25zIGFzIGEg REhDUHY2IHNlcnZlciB3aXRoIG5vDQo+IHJlbGF5LiBXaGVuIHRoZSByZWxheSBhbmQgc2VydmVy IGZ1bmN0aW9ucyBhcmUgcGVyZm9ybWVkIGJ5IHNlcGFyYXRlIGRldmljZXMgYQ0KPiBudW1iZXIg b2YgcHJvYmxlbXMgd2l0aCBob3cgcmVsYXlzIGJlaGF2ZSBoYXZlIGJlZW4gb2JzZXJ2ZWQsIHNv IHRoaXMNCj4gZG9jdW1lbnQgYWRkcmVzc2VzIHRoZW0uDQo+ID4NCj4gPiBEdXJpbmcgV0dMQyBm b3IgdGhpcywgT2xlIHJhaXNlZCBhIGNvbW1lbnQgcmVsYXRlZCB0byBvbmUgb2YgdGhlIHJvdXRp bmcNCj4gcmVxdWlyZW1lbnRzOg0KPiA+DQo+ID4gUi00OiAgICBJZiB0aGUgcmVsYXkgaGFzIGxl YXJuZWQgYSByb3V0ZSBmb3IgYSBkZWxlZ2F0ZWQgcHJlZml4IHZpYSBhDQo+ID4gICAgICAgICAg ICBnaXZlbiBpbnRlcmZhY2UsIGFuZCByZWNlaXZlcyB0cmFmZmljIG9uIHRoaXMgaW50ZXJmYWNl IHdpdGgNCj4gPiAgICAgICAgICAgIGEgZGVzdGluYXRpb24gYWRkcmVzcyB3aXRoaW4gdGhlIGRl bGVnYXRlZCBwcmVmaXggKHRoYXQgaXMNCj4gPiAgICAgICAgICAgIG5vdCBhbiBvbi1saW5rIHBy ZWZpeCBmb3IgdGhlIHJlbGF5KSwgdGhlbiBpdCBNVVNUIGJlDQo+ID4gICAgICAgICAgICBkcm9w cGVkLiAgVGhpcyBpcyB0byBwcmV2ZW50IHJvdXRpbmcgbG9vcHMuICBBbiBJQ01QdjYgVHlwZQ0K PiA+ICAgICAgICAgICAgMSwgQ29kZSA2IChEZXN0aW5hdGlvbiBVbnJlYWNoYWJsZSwgcmVqZWN0 IHJvdXRlIHRvDQo+ID4gICAgICAgICAgICBkZXN0aW5hdGlvbikgZXJyb3IgbWVzc2FnZSBNQVkg YmUgc2VudCBiYWNrIHRvIHRoZSBjbGllbnQuDQo+ID4gICAgICAgICAgICBUaGUgSUNNUCBwb2xp Y3kgU0hPVUxEIGJlIGNvbmZpZ3VyYWJsZS4NCj4gPg0KPiA+IFRoZSBwcm9ibGVtIHRoYXQgdGhp cyBpcyB0cnlpbmcgdG8gc29sdmUgaXM6DQo+ID4NCj4gPiAzLjUuICBGb3J3YXJkaW5nIExvb3Bz IGJldHdlZW4gQ2xpZW50IGFuZCBSZWxheQ0KPiA+DQo+ID4gICAgSWYgdGhlIGNsaWVudCBsb3Nl cyBpbmZvcm1hdGlvbiBhYm91dCBhIHByZWZpeCB0aGF0IGl0IGlzIGRlbGVnYXRlZA0KPiA+ICAg IHdoaWxlIHRoZSBsZWFzZSBlbnRyeSBhbmQgYXNzb2NpYXRlZCByb3V0ZSBpcyBzdGlsbCBhY3Rp dmUgaW4gdGhlDQo+ID4gICAgZGVsZWdhdGluZyByZWxheSwgdGhlbiB0aGUgcmVsYXkgd2lsbCBm b3J3YXJkIHRyYWZmaWMgdG8gdGhlIGNsaWVudA0KPiA+ICAgIHdoaWNoIHRoZSBjbGllbnQgd2ls bCByZXR1cm4gdG8gdGhlIHJlbGF5ICh3aGljaCBpcyB0aGUgY2xpZW50J3MNCj4gPiAgICBkZWZh dWx0IGdhdGV3YXkgKGxlYXJudCB2aWEgYW4gUkEpLiAgVGhlIGxvb3Agd2lsbCBjb250aW51ZSB1 bnRpbA0KPiA+ICAgIGVpdGhlciB0aGUgY2xpZW50IGlzIHN1Y2Nlc3NmdWxseSByZXByb3Zpc2lv bmVkIHZpYSBESENQLCBvciB0aGUgbGVhc2UNCj4gPiAgICBhZ2VzIG91dCBpbiB0aGUgcmVsYXku DQo+ID4NCj4gPiBPbGXigJlzIGNvbW1lbnQ6ICJBbmQgSSB3b3VsZCBhbHNvIGJlIGhhcHB5IGlm IHdlIGNvdWxkIGhhdmUgc29tZQ0KPiBpbXBsZW1lbnRvcnMgY2hpbWUgaW4gd2l0aCBhICJ3ZSBh cmUgaGFwcHkgYW5kIGFibGUgdG8gaW1wbGVtZW50IHRoaXMNCj4gcmVxdWlyZW1lbnTigJ0u4oCd DQo+ID4NCj4gPiBXZSB3b3VsZCBhcHByZWNpYXRlIGFueSBmZWVkYmFjayBvbiB0aGlzLCBlc3Bl Y2lhbGx5IGZyb20gYW55b25lIHdpdGgNCj4gZXhwZXJpZW5jZSBpbXBsZW1lbnRpbmcgREhDUHY2 IHJlbGF5cyB3aXRoIFBELg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+IElhbg0KPiA+DQo+ID4gQ3Vy cmVudCBkcmFmdCB2ZXJzaW9uOg0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtZGhjLWRoY3B2Ni1wZC1yZWxheS1yZXF1aXINCj4gPiBlbWVudHMvDQo+ID4N Cj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gZGhjd2cgbWFpbGluZyBsaXN0DQo+ID4gZGhjd2dAaWV0Zi5vcmcNCj4gPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnDQo+IA0KPiANCj4gDQo+IC0tDQo+ IFNZLCBKZW4gTGlua292YSBha2EgRnVycnkNCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IElFVEYgSVB2 NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiBpcHY2QGlldGYub3JnDQo+IEFkbWluaXN0 cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lw djYNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg== From nobody Fri Oct 9 04:18: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 D5A453A0DDD; Fri, 9 Oct 2020 04:18:25 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=gmx.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 uD2k8HQGms8T; Fri, 9 Oct 2020 04:18:24 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 99C4B3A0D52; Fri, 9 Oct 2020 04:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1602242289; bh=tQ/XCG6pniOhv9VSc1j9BU3/VnZDm1XMy7bXVE01M0g=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=UUzPFxEMqWSfXeMNBqGWbqR7mSn9WZUniVyiV+yIpcwhnjL/HTwTlYjaaH3KK0+jM 93BZx/RXLujSqb7h+22LEgUjZrc146tQZflYqBMmWqyifH/2ej10+9koYBYdynSaFf iY2h3jaARCrHLWra6dOY9PXD4SdjbpLENWxuVo50= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.128.43] ([87.79.171.64]) by mail.gmx.com (mrgmx005 [212.227.17.184]) with ESMTPSA (Nemesis) id 1MsHs0-1kC4Nv0akM-00tnNY; Fri, 09 Oct 2020 13:18:09 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: ianfarrer@gmx.com In-Reply-To: Date: Fri, 9 Oct 2020 13:18:05 +0200 Cc: dhcwg , v6ops list , 6man Content-Transfer-Encoding: quoted-printable Message-Id: References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> To: Vasilenko Eduard X-Mailer: Apple Mail (2.3445.104.15) X-Provags-ID: V03:K1:mS/nJGmsivGITz5Wu7oFCYrontv8wOR391JWBFFDk1hwpaxOK9G OK69HBwRhNAZrqzr5pScPbxeK8WR6w8FeJNJIg5EJtILrbIxOgQGf/IltjZtWfL9O6Lc0Yv ssV2xuOZ3vWxj7kIhEpT2o+uvnYxg+sNSJK8SG9i8kImvc73tvYFpGPo4EgooeP+6WrR2DV I0U6yWRBzFhKqW+5vwtwQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:TANwVFEmSic=:7kpTjt4jKkN4GuZoOD7klM k02DMUbIg/kT8woHECBZRQH+dk31Zl+qydICbalJT5O799/JONJJmnHKCVeZb4p+qJ4qStWqO V1xU8Ks1L/2ACHMAisNcAPuacz4EQdy0Ll6gkMaefKuGHHrqxg2zcz6ehVWPyhwa/tQrmg1lw 3Kkiny+H/YXJ121Zxru+9eNO19/i+ikmY9MUrIqx150KmdINb0IWjhVEzrHaGNmmtpUuZdAWw NWJ9KMLWSRkGBJT4XcqIDxwJBsG9B4G2oefQ528DvaPu3mGxf7CmL5sE+FOAUMe5pmbNHfYa+ 9gcn1KY43Taf+UlmQslxVumAb7llVNRX/j2UibI4nuzna6xyT6ezAQRMF64U7u8fGSitsJVhW YXhZm7dGWA1f1ZxByagGzqXQ5BT5ngNuqwjYw7nSkVVkLPjLip46dIiKjK+FsUIZ0n+SwYXlP iDpLNBpt3dzw1whVSHK8M4rUEz2+gWw/AC7GFLfQKaUfXxc/kgQac3hBjJQCBenncvO0/lgVo CAzaprkbS0MfcmbVIopWkoT7PyKjB8MRG7McK47O53nqZmk7xN6hPYfMy39mFlJaog3w420m2 I/QlaJFchjyLB+FfPqM1X7v7f699f3GPTG7iEU9yjkMzUxzieVUTz6BfVEIweNZZ7bqnPOctK wN02iUn9CPFMtmHDpEjCCWYnMuj0qthXoj//Lm45pDPGV+7HTzfuxqlIKorKwdkR9f8UIQepu XO5deT7Pm/GLACWeljVMH24D4pleM2I7/IOWq2Qm9KUs2u6K+y8hsIm/JuJJI0U7fGEjL+kAg 3/td+THc8slGoPH3JACC95aixaPbPe1m+uHWqqHBxLi9CErB2/EDj37TwQwZ04q8HC2dzOcOW Khleq3qeisBCrpPsfsZObKQex7u9+Tv7J6cUV9zwsHwvdehFOVLijPa0S4f2EUfQQnKpyK5/h hbs96eAUPFT+nrxwCzjfaWaD48r29By/dLs6Rj5h1Dr2zhjD5fYNqLUAB1trma1H27cihEaP5 DuHylfEafODqSWusphXXniH5Mv4COQdgrWaS3HRnWoelFM9nFrMjXd9mF+nMJ8D4K5FKMgI8R lIUjqRDNC+lArlJbrHNuP9z0iOqypuiO1L+nS+FzcZWSK2ow656fJEoSPHbmI2Y0IsS2YZmIh Bdu/XYtPTBfNZYGfdDfDA4V9YgBhX/keqiZJ55N5prrxWoVUckFKd9HyfO6R/4PAmPjr8bT8P EZ+z1fx5vWYFbSi7A134IYfV/TU/j4D21r9QRPQ== Archived-At: Subject: Re: [v6ops] [dhcwg] Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Fri, 09 Oct 2020 11:18:26 -0000 Hi Eduard, Please see inline. Ian > On 9. Oct 2020, at 11:57, Vasilenko Eduard = wrote: >=20 > Hi all, > I believe that the current text behind requirement "R-4" is not = accurate. > it is not possible to install the route to just multi-access interface = (Ethernet). Any vendor software would refuse to do it for the good = reason. > In that case, it should be not interface, but "next hop" (MAC address = should be included). > IMHO: requirement should be improved: "Interface" should be replaced = by "next-hop=E2=80=9D [if - Good point. I=E2=80=99m reworking the requirement text at the = moment, so I=E2=80=99ll incorporate this.] >=20 > Then it would be the real challenge to check that traffic has been = received from specific MAC. > It is not uRPF check, because RFP is about IP addresses only. > Moreover, filtering should be done on the "destination IP" & "source = MAC" (logical "AND") > I did google a little - I have found no vendors implemented RPF check = at MAC layer. > Hence, this requirement is the strong new feature request. > Probably, it would be ignored by vendors anyway. > IMHO: if you could correct it to "nex-hop" then you would keep this = "good wish" in the document. Just change "MUST" to "MAY=E2=80=9D. [if - As the requirement will be changed to a configurable policy, then = it will become SHOULD.] >=20 > PS: Yea, DHCP is not routing protocol:-( > Eduard >> -----Original Message----- >> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Jen Linkova >> Sent: 8 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2020 =D0=B3. 4:25 >> To: ianfarrer@gmx.com >> Cc: dhcwg ; v6ops list ; 6man >> >> Subject: Re: [dhcwg] Question to DHCPv6 Relay Implementors regarding = draft- >> ietf-dhc-dhcpv6-pd-relay-requirements >>=20 >> On Wed, Oct 7, 2020 at 9:25 PM wrote: >>> We are currently finishing WGLC for this draft. It describes >>> requirements for a 'DHCPv6 Delegating Relay' - this is a router = functioning as >> the L3 edge and DHCPv6 relay (only) with prefix delegation. This is a = common >> deployment scenario, but RFC3633/8415 only really describes PD using = a >> Delegating Router - i.e the L3 edge also functions as a DHCPv6 server = with no >> relay. When the relay and server functions are performed by separate = devices a >> number of problems with how relays behave have been observed, so this >> document addresses them. >>>=20 >>> During WGLC for this, Ole raised a comment related to one of the = routing >> requirements: >>>=20 >>> R-4: If the relay has learned a route for a delegated prefix via = a >>> given interface, and receives traffic on this interface = with >>> a destination address within the delegated prefix (that is >>> not an on-link prefix for the relay), then it MUST be >>> dropped. This is to prevent routing loops. An ICMPv6 = Type >>> 1, Code 6 (Destination Unreachable, reject route to >>> destination) error message MAY be sent back to the client. >>> The ICMP policy SHOULD be configurable. >>>=20 >>> The problem that this is trying to solve is: >>>=20 >>> 3.5. Forwarding Loops between Client and Relay >>=20 >> I might be missing smth but... >> Let's say I have a relay and it's 'south' (client-facing) interface = is connected to a >> switch. The client AND second device (another router or a host) are = connected >> to the same segment. >> The client gets a prefix, the relay 'learned' (or shall we call it >> 'install'?) the route for the delegated prefix pointing to its = 'south' >> interface with the client address as a next-hop. >> What would happen if the *second* device sends traffic towards the = delegated >> prefix? As that device is usig the relay as its default gateway, the = traffic would >> be sent there. >> If I read the draft correctly, instead of forwarding the traffic and = maybe sending >> the redirect, the relay is expected to drop it? >>=20 >> -- >> SY, Jen Linkova aka Furry >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- From nobody Fri Oct 9 07:02:12 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 6E8D33A047D; Fri, 9 Oct 2020 07:02:10 -0700 (PDT) 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=boeing.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 Z3eixSU9PYV6; Fri, 9 Oct 2020 07:02:08 -0700 (PDT) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 D32A33A0407; Fri, 9 Oct 2020 07:02:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 099E20NZ025121; Fri, 9 Oct 2020 10:02:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602252124; bh=ABepccQDrq2BhE+kMPtBhaefuCFRL0hPmYLFSle8gC4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=a3q2ujM1wxbFj+lcrV+osmVD+fuaFzihfdUzbyiU3dGrG23oIZtZkubonyXwDSLwj ZhamdMyBZhvVLAxir62oBPIgHabZoAniem92Ail8iM1t8ZyEt8zWSguTR/Skey9LRS 7COB1i41ymJv1j6cQIqgR9beWE/bWgU17RtJQR7l65ACpTtUdzpEzI9G6YVHYmzd4l 8FoxYOYlLGF1OlRgCrhqEaCqOk6N9jRmGVRM7V0uHixm4iqb/7TY6B+AvtAC7UBM1G V4dQynpJwJthRT73aRW5RIhUmJhXB65iXb5t6QrSNXWhikNRXC2Nh3sIWRgjzETDhH 06fTM3MIMhI2Q== Received: from XCH16-07-10.nos.boeing.com (xch16-07-10.nos.boeing.com [144.115.66.112]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 099E1t9r024778 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 9 Oct 2020 10:01:55 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-10.nos.boeing.com (144.115.66.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Fri, 9 Oct 2020 07:01:54 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8]) by XCH16-07-10.nos.boeing.com ([fe80::e065:4e77:ac47:d9a8%2]) with mapi id 15.01.2044.004; Fri, 9 Oct 2020 07:01:54 -0700 From: "Templin (US), Fred L" To: Ole Troan CC: dhcwg , v6ops list , 6man Thread-Topic: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AQHWnkS+UHZEXbeyVUaRnVx7EHKeyA== Date: Fri, 9 Oct 2020 14:01:54 +0000 Message-ID: <5fd7f95f054e4c6fb91d245e4a9a016a@boeing.com> References: <6373DDB1-753B-4E15-8097-9ED03F1BFC19@employees.org> <5b45336f7d9d489bb13a3559fd0a6b10@boeing.com> <66fcc6c4c1d243108b6b2eb19719324c@boeing.com> In-Reply-To: <66fcc6c4c1d243108b6b2eb19719324c@boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 309C4EDF93173310AE3BADB98E696B96979A1481187BA1BD119A7121870EDCFF2000:8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [dhcwg] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Fri, 09 Oct 2020 14:02:11 -0000 Responding to myself since folks seem to have blasted past this proposal: > So, why not fix the problem at the client instead of at the relay? The cl= ient could > have a simple check to make sure it does not forward a packet out the sam= e > interface that it arrived on due to a default route. That way, the relay = would > never see a packet originating from node A with a destination address A. > (BTW, it should be OK for the client to forward a packet out the same int= erface > it arrived on due to a more-specific route - but not due to a default ro= ute.) The problem that is being described is a client problem; not a relay proble= m. So, why not fix it in the client? Fixing it in the client also avoids waste= d message transmissions on the link from the client to the relay since packets that w= ould cause a loop would never be transmitted by the client at all. This is very = important for some link types such as aviation data links where the data rates are lo= w to begin with. Fred From nobody Fri Oct 9 08:41: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 A2F6C3A09E1; Fri, 9 Oct 2020 08:41:25 -0700 (PDT) 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=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 5p0_u_MlfiZ1; Fri, 9 Oct 2020 08:41:24 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 404213A09DB; Fri, 9 Oct 2020 08:41:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id DD2B9389AB; Fri, 9 Oct 2020 11:46:51 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 20ys6r092Duf; Fri, 9 Oct 2020 11:46:49 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CB2E2389A3; Fri, 9 Oct 2020 11:46:49 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E9706733; Fri, 9 Oct 2020 11:41:18 -0400 (EDT) From: Michael Richardson To: Jen Linkova , "Bernie Volz \(volz\)" , dhcwg , 6man , v6ops list In-Reply-To: References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [v6ops] [dhcwg] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Fri, 09 Oct 2020 15:41:26 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Jen Linkova wrote: > I think there is confusion re: the scenario we are talking about. I've > attached the diagram for the case which concerns me. > So: > - The Relay R has an interface eth0 connected to a switch S. > - Devices A and B are connected to the same switch and using R as a > default gateway. > - The prefix 2001:db8::/56 was delegated to a client A via the relay = R. a friendly amendment to your example to aid in human comprehension: } - The prefix 2001:db8:0000:0123:/64 was delegated to a client A via = the relay R. } - R installs a route for 2001:db8:0000:0123:/64 towards A via eth0. > - The device B (which has an address NOT from the delegated prefix, > but from another /64 assigned to that common link, let's sat > 2001:db8:cafe::/64) sends a packet to an address from the delegated now, my brain can more clearly see that 2001:db8:cafe::/64 is not within 2001:db8:0000:0123:/64, while I had to use a few extra brain cells to see that it wasn't in that ::/56 :-) > What I'd expect to happen (with DHCP-PD or without - e.g. if R has a > static route towards A, not a dynamic route produced by PD): > - the packet is sent to A. Well, if A does not have a route to > 2001:db8::42 then indeed a routing loop might happen. But if A does > have a route, the packet will be delivered. > What seems to be required by R4: > - R detects that the packet is received via eth0 and needs to be sent > back to eth0. R4 seems to require such packets to be dropped. > So if B would never be able to communicate to any address in the > delegated prefix, right? > Am I missing anything? I think that you got it right. >> Perhaps the missing piece of the rule is don=E2=80=99t send it back = to where it came from, based on link layer addresses (or link if point-to-p= oint). > Yes. If R4 was saying 'drop the packet if it comes from the same > link-layer address you are going to send it back' - it would make > total sense. But I don't think routers do *that*. Yes, if we made the check on L2 address, then it would work. And I agree that routers are exactly doing that. I think that it also works if B is a router with additional interfaces downstream, unless there are multiple paths. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+AhJ4ACgkQgItw+93Q 3WXtsAf+IXnYJBoc15it2nrWNWNgjyTyrSDmbISdfuLtaVn2or5y9x6ewztUhn8t bj82+HkeFfaQgEPRf8I/TS3BdDb8tZwBsZ0RUq5fnVVK/Xl7a8pdHqRaDiF/CBKq o5pTEAUmrO3Vr0uBt6eDHqd5OkCpmVppGRIwdWLviVuGF9mkAE5gCxJicMrEMFUE 5ySe8UFtXlHF6hvwm2id1fTerq6vdMmlJWj5TJcqBREEvmQC59tvVAPguEqXmyJC t7TlDgZnzPfLhVaFxq41Rxhzpo6UOyP29J3TrhHO+mcyCGR1RklvJY0S8nbDn2yU jxU8y4df7BMKE8nfrxoWqJ3GD1e0hw== =f2dN -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Oct 10 21:30: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 6CE963A09E4; Sat, 10 Oct 2020 21:30:15 -0700 (PDT) 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, 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 (1024-bit key) header.d=delong.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 pP4-IBaBU8Pd; Sat, 10 Oct 2020 21:30:10 -0700 (PDT) Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id A8CB83A0E79; Sat, 10 Oct 2020 21:30:05 -0700 (PDT) Received: from [IPv6:2001:470:496b:0:901d:ceeb:51a:4faf] ([IPv6:2001:470:496b:0:901d:ceeb:51a:4faf]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 09B4Tqja2997134 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 10 Oct 2020 21:29:53 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 09B4Tqja2997134 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1602390595; bh=aSkwdudthiN93Ss804ZMIop7b1s7S4vvC5UMLDNhBXU=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=CpuTdAVt0BpyFBjOX47Fo/C16ultYu6wLifQ45QV07leBqg18cd2IFACwdrMuxsOS 9yXILCzn5ZjNNdmw4O0OgGywmt4IPhy9VtHd6+pLHG7y4GYm/Fv8cHo2YhAneHpmXM HCpsPT/BD8GYxZ/7fq5fLYQknmuFeHWOf2kq0Hzk= From: Owen DeLong Message-Id: <033A6CDA-63DD-4E3B-9AEB-EAF36B7F8AB7@delong.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_61384999-21CE-4B04-B471-5926992A9BC9" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Sat, 10 Oct 2020 21:29:52 -0700 In-Reply-To: <54DA4651-1C55-4DF9-BF3D-7E851B6692F4@mit.edu> Cc: Ted Lemon , "v6ops@ietf.org" , "last-call@ietf.org" , "secdir@ietf.org" , Christopher Wood via Datatracker , "draft-ietf-v6ops-cpe-slaac-renum.all@ietf.org" , Christopher Wood To: Uri Blumenthal References: <4FC30E5B-EF9F-4238-A683-CE8235BDD2EF@fugue.com> <54DA4651-1C55-4DF9-BF3D-7E851B6692F4@mit.edu> X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Sat, 10 Oct 2020 21:29:55 -0700 (PDT) Archived-At: Subject: Re: [v6ops] [secdir] Secdir last call review of draft-ietf-v6ops-cpe-slaac-renum-04 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, 11 Oct 2020 04:30:16 -0000 --Apple-Mail=_61384999-21CE-4B04-B471-5926992A9BC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Virtually anyone that could possibly be on both interfaces has access to = do far more damage to the network than would be possible from this = particular vulnerability. The northbound interface is between the CPE and the ISP. The southbound = interface is to the site local area networks. Only the site administrator(s) should (theoretically) have access to = both networks. An attacker who has access to both can override virtually = any automated network provisioning at the local site. Owen > On Sep 9, 2020, at 7:17 PM, Uri Blumenthal wrote: >=20 > Capability-wise, what's the likelihood that the attacker would be = present on the southbound interface, but *not* on the northbound one? >=20 > Sent from my test iPhone >=20 >> On Sep 9, 2020, at 19:32, Ted Lemon wrote: >>=20 >> =EF=BB=BF On Sep 9, 2020, at 7:16 PM, Christopher Wood via = Datatracker > wrote: >>> - Section 3: is it possible for an attacker to send DHCPv6 Prefix = Delegations >>> with lifetime=3D0 to CE routers that support LAN-side DHCPv6 and = amplify >>> Reconfigure messages to supporting clients? (I don't know if this is = a concern >>> or part of the threat model, but this did seem to be a case of = possible >>> request/response asymmetry.) - Section 4: rationale for these = default values, >>> if available, might be worth including. (Why not make them shorter? = What are >>> the tradeoffs?) - Section 6: it might be worth noting what happens = if stable >>> storage is unavailable or otherwise compromised when trying to store = prefix >>> information. What happens if the "A" or "L" bits are modified? (I = suspect >>> nothing dangerous, but it's not clear to me whether or not integrity = is >>> important.) >>=20 >> The attacker on the southbound link would have to know the = transaction ID of the DHCP request/confirm/renew message, which is only = sent on the northbound interface, and would have to know the DUID and = IAID used by the client, again never seen on the southbound link, and = would have to know the server=E2=80=99s DUID, again only visible = northbound. I don=E2=80=99t think this is a feasible attack. It=E2=80=99s = hard to see what the benefit of such an attack would be=E2=80=94in order = to effect this attack without knowledge of the exchange on the = northbound interface, the client would have to be continuously spamming = the southbound link with attempts, so that would be a negative = amplication factor of perhaps 2^256, perhaps less if the identifiers can = be predicted and renewal times can be predicted. >>=20 >> And this assumes that the DHCPv6 PD client on the CPE device will = even accept a DHCP Reply on its southbound interface. >>=20 >> :) >>=20 >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_61384999-21CE-4B04-B471-5926992A9BC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Virtually anyone that could possibly be on both interfaces = has access to do far more damage to the network than would be possible = from this particular vulnerability.

The northbound interface is between the = CPE and the ISP. The southbound interface is to the site local area = networks.

Only = the site administrator(s) should (theoretically) have access to both = networks. An attacker who has access to both can override virtually any = automated network provisioning at the local site.
Owen


On Sep 9, 2020, at 7:17 PM, Uri Blumenthal <uri@mit.edu> = wrote:

Capability-wise, what's the = likelihood that the attacker would be present on the southbound = interface, but *not* on the northbound one?

Sent from my test = iPhone

On Sep 9, 2020, at 19:32, Ted Lemon <mellon@fugue.com> = wrote:

=EF=BB=BF On Sep 9, 2020, at 7:16 PM, Christopher Wood via Datatracker = <noreply@ietf.org> wrote:
- Section 3: is it possible for an attacker to send DHCPv6 = Prefix Delegations
with lifetime=3D0 to CE routers that support LAN-side DHCPv6 = and amplify
Reconfigure = messages to supporting clients? (I don't know if this is a = concern
or part of = the threat model, but this did seem to be a case of possible
request/response asymmetry.) - Section 4: rationale for these = default values,
if available, might be worth including. (Why not make them = shorter? What are
the tradeoffs?) - Section 6: it might be worth noting what = happens if stable
storage is unavailable or otherwise compromised when trying = to store prefix
information. What happens if the "A" or "L" bits are = modified? (I suspect
nothing dangerous, but it's not clear to me whether or not = integrity is
important.)

The attacker on the southbound link would have to know the = transaction ID of the DHCP request/confirm/renew message, which is only = sent on the northbound interface, and would have to know the DUID and = IAID used by the client, again never seen on the southbound link, and = would have to know the server=E2=80=99s DUID, again only visible = northbound. I don=E2=80=99t think this is a feasible attack. It=E2=80=99s = hard to see what the benefit of such an attack would be=E2=80=94in order = to effect this attack without knowledge of the exchange on the = northbound interface, the client would have to be continuously spamming = the southbound link with attempts, so that would be a negative = amplication factor of perhaps 2^256, perhaps less if the identifiers can = be predicted and renewal times can be predicted.

And this assumes that the DHCPv6 PD = client on the CPE device will even accept a DHCP Reply on its southbound = interface.

:)

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
______________________________________= _________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

= --Apple-Mail=_61384999-21CE-4B04-B471-5926992A9BC9-- From nobody Sun Oct 11 21:11:17 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 C41463A0A13 for ; Sun, 11 Oct 2020 21:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 R95yArAPIead for ; Sun, 11 Oct 2020 21:11:14 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 2B5B33A0A0B for ; Sun, 11 Oct 2020 21:11:14 -0700 (PDT) Received: from lhreml727-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 5DAFDFBB8D67EB3D8925 for ; Mon, 12 Oct 2020 05:11:11 +0100 (IST) Received: from lhreml727-chm.china.huawei.com (10.201.108.78) by lhreml727-chm.china.huawei.com (10.201.108.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 12 Oct 2020 05:11:11 +0100 Received: from DGGEML403-HUB.china.huawei.com (10.3.17.33) by lhreml727-chm.china.huawei.com (10.201.108.78) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Mon, 12 Oct 2020 05:11:10 +0100 Received: from DGGEML512-MBX.china.huawei.com ([169.254.2.53]) by DGGEML403-HUB.china.huawei.com ([fe80::74d9:c659:fbec:21fa%31]) with mapi id 14.03.0487.000; Mon, 12 Oct 2020 12:11:05 +0800 From: "Pengshuping (Peng Shuping)" To: "v6ops@ietf.org" Thread-Topic: New Version Notification for draft-peng-v6ops-hbh-00.txt Thread-Index: AQHWoEmEVdG89yALrUKwcAEpVIuNo6mTUpXg Date: Mon, 12 Oct 2020 04:11:05 +0000 Message-ID: <4278D47A901B3041A737953BAA078ADE1946824A@dggeml512-mbx.china.huawei.com> References: <160247403357.25160.13795920342624099987@ietfa.amsl.com> In-Reply-To: <160247403357.25160.13795920342624099987@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.153.195.37] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [v6ops] FW: New Version Notification for draft-peng-v6ops-hbh-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: Mon, 12 Oct 2020 04:11:16 -0000 RGVhciBhbGwsDQoNCldlIGhhdmUgcG9zdGVkIHRoaXMgZHJhZnQgb24gdGhlIHByb2Nlc3Npbmcg b2YgdGhlIEhvcC1ieS1Ib3AgT3B0aW9ucyBIZWFkZXIuIA0KDQogICBUaGlzIGRvY3VtZW50IGRl c2NyaWJlcyB0aGUgcHJvY2Vzc2luZyBvZiB0aGUgSG9wLWJ5LUhvcCBPcHRpb25zDQogICBIZWFk ZXIgaW4gdG9kYXkncyByb3V0ZXJzIGluIHRoZSBhc3BlY3RzIG9mIHN0YW5kYXJkcyBzcGVjaWZp Y2F0aW9uLA0KICAgY29tbW9uIGltcGxlbWVudGF0aW9ucywgYW5kIGRlZmF1bHQgb3BlcmF0aW9u cy4gIFRoaXMgZG9jdW1lbnQNCiAgIG91dGxpbmVzIHRoZSByZWFzb25zIHdoeSB0aGUgSG9wLWJ5 LUhvcCBPcHRpb25zIEhlYWRlciBpcyByYXJlbHkNCiAgIHV0aWxpemVkIGluIGN1cnJlbnQgbmV0 d29ya3MuICBJbiBhZGRpdGlvbiwgdGhpcyBkb2N1bWVudCBkZXNjcmliZXMNCiAgIHdoeSB0aGUg SEJIIGNvdWxkIGJlIHVzZWQgYXMgYSBwb3dlcmZ1bCBtZWNoYW5pc20gYWxsb3dpbmcgZGVwbG95 bWVudA0KICAgYW5kIG9wZXJhdGlvbnMgb2YgbmV3IHNlcnZpY2VzIHJlcXVpcmluZyBhIG1vcmUg b3B0aW1pemVkIHdheSB0bw0KICAgbGV2ZXJhZ2UgbmV0d29yayByZXNvdXJjZXMgb2YgYW4gaW5m cmFzdHJ1Y3R1cmUuICBUaGUgSG9wLWJ5LUhvcA0KICAgT3B0aW9ucyBIZWFkZXIgaXMgdGFrZW4g aW50byBjb25zaWRlcmF0aW9uIGFzIGEgdmFsdWFibGUgY29udGFpbmVyDQogICBmb3IgY2Fycnlp bmcgdGhlIGluZm9ybWF0aW9uIGZhY2lsaXRhdGluZyB0aGUgaW50cm9kdWN0aW9uIG9mIG5ldw0K ICAgc2VydmljZXMuICBUaGUgZGVzaXJlZCwgYW5kIHByb3Bvc2VkLCBwcm9jZXNzaW5nIGJlaGF2 aW9yIG9mIHRoZSBIQkgNCiAgIGFuZCB0aGUgbWlncmF0aW9uIHN0cmF0ZWdpZXMgdG93YXJkcyBp dCBhcmUgYWxzbyBzdWdnZXN0ZWQuDQoNCllvdXIgcmV2aWV3IGFuZCBjb21tZW50cyBhcmUgdmVy eSB3ZWxjb21lZC4gVGhhbmsgeW91ISANCg0KQmVzdCByZWdhcmRzLA0KU2h1cGluZw0KDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiBTZW50OiBNb25kYXksIE9j dG9iZXIgMTIsIDIwMjAgMTE6NDEgQU0NCj4gVG86IExpemhlbmJpbiA8bGl6aGVuYmluQGh1YXdl aS5jb20+OyBQZW5nc2h1cGluZyAoUGVuZyBTaHVwaW5nKQ0KPiA8cGVuZ3NodXBpbmdAaHVhd2Vp LmNvbT4NCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1wZW5n LXY2b3BzLWhiaC0wMC50eHQNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt cGVuZy12Nm9wcy1oYmgtMDAudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseQ0KPiBzdWJtaXR0ZWQg YnkgU2h1cGluZyBQZW5nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+ IE5hbWU6CQlkcmFmdC1wZW5nLXY2b3BzLWhiaA0KPiBSZXZpc2lvbjoJMDANCj4gVGl0bGU6CQlQ cm9jZXNzaW5nIG9mIHRoZSBIb3AtYnktSG9wIE9wdGlvbnMgSGVhZGVyDQo+IERvY3VtZW50IGRh dGU6CTIwMjAtMTAtMTINCj4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gUGFnZXM6 CQkxMQ0KPiBVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtcGVu Zy12Nm9wcy1oYmgtMDAudHh0DQo+IFN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1wZW5nLXY2b3BzLWhiaC8NCj4gSHRtbGl6ZWQ6DQo+IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtcGVuZy12Nm9wcy1oYmgNCj4g SHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wZW5nLXY2 b3BzLWhiaC0wMA0KPiANCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIGRvY3VtZW50IGRlc2Ny aWJlcyB0aGUgcHJvY2Vzc2luZyBvZiB0aGUgSG9wLWJ5LUhvcCBPcHRpb25zDQo+ICAgIEhlYWRl ciBpbiB0b2RheSdzIHJvdXRlcnMgaW4gdGhlIGFzcGVjdHMgb2Ygc3RhbmRhcmRzIHNwZWNpZmlj YXRpb24sDQo+ICAgIGNvbW1vbiBpbXBsZW1lbnRhdGlvbnMsIGFuZCBkZWZhdWx0IG9wZXJhdGlv bnMuICBUaGlzIGRvY3VtZW50DQo+ICAgIG91dGxpbmVzIHRoZSByZWFzb25zIHdoeSB0aGUgSG9w LWJ5LUhvcCBPcHRpb25zIEhlYWRlciBpcyByYXJlbHkNCj4gICAgdXRpbGl6ZWQgaW4gY3VycmVu dCBuZXR3b3Jrcy4gIEluIGFkZGl0aW9uLCB0aGlzIGRvY3VtZW50IGRlc2NyaWJlcw0KPiAgICB3 aHkgdGhlIEhCSCBjb3VsZCBiZSB1c2VkIGFzIGEgcG93ZXJmdWwgbWVjaGFuaXNtIGFsbG93aW5n DQo+IGRlcGxveW1lbnQNCj4gICAgYW5kIG9wZXJhdGlvbnMgb2YgbmV3IHNlcnZpY2VzIHJlcXVp cmluZyBhIG1vcmUgb3B0aW1pemVkIHdheSB0bw0KPiAgICBsZXZlcmFnZSBuZXR3b3JrIHJlc291 cmNlcyBvZiBhbiBpbmZyYXN0cnVjdHVyZS4gIFRoZSBIb3AtYnktSG9wDQo+ICAgIE9wdGlvbnMg SGVhZGVyIGlzIHRha2VuIGludG8gY29uc2lkZXJhdGlvbiBhcyBhIHZhbHVhYmxlIGNvbnRhaW5l cg0KPiAgICBmb3IgY2FycnlpbmcgdGhlIGluZm9ybWF0aW9uIGZhY2lsaXRhdGluZyB0aGUgaW50 cm9kdWN0aW9uIG9mIG5ldw0KPiAgICBzZXJ2aWNlcy4gIFRoZSBkZXNpcmVkLCBhbmQgcHJvcG9z ZWQsIHByb2Nlc3NpbmcgYmVoYXZpb3Igb2YgdGhlIEhCSA0KPiAgICBhbmQgdGhlIG1pZ3JhdGlv biBzdHJhdGVnaWVzIHRvd2FyZHMgaXQgYXJlIGFsc28gc3VnZ2VzdGVkLg0KPiANCj4gDQo+IA0K PiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl cyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IFRoZSBJ RVRGIFNlY3JldGFyaWF0DQo+IA0KDQo= From nobody Mon Oct 12 07:12:50 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 97EFA3A0D86; Mon, 12 Oct 2020 07:12:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , "The IESG" , "Owen DeLong" , , , , X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160251196460.2096.9456610569317295405@ietfa.amsl.com> Date: Mon, 12 Oct 2020 07:12:44 -0700 From: IETF Secretariat Archived-At: Subject: [v6ops] Telechat 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: Mon, 12 Oct 2020 14:12:45 -0000 Placed on agenda for telechat - 2020-10-22 WARNING: This may not leave enough time for directorate reviews! Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-v6ops-slaac-renum/ From nobody Tue Oct 13 06:16: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 DC2253A0FBF; Tue, 13 Oct 2020 06:16:32 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=gmx.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 JGHGf7PXxmEw; Tue, 13 Oct 2020 06:16:29 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 531C83A0FC3; Tue, 13 Oct 2020 06:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1602594978; bh=MUlrod63sPpELBIXNdF+bF872lewdh9caqKmhRvovUQ=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=ciY5/pT5ENX+APzoyWmhhhVuhhd2pQsbd5tlfB8jQ/Jcku5+6U9NV0hlEFWrn9wIM EwIeVN3CR8+S7MzKho+o7YCx1xFrB9dtsAjV4DNQQknBkepF+XCZ3xPycHt5bDt9Fz u69DIZ1/7hHxZ/B8mFcwWk/N9jbDju/b4rWMazeA= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from ians-mbp-5.fritz.box ([78.35.192.234]) by mail.gmx.com (mrgmx104 [212.227.17.174]) with ESMTPSA (Nemesis) id 1MeCtj-1jsAfF2KLn-00bLxx; Tue, 13 Oct 2020 15:16:18 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: ianfarrer@gmx.com In-Reply-To: <19432.1602258078@localhost> Date: Tue, 13 Oct 2020 15:16:15 +0200 Cc: "Bernie Volz (volz)" , dhcwg , 6man , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: <644565BC-5818-4244-A34A-1B39C3FC9175@gmx.com> References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <19432.1602258078@localhost> To: Michael Richardson , Jen Linkova X-Mailer: Apple Mail (2.3445.104.15) X-Provags-ID: V03:K1:UObRgEoF2hwAUSAMwYsB+ZUJ8Bgw0o5lkof3H+RX9g4obm5MEnD Pli9CAql6xsh1sBYQmoqESh/W/75ySQ5WjrFjj1Pp7F3Y6Nq/8t8v2VHveM0dMiqU9GXMhl ghLNs7DKirVa9Y+col0ljo+KrVvBs0c2p0PcngqZEUqxWNQ4je7al2n1YMa2Y6zwcc/Bm+B pEtfFLRGCfxkU39MbtUfQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:AATCoIsjmAM=:neYXd+kRdGzY3S0kpB0aKA R2B28/XmAgqxNwOBofCWoDEDr4SM6rrFVN+J0OYTK4sgAksJvJr3E+PgW60bqzeeXt6/pg06P 8IgTpl4frn4LydUNsnsa58Vw2OHNSWphV8B1wKvS+D+egdHyDGBBtM/JtcSV8/0Yvl9YurBK0 qlB8VzBalcV1VQiIVa8ma4vNAkS0LDzusEaOmyXFTZN9Ejsvd5+XggzoiJU2X2HhuYdVYIvAa 5LPp9pCUvA1j9hoXqbyOxnDzBwSecPbEK/IJmFEPw7+aw9//TU+jvba6/qbNbdYfON8iqoh6Z OEMdLvZfucikBAP6u6rm7kekt5aLnIy8TdGVAB/rRnKRETjZxlok9GXdtfsl6v9WIdQXx6pwq Qj38UW45znZAPlzkeVgJa3nBkK5CY1nt2C3C0z46y2tkhmsgZvj0Q7UcVv2SwfPdfVGIziiuR KhUKxO6UJAvw3iovHHQkR35Hao4LsOk17/zcro+zSFEO1dy2AOJSjleTdkbU9kl/bQwQT5IdP dx37VINcAHEr/yre+vjyQRGSGl1Y7rXHuWQ6NFcXEQv+7GHieNAKDP6cmLOgzhqZXPVKniBjF cKjaXeCjg9SJUCEWI3iFEJNFyj8xs9O41bf0CgNBBgrQYG1nhKoK3IvSPQ6GK71EV+5h2ETeZ ZHU1pkXyYdw9zZxuBPeZKYSNcQDEYFmm91/oNtMqNhlZ+XckmrmdNBCglhQXQMXriV+6AgPsw tNHKIdy3mTE6b0bplOknC68HBI7pf0YTZTP/i5KNgokA7QeRKlPUtrICb6+GTxjzyy44UUUoo yapI1LjAceubu8nR9WxNc+YrQqB1Us/v33/rmnKvu05UZ0QEVF1WRZ11uGCzCZtb0KUpSCkvX t3qOhDw7XKmfdjbEj+I3qCFJVyC8+CI+kPUhRJGEi6CmmZxAr8AHMaj+BBZiYj0ezY1QTaLjw YP7Pic55uWpGM/Xv9nvXs6+fm8+qIHyGYDvAjJpnNj48zs3uJ3cW3nW7wv8o9lEbrXL6W8O5E HGUcFBu5M1lWdkZ4QYuQywXBHO3V3T/fBu6HGyYWkRo0Q4ZcRtzlIdXRBptbqjzBCBZL/JGqI USSTC985sfk7Pq6XwSE+9N0Rjf0ZLmMQo23b24xNXLP2vgRyhICzkITztQANga+qLR4UgZP24 HYZNH5Cj2XfazszcW3wlvoWm+HMLA542DasbR9lVSPa0fg2cbgfLMOcIhOsJogbm+PsPEtwPK Ls/CiI7HDXX8sAsoZ7Fnove82YeHD1l2+Pae/h7fHFmuOMO1nlviewMajrU8= Archived-At: Subject: Re: [v6ops] [dhcwg] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Tue, 13 Oct 2020 13:16:33 -0000 Hi, Thanks for all of the discussion on this. We=E2=80=99ve reworked the = requirement as follows: R-4 To prevent routing loops, the relay SHOULD implement a configurable = policy to drop client traffic as follows: For point-to-point links, when the = packet's=20 ingress and egress interfaces match. For multi-access links, when the = packet's=20 ingress and egress interface match, and the source MAC and next-hop MAC = addresses match. An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route = to destination) error message MAY be sent back to the client. The ICMP = policy SHOULD be configurable. Thanks, Ian > On 9. Oct 2020, at 17:41, Michael Richardson = wrote: >=20 >=20 > Jen Linkova wrote: >> I think there is confusion re: the scenario we are talking about. = I've >> attached the diagram for the case which concerns me. >> So: >> - The Relay R has an interface eth0 connected to a switch S. >> - Devices A and B are connected to the same switch and using R as a >> default gateway. >> - The prefix 2001:db8::/56 was delegated to a client A via the relay = R. >=20 > a friendly amendment to your example to aid in human comprehension: > } - The prefix 2001:db8:0000:0123:/64 was delegated to a client A = via the relay R. > } - R installs a route for 2001:db8:0000:0123:/64 towards A via = eth0. >=20 >> - The device B (which has an address NOT from the delegated prefix, >> but from another /64 assigned to that common link, let's sat >> 2001:db8:cafe::/64) sends a packet to an address from the delegated >=20 > now, my brain can more clearly see that 2001:db8:cafe::/64 is not > within 2001:db8:0000:0123:/64, while I had to use a few extra brain = cells to > see that it wasn't in that ::/56 :-) >=20 >> What I'd expect to happen (with DHCP-PD or without - e.g. if R has a >> static route towards A, not a dynamic route produced by PD): >> - the packet is sent to A. Well, if A does not have a route to >> 2001:db8::42 then indeed a routing loop might happen. But if A does >> have a route, the packet will be delivered. >=20 >> What seems to be required by R4: >> - R detects that the packet is received via eth0 and needs to be sent >> back to eth0. R4 seems to require such packets to be dropped. >> So if B would never be able to communicate to any address in the >> delegated prefix, right? >=20 >> Am I missing anything? >=20 > I think that you got it right. >=20 >>> Perhaps the missing piece of the rule is don=E2=80=99t send it back = to where it came from, based on link layer addresses (or link if = point-to-point). >=20 >> Yes. If R4 was saying 'drop the packet if it comes from the same >> link-layer address you are going to send it back' - it would make >> total sense. But I don't think routers do *that*. >=20 > Yes, if we made the check on L2 address, then it would work. > And I agree that routers are exactly doing that. >=20 > I think that it also works if B is a router with additional interfaces > downstream, unless there are multiple paths. >=20 > -- > Michael Richardson . o O ( IPv6 I=C3=B8T = consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Tue Oct 13 06:44: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 17E673A0FD2; Tue, 13 Oct 2020 06:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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_H4=0.001, RCVD_IN_MSPIKE_WL=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=Ott9PxSt; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=yb2v7weh Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1hO3EAg0SUi; Tue, 13 Oct 2020 06:44:49 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6DF3A0CDB; Tue, 13 Oct 2020 06:44:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6726; q=dns/txt; s=iport; t=1602596689; x=1603806289; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TGju4Ihr25zfBSiXhE5CI8MSgmEEyjVcxBPWIVUNCLY=; b=Ott9PxSt54r3h6nsv4dXG254lvpXtkh6pfLlV4kpjuJvYmPwYujr72mQ oUqRFqFpcKyvHv0QaGwVbup7L+jr2k/RYe2Ab1AajDZgyIsiI9swlX5Tu 5CP4SUYXYLV4rWJshExCO3cuPlm7uQ3N5MgWZaw/3U07+kLK/U190Jyst 8=; X-IPAS-Result: =?us-ascii?q?A0CbBgCaroVf/40NJK1gHgEBCxIMQIFEC4FSUQdwWS8sC?= =?us-ascii?q?oQzg0YDjVGKEY5qgS6BJQNVCwEBAQ0BARgLCgIEAQGBVYJ1AheBawIlNAkOA?= =?us-ascii?q?gMBAQEDAgMBAQEBBQEBAQIBBgRthVwMhXIBAQEBAgEBARAREQwBASwLAQQHB?= =?us-ascii?q?AIBCBEEAQEBAgIfBwICAh8GCxUICAIEAQ0FCBqDBYJLAw4gAQ6dPwKBOYhhd?= =?us-ascii?q?oEygwEBAQWFGQ0LghADBoEOKoJyg26GVhuCAIEQRIJNPoIaQgEBgWEVD4JxM?= =?us-ascii?q?4ItkCuDIqNIUgqCaZVfhS2hPZMmjV2SSQIEAgQFAg4BAQWBVDoqgS1wFTuCa?= =?us-ascii?q?VAXAg2OHwwXFIM6hRSFQnQ3AgYBCQEBAwl8jDsBgRABAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3ARUDXFRaoGTPign8JtPPjMQz/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaRD4re+7RPjO+F+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGF8PuIVbVpy764TsbAB?= =?us-ascii?q?6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw=3D=?= =?us-ascii?q?3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,370,1596499200"; d="scan'208";a="554222620" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Oct 2020 13:44:47 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 09DDilE4023261 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 13 Oct 2020 13:44:47 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 13 Oct 2020 08:44:47 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 13 Oct 2020 08:44:46 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 13 Oct 2020 09:44:46 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=O2Ge6hCZh/dlTk52Yf4I9vfzivHA/hK8wh7cWMSX7AoswMMgPtf4JpqcwhsnuVNMKveAAlZfezlS/TXwsHzzmHowy3x87DAIHSYsBqQALBCOBVIQU34Bsf7ZYZEOghIZg5xGKlGw+bkkCLfm9dCaW9Z02JiyWGfHQzcuNAPx/B2yNyVWlwm506hvJeN6UwYTX6+exi46hEKZCiK7VUReOCs4DqbAPBZqvlnt5vvBvujRYsy4eYMwVDAkILbdyz08M09SP7fV16Y7PmwpAxfr681pyIYD5UybVlgCKyehLHqBD7Wn/iIZFyECCIh3dOl61QngY0LNxkurxFNqcgqiLg== 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=TGju4Ihr25zfBSiXhE5CI8MSgmEEyjVcxBPWIVUNCLY=; b=ecPc0OIY8JVa9xCk8k1bgNfcc3nbbS6JMBBNlzZG1oYLD7SO91s7jOyks3m/YT1/IpIDXe7P4FfN5JmtuulmAl+xi9/yqRBchBU6LQhF1GXpfGf2xZa/1lRx80AHLwAQMwVNpK7qIBLDVh6cr9y4Gp9TVuaVnAyQ1HIRwSYCNL7YX2U0aSU2nRa4Z8LBXcqnw0UUSQ63kBMdQGwuK3SdQG0NYnVKGWW3qdGcsGUZjEMm/rA/Pm6i82lsQ74lyCk946UVr6vjqmLFDAEcXkg2zunSJvaiUCitfq3m0WiKv8OQx6iKXYgZ+lL38MOsnXJ/7563thWQvRvnQ2SEyLHTYw== 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=TGju4Ihr25zfBSiXhE5CI8MSgmEEyjVcxBPWIVUNCLY=; b=yb2v7wehxq2rDvdMpNyOu4ZvClWXTY0DhdDasSLCLxnkuRm+blUNUMID6yw/DYR2dfzyx1AaYc+LTIHzzIDMD9hUYvutse6VdKrckLOpE2nsZu2jRUjmwoiQ0WRDFgVB+0v1DDHv46llhW4e4Trv7M7Xl9PVZi51QG/qv3Undhg= Received: from BYAPR11MB2549.namprd11.prod.outlook.com (2603:10b6:a02:c4::33) by SJ0PR11MB5056.namprd11.prod.outlook.com (2603:10b6:a03:2d5::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.28; Tue, 13 Oct 2020 13:44:45 +0000 Received: from BYAPR11MB2549.namprd11.prod.outlook.com ([fe80::2cd2:d609:5fb7:4d27]) by BYAPR11MB2549.namprd11.prod.outlook.com ([fe80::2cd2:d609:5fb7:4d27%5]) with mapi id 15.20.3455.027; Tue, 13 Oct 2020 13:44:45 +0000 From: "Bernie Volz (volz)" To: "ianfarrer@gmx.com" , Michael Richardson , Jen Linkova CC: dhcwg , 6man , v6ops list Thread-Topic: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AQHWoWMb7h/SuZNgk0iBKtkQ2d57eamVg+CA Date: Tue, 13 Oct 2020 13:44:45 +0000 Message-ID: References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <19432.1602258078@localhost> <644565BC-5818-4244-A34A-1B39C3FC9175@gmx.com> In-Reply-To: <644565BC-5818-4244-A34A-1B39C3FC9175@gmx.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmx.com; dkim=none (message not signed) header.d=none;gmx.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.91] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 96ab03e1-92ea-45be-b789-08d86f7e2527 x-ms-traffictypediagnostic: SJ0PR11MB5056: 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: qYu5b20xfvKdCmpTSWtVlr+Y+yl/qtO8KLMwDExwZjSHXHwBqI7KFtgpZDqC2nlQPgK7QrlnhB7wyDB7Aj30U3E6xo8cTKyfHUaKCJEuzs9YwMiIPwct6syu65Kk6YhHs62AYaAooHdZV4DcpWsQiafIVh8SRzNFh7P+wCo+Y6zhXBOGIO7+RkV1+RV9qoZyrSajJEjlT2Cl6Jr4xjIgKPyKsZowhIVQm+hygg+L+8aaMGCMT/bv1W4zZJvC01DKBnA0JOBRiVih1Gljv8BkuFZRvbZs2Fkm+kMgBnvt2hQ2mIWS3OKVorr2vf4nPd6m4gSjWSSleLGv5+YA/ACjkmgoK/TW3p2CN39C3hCIpaWcT8hm8BBNCRw/96zttFw1qzQw3B73tnW+d7cImiYc1wYpc4WQoXRJMBXsjgxBru9VCRd6mKxVxYhnUnd6TRnHMppk4cMs3LRJ4p3F+fA3jQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2549.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(376002)(346002)(39860400002)(366004)(136003)(8676002)(110136005)(55016002)(9686003)(186003)(6506007)(53546011)(66574015)(966005)(478600001)(54906003)(316002)(26005)(7696005)(33656002)(66476007)(76116006)(66556008)(64756008)(66946007)(52536014)(2906002)(4326008)(66446008)(86362001)(5660300002)(83080400001)(83380400001)(8936002)(71200400001)(518174003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: hZkMU/umU+Ms0MAI8ot5fVyiRNP9+tEDMAbJTKLBNCdrLMseKzYNSbj8PPPzmu4/w0tFrZ4AS9iX0w5wrsA7kpTL2g28tWwKomJpsz+PqotSuOZkiRlf2ImV8PRfebcXOug/ltlXKGeKC7FoJucAEIJrJQgRZ+POc6b0lnFla1BIDQzce/ulqapg7UByiJxUoLPeVM2e5+Dn50RbA2I2GKRByKIBLbqVlwG03+XLE4n/VcQwq0R9J9AtbbDzJdMR5FixQ0xrhGYVtHILp/fhHN/glxYotqKlCeY28Po16YFjWZaIlzvYObizpxSOng41q5lq2u5MWnmDL8LnSF2X0FA1tXXndA9MPVErBta5npMH8s29eLW4XnDTYuAeeYZ5DWTUwQMriXf6XLTlwsivFBBJbagYmPO2LGKVh7H5S4GdKmdG5kaGGwpSQhOyGniKNG/X+NLLH4fRp3a/sH6EpFtm32l9lghc33x0B4ORbdCbkBvQCuPxAsrQPWQCi/3/ZF0jgz5Fa4itfgOKmxQiziItcDfuk1ZovxndVyolK6bmalkJCnE94MFAqx4wE6g/y1eLFhXRLFJIN/CXO2co1VIxgWn/KWLRQluzuDZghmWLs6TE84r8CUcTG+CKaxjyXrf5hCIYaviE9Ej0luPwMA== 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: BYAPR11MB2549.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 96ab03e1-92ea-45be-b789-08d86f7e2527 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2020 13:44:45.1098 (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: VhCIptX6nIKmE2q0Qre+eFxz6/cOZFSfdQTFq6IFP0lMFLpduo3bjpRoI0o1ECN9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB5056 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [v6ops] [dhcwg] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Tue, 13 Oct 2020 13:44:51 -0000 SGk6DQoNCkRvIHdlIGtub3cgdGhhdCB0aGlzIGlzICJjbGllbnQiIHRyYWZmaWM/IEFuZCB3aGF0 IGlzIHRoZSAiY2xpZW50IiAtIGVzcGVjaWFsbHkgZ2l2ZW4gaW4gdGhlIGNhc2UgdGhhdCBKZW4g c2hvd2VkLg0KDQpGb3IgYSBSRkM0NDQzIERlc3RpbmF0aW9uIFVucmVhY2hhYmxlIGFkZHJlc3Ms IHRoZSBJUHY2IGRlc3RpbmF0aW9uIGFkZHJlc3MgZmllbGQgaXMgYXMgZm9sbG93czoNCg0KICAg SVB2NiBGaWVsZHM6DQoNCiAgIERlc3RpbmF0aW9uIEFkZHJlc3MNCg0KICAgICAgICAgICAgICAg ICAgQ29waWVkIGZyb20gdGhlIFNvdXJjZSBBZGRyZXNzIGZpZWxkIG9mIHRoZSBpbnZva2luZw0K ICAgICAgICAgICAgICAgICAgcGFja2V0Lg0KDQpTbywgYXJlIHlvdSBjaGFuZ2luZyB0aGlzPw0K DQpJZiBub3QsIHBlcmhhcHMgd2UganVzdCBzYXk6DQoNClItNA0KVG8gcHJldmVudCByb3V0aW5n IGxvb3BzLCB0aGUgcmVsYXkgU0hPVUxEIGltcGxlbWVudCBhIGNvbmZpZ3VyYWJsZSBwb2xpY3kg dG8gZHJvcCB0cmFmZmljIHJlY2VpdmVkIGZyb20gYW4gdXBsaW5rIGludGVyZmFjZSBhcyBmb2xs b3dzOiAgRm9yIHBvaW50LXRvLXBvaW50IGxpbmtzLCB3aGVuIHRoZSBwYWNrZXQncyBpbmdyZXNz IGFuZCBlZ3Jlc3MgaW50ZXJmYWNlcyBtYXRjaC4gRm9yIG11bHRpLWFjY2VzcyBsaW5rcywgd2hl biB0aGUgcGFja2V0J3MgaW5ncmVzcyBhbmQgZWdyZXNzIGludGVyZmFjZSBtYXRjaCwgYW5kIHRo ZSBzb3VyY2UgTUFDIGFuZCBuZXh0LWhvcCBNQUMgYWRkcmVzc2VzIG1hdGNoLiBBbiBJQ01QdjYg VHlwZSAxLCBDb2RlIDYgKERlc3RpbmF0aW9uIFVucmVhY2hhYmxlLCByZWplY3Qgcm91dGUgdG8N CmRlc3RpbmF0aW9uKSBlcnJvciBtZXNzYWdlIE1BWSBiZSBzZW50IGFzIHBlciBbUkZDNDQ0M10s IHNlY3Rpb24gMy4xLiAgVGhlIElDTVAgcG9saWN5IFNIT1VMRCBiZSBjb25maWd1cmFibGUuDQoN Ci0gQmVybmllDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpYW5mYXJyZXJA Z214LmNvbSA8aWFuZmFycmVyQGdteC5jb20+IA0KU2VudDogVHVlc2RheSwgT2N0b2JlciAxMywg MjAyMCA5OjE2IEFNDQpUbzogTWljaGFlbCBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4u Y2E+OyBKZW4gTGlua292YSA8ZnVycnkxM0BnbWFpbC5jb20+DQpDYzogQmVybmllIFZvbHogKHZv bHopIDx2b2x6QGNpc2NvLmNvbT47IGRoY3dnIDxkaGN3Z0BpZXRmLm9yZz47IDZtYW4gPGlwdjZA aWV0Zi5vcmc+OyB2Nm9wcyBsaXN0IDx2Nm9wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbZGhj d2ddIFt2Nm9wc10gW0VYVEVSTkFMXSBSZTogUXVlc3Rpb24gdG8gREhDUHY2IFJlbGF5IEltcGxl bWVudG9ycyByZWdhcmRpbmcgZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LXBkLXJlbGF5LXJlcXVpcmVt ZW50cw0KDQpIaSwNCg0KVGhhbmtzIGZvciBhbGwgb2YgdGhlIGRpc2N1c3Npb24gb24gdGhpcy4g V2XigJl2ZSByZXdvcmtlZCB0aGUgcmVxdWlyZW1lbnQgYXMgZm9sbG93czoNCg0KUi00DQpUbyBw cmV2ZW50IHJvdXRpbmcgbG9vcHMsIHRoZSByZWxheSBTSE9VTEQgaW1wbGVtZW50IGEgY29uZmln dXJhYmxlIHBvbGljeSB0byBkcm9wIGNsaWVudCB0cmFmZmljIGFzIGZvbGxvd3M6ICBGb3IgcG9p bnQtdG8tcG9pbnQgbGlua3MsIHdoZW4gdGhlIHBhY2tldCdzIGluZ3Jlc3MgYW5kIGVncmVzcyBp bnRlcmZhY2VzIG1hdGNoLiBGb3IgbXVsdGktYWNjZXNzIGxpbmtzLCB3aGVuIHRoZSBwYWNrZXQn cyBpbmdyZXNzIGFuZCBlZ3Jlc3MgaW50ZXJmYWNlIG1hdGNoLCBhbmQgdGhlIHNvdXJjZSBNQUMg YW5kIG5leHQtaG9wIE1BQyBhZGRyZXNzZXMgbWF0Y2guIEFuIElDTVB2NiBUeXBlIDEsIENvZGUg NiAoRGVzdGluYXRpb24gVW5yZWFjaGFibGUsIHJlamVjdCByb3V0ZSB0bw0KZGVzdGluYXRpb24p IGVycm9yIG1lc3NhZ2UgTUFZIGJlIHNlbnQgYmFjayB0byB0aGUgY2xpZW50LiAgVGhlIElDTVAg cG9saWN5IFNIT1VMRCBiZSBjb25maWd1cmFibGUuDQoNClRoYW5rcywNCklhbg0KDQo+IE9uIDku IE9jdCAyMDIwLCBhdCAxNzo0MSwgTWljaGFlbCBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxt YW4uY2E+IHdyb3RlOg0KPiANCj4gDQo+IEplbiBMaW5rb3ZhIDxmdXJyeTEzQGdtYWlsLmNvbT4g d3JvdGU6DQo+PiBJIHRoaW5rIHRoZXJlIGlzIGNvbmZ1c2lvbiByZTogdGhlIHNjZW5hcmlvIHdl IGFyZSB0YWxraW5nIGFib3V0LiANCj4+IEkndmUgYXR0YWNoZWQgdGhlIGRpYWdyYW0gZm9yIHRo ZSBjYXNlIHdoaWNoIGNvbmNlcm5zIG1lLg0KPj4gU286DQo+PiAtIFRoZSBSZWxheSBSIGhhcyBh biBpbnRlcmZhY2UgZXRoMCBjb25uZWN0ZWQgdG8gYSBzd2l0Y2ggUy4NCj4+IC0gRGV2aWNlcyBB IGFuZCBCIGFyZSBjb25uZWN0ZWQgdG8gdGhlIHNhbWUgc3dpdGNoIGFuZCB1c2luZyBSIGFzIGEg DQo+PiBkZWZhdWx0IGdhdGV3YXkuDQo+PiAtIFRoZSBwcmVmaXggMjAwMTpkYjg6Oi81NiB3YXMg ZGVsZWdhdGVkIHRvIGEgY2xpZW50IEEgdmlhIHRoZSByZWxheSBSLg0KPiANCj4gYSBmcmllbmRs eSBhbWVuZG1lbnQgdG8geW91ciBleGFtcGxlIHRvIGFpZCBpbiBodW1hbiBjb21wcmVoZW5zaW9u Og0KPiAgICAgfSAtIFRoZSBwcmVmaXggMjAwMTpkYjg6MDAwMDowMTIzOi82NCB3YXMgZGVsZWdh dGVkIHRvIGEgY2xpZW50IEEgdmlhIHRoZSByZWxheSBSLg0KPiAgICAgfSAgLSBSIGluc3RhbGxz IGEgcm91dGUgZm9yIDIwMDE6ZGI4OjAwMDA6MDEyMzovNjQgdG93YXJkcyBBIHZpYSBldGgwLg0K PiANCj4+IC0gVGhlIGRldmljZSBCICh3aGljaCBoYXMgYW4gYWRkcmVzcyBOT1QgZnJvbSB0aGUg ZGVsZWdhdGVkIHByZWZpeCwgDQo+PiBidXQgZnJvbSBhbm90aGVyIC82NCBhc3NpZ25lZCB0byB0 aGF0IGNvbW1vbiBsaW5rLCBsZXQncyBzYXQNCj4+IDIwMDE6ZGI4OmNhZmU6Oi82NCkgc2VuZHMg YSBwYWNrZXQgdG8gYW4gYWRkcmVzcyBmcm9tIHRoZSBkZWxlZ2F0ZWQNCj4gDQo+IG5vdywgbXkg YnJhaW4gY2FuIG1vcmUgY2xlYXJseSBzZWUgdGhhdCAyMDAxOmRiODpjYWZlOjovNjQgaXMgbm90 IA0KPiB3aXRoaW4gMjAwMTpkYjg6MDAwMDowMTIzOi82NCwgd2hpbGUgSSBoYWQgdG8gdXNlIGEg ZmV3IGV4dHJhIGJyYWluIA0KPiBjZWxscyB0byBzZWUgdGhhdCBpdCB3YXNuJ3QgaW4gdGhhdCA6 Oi81NiA6LSkNCj4gDQo+PiBXaGF0IEknZCBleHBlY3QgdG8gaGFwcGVuICh3aXRoIERIQ1AtUEQg b3Igd2l0aG91dCAtIGUuZy4gaWYgUiBoYXMgYSANCj4+IHN0YXRpYyByb3V0ZSB0b3dhcmRzIEEs IG5vdCBhIGR5bmFtaWMgcm91dGUgcHJvZHVjZWQgYnkgUEQpOg0KPj4gLSB0aGUgcGFja2V0IGlz IHNlbnQgdG8gQS4gV2VsbCwgaWYgQSBkb2VzIG5vdCBoYXZlIGEgcm91dGUgdG8NCj4+IDIwMDE6 ZGI4Ojo0MiB0aGVuIGluZGVlZCBhIHJvdXRpbmcgbG9vcCBtaWdodCBoYXBwZW4uIEJ1dCBpZiBB IGRvZXMgDQo+PiBoYXZlIGEgcm91dGUsIHRoZSBwYWNrZXQgd2lsbCBiZSBkZWxpdmVyZWQuDQo+ IA0KPj4gV2hhdCBzZWVtcyB0byBiZSByZXF1aXJlZCBieSBSNDoNCj4+IC0gUiBkZXRlY3RzIHRo YXQgdGhlIHBhY2tldCBpcyByZWNlaXZlZCB2aWEgZXRoMCBhbmQgbmVlZHMgdG8gYmUgc2VudCAN Cj4+IGJhY2sgdG8gZXRoMC4gUjQgc2VlbXMgdG8gcmVxdWlyZSBzdWNoIHBhY2tldHMgdG8gYmUg ZHJvcHBlZC4NCj4+IFNvIGlmIEIgd291bGQgbmV2ZXIgYmUgYWJsZSB0byBjb21tdW5pY2F0ZSB0 byBhbnkgYWRkcmVzcyBpbiB0aGUgDQo+PiBkZWxlZ2F0ZWQgcHJlZml4LCByaWdodD8NCj4gDQo+ PiBBbSBJIG1pc3NpbmcgYW55dGhpbmc/DQo+IA0KPiBJIHRoaW5rIHRoYXQgeW91IGdvdCBpdCBy aWdodC4NCj4gDQo+Pj4gUGVyaGFwcyB0aGUgbWlzc2luZyBwaWVjZSBvZiB0aGUgcnVsZSBpcyBk b27igJl0IHNlbmQgaXQgYmFjayB0byB3aGVyZSBpdCBjYW1lIGZyb20sIGJhc2VkIG9uIGxpbmsg bGF5ZXIgYWRkcmVzc2VzIChvciBsaW5rIGlmIHBvaW50LXRvLXBvaW50KS4NCj4gDQo+PiBZZXMu IElmIFI0IHdhcyBzYXlpbmcgJ2Ryb3AgdGhlIHBhY2tldCBpZiBpdCBjb21lcyBmcm9tIHRoZSBz YW1lIA0KPj4gbGluay1sYXllciBhZGRyZXNzIHlvdSBhcmUgZ29pbmcgdG8gc2VuZCBpdCBiYWNr JyAtIGl0IHdvdWxkIG1ha2UgDQo+PiB0b3RhbCBzZW5zZS4gQnV0IEkgZG9uJ3QgdGhpbmsgcm91 dGVycyBkbyAqdGhhdCouDQo+IA0KPiBZZXMsIGlmIHdlIG1hZGUgdGhlIGNoZWNrIG9uIEwyIGFk ZHJlc3MsIHRoZW4gaXQgd291bGQgd29yay4NCj4gQW5kIEkgYWdyZWUgdGhhdCByb3V0ZXJzIGFy ZSBleGFjdGx5IGRvaW5nIHRoYXQuDQo+IA0KPiBJIHRoaW5rIHRoYXQgaXQgYWxzbyB3b3JrcyBp ZiBCIGlzIGEgcm91dGVyIHdpdGggYWRkaXRpb25hbCBpbnRlcmZhY2VzIA0KPiBkb3duc3RyZWFt LCB1bmxlc3MgdGhlcmUgYXJlIG11bHRpcGxlIHBhdGhzLg0KPiANCj4gLS0NCj4gTWljaGFlbCBS aWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+ICAgLiBvIE8gKCBJUHY2IEnDuFQgY29u c3VsdGluZyApDQo+ICAgICAgICAgICBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MgSW5jLCBPdHRh d2EgYW5kIFdvcmxkd2lkZQ0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSUVURiBJUHY2IHdvcmtpbmcg Z3JvdXAgbWFpbGluZyBsaXN0DQo+IGlwdjZAaWV0Zi5vcmcNCj4gQWRtaW5pc3RyYXRpdmUgUmVx dWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KDQo= From nobody Tue Oct 13 06:56: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 1E3D93A0C4A; Tue, 13 Oct 2020 06:56:04 -0700 (PDT) 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, 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=boeing.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 cfWNWrRs2_rb; Tue, 13 Oct 2020 06:56:01 -0700 (PDT) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 102FC3A0C17; Tue, 13 Oct 2020 06:56:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09DDtuDG024874; Tue, 13 Oct 2020 09:55:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602597358; bh=nBRmWCzZLXkAGThBPBPj98WAR/cuHx2jfpR62zuPaAk=; h=From:To:CC:Subject:Date:From; b=fXpyFqgB1uvXLG2lUk+XMqnJ3Kd4bSP9Kvcq+CQnnLYz/mkX2Mbe+skX8hcFBRUCd EuPejC0iXdPzv21e1a8ZKXUDEbB6qMMVx6a8dqoOqKiCRO9qFuHy8rlsn7drqMUsEQ 6mk14NtPMF70p2CfJh/GBX/YYcaT1q8YZzHb/zQ4LpQmR+Ich9KrmvXAlcRYuwBAq9 iIYCxZow8ZJ9kKqcVyHvcA+GWCHp4axLVf84JoBVBQvrq6uC/sQCVKjwfCBGj45GLY +lP/F7OKNFwMX4VCJ52oQN7ijxFJQPVJzrur7mC3X45GyMjWkBIMRX+TMQzGtS4/PK Z/tVx3Wg9px3A== Received: from XCH16-07-07.nos.boeing.com (xch16-07-07.nos.boeing.com [144.115.66.109]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09DDtrir024827 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 13 Oct 2020 09:55:53 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-07.nos.boeing.com (144.115.66.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Tue, 13 Oct 2020 06:55:52 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Tue, 13 Oct 2020 06:55:52 -0700 From: "Templin (US), Fred L" To: "ianfarrer@gmx.com" , Michael Richardson , Jen Linkova CC: dhcwg , v6ops list , "Bernie Volz (volz)" , 6man Thread-Topic: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AdahZz7s2M1crQrvQoqZsITGBawESA== Date: Tue, 13 Oct 2020 13:55:52 +0000 Message-ID: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: B6D58ADA975AFF8F673530ADAAA8053FAC117C098FA2FC854F677FA63D3D1A7F2000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [dhcwg] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Tue, 13 Oct 2020 13:56:04 -0000 SWFuLA0KDQo+IEZvciBtdWx0aS1hY2Nlc3MgbGlua3MsIHdoZW4gdGhlIHBhY2tldCdzDQo+IGlu Z3Jlc3MgYW5kIGVncmVzcyBpbnRlcmZhY2UgbWF0Y2gsIGFuZCB0aGUgc291cmNlIE1BQyBhbmQg bmV4dC1ob3AgTUFDIGFkZHJlc3Nlcw0KPiBtYXRjaC4NCg0KQXMgSSBzYWlkLCB0aGlzIGdldHMg dmVyeSB0cmlja3kgaWYgdGhlIGNsaWVudCBoYXMgbXVsdGlwbGUgTUFDcy4gSWYgQ2xpZW50IEEg aGFzIE1BQyBhZGRyZXNzZXMNCmExLCBhMiwgYTMsIGE0LCBldGMuIGl0IGJlY29tZXMgdmVyeSBk aWZmaWN1bHQgZm9yIHRoZSByZWxheSB0byBrbm93IHRoYXQgYSBwYWNrZXQgcmVjZWl2ZWQNCmZy b20gb25lIG9mIHRoZSBNQUMgYWRkcmVzc2VzIChlLmcuLCBhMSkgbXVzdCBub3QgYmUgc2VudCBi YWNrIHRvIGFub3RoZXIgb2YgdGhlIE1BQw0KYWRkcmVzc2VzIChlLmcuLCBhMykuIEkgdGhpbmsg YW5vdGhlciBmYWlsdXJlIGNhc2UgaXMgaWYgdGhlcmUgaXMgYSBwcm94eSBiZXR3ZWVuIHRoZSBj bGllbnQNCmFuZCByZWxheS4gSW4gdGhhdCBjYXNlLCB0aGUgcmVsYXkgd2lsbCBzZWUgdGhlIE1B QyBhZGRyZXNzIG9mIHRoZSBwcm94eSBhbmQgbm90IHRoZQ0KTUFDIGFkZHJlc3Mgb2YgY2xpZW50 IEEuIEFuZCwgaWYgdGhlcmUgd2VyZSBtdWx0aXBsZSBhZGRpdGlvbmFsIGNsaWVudHMgQiwgQywg RCwgZXRjLg0Kc2hhcmluZyB0aGUgc2FtZSBwcm94eSB0aGVuIHRoZSBwcm9wb3NlZCBjaGVjayBj b3VsZCBibG9jayBsZWdpdGltYXRlIHRyYWZmaWMuDQoNCkFzIEkgc2FpZCBiZWZvcmUsIEkgdGhp bmsgdGhlIGJldHRlciBmaXggaXMgdG8gaW5zdHJ1bWVudCB0aGUgY2xpZW50LiBJZiB0aGUgY2xp ZW50IHJlY2VpdmVzDQphIHBhY2tldCBvbiBpdHMgcmVsYXktZmFjaW5nIGludGVyZmFjZSwgYW5k IHRoZSByb3V0aW5nIHN5c3RlbSBkZXRlcm1pbmVzIHRoYXQgdGhlDQpwYWNrZXQgc2hvdWxkIGJl IGZvcndhcmRlZCBvdXQgdGhlIHNhbWUgaW50ZXJmYWNlIHZpYSBhIGRlZmF1bHQgcm91dGUsIHRo ZSBjbGllbnQNCm11c3QgZHJvcCB0aGUgcGFja2V0LiBUaGF0IHdheSwgdGhlIHJlbGF5IG5ldmVy IHNlZXMgYSBsb29wZWQgcGFja2V0LCBhbmQgdGhlcmUNCmlzIG5vIGV4dHJhbmVvdXMgdHJhZmZp YyBvbiB0aGUgY2xpZW50L3JlbGF5IGludGVyZmFjZS4NCg0KRnJlZA0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGRoY3dnIFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIGlhbmZhcnJlckBnbXguY29tDQo+IFNlbnQ6IFR1ZXNkYXksIE9j dG9iZXIgMTMsIDIwMjAgNjoxNiBBTQ0KPiBUbzogTWljaGFlbCBSaWNoYXJkc29uIDxtY3IraWV0 ZkBzYW5kZWxtYW4uY2E+OyBKZW4gTGlua292YSA8ZnVycnkxM0BnbWFpbC5jb20+DQo+IENjOiBk aGN3ZyA8ZGhjd2dAaWV0Zi5vcmc+OyB2Nm9wcyBsaXN0IDx2Nm9wc0BpZXRmLm9yZz47IEJlcm5p ZSBWb2x6ICh2b2x6KSA8dm9sej00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz47IDZtYW4NCj4g PGlwdjZAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbZGhjd2ddIFt2Nm9wc10gW0VYVEVSTkFM XSBSZTogUXVlc3Rpb24gdG8gREhDUHY2IFJlbGF5IEltcGxlbWVudG9ycyByZWdhcmRpbmcgZHJh ZnQtaWV0Zi1kaGMtZGhjcHY2LXBkLXJlbGF5LQ0KPiByZXF1aXJlbWVudHMNCj4gDQo+IEhpLA0K PiANCj4gVGhhbmtzIGZvciBhbGwgb2YgdGhlIGRpc2N1c3Npb24gb24gdGhpcy4gV2XigJl2ZSBy ZXdvcmtlZCB0aGUgcmVxdWlyZW1lbnQgYXMgZm9sbG93czoNCj4gDQo+IFItNA0KPiBUbyBwcmV2 ZW50IHJvdXRpbmcgbG9vcHMsIHRoZSByZWxheSBTSE9VTEQgaW1wbGVtZW50IGEgY29uZmlndXJh YmxlIHBvbGljeSB0bw0KPiBkcm9wIGNsaWVudCB0cmFmZmljIGFzIGZvbGxvd3M6ICBGb3IgcG9p bnQtdG8tcG9pbnQgbGlua3MsIHdoZW4gdGhlIHBhY2tldCdzDQo+IGluZ3Jlc3MgYW5kIGVncmVz cyBpbnRlcmZhY2VzIG1hdGNoLiBGb3IgbXVsdGktYWNjZXNzIGxpbmtzLCB3aGVuIHRoZSBwYWNr ZXQncw0KPiBpbmdyZXNzIGFuZCBlZ3Jlc3MgaW50ZXJmYWNlIG1hdGNoLCBhbmQgdGhlIHNvdXJj ZSBNQUMgYW5kIG5leHQtaG9wIE1BQyBhZGRyZXNzZXMNCj4gbWF0Y2guIEFuIElDTVB2NiBUeXBl IDEsIENvZGUgNiAoRGVzdGluYXRpb24gVW5yZWFjaGFibGUsIHJlamVjdCByb3V0ZSB0bw0KPiBk ZXN0aW5hdGlvbikgZXJyb3IgbWVzc2FnZSBNQVkgYmUgc2VudCBiYWNrIHRvIHRoZSBjbGllbnQu ICBUaGUgSUNNUCBwb2xpY3kNCj4gU0hPVUxEIGJlIGNvbmZpZ3VyYWJsZS4NCj4gDQo+IFRoYW5r cywNCj4gSWFuDQo+IA0KPiA+IE9uIDkuIE9jdCAyMDIwLCBhdCAxNzo0MSwgTWljaGFlbCBSaWNo YXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+IHdyb3RlOg0KPiA+DQo+ID4NCj4gPiBKZW4g TGlua292YSA8ZnVycnkxM0BnbWFpbC5jb20+IHdyb3RlOg0KPiA+PiBJIHRoaW5rIHRoZXJlIGlz IGNvbmZ1c2lvbiByZTogdGhlIHNjZW5hcmlvIHdlIGFyZSB0YWxraW5nIGFib3V0LiBJJ3ZlDQo+ ID4+IGF0dGFjaGVkIHRoZSBkaWFncmFtIGZvciB0aGUgY2FzZSB3aGljaCBjb25jZXJucyBtZS4N Cj4gPj4gU286DQo+ID4+IC0gVGhlIFJlbGF5IFIgaGFzIGFuIGludGVyZmFjZSBldGgwIGNvbm5l Y3RlZCB0byBhIHN3aXRjaCBTLg0KPiA+PiAtIERldmljZXMgQSBhbmQgQiBhcmUgY29ubmVjdGVk IHRvIHRoZSBzYW1lIHN3aXRjaCBhbmQgdXNpbmcgUiBhcyBhDQo+ID4+IGRlZmF1bHQgZ2F0ZXdh eS4NCj4gPj4gLSBUaGUgcHJlZml4IDIwMDE6ZGI4OjovNTYgd2FzIGRlbGVnYXRlZCB0byBhIGNs aWVudCBBIHZpYSB0aGUgcmVsYXkgUi4NCj4gPg0KPiA+IGEgZnJpZW5kbHkgYW1lbmRtZW50IHRv IHlvdXIgZXhhbXBsZSB0byBhaWQgaW4gaHVtYW4gY29tcHJlaGVuc2lvbjoNCj4gPiAgICAgfSAt IFRoZSBwcmVmaXggMjAwMTpkYjg6MDAwMDowMTIzOi82NCB3YXMgZGVsZWdhdGVkIHRvIGEgY2xp ZW50IEEgdmlhIHRoZSByZWxheSBSLg0KPiA+ICAgICB9ICAtIFIgaW5zdGFsbHMgYSByb3V0ZSBm b3IgMjAwMTpkYjg6MDAwMDowMTIzOi82NCB0b3dhcmRzIEEgdmlhIGV0aDAuDQo+ID4NCj4gPj4g LSBUaGUgZGV2aWNlIEIgKHdoaWNoIGhhcyBhbiBhZGRyZXNzIE5PVCBmcm9tIHRoZSBkZWxlZ2F0 ZWQgcHJlZml4LA0KPiA+PiBidXQgZnJvbSBhbm90aGVyIC82NCBhc3NpZ25lZCB0byB0aGF0IGNv bW1vbiBsaW5rLCBsZXQncyBzYXQNCj4gPj4gMjAwMTpkYjg6Y2FmZTo6LzY0KSBzZW5kcyBhIHBh Y2tldCB0byBhbiBhZGRyZXNzIGZyb20gdGhlIGRlbGVnYXRlZA0KPiA+DQo+ID4gbm93LCBteSBi cmFpbiBjYW4gbW9yZSBjbGVhcmx5IHNlZSB0aGF0IDIwMDE6ZGI4OmNhZmU6Oi82NCBpcyBub3QN Cj4gPiB3aXRoaW4gMjAwMTpkYjg6MDAwMDowMTIzOi82NCwgd2hpbGUgSSBoYWQgdG8gdXNlIGEg ZmV3IGV4dHJhIGJyYWluIGNlbGxzIHRvDQo+ID4gc2VlIHRoYXQgaXQgd2Fzbid0IGluIHRoYXQg OjovNTYgOi0pDQo+ID4NCj4gPj4gV2hhdCBJJ2QgZXhwZWN0IHRvIGhhcHBlbiAod2l0aCBESENQ LVBEIG9yIHdpdGhvdXQgLSBlLmcuIGlmIFIgaGFzIGENCj4gPj4gc3RhdGljIHJvdXRlIHRvd2Fy ZHMgQSwgbm90IGEgZHluYW1pYyByb3V0ZSBwcm9kdWNlZCBieSBQRCk6DQo+ID4+IC0gdGhlIHBh Y2tldCBpcyBzZW50IHRvIEEuIFdlbGwsIGlmIEEgZG9lcyBub3QgaGF2ZSBhIHJvdXRlIHRvDQo+ ID4+IDIwMDE6ZGI4Ojo0MiB0aGVuIGluZGVlZCBhIHJvdXRpbmcgbG9vcCBtaWdodCBoYXBwZW4u IEJ1dCBpZiBBIGRvZXMNCj4gPj4gaGF2ZSBhIHJvdXRlLCB0aGUgcGFja2V0IHdpbGwgYmUgZGVs aXZlcmVkLg0KPiA+DQo+ID4+IFdoYXQgc2VlbXMgdG8gYmUgcmVxdWlyZWQgYnkgUjQ6DQo+ID4+ IC0gUiBkZXRlY3RzIHRoYXQgdGhlIHBhY2tldCBpcyByZWNlaXZlZCB2aWEgZXRoMCBhbmQgbmVl ZHMgdG8gYmUgc2VudA0KPiA+PiBiYWNrIHRvIGV0aDAuIFI0IHNlZW1zIHRvIHJlcXVpcmUgc3Vj aCBwYWNrZXRzIHRvIGJlIGRyb3BwZWQuDQo+ID4+IFNvIGlmIEIgd291bGQgbmV2ZXIgYmUgYWJs ZSB0byBjb21tdW5pY2F0ZSB0byBhbnkgYWRkcmVzcyBpbiB0aGUNCj4gPj4gZGVsZWdhdGVkIHBy ZWZpeCwgcmlnaHQ/DQo+ID4NCj4gPj4gQW0gSSBtaXNzaW5nIGFueXRoaW5nPw0KPiA+DQo+ID4g SSB0aGluayB0aGF0IHlvdSBnb3QgaXQgcmlnaHQuDQo+ID4NCj4gPj4+IFBlcmhhcHMgdGhlIG1p c3NpbmcgcGllY2Ugb2YgdGhlIHJ1bGUgaXMgZG9u4oCZdCBzZW5kIGl0IGJhY2sgdG8gd2hlcmUg aXQgY2FtZSBmcm9tLCBiYXNlZCBvbiBsaW5rIGxheWVyIGFkZHJlc3NlcyAob3IgbGluayBpZiBw b2ludC10by0NCj4gcG9pbnQpLg0KPiA+DQo+ID4+IFllcy4gSWYgUjQgd2FzIHNheWluZyAnZHJv cCB0aGUgcGFja2V0IGlmIGl0IGNvbWVzIGZyb20gdGhlIHNhbWUNCj4gPj4gbGluay1sYXllciBh ZGRyZXNzIHlvdSBhcmUgZ29pbmcgdG8gc2VuZCBpdCBiYWNrJyAtIGl0IHdvdWxkIG1ha2UNCj4g Pj4gdG90YWwgc2Vuc2UuIEJ1dCBJIGRvbid0IHRoaW5rIHJvdXRlcnMgZG8gKnRoYXQqLg0KPiA+ DQo+ID4gWWVzLCBpZiB3ZSBtYWRlIHRoZSBjaGVjayBvbiBMMiBhZGRyZXNzLCB0aGVuIGl0IHdv dWxkIHdvcmsuDQo+ID4gQW5kIEkgYWdyZWUgdGhhdCByb3V0ZXJzIGFyZSBleGFjdGx5IGRvaW5n IHRoYXQuDQo+ID4NCj4gPiBJIHRoaW5rIHRoYXQgaXQgYWxzbyB3b3JrcyBpZiBCIGlzIGEgcm91 dGVyIHdpdGggYWRkaXRpb25hbCBpbnRlcmZhY2VzDQo+ID4gZG93bnN0cmVhbSwgdW5sZXNzIHRo ZXJlIGFyZSBtdWx0aXBsZSBwYXRocy4NCj4gPg0KPiA+IC0tDQo+ID4gTWljaGFlbCBSaWNoYXJk c29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+ICAgLiBvIE8gKCBJUHY2IEnDuFQgY29uc3VsdGlu ZyApDQo+ID4gICAgICAgICAgIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3JrcyBJbmMsIE90dGF3YSBh bmQgV29ybGR3aWRlDQo+ID4NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IElFVEYgSVB2NiB3b3JraW5n IGdyb3VwIG1haWxpbmcgbGlzdA0KPiA+IGlwdjZAaWV0Zi5vcmcNCj4gPiBBZG1pbmlzdHJhdGl2 ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+ ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IGRoY3dnIG1haWxpbmcgbGlzdA0KPiBkaGN3Z0BpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RoY3dnDQo= From nobody Tue Oct 13 09:08: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 54DCE3A082F; Tue, 13 Oct 2020 09:08:39 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=gmx.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 Mt8pYjBYuxZv; Tue, 13 Oct 2020 09:08:37 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 203103A0407; Tue, 13 Oct 2020 09:08:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1602605303; bh=xIjkzcCPUcnVtsylbB3z+2xF4jTsLZRD7rtXHeZMFQw=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=an1vaMxoQGaPk04qj0CELknKwyc5OyrzDL16KDDofOqsAslHvjKooH63U+wL3KHWX utGl4DQR1aCj2BXKNC7GhhBQNZ9+oK7EHM56kwIW/JjRqnMwBQbhxC8et3umEtRvcS Gr6M91orixV3YRUhawWWg9hjZ/Yn6UP6thbP4JJg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from ians-mbp-5.fritz.box ([78.35.192.234]) by mail.gmx.com (mrgmx104 [212.227.17.174]) with ESMTPSA (Nemesis) id 1MDysm-1ka6ba37XY-00A1UB; Tue, 13 Oct 2020 18:08:22 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: ianfarrer@gmx.com In-Reply-To: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> Date: Tue, 13 Oct 2020 18:08:19 +0200 Cc: Michael Richardson , Jen Linkova , dhcwg , v6ops list , "Bernie Volz (volz)" , 6man Content-Transfer-Encoding: quoted-printable Message-Id: <9C612486-C25D-463F-8FB4-5BAAF9A96AE5@gmx.com> References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> To: "Templin (US), Fred L" X-Mailer: Apple Mail (2.3445.104.15) X-Provags-ID: V03:K1:iLh6DyiSIal6NUjOWM0vsnWmFWJee8x9lkLPHkFLsZVNqB1IO+e /wwfS7fD5aD1bIoroopm6ozVxTAJdM8ozVJhCCgsh1gus0YwBCiMpIM0zdaRpjayk28UMgq vGk8A2TDtqoT5UivHitprdEzFd6Kjo2oPICt7CGruGfet8HBXNu/eaIszWhiIP35EauJIxy n1b2AOTcu0zrDOQwmRRDQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:0c42wfXtyiU=:r5xpJAtDhq5/WYoITZaGcw pvvpD82Cd4U9ZSa9Y3jgacCXEdpy9L9HKZgCLr0E3CR1Amzdq/b8CUbOSUtru7aYbqNzBGumv mLg7/pXEux4ER/J8xIrsnrL80CyViCptIBERbmJP/J2gLHtDJMCXXcuhvucfkBNM5zgawC6NH aZ45dKW3Qalgpa9UsqWPSKhAT+j44lr3dfQtnBueQVcyXuO+O+3teuHSuC8s5YaZVtqrB+TvE mDHzMmjeFhLR/DgN9wa7w36ohgEeACKcWWXvlW19+zLKA+sOvKmNpRmohg/7qQld+3pLlRqiC EuGSyfasty+/rKf4vWTBfo0FzgAGtKedheydTzVZlxgubj0NL4AZH/hwCF4tJAVS70BBTmPth 0uERZawflBk3dpBQPp7ONqNPfTB43FlJ4QayIwIoUS3+JEwFF1VLp9QXWLL330BumM3sQRgvR 1t2KcCGnS+axgMS9PUkpyKlM84uw/uOsFgWfR76U+WT6vOgHZ3Bgn/pO6ArAu5h83wFUsFJTp 0ugwfkJNbSZze2ioBrjox1gqkz0btCmV2mXYljXZ5SH3lZItVnzoNVf7gxMkuAB8SbZmwE6hE 6Rs2dR25fsWjPk1gfGLAs5JyDl7cTpKU/PB7+2DcjoE4Zr+WSUoK54cOsiO+/hK4PHYf1LJ/h vVdCngjm32axlD8BuJgzzZCEPHIRTSqIoAWe3Fxfvl6hAK/KjgmGzV0RYYeTP1tq9xaZLjtdQ dWcSvwAC/SkxE46ifdwBqpi9lZxd1ykmh0vQg1NvjZGQ3L3GfN43ndPrF8wylIh2hMSSR+/Md /P7jTF0VBLM+DNe2KMKyEfXjs87DUR2libipJGD2zqesfZ9yikEf9J8Cp2Pd76YLFDvZyIy0y XgMHAFOxlRxYQfwWlTTUVDdMl0W2CwHkNQ+r/ZkvEnDCNuTfei1ukALXKHUOkVQ+iXOrc1Opt 5wUDFHvmxqBoeOO4iDL8tBkzcBFPho6p/3T9fAUZqOk27Qw+vpOu3lgJOeXK0wNL1RYRBvkZI yfo5WRayTtLncqHtx05y53elWoePExqy3cS9WPsfFHWtK7UGi8auDd5elpvcnCV0Du9i4ey8l jPkm7qdAe6rMHbu44PrXbQG0o7FIZuro+aD60wuD2ROsL3Nc2VE3Ygg/rskFvRAuDle6S7QE9 PrNZQ10kVJo5r1WNPuZbyITQVwOMUxqj7mydTjZKPfZX72uahBHHqiLoXMdUKeKeRVgGPt0Eg GBmTi3Uh+ib99FBnrcczbeeYr+tpm6wLrpov9YgOFtw7SCct37GVRx2XWz0ZkJjkiNR7PgZ83 2+JnZsBv Archived-At: Subject: Re: [v6ops] [dhcwg] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Tue, 13 Oct 2020 16:08:40 -0000 HI Fred, Please see inline below. Thanks, Ian > On 13. Oct 2020, at 15:55, Templin (US), Fred L = wrote: >=20 > Ian, >=20 >> For multi-access links, when the packet's >> ingress and egress interface match, and the source MAC and next-hop = MAC addresses >> match. >=20 > As I said, this gets very tricky if the client has multiple MACs. If = Client A has MAC addresses > a1, a2, a3, a4, etc. it becomes very difficult for the relay to know = that a packet received > from one of the MAC addresses (e.g., a1) must not be sent back to = another of the MAC > addresses (e.g., a3). I think another failure case is if there is a = proxy between the client > and relay. In that case, the relay will see the MAC address of the = proxy and not the > MAC address of client A. And, if there were multiple additional = clients B, C, D, etc. > sharing the same proxy then the proposed check could block legitimate = traffic. [if - The client would have to source DHCP multicast messages from MAC = a3 and source egress traffic from MAC a1. Have you got an example of why = the client might be configured in this way?=20 Isn=E2=80=99t the worst case here that the results would be no different = to R-4 not existing, but for the (I would guess more common) single = client MAC address case, we can improve things? - For the proxy case, I can see the problem that you describe and in this = case, the best course of action would be to disable the drop policy.] >=20 > As I said before, I think the better fix is to instrument the client. = If the client receives > a packet on its relay-facing interface, and the routing system = determines that the > packet should be forwarded out the same interface via a default route, = the client > must drop the packet. That way, the relay never sees a looped packet, = and there > is no extraneous traffic on the client/relay interface. [if - There=E2=80=99s a couple of problems that this requirement is = trying to address: 1, A misbehaving client (accidentally or otherwise) 2, The volume of traffic being forwarded by the relay consumes the = available bandwidth meaning that DHCP configuration can=E2=80=99t complete In both cases, the client can=E2=80=99t be relied on to solve the = problem] >=20 > Fred >=20 >> -----Original Message----- >> From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of = ianfarrer@gmx.com >> Sent: Tuesday, October 13, 2020 6:16 AM >> To: Michael Richardson ; Jen Linkova = >> Cc: dhcwg ; v6ops list ; Bernie Volz = (volz) ; 6man >> >> Subject: Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DHCPv6 Relay = Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay- >> requirements >>=20 >> Hi, >>=20 >> Thanks for all of the discussion on this. We=E2=80=99ve reworked the = requirement as follows: >>=20 >> R-4 >> To prevent routing loops, the relay SHOULD implement a configurable = policy to >> drop client traffic as follows: For point-to-point links, when the = packet's >> ingress and egress interfaces match. For multi-access links, when the = packet's >> ingress and egress interface match, and the source MAC and next-hop = MAC addresses >> match. An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject = route to >> destination) error message MAY be sent back to the client. The ICMP = policy >> SHOULD be configurable. >>=20 >> Thanks, >> Ian >>=20 >>> On 9. Oct 2020, at 17:41, Michael Richardson = wrote: >>>=20 >>>=20 >>> Jen Linkova wrote: >>>> I think there is confusion re: the scenario we are talking about. = I've >>>> attached the diagram for the case which concerns me. >>>> So: >>>> - The Relay R has an interface eth0 connected to a switch S. >>>> - Devices A and B are connected to the same switch and using R as a >>>> default gateway. >>>> - The prefix 2001:db8::/56 was delegated to a client A via the = relay R. >>>=20 >>> a friendly amendment to your example to aid in human comprehension: >>> } - The prefix 2001:db8:0000:0123:/64 was delegated to a client A = via the relay R. >>> } - R installs a route for 2001:db8:0000:0123:/64 towards A via = eth0. >>>=20 >>>> - The device B (which has an address NOT from the delegated prefix, >>>> but from another /64 assigned to that common link, let's sat >>>> 2001:db8:cafe::/64) sends a packet to an address from the delegated >>>=20 >>> now, my brain can more clearly see that 2001:db8:cafe::/64 is not >>> within 2001:db8:0000:0123:/64, while I had to use a few extra brain = cells to >>> see that it wasn't in that ::/56 :-) >>>=20 >>>> What I'd expect to happen (with DHCP-PD or without - e.g. if R has = a >>>> static route towards A, not a dynamic route produced by PD): >>>> - the packet is sent to A. Well, if A does not have a route to >>>> 2001:db8::42 then indeed a routing loop might happen. But if A does >>>> have a route, the packet will be delivered. >>>=20 >>>> What seems to be required by R4: >>>> - R detects that the packet is received via eth0 and needs to be = sent >>>> back to eth0. R4 seems to require such packets to be dropped. >>>> So if B would never be able to communicate to any address in the >>>> delegated prefix, right? >>>=20 >>>> Am I missing anything? >>>=20 >>> I think that you got it right. >>>=20 >>>>> Perhaps the missing piece of the rule is don=E2=80=99t send it = back to where it came from, based on link layer addresses (or link if = point-to- >> point). >>>=20 >>>> Yes. If R4 was saying 'drop the packet if it comes from the same >>>> link-layer address you are going to send it back' - it would make >>>> total sense. But I don't think routers do *that*. >>>=20 >>> Yes, if we made the check on L2 address, then it would work. >>> And I agree that routers are exactly doing that. >>>=20 >>> I think that it also works if B is a router with additional = interfaces >>> downstream, unless there are multiple paths. >>>=20 >>> -- >>> Michael Richardson . o O ( IPv6 I=C3=B8T = consulting ) >>> Sandelman Software Works Inc, Ottawa and Worldwide >>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg From nobody Tue Oct 13 09:42: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 6013B3A09DB; Tue, 13 Oct 2020 09:42:14 -0700 (PDT) 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, RCVD_IN_MSPIKE_H2=-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=boeing.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 ks4vIdiQfGoW; Tue, 13 Oct 2020 09:42:12 -0700 (PDT) Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 2E1D23A09CC; Tue, 13 Oct 2020 09:42:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09DGg5sZ031670; Tue, 13 Oct 2020 12:42:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602607330; bh=Q14ZRlMrvxSzp0SUJGSGPg4EDjomy1SdfLeDfXPtPhA=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=mSllvAULmtt7gjiOFufmhojVQKejG6xp9xAevqGhNv51zn4Ek4MeFAyQ8YBURnhSj x45cUWZXja9HDg2AXz0Qo3Ru4rFXVxzQu0AZaH8Titqn1B725vrb/Nljp3wmjtZ3N2 6l2x61dTjtkrTqnRrDqE5TPmuyZ/ThvhJS6QPZ5pimMYSywrMAnM/KDHZTXU0NNzqF SORxnM7MkcG92QyMnuApqMlipFbpcu9fC3Azj9wMg2FvhVI8/nQGC6QVnk/sBv3KTg PjQ8Ds6gGs8ZsBQDc43vbsFqy/CBtW2OFabRacE9uCyEyLQOR7wqjL6SM2ik24/R90 D1FetQHkXf1JA== Received: from XCH16-07-10.nos.boeing.com (xch16-07-10.nos.boeing.com [144.115.66.112]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09DGg2bp031350 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 13 Oct 2020 12:42:02 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-10.nos.boeing.com (144.115.66.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Tue, 13 Oct 2020 09:42:01 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Tue, 13 Oct 2020 09:42:01 -0700 From: "Templin (US), Fred L" To: "ianfarrer@gmx.com" CC: Michael Richardson , Jen Linkova , dhcwg , v6ops list , "Bernie Volz (volz)" , 6man Thread-Topic: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AdahZz7s2M1crQrvQoqZsITGBawESAATn5SAAA4dvgA= Date: Tue, 13 Oct 2020 16:42:01 +0000 Message-ID: <86d4e46a49c046dfabd1375210fefbce@boeing.com> References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> <9C612486-C25D-463F-8FB4-5BAAF9A96AE5@gmx.com> In-Reply-To: <9C612486-C25D-463F-8FB4-5BAAF9A96AE5@gmx.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 338B30B65CABCC84017E479834CE865B2967EEF4F532FC53FC2650F852FFBAD92000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [EXTERNAL] Re: [dhcwg] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Tue, 13 Oct 2020 16:42:14 -0000 SGkgSWFuLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGlhbmZhcnJl ckBnbXguY29tIFttYWlsdG86aWFuZmFycmVyQGdteC5jb21dDQo+IFNlbnQ6IFR1ZXNkYXksIE9j dG9iZXIgMTMsIDIwMjAgOTowOCBBTQ0KPiBUbzogVGVtcGxpbiAoVVMpLCBGcmVkIEwgPEZyZWQu TC5UZW1wbGluQGJvZWluZy5jb20+DQo+IENjOiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitpZXRm QHNhbmRlbG1hbi5jYT47IEplbiBMaW5rb3ZhIDxmdXJyeTEzQGdtYWlsLmNvbT47IGRoY3dnIDxk aGN3Z0BpZXRmLm9yZz47IHY2b3BzIGxpc3QNCj4gPHY2b3BzQGlldGYub3JnPjsgQmVybmllIFZv bHogKHZvbHopIDx2b2x6PTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPjsgNm1hbiA8aXB2NkBp ZXRmLm9yZz4NCj4gU3ViamVjdDogW0VYVEVSTkFMXSBSZTogW2RoY3dnXSBbdjZvcHNdIFJlOiBR dWVzdGlvbiB0byBESENQdjYgUmVsYXkgSW1wbGVtZW50b3JzIHJlZ2FyZGluZyBkcmFmdC1pZXRm LWRoYy1kaGNwdjYtcGQtcmVsYXktDQo+IHJlcXVpcmVtZW50cw0KPiANCj4gVGhpcyBtZXNzYWdl IHdhcyBzZW50IGZyb20gb3V0c2lkZSBvZiBCb2VpbmcuIFBsZWFzZSBkbyBub3QgY2xpY2sgbGlu a3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IHJlY29nbml6ZSB0aGUgc2VuZGVyIGFu ZA0KPiBrbm93IHRoYXQgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCj4gDQo+IA0KPiBISSBGcmVkLA0K PiANCj4gUGxlYXNlIHNlZSBpbmxpbmUgYmVsb3cuDQo+IA0KPiBUaGFua3MsDQo+IElhbg0KPiAN Cj4gPiBPbiAxMy4gT2N0IDIwMjAsIGF0IDE1OjU1LCBUZW1wbGluIChVUyksIEZyZWQgTCA8RnJl ZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBJYW4sDQo+ID4NCj4gPj4g Rm9yIG11bHRpLWFjY2VzcyBsaW5rcywgd2hlbiB0aGUgcGFja2V0J3MNCj4gPj4gaW5ncmVzcyBh bmQgZWdyZXNzIGludGVyZmFjZSBtYXRjaCwgYW5kIHRoZSBzb3VyY2UgTUFDIGFuZCBuZXh0LWhv cCBNQUMgYWRkcmVzc2VzDQo+ID4+IG1hdGNoLg0KPiA+DQo+ID4gQXMgSSBzYWlkLCB0aGlzIGdl dHMgdmVyeSB0cmlja3kgaWYgdGhlIGNsaWVudCBoYXMgbXVsdGlwbGUgTUFDcy4gSWYgQ2xpZW50 IEEgaGFzIE1BQyBhZGRyZXNzZXMNCj4gPiBhMSwgYTIsIGEzLCBhNCwgZXRjLiBpdCBiZWNvbWVz IHZlcnkgZGlmZmljdWx0IGZvciB0aGUgcmVsYXkgdG8ga25vdyB0aGF0IGEgcGFja2V0IHJlY2Vp dmVkDQo+ID4gZnJvbSBvbmUgb2YgdGhlIE1BQyBhZGRyZXNzZXMgKGUuZy4sIGExKSBtdXN0IG5v dCBiZSBzZW50IGJhY2sgdG8gYW5vdGhlciBvZiB0aGUgTUFDDQo+ID4gYWRkcmVzc2VzIChlLmcu LCBhMykuIEkgdGhpbmsgYW5vdGhlciBmYWlsdXJlIGNhc2UgaXMgaWYgdGhlcmUgaXMgYSBwcm94 eSBiZXR3ZWVuIHRoZSBjbGllbnQNCj4gPiBhbmQgcmVsYXkuIEluIHRoYXQgY2FzZSwgdGhlIHJl bGF5IHdpbGwgc2VlIHRoZSBNQUMgYWRkcmVzcyBvZiB0aGUgcHJveHkgYW5kIG5vdCB0aGUNCj4g PiBNQUMgYWRkcmVzcyBvZiBjbGllbnQgQS4gQW5kLCBpZiB0aGVyZSB3ZXJlIG11bHRpcGxlIGFk ZGl0aW9uYWwgY2xpZW50cyBCLCBDLCBELCBldGMuDQo+ID4gc2hhcmluZyB0aGUgc2FtZSBwcm94 eSB0aGVuIHRoZSBwcm9wb3NlZCBjaGVjayBjb3VsZCBibG9jayBsZWdpdGltYXRlIHRyYWZmaWMu DQo+IA0KPiBbaWYgLSBUaGUgY2xpZW50IHdvdWxkIGhhdmUgdG8gc291cmNlIERIQ1AgbXVsdGlj YXN0IG1lc3NhZ2VzIGZyb20gTUFDIGEzIGFuZCBzb3VyY2UgZWdyZXNzIHRyYWZmaWMgZnJvbSBN QUMgYTEuIEhhdmUgeW91IGdvdCBhbg0KPiBleGFtcGxlIG9mIHdoeSB0aGUgY2xpZW50IG1pZ2h0 IGJlIGNvbmZpZ3VyZWQgaW4gdGhpcyB3YXk/DQoNCkl0IGlzIGNhbGxlZCAibXVsdGlsaW5rIiwg YW5kIHNvbWUgaW50ZXJmYWNlcyB0eXBlcyBzdWNoIGFzIE9NTkkgdW5kZXJzdGFuZA0KaG93IHRv IGRvIG11bHRpbGluayB3aGVyZSB0aGUgdXBzdHJlYW0gYW5kIGRvd25zdHJlYW0gTUFDIGFkZHJl c3Nlcw0KbWF5IGJlIGFzeW1tZXRyaWMuDQoNCj4gSXNu4oCZdCB0aGUgd29yc3QgY2FzZSBoZXJl IHRoYXQgdGhlIHJlc3VsdHMgd291bGQgYmUgbm8gZGlmZmVyZW50IHRvIFItNCBub3QgZXhpc3Rp bmcsIGJ1dCBmb3IgdGhlIChJIHdvdWxkIGd1ZXNzIG1vcmUgY29tbW9uKSBzaW5nbGUNCj4gY2xp ZW50IE1BQyBhZGRyZXNzIGNhc2UsIHdlIGNhbiBpbXByb3ZlIHRoaW5ncz8NCiANCkV2ZW4gd2l0 aCB0aGUgc2luZ2xlIGNsaWVudCBNQUMgYWRkcmVzcyBjYXNlLCBpdCB3b3VsZCBub3Qgd29yayBp ZiB0aGVyZSB3ZXJlIGEgcHJveHkuDQoNCj4gRm9yIHRoZSBwcm94eSBjYXNlLCBJIGNhbiBzZWUg dGhlIHByb2JsZW0gdGhhdCB5b3UgZGVzY3JpYmUgYW5kIGluIHRoaXMgY2FzZSwgdGhlIGJlc3QN Cj4gY291cnNlIG9mIGFjdGlvbiB3b3VsZCBiZSB0byBkaXNhYmxlIHRoZSBkcm9wIHBvbGljeS5d DQoNCkkgdGhpbmsgdGhlIHByb3h5IGNhc2UgaXMgcmVhbCwgYW5kIG1heSBiZSBxdWl0ZSBjb21t b24gZm9yIHNvbWUgaW50ZXJmYWNlIHR5cGVzLg0KDQo+ID4gQXMgSSBzYWlkIGJlZm9yZSwgSSB0 aGluayB0aGUgYmV0dGVyIGZpeCBpcyB0byBpbnN0cnVtZW50IHRoZSBjbGllbnQuIElmIHRoZSBj bGllbnQgcmVjZWl2ZXMNCj4gPiBhIHBhY2tldCBvbiBpdHMgcmVsYXktZmFjaW5nIGludGVyZmFj ZSwgYW5kIHRoZSByb3V0aW5nIHN5c3RlbSBkZXRlcm1pbmVzIHRoYXQgdGhlDQo+ID4gcGFja2V0 IHNob3VsZCBiZSBmb3J3YXJkZWQgb3V0IHRoZSBzYW1lIGludGVyZmFjZSB2aWEgYSBkZWZhdWx0 IHJvdXRlLCB0aGUgY2xpZW50DQo+ID4gbXVzdCBkcm9wIHRoZSBwYWNrZXQuIFRoYXQgd2F5LCB0 aGUgcmVsYXkgbmV2ZXIgc2VlcyBhIGxvb3BlZCBwYWNrZXQsIGFuZCB0aGVyZQ0KPiA+IGlzIG5v IGV4dHJhbmVvdXMgdHJhZmZpYyBvbiB0aGUgY2xpZW50L3JlbGF5IGludGVyZmFjZS4NCj4gDQo+ IFtpZiAtIFRoZXJl4oCZcyBhIGNvdXBsZSBvZiBwcm9ibGVtcyB0aGF0IHRoaXMgcmVxdWlyZW1l bnQgaXMgdHJ5aW5nIHRvIGFkZHJlc3M6DQo+IA0KPiAxLCBBIG1pc2JlaGF2aW5nIGNsaWVudCAo YWNjaWRlbnRhbGx5IG9yIG90aGVyd2lzZSkNCg0KVGhlIGNoZWNrIEkgb3V0bGluZWQgcHJldmVu dHMgdGhlIGFjY2lkZW50YWwgY2FzZS4gQSBtaXNiZWhhdmluZyBjbGllbnQgdGhhdA0KcmVjZWl2 ZXMgYSBsZWdpdGltYXRlIHByZWZpeCBkZWxlZ2F0aW9uIGFuZCB0aGVuIHByb2NlZWRzIHRvIGRv IGJhZCB0aGluZ3MNCndpdGggaXQgaXMgb25lIHdobyBzaG91bGQgYmUgZGVuaWVkIHNlcnZpY2Ug aW4gdGhlIGZ1dHVyZS4NCg0KQnV0IGluIHRlcm1zIG9mIGEgbWlzYmVoYXZpbmcgY2xpZW50LCBo b3cgd291bGQgdGhpcyBiZSBhbnkgZGlmZmVyZW50IHRoYW4gdGhlDQpjYXNlIHdoZXJlIGEgc3R1 YiByb3V0ZXIgdXNlcyBhIHJvdXRpbmcgcHJvdG9jb2wgKFJJUCwgT1NQRiwgZXRjLikgYW5kIGFk dmVydGlzZXMNCmEgcHJlZml4IHRoYXQgY2F1c2VzIHRoZSB1cHN0cmVhbSByb3V0ZXIgdG8gYWRk IHRoZSBwcmVmaXggdG8gdGhlIFJJQi9GSUIsIGJ1dA0KdGhlbiB0aGUgc3R1YiByb3V0ZXIgc2Vu ZHMgYmFkIHNlbGYtYWRkcmVzc2VkIHRyYWZmaWMgdG8gdGhlIHVwc3RyZWFtIHJvdXRlcg0KY2F1 c2luZyBhIHBpbmctcG9uZ2luZyBsb29wPw0KDQo+IDIsIFRoZSB2b2x1bWUgb2YgdHJhZmZpYyBi ZWluZyBmb3J3YXJkZWQgYnkgdGhlIHJlbGF5IGNvbnN1bWVzIHRoZSBhdmFpbGFibGUgYmFuZHdp ZHRoIG1lYW5pbmcNCj4gdGhhdCBESENQIGNvbmZpZ3VyYXRpb24gY2Fu4oCZdCBjb21wbGV0ZQ0K PiANCj4gSW4gYm90aCBjYXNlcywgdGhlIGNsaWVudCBjYW7igJl0IGJlIHJlbGllZCBvbiB0byBz b2x2ZSB0aGUgcHJvYmxlbV0NCg0KSG93IGRvIHJvdXRpbmcgcHJvdG9jb2xzIChSSVAsIE9TUEYs IGV0Yy4pIGFkZHJlc3MgdGhlIG1pc2JlaGF2aW5nIHN0dWINCnJvdXRlciBjYXNlPw0KDQpUaGFu a3MgLSBGcmVkDQoNCiA+IA0KPiA+DQo+ID4gRnJlZA0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IGRoY3dnIFttYWlsdG86ZGhjd2ctYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIGlhbmZhcnJlckBnbXguY29tDQo+ID4+IFNlbnQ6IFR1ZXNkYXks IE9jdG9iZXIgMTMsIDIwMjAgNjoxNiBBTQ0KPiA+PiBUbzogTWljaGFlbCBSaWNoYXJkc29uIDxt Y3IraWV0ZkBzYW5kZWxtYW4uY2E+OyBKZW4gTGlua292YSA8ZnVycnkxM0BnbWFpbC5jb20+DQo+ ID4+IENjOiBkaGN3ZyA8ZGhjd2dAaWV0Zi5vcmc+OyB2Nm9wcyBsaXN0IDx2Nm9wc0BpZXRmLm9y Zz47IEJlcm5pZSBWb2x6ICh2b2x6KSA8dm9sej00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz47 IDZtYW4NCj4gPj4gPGlwdjZAaWV0Zi5vcmc+DQo+ID4+IFN1YmplY3Q6IFJlOiBbZGhjd2ddIFt2 Nm9wc10gW0VYVEVSTkFMXSBSZTogUXVlc3Rpb24gdG8gREhDUHY2IFJlbGF5IEltcGxlbWVudG9y cyByZWdhcmRpbmcgZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LXBkLXJlbGF5LQ0KPiA+PiByZXF1aXJl bWVudHMNCj4gPj4NCj4gPj4gSGksDQo+ID4+DQo+ID4+IFRoYW5rcyBmb3IgYWxsIG9mIHRoZSBk aXNjdXNzaW9uIG9uIHRoaXMuIFdl4oCZdmUgcmV3b3JrZWQgdGhlIHJlcXVpcmVtZW50IGFzIGZv bGxvd3M6DQo+ID4+DQo+ID4+IFItNA0KPiA+PiBUbyBwcmV2ZW50IHJvdXRpbmcgbG9vcHMsIHRo ZSByZWxheSBTSE9VTEQgaW1wbGVtZW50IGEgY29uZmlndXJhYmxlIHBvbGljeSB0bw0KPiA+PiBk cm9wIGNsaWVudCB0cmFmZmljIGFzIGZvbGxvd3M6ICBGb3IgcG9pbnQtdG8tcG9pbnQgbGlua3Ms IHdoZW4gdGhlIHBhY2tldCdzDQo+ID4+IGluZ3Jlc3MgYW5kIGVncmVzcyBpbnRlcmZhY2VzIG1h dGNoLiBGb3IgbXVsdGktYWNjZXNzIGxpbmtzLCB3aGVuIHRoZSBwYWNrZXQncw0KPiA+PiBpbmdy ZXNzIGFuZCBlZ3Jlc3MgaW50ZXJmYWNlIG1hdGNoLCBhbmQgdGhlIHNvdXJjZSBNQUMgYW5kIG5l eHQtaG9wIE1BQyBhZGRyZXNzZXMNCj4gPj4gbWF0Y2guIEFuIElDTVB2NiBUeXBlIDEsIENvZGUg NiAoRGVzdGluYXRpb24gVW5yZWFjaGFibGUsIHJlamVjdCByb3V0ZSB0bw0KPiA+PiBkZXN0aW5h dGlvbikgZXJyb3IgbWVzc2FnZSBNQVkgYmUgc2VudCBiYWNrIHRvIHRoZSBjbGllbnQuICBUaGUg SUNNUCBwb2xpY3kNCj4gPj4gU0hPVUxEIGJlIGNvbmZpZ3VyYWJsZS4NCj4gPj4NCj4gPj4gVGhh bmtzLA0KPiA+PiBJYW4NCj4gPj4NCj4gPj4+IE9uIDkuIE9jdCAyMDIwLCBhdCAxNzo0MSwgTWlj aGFlbCBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+IHdyb3RlOg0KPiA+Pj4NCj4g Pj4+DQo+ID4+PiBKZW4gTGlua292YSA8ZnVycnkxM0BnbWFpbC5jb20+IHdyb3RlOg0KPiA+Pj4+ IEkgdGhpbmsgdGhlcmUgaXMgY29uZnVzaW9uIHJlOiB0aGUgc2NlbmFyaW8gd2UgYXJlIHRhbGtp bmcgYWJvdXQuIEkndmUNCj4gPj4+PiBhdHRhY2hlZCB0aGUgZGlhZ3JhbSBmb3IgdGhlIGNhc2Ug d2hpY2ggY29uY2VybnMgbWUuDQo+ID4+Pj4gU286DQo+ID4+Pj4gLSBUaGUgUmVsYXkgUiBoYXMg YW4gaW50ZXJmYWNlIGV0aDAgY29ubmVjdGVkIHRvIGEgc3dpdGNoIFMuDQo+ID4+Pj4gLSBEZXZp Y2VzIEEgYW5kIEIgYXJlIGNvbm5lY3RlZCB0byB0aGUgc2FtZSBzd2l0Y2ggYW5kIHVzaW5nIFIg YXMgYQ0KPiA+Pj4+IGRlZmF1bHQgZ2F0ZXdheS4NCj4gPj4+PiAtIFRoZSBwcmVmaXggMjAwMTpk Yjg6Oi81NiB3YXMgZGVsZWdhdGVkIHRvIGEgY2xpZW50IEEgdmlhIHRoZSByZWxheSBSLg0KPiA+ Pj4NCj4gPj4+IGEgZnJpZW5kbHkgYW1lbmRtZW50IHRvIHlvdXIgZXhhbXBsZSB0byBhaWQgaW4g aHVtYW4gY29tcHJlaGVuc2lvbjoNCj4gPj4+ICAgIH0gLSBUaGUgcHJlZml4IDIwMDE6ZGI4OjAw MDA6MDEyMzovNjQgd2FzIGRlbGVnYXRlZCB0byBhIGNsaWVudCBBIHZpYSB0aGUgcmVsYXkgUi4N Cj4gPj4+ICAgIH0gIC0gUiBpbnN0YWxscyBhIHJvdXRlIGZvciAyMDAxOmRiODowMDAwOjAxMjM6 LzY0IHRvd2FyZHMgQSB2aWEgZXRoMC4NCj4gPj4+DQo+ID4+Pj4gLSBUaGUgZGV2aWNlIEIgKHdo aWNoIGhhcyBhbiBhZGRyZXNzIE5PVCBmcm9tIHRoZSBkZWxlZ2F0ZWQgcHJlZml4LA0KPiA+Pj4+ IGJ1dCBmcm9tIGFub3RoZXIgLzY0IGFzc2lnbmVkIHRvIHRoYXQgY29tbW9uIGxpbmssIGxldCdz IHNhdA0KPiA+Pj4+IDIwMDE6ZGI4OmNhZmU6Oi82NCkgc2VuZHMgYSBwYWNrZXQgdG8gYW4gYWRk cmVzcyBmcm9tIHRoZSBkZWxlZ2F0ZWQNCj4gPj4+DQo+ID4+PiBub3csIG15IGJyYWluIGNhbiBt b3JlIGNsZWFybHkgc2VlIHRoYXQgMjAwMTpkYjg6Y2FmZTo6LzY0IGlzIG5vdA0KPiA+Pj4gd2l0 aGluIDIwMDE6ZGI4OjAwMDA6MDEyMzovNjQsIHdoaWxlIEkgaGFkIHRvIHVzZSBhIGZldyBleHRy YSBicmFpbiBjZWxscyB0bw0KPiA+Pj4gc2VlIHRoYXQgaXQgd2Fzbid0IGluIHRoYXQgOjovNTYg Oi0pDQo+ID4+Pg0KPiA+Pj4+IFdoYXQgSSdkIGV4cGVjdCB0byBoYXBwZW4gKHdpdGggREhDUC1Q RCBvciB3aXRob3V0IC0gZS5nLiBpZiBSIGhhcyBhDQo+ID4+Pj4gc3RhdGljIHJvdXRlIHRvd2Fy ZHMgQSwgbm90IGEgZHluYW1pYyByb3V0ZSBwcm9kdWNlZCBieSBQRCk6DQo+ID4+Pj4gLSB0aGUg cGFja2V0IGlzIHNlbnQgdG8gQS4gV2VsbCwgaWYgQSBkb2VzIG5vdCBoYXZlIGEgcm91dGUgdG8N Cj4gPj4+PiAyMDAxOmRiODo6NDIgdGhlbiBpbmRlZWQgYSByb3V0aW5nIGxvb3AgbWlnaHQgaGFw cGVuLiBCdXQgaWYgQSBkb2VzDQo+ID4+Pj4gaGF2ZSBhIHJvdXRlLCB0aGUgcGFja2V0IHdpbGwg YmUgZGVsaXZlcmVkLg0KPiA+Pj4NCj4gPj4+PiBXaGF0IHNlZW1zIHRvIGJlIHJlcXVpcmVkIGJ5 IFI0Og0KPiA+Pj4+IC0gUiBkZXRlY3RzIHRoYXQgdGhlIHBhY2tldCBpcyByZWNlaXZlZCB2aWEg ZXRoMCBhbmQgbmVlZHMgdG8gYmUgc2VudA0KPiA+Pj4+IGJhY2sgdG8gZXRoMC4gUjQgc2VlbXMg dG8gcmVxdWlyZSBzdWNoIHBhY2tldHMgdG8gYmUgZHJvcHBlZC4NCj4gPj4+PiBTbyBpZiBCIHdv dWxkIG5ldmVyIGJlIGFibGUgdG8gY29tbXVuaWNhdGUgdG8gYW55IGFkZHJlc3MgaW4gdGhlDQo+ ID4+Pj4gZGVsZWdhdGVkIHByZWZpeCwgcmlnaHQ/DQo+ID4+Pg0KPiA+Pj4+IEFtIEkgbWlzc2lu ZyBhbnl0aGluZz8NCj4gPj4+DQo+ID4+PiBJIHRoaW5rIHRoYXQgeW91IGdvdCBpdCByaWdodC4N Cj4gPj4+DQo+ID4+Pj4+IFBlcmhhcHMgdGhlIG1pc3NpbmcgcGllY2Ugb2YgdGhlIHJ1bGUgaXMg ZG9u4oCZdCBzZW5kIGl0IGJhY2sgdG8gd2hlcmUgaXQgY2FtZSBmcm9tLCBiYXNlZCBvbiBsaW5r IGxheWVyIGFkZHJlc3NlcyAob3IgbGluayBpZiBwb2ludC0NCj4gdG8tDQo+ID4+IHBvaW50KS4N Cj4gPj4+DQo+ID4+Pj4gWWVzLiBJZiBSNCB3YXMgc2F5aW5nICdkcm9wIHRoZSBwYWNrZXQgaWYg aXQgY29tZXMgZnJvbSB0aGUgc2FtZQ0KPiA+Pj4+IGxpbmstbGF5ZXIgYWRkcmVzcyB5b3UgYXJl IGdvaW5nIHRvIHNlbmQgaXQgYmFjaycgLSBpdCB3b3VsZCBtYWtlDQo+ID4+Pj4gdG90YWwgc2Vu c2UuIEJ1dCBJIGRvbid0IHRoaW5rIHJvdXRlcnMgZG8gKnRoYXQqLg0KPiA+Pj4NCj4gPj4+IFll cywgaWYgd2UgbWFkZSB0aGUgY2hlY2sgb24gTDIgYWRkcmVzcywgdGhlbiBpdCB3b3VsZCB3b3Jr Lg0KPiA+Pj4gQW5kIEkgYWdyZWUgdGhhdCByb3V0ZXJzIGFyZSBleGFjdGx5IGRvaW5nIHRoYXQu DQo+ID4+Pg0KPiA+Pj4gSSB0aGluayB0aGF0IGl0IGFsc28gd29ya3MgaWYgQiBpcyBhIHJvdXRl ciB3aXRoIGFkZGl0aW9uYWwgaW50ZXJmYWNlcw0KPiA+Pj4gZG93bnN0cmVhbSwgdW5sZXNzIHRo ZXJlIGFyZSBtdWx0aXBsZSBwYXRocy4NCj4gPj4+DQo+ID4+PiAtLQ0KPiA+Pj4gTWljaGFlbCBS aWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+ICAgLiBvIE8gKCBJUHY2IEnDuFQgY29u c3VsdGluZyApDQo+ID4+PiAgICAgICAgICBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MgSW5jLCBP dHRhd2EgYW5kIFdvcmxkd2lkZQ0KPiA+Pj4NCj4gPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+PiBJRVRG IElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gPj4+IGlwdjZAaWV0Zi5vcmcNCj4g Pj4+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lwdjYNCj4gPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+DQo+ID4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IGRoY3dnIG1haWxpbmcg bGlzdA0KPiA+PiBkaGN3Z0BpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2RoY3dnDQoNCg== From nobody Tue Oct 13 10:03: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 6BB6B3A0A35; Tue, 13 Oct 2020 10:03:12 -0700 (PDT) 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 sWXjAAY5wG61; Tue, 13 Oct 2020 10:03:10 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6693B3A0A2C; Tue, 13 Oct 2020 10:03:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 3E49438991; Tue, 13 Oct 2020 13:08:54 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id X6R2zw_S-2HZ; Tue, 13 Oct 2020 13:08:53 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E61733898F; Tue, 13 Oct 2020 13:08:52 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C3B5CA9A; Tue, 13 Oct 2020 13:03:06 -0400 (EDT) From: Michael Richardson To: "Templin \(US\)\, Fred L" , "ianfarrer\@gmx.com" , Jen Linkova , dhcwg , v6ops list , 6man In-Reply-To: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [v6ops] [dhcwg] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Tue, 13 Oct 2020 17:03:13 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Templin (US), Fred L wrote: >> For multi-access links, when the packet's >> ingress and egress interface match, and the source MAC and next-hop = MAC addresses >> match. > As I said, this gets very tricky if the client has multiple MACs. If = Client A has MAC addresses > a1, a2, a3, a4, etc. it becomes very difficult for the relay to know = that a packet received > from one of the MAC addresses (e.g., a1) must not be sent back to ano= ther of the MAC > addresses (e.g., a3). I think another failure case is if there is a p= roxy between the client > and relay. In that case, the relay will see the MAC address of the pr= oxy and not the > MAC address of client A. And, if there were multiple additional clien= ts B, C, D, etc. > sharing the same proxy then the proposed check could block legitimate > traffic. okay, but let's be clear about what "failure" here means. If the client has multiple MAC addresses, then the router *fails* to eliminate the loop. It does not drop traffic it shouldn't. So this policy doesn't make the situation worse. I don't know what kind of relay you are talking about. If it's a L2 switching fabric, and it rewrites mac addressess, then there is a problem. If it's an L3 router, then yes, the MAC address will change. But, that L3 router will *also* need a route to the client. That first L3 router should be the one dropping the traffic. > As I said before, I think the better fix is to instrument the client.= If the client receives > a packet on its relay-facing interface, and the routing system determ= ines that the > packet should be forwarded out the same interface via a default route= , the client > must drop the packet. That way, the relay never sees a looped packet,= and there > is no extraneous traffic on the client/relay interface. I agree that it should *also* be fixed on the client. 1) The client will never do any forwarding if the the client has forwarding turned off. 2) There are many cases where there are legitimate reasons to have an one-armed router like this. So, whatever text you right must be sure th= at the client is looking at the same packet, and not the IPsec transformed = one. (The Linux kernel does not make this trivial to get right, for instance) =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+F3coACgkQgItw+93Q 3WU2Rwf/QmjXXz56FNSH/vLgg4ATdjv3b2QQT4278QEpb1Ju/HkzEQNa9/gwHJlW yf7zQq4a3lNryUFoAkvCsI1vMX/32OMyNCI6tFasGDCW2awp7A6LnwHAntsx+KRj ldmwCsiaT8ITJyDyu1qSPwA9uEJT9vHWdaL9Z6e0Nl3cIWEUsRvPvIgb1qleOkey 4B724NiUnIEh8QVMJ5f6glVrVGlsvQCnZrGdbxBh7nZjYp2wSdQbPRGXFNJV/ZEq FRdys2HVF0z4EJH1QNqfyT8cYY3GG6Qk8p5hgXedBNVE8W3rEhv0BLwEnKU4Jcsw 2e5I8X8vBs97FHqtbQvr8KxHyAoPIw== =aBte -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Oct 13 10: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 4B20B3A0C44; Tue, 13 Oct 2020 10:44:38 -0700 (PDT) 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, 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=boeing.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 wzAc9HwWKjL2; Tue, 13 Oct 2020 10:44:36 -0700 (PDT) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 4BC7A3A0C43; Tue, 13 Oct 2020 10:44:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09DHiVt0021625; Tue, 13 Oct 2020 13:44:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602611074; bh=9O6RlLKBiVL9a/i/HRHNs+1X5gKeCX5zDidjUEvZMf0=; h=From:To:Subject:Date:References:In-Reply-To:From; b=EpEkl1HzvLVM335E19Gy40AvMtfS+AyElWaBdoEbONxAgGjDQ8xv0qTXgsNA2nQlj JWZAjxlijZ4ws19BqySyHG+tFLpCA6vurvd2qUB7tsklspcSR/dTxXi2GS2iBlOSme Y/qcshW3G4UIgUXEFjwHICoOj2JjJYui4tJBRpqsuPIbREWg2sJy56hgLAG/yh4tqB UzvrANDB2Pi7m279s6F50j3KwWFzQ78ZuICvvaqXfLh5PNDiHMXVi7W3WqWghu7KYz 5Tx6iN4pSWXvnXkkUGVJ+G5QCeMlzTrvm7YTKpTJiQLtshF97XKs1ozEu2bBpFgdqF 3WQ2q3rQhuf9A== Received: from XCH16-07-07.nos.boeing.com (xch16-07-07.nos.boeing.com [144.115.66.109]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09DHiTIh021336 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 13 Oct 2020 13:44:29 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-07.nos.boeing.com (144.115.66.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Tue, 13 Oct 2020 10:44:27 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Tue, 13 Oct 2020 10:44:27 -0700 From: "Templin (US), Fred L" To: Michael Richardson , "ianfarrer@gmx.com" , Jen Linkova , dhcwg , v6ops list , 6man Thread-Topic: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AdahZz7s2M1crQrvQoqZsITGBawESAAViWEAAA15P3A= Date: Tue, 13 Oct 2020 17:44:27 +0000 Message-ID: <378d3420690246bbae253fb15be8c9a7@boeing.com> References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> <10487.1602608586@localhost> In-Reply-To: <10487.1602608586@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: B3F8A8C1C34F44DB199A02F3082FB4FAE0AFB241DDCE0F6D2CC4A8BBEC46325E2000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [EXTERNAL] Re: [dhcwg] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Tue, 13 Oct 2020 17:44:38 -0000 TWljaGFlbCwgd2hhdCBJIHdhcyByZWZlcnJpbmcgdG8gYmVsb3cgYXMgImZhaWx1cmUiIGlzIHRo ZSBwcm94eSBjYXNlIHdoZW4NCnRoZXJlIGlzIGFuIEwyIHByb3h5IFAgYmV0d2VlbiB0aGUgY2xp ZW50IGFuZCByZWxheSAoZS5nLiwgUkZDNDg5KS4gVGhlcmUNCmNvdWxkIGJlIG1hbnkgY2xpZW50 cyBBLCBCLCBDLCBELCBldGMuIG9uIGRvd25zdHJlYW0gbGluayBzZWdtZW50cyBvZg0KdGhlIHBy b3h5LCB3aXRoIHRoZSByZWxheSBSIG9uIGFuIHVwc3RyZWFtIGxpbmsgc2VnbWVudC4gVGhlIHJl bGF5IHdvdWxkDQp0aGVuIG5vdCBzZWUgdGhlIGluZGl2aWR1YWwgY2xpZW50IE1BQyBhZGRyZXNz ZXMgQSwgQiwgQywgRCwgZXRjLiAtIGl0IHdvdWxkDQpzZWUgb25seSB0aGUgcHJveHkgTUFDIGFk ZHJlc3MgUCBpbiBhbGwgY2FzZXMuIFNvLCBpdCBpcyB0cnVlIHRoYXQgYW4gUlBGDQpjaGVjayBp biB0aGUgcmVsYXkgd291bGQgZHJvcCBhIHBhY2tldCBmcm9tIGNsaWVudCBBIGFkZHJlc3NlZCB0 byBpdHNlbGYsDQpidXQgaXQgd291bGQgYWxzbyBkcm9wIGFueSBvZiBjbGllbnQgQSdzIHBhY2tl dHMgYWRkcmVzc2VkIHRvIGNsaWVudHMgQiwNCkMsIEQsIGV0Yy4gVGhhdCBpcyB3aGF0IEkgbWVh bnQgYnkgImZhaWx1cmUiIGluIHRoaXMgY29udGV4dC4NCg0KRnJlZA0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE1pY2hhZWwgUmljaGFyZHNvbiBbbWFpbHRvOm1jcitp ZXRmQHNhbmRlbG1hbi5jYV0NCj4gU2VudDogVHVlc2RheSwgT2N0b2JlciAxMywgMjAyMCAxMDow MyBBTQ0KPiBUbzogVGVtcGxpbiAoVVMpLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5j b20+OyBpYW5mYXJyZXJAZ214LmNvbTsgSmVuIExpbmtvdmEgPGZ1cnJ5MTNAZ21haWwuY29tPjsg ZGhjd2cNCj4gPGRoY3dnQGlldGYub3JnPjsgdjZvcHMgbGlzdCA8djZvcHNAaWV0Zi5vcmc+OyA2 bWFuIDxpcHY2QGlldGYub3JnPg0KPiBTdWJqZWN0OiBbRVhURVJOQUxdIFJlOiBbZGhjd2ddIFt2 Nm9wc10gUmU6IFF1ZXN0aW9uIHRvIERIQ1B2NiBSZWxheSBJbXBsZW1lbnRvcnMgcmVnYXJkaW5n IGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1wZC1yZWxheS0NCj4gcmVxdWlyZW1lbnRzDQo+IA0KPiAN Cj4gVGVtcGxpbiAoVVMpLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+IHdyb3Rl Og0KPiAgICAgPj4gRm9yIG11bHRpLWFjY2VzcyBsaW5rcywgd2hlbiB0aGUgcGFja2V0J3MNCj4g ICAgID4+IGluZ3Jlc3MgYW5kIGVncmVzcyBpbnRlcmZhY2UgbWF0Y2gsIGFuZCB0aGUgc291cmNl IE1BQyBhbmQgbmV4dC1ob3AgTUFDIGFkZHJlc3Nlcw0KPiAgICAgPj4gbWF0Y2guDQo+IA0KPiAg ICAgPiBBcyBJIHNhaWQsIHRoaXMgZ2V0cyB2ZXJ5IHRyaWNreSBpZiB0aGUgY2xpZW50IGhhcyBt dWx0aXBsZSBNQUNzLiBJZiBDbGllbnQgQSBoYXMgTUFDIGFkZHJlc3Nlcw0KPiAgICAgPiBhMSwg YTIsIGEzLCBhNCwgZXRjLiBpdCBiZWNvbWVzIHZlcnkgZGlmZmljdWx0IGZvciB0aGUgcmVsYXkg dG8ga25vdyB0aGF0IGEgcGFja2V0IHJlY2VpdmVkDQo+ICAgICA+IGZyb20gb25lIG9mIHRoZSBN QUMgYWRkcmVzc2VzIChlLmcuLCBhMSkgbXVzdCBub3QgYmUgc2VudCBiYWNrIHRvIGFub3RoZXIg b2YgdGhlIE1BQw0KPiAgICAgPiBhZGRyZXNzZXMgKGUuZy4sIGEzKS4gSSB0aGluayBhbm90aGVy IGZhaWx1cmUgY2FzZSBpcyBpZiB0aGVyZSBpcyBhIHByb3h5IGJldHdlZW4gdGhlIGNsaWVudA0K PiAgICAgPiBhbmQgcmVsYXkuIEluIHRoYXQgY2FzZSwgdGhlIHJlbGF5IHdpbGwgc2VlIHRoZSBN QUMgYWRkcmVzcyBvZiB0aGUgcHJveHkgYW5kIG5vdCB0aGUNCj4gICAgID4gTUFDIGFkZHJlc3Mg b2YgY2xpZW50IEEuIEFuZCwgaWYgdGhlcmUgd2VyZSBtdWx0aXBsZSBhZGRpdGlvbmFsIGNsaWVu dHMgQiwgQywgRCwgZXRjLg0KPiAgICAgPiBzaGFyaW5nIHRoZSBzYW1lIHByb3h5IHRoZW4gdGhl IHByb3Bvc2VkIGNoZWNrIGNvdWxkIGJsb2NrIGxlZ2l0aW1hdGUNCj4gICAgID4gdHJhZmZpYy4N Cj4gDQo+IG9rYXksIGJ1dCBsZXQncyBiZSBjbGVhciBhYm91dCB3aGF0ICJmYWlsdXJlIiBoZXJl IG1lYW5zLg0KPiBJZiB0aGUgY2xpZW50IGhhcyBtdWx0aXBsZSBNQUMgYWRkcmVzc2VzLCB0aGVu IHRoZSByb3V0ZXIgKmZhaWxzKiB0bw0KPiBlbGltaW5hdGUgdGhlIGxvb3AuICBJdCBkb2VzIG5v dCBkcm9wIHRyYWZmaWMgaXQgc2hvdWxkbid0Lg0KPiBTbyB0aGlzIHBvbGljeSBkb2Vzbid0IG1h a2UgdGhlIHNpdHVhdGlvbiB3b3JzZS4NCj4gDQo+IEkgZG9uJ3Qga25vdyB3aGF0IGtpbmQgb2Yg cmVsYXkgeW91IGFyZSB0YWxraW5nIGFib3V0Lg0KPiBJZiBpdCdzIGEgTDIgc3dpdGNoaW5nIGZh YnJpYywgYW5kIGl0IHJld3JpdGVzIG1hYyBhZGRyZXNzZXNzLCB0aGVuIHRoZXJlIGlzDQo+IGEg cHJvYmxlbS4NCj4gDQo+IElmIGl0J3MgYW4gTDMgcm91dGVyLCB0aGVuIHllcywgdGhlIE1BQyBh ZGRyZXNzIHdpbGwgY2hhbmdlLg0KPiBCdXQsIHRoYXQgTDMgcm91dGVyIHdpbGwgKmFsc28qIG5l ZWQgYSByb3V0ZSB0byB0aGUgY2xpZW50Lg0KPiBUaGF0IGZpcnN0IEwzIHJvdXRlciBzaG91bGQg YmUgdGhlIG9uZSBkcm9wcGluZyB0aGUgdHJhZmZpYy4NCj4gDQo+ICAgICA+IEFzIEkgc2FpZCBi ZWZvcmUsIEkgdGhpbmsgdGhlIGJldHRlciBmaXggaXMgdG8gaW5zdHJ1bWVudCB0aGUgY2xpZW50 LiBJZiB0aGUgY2xpZW50IHJlY2VpdmVzDQo+ICAgICA+IGEgcGFja2V0IG9uIGl0cyByZWxheS1m YWNpbmcgaW50ZXJmYWNlLCBhbmQgdGhlIHJvdXRpbmcgc3lzdGVtIGRldGVybWluZXMgdGhhdCB0 aGUNCj4gICAgID4gcGFja2V0IHNob3VsZCBiZSBmb3J3YXJkZWQgb3V0IHRoZSBzYW1lIGludGVy ZmFjZSB2aWEgYSBkZWZhdWx0IHJvdXRlLCB0aGUgY2xpZW50DQo+ICAgICA+IG11c3QgZHJvcCB0 aGUgcGFja2V0LiBUaGF0IHdheSwgdGhlIHJlbGF5IG5ldmVyIHNlZXMgYSBsb29wZWQgcGFja2V0 LCBhbmQgdGhlcmUNCj4gICAgID4gaXMgbm8gZXh0cmFuZW91cyB0cmFmZmljIG9uIHRoZSBjbGll bnQvcmVsYXkgaW50ZXJmYWNlLg0KPiANCj4gSSBhZ3JlZSB0aGF0IGl0IHNob3VsZCAqYWxzbyog YmUgZml4ZWQgb24gdGhlIGNsaWVudC4NCj4gDQo+IDEpIFRoZSBjbGllbnQgd2lsbCBuZXZlciBk byBhbnkgZm9yd2FyZGluZyBpZiB0aGUgdGhlIGNsaWVudCBoYXMgZm9yd2FyZGluZw0KPiAgICB0 dXJuZWQgb2ZmLg0KPiANCj4gMikgVGhlcmUgYXJlIG1hbnkgY2FzZXMgd2hlcmUgdGhlcmUgYXJl IGxlZ2l0aW1hdGUgcmVhc29ucyB0byBoYXZlIGFuDQo+ICAgIG9uZS1hcm1lZCByb3V0ZXIgbGlr ZSB0aGlzLiAgU28sIHdoYXRldmVyIHRleHQgeW91IHJpZ2h0IG11c3QgYmUgc3VyZSB0aGF0DQo+ ICAgIHRoZSBjbGllbnQgaXMgbG9va2luZyBhdCB0aGUgc2FtZSBwYWNrZXQsIGFuZCBub3QgdGhl IElQc2VjIHRyYW5zZm9ybWVkIG9uZS4NCj4gICAgKFRoZSBMaW51eCBrZXJuZWwgZG9lcyBub3Qg bWFrZSB0aGlzIHRyaXZpYWwgdG8gZ2V0IHJpZ2h0LCBmb3IgaW5zdGFuY2UpDQo+IA0KPiANCj4g LS0NCj4gTWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+ICAgLiBvIE8g KCBJUHY2IEnDuFQgY29uc3VsdGluZyApDQo+ICAgICAgICAgICAgU2FuZGVsbWFuIFNvZnR3YXJl IFdvcmtzIEluYywgT3R0YXdhIGFuZCBXb3JsZHdpZGUNCj4gDQo+IA0KPiANCg0K From nobody Tue Oct 13 11:00: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 BFA663A0CBB for ; Tue, 13 Oct 2020 11:00:11 -0700 (PDT) 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, 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=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 d_Nn6L9cCZda for ; Tue, 13 Oct 2020 11:00:09 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 B72883A0CB9 for ; Tue, 13 Oct 2020 11:00:09 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id 67so377442iob.8 for ; Tue, 13 Oct 2020 11:00:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ABK2azN+DNvkG2xdSz9wdGrJU6ntdGVnuB8aB1CezpA=; b=Ybu32vVGp7KUYyaZ3mBA8u1L/b56P68dBclLjYdNKc2kQZM8afurACxbzaqpx/1b89 OHw4+tQrgv/bjJ+E4pK/GX0XwAI52oV+rNtEPHmqEcHMEBuYPp6qB27b+HKeON3pYXMo j9/96UFBYqd2RcWY/w+ZuaQC3AyZVHnMEGxlDukFaJF2VqTFMLXgt5vx9+NCO14ZGo4g 8w+f3yWestLVDrXIMZfHVLcj9DQwAG3rf3SLVVMFb2MCH5TLb/d39PKFvLQCs0W7hECe TNih+lXPvK74CiX+/YxA66XdDKqJ+t97VeE6yLN39RqS8V566EV9n/In6SvEvJ/70nTo 0enA== 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=ABK2azN+DNvkG2xdSz9wdGrJU6ntdGVnuB8aB1CezpA=; b=bjlG+Vs1Ge5FrjxhO8vYwp6ibaIu7uBIAov1zA9BirPzX8aUCGd7irdGrbE6rrnWHi jPPPc66xS77St+HzIRzx8ewNwnDnvL8LKow5LckGNMhuDSsUZ7R+hifjY9jbBtlLLdV7 QP8oDmeSB10/bHxWfwA9Q1zvDdk8x0RHZta9TsOH1Tux+J2U3lZdChDfI2FWbyVv3G3T Smgv8oZkGTX5k40o9c5Dj6ddtmGalGzXiAdYj4X88IRmUEDz+e/xO3Bua+nWqgGGfdBW 4E7dH58RBgYgMZPro2d4H3KtfqKa3S1sykh6tdShuyR79OSyfynzO8rehwDsTCdTgYqw uaPA== X-Gm-Message-State: AOAM532keVjFi76oJg+esXVi1fQVUoAggoGgojSzEZBcCwoA9MS0fJWm HOObdO6XpXToNKIKYQKsTwRnGA== X-Google-Smtp-Source: ABdhPJxbK5H/K9pgRZVL3gZRffqvZsdi7HHZFOoeOI6s9+Z1CwFMek8uFmjXx8xJAmf/aiOMJn6qEw== X-Received: by 2002:a6b:8dca:: with SMTP id p193mr24172iod.77.1602612008058; Tue, 13 Oct 2020 11:00:08 -0700 (PDT) Received: from mithrandir.lan (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id z20sm480900ior.2.2020.10.13.11.00.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Oct 2020 11:00:07 -0700 (PDT) From: Ted Lemon Message-Id: <4478E969-8C25-46E1-9C21-B74189F23058@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F3D0D4E9-732B-4BA8-80CE-9FFD422A360A" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.82\)) Date: Tue, 13 Oct 2020 14:00:04 -0400 In-Reply-To: <378d3420690246bbae253fb15be8c9a7@boeing.com> Cc: Michael Richardson , "ianfarrer@gmx.com" , Jen Linkova , dhcwg , v6ops list , 6man To: "Templin (US), Fred L" References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> <10487.1602608586@localhost> <378d3420690246bbae253fb15be8c9a7@boeing.com> X-Mailer: Apple Mail (2.3654.0.3.2.82) Archived-At: Subject: Re: [v6ops] [dhcwg] [EXTERNAL] Re: Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Tue, 13 Oct 2020 18:00:12 -0000 --Apple-Mail=_F3D0D4E9-732B-4BA8-80CE-9FFD422A360A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Fred, according to RFC6221: > The LDRA MUST copy the IP source address from the client-originated > message into the peer-address field of the Relay-Forward message. > The LDRA MUST copy the link-layer source address from the client- > originated message into the link-layer source address of the Relay- > Forward message. This is also true for the destination address. So if that is what my = mean by an =E2=80=9CL2 proxy,=E2=80=9D I don=E2=80=99t think that the = original MAC address would be hidden by it. > On Oct 13, 2020, at 1:44 PM, Templin (US), Fred L = wrote: >=20 > Michael, what I was referring to below as "failure" is the proxy case = when > there is an L2 proxy P between the client and relay (e.g., RFC489). = There > could be many clients A, B, C, D, etc. on downstream link segments of > the proxy, with the relay R on an upstream link segment. The relay = would > then not see the individual client MAC addresses A, B, C, D, etc. - it = would > see only the proxy MAC address P in all cases. So, it is true that an = RPF > check in the relay would drop a packet from client A addressed to = itself, > but it would also drop any of client A's packets addressed to clients = B, > C, D, etc. That is what I meant by "failure" in this context. >=20 > Fred >=20 >> -----Original Message----- >> From: Michael Richardson [mailto:mcr+ietf@sandelman.ca] >> Sent: Tuesday, October 13, 2020 10:03 AM >> To: Templin (US), Fred L ; = ianfarrer@gmx.com; Jen Linkova ; dhcwg >> ; v6ops list ; 6man >> Subject: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay = Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay- >> requirements >>=20 >>=20 >> Templin (US), Fred L wrote: >>>> For multi-access links, when the packet's >>>> ingress and egress interface match, and the source MAC and next-hop = MAC addresses >>>> match. >>=20 >>> As I said, this gets very tricky if the client has multiple MACs. If = Client A has MAC addresses >>> a1, a2, a3, a4, etc. it becomes very difficult for the relay to know = that a packet received >>> from one of the MAC addresses (e.g., a1) must not be sent back to = another of the MAC >>> addresses (e.g., a3). I think another failure case is if there is a = proxy between the client >>> and relay. In that case, the relay will see the MAC address of the = proxy and not the >>> MAC address of client A. And, if there were multiple additional = clients B, C, D, etc. >>> sharing the same proxy then the proposed check could block = legitimate >>> traffic. >>=20 >> okay, but let's be clear about what "failure" here means. >> If the client has multiple MAC addresses, then the router *fails* to >> eliminate the loop. It does not drop traffic it shouldn't. >> So this policy doesn't make the situation worse. >>=20 >> I don't know what kind of relay you are talking about. >> If it's a L2 switching fabric, and it rewrites mac addressess, then = there is >> a problem. >>=20 >> If it's an L3 router, then yes, the MAC address will change. >> But, that L3 router will *also* need a route to the client. >> That first L3 router should be the one dropping the traffic. >>=20 >>> As I said before, I think the better fix is to instrument the = client. If the client receives >>> a packet on its relay-facing interface, and the routing system = determines that the >>> packet should be forwarded out the same interface via a default = route, the client >>> must drop the packet. That way, the relay never sees a looped = packet, and there >>> is no extraneous traffic on the client/relay interface. >>=20 >> I agree that it should *also* be fixed on the client. >>=20 >> 1) The client will never do any forwarding if the the client has = forwarding >> turned off. >>=20 >> 2) There are many cases where there are legitimate reasons to have an >> one-armed router like this. So, whatever text you right must be = sure that >> the client is looking at the same packet, and not the IPsec = transformed one. >> (The Linux kernel does not make this trivial to get right, for = instance) >>=20 >>=20 >> -- >> Michael Richardson . o O ( IPv6 I=C3=B8T = consulting ) >> Sandelman Software Works Inc, Ottawa and Worldwide >>=20 >>=20 >>=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg --Apple-Mail=_F3D0D4E9-732B-4BA8-80CE-9FFD422A360A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Fred,= according to RFC6221:

   The LDRA MUST =
copy the IP source address from the client-originated
   message into the peer-address field of the Relay-Forward message.
   The LDRA MUST copy the link-layer source address from the client-
   originated message into the link-layer source address of the Relay-
   Forward message.

This is also true for the destination address. So = if that is what my mean by an =E2=80=9CL2 proxy,=E2=80=9D I don=E2=80=99t = think that the original MAC address would be hidden by it.

On Oct = 13, 2020, at 1:44 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:

Michael, what I was referring to below as "failure" is the = proxy case when
there is an L2 proxy P between the client = and relay (e.g., RFC489). There
could be many clients A, = B, C, D, etc. on downstream link segments of
the proxy, = with the relay R on an upstream link segment. The relay would
then not see the individual client MAC addresses A, B, C, D, = etc. - it would
see only the proxy MAC address P in all = cases. So, it is true that an RPF
check in the relay would = drop a packet from client A addressed to itself,
but it = would also drop any of client A's packets addressed to clients B,
C, D, etc. That is what I meant by "failure" in this = context.

Fred

-----Original = Message-----
From: Michael Richardson [mailto:mcr+ietf@sandelman.ca]
Sent: = Tuesday, October 13, 2020 10:03 AM
To: Templin (US), Fred = L <Fred.L.Templin@boeing.com>; ianfarrer@gmx.com; Jen = Linkova <furry13@gmail.com>; dhcwg
<dhcwg@ietf.org>; v6ops = list <v6ops@ietf.org>; 6man <ipv6@ietf.org>
Subject: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to = DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-
requirements


Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
For multi-access links, when the packet's
ingress= and egress interface match, and the source MAC and next-hop MAC = addresses
match.
As I said, this gets = very tricky if the client has multiple MACs. If Client A has MAC = addresses
a1, a2, a3, a4, etc. it becomes very difficult = for the relay to know that a packet received
from one of = the MAC addresses (e.g., a1) must not be sent back to another of the = MAC
addresses (e.g., a3). I think another failure case is = if there is a proxy between the client
and relay. In that = case, the relay will see the MAC address of the proxy and not the
MAC address of client A. And, if there were multiple = additional clients B, C, D, etc.
sharing the same proxy = then the proposed check could block legitimate
traffic.

okay, but let's be clear about = what "failure" here means.
If the client has multiple MAC = addresses, then the router *fails* to
eliminate the loop. =  It does not drop traffic it shouldn't.
So this = policy doesn't make the situation worse.

I = don't know what kind of relay you are talking about.
If = it's a L2 switching fabric, and it rewrites mac addressess, then there = is
a problem.

If it's an L3 = router, then yes, the MAC address will change.
But, that = L3 router will *also* need a route to the client.
That = first L3 router should be the one dropping the traffic.

As I said before, I = think the better fix is to instrument the client. If the client = receives
a packet on its relay-facing interface, and the = routing system determines that the
packet should be = forwarded out the same interface via a default route, the client
must drop the packet. That way, the relay never sees a looped = packet, and there
is no extraneous traffic on the = client/relay interface.

I = agree that it should *also* be fixed on the client.

1) The client will never do any forwarding if the the client = has forwarding
  turned off.

2) There are many cases where there are legitimate reasons to = have an
  one-armed router like this.  So, = whatever text you right must be sure that
  the = client is looking at the same packet, and not the IPsec transformed = one.
  (The Linux kernel does not make this = trivial to get right, for instance)


--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 I=C3=B8T= consulting )
=           Sandelman = Software Works Inc, Ottawa and Worldwide




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

= --Apple-Mail=_F3D0D4E9-732B-4BA8-80CE-9FFD422A360A-- From nobody Tue Oct 13 11:38: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 842223A0EFD; Tue, 13 Oct 2020 11:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, 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=boeing.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 uT5UD_pg7kax; Tue, 13 Oct 2020 11:38:33 -0700 (PDT) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 530C43A0EFC; Tue, 13 Oct 2020 11:38:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09DIcQGt016729; Tue, 13 Oct 2020 14:38:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602614311; bh=IId8N0xUeMZGHuEjn2hIB2Foe1YvV5zlY3QB7/NDrYA=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=AVVdNx3q3YfH7EvI48zLwaKAbsS5DS2YK94n6/Xe0PB6tMhQ41dm8but3IScYq7jV sZOZzY7OknjynAb1nSwj7g0pPw83JGI/rfdLkAmnl26Sdkx82LAyV1sWjA5c7vHwlI CsVHguK+YgZEgetEbFrt3ctueBsjiHhjVzNiWT/MQpSi0x+B/SRkOeOZWdhZB9B34F XO5anEqZ0E84ri7vgEhgWLR7RmBPVRWJkx9BGJS0QZkDA4seMx/rFW5fl8wuWkQnJR 2+v7GD8dYm+gdPh07ZZbF4IlInhxb9s7kBaLWho4enveuONSQfIJBLJAjOxESIafs5 t4O3hWIDQ1Mdg== Received: from XCH16-07-09.nos.boeing.com (xch16-07-09.nos.boeing.com [144.115.66.111]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09DIcFUB015596 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 13 Oct 2020 14:38:15 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-09.nos.boeing.com (144.115.66.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Tue, 13 Oct 2020 11:38:13 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Tue, 13 Oct 2020 11:38:13 -0700 From: "Templin (US), Fred L" To: Ted Lemon CC: Michael Richardson , "ianfarrer@gmx.com" , Jen Linkova , dhcwg , v6ops list , 6man Thread-Topic: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AQHWoZACP+11iV2gnk+uDowUHAjjrA== Date: Tue, 13 Oct 2020 18:38:13 +0000 Message-ID: <9428b888a7c046a38f85de8fcc260857@boeing.com> References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> <10487.1602608586@localhost> <378d3420690246bbae253fb15be8c9a7@boeing.com> <4478E969-8C25-46E1-9C21-B74189F23058@fugue.com> In-Reply-To: <4478E969-8C25-46E1-9C21-B74189F23058@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: F7E43743103245479EE90E0655F6384FC4A2EC8F91318DA43046332858DC3DDD2000:8 Content-Type: multipart/alternative; boundary="_000_9428b888a7c046a38f85de8fcc260857boeingcom_" MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [dhcwg] [EXTERNAL] Re: Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Tue, 13 Oct 2020 18:38:36 -0000 --_000_9428b888a7c046a38f85de8fcc260857boeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGVkLA0KDQpUaGluayBvZiB0aGUgTDIgcHJveHkgYXMgYSBtaWRkbGVib3ggdGhhdCBvY2N1 cnMgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgcmVsYXkgKGV2ZW4NCmZvciB0aGUgUkZDNjIy MSBMRFJBIGNhc2UpLiBUaGUgY2xpZW50IGlzIG9uIGEg4oCcZG93bnN0cmVhbSBsaW5rIHNlZ21l bnTigJ0gb2YgdGhlIHByb3h5LA0KYW5kIHRoZSByZWxheSBpcyBvbiBhbiDigJx1cHN0cmVhbSBs aW5rIHNlZ21lbnTigJ0gb2YgdGhlIHByb3h5LiBXaGVuIHRoZSBMRFJBIHJ1bm5pbmcgaW4NCnRo ZSBzYW1lIHBoeXNpY2FsIGJveCBhcyB0aGUgcmVsYXkgZ2V0cyB0aGUgREhDUHY2IFNvbGljaXQg bWVzc2FnZSwgdGhlIGxpbmstbGF5ZXIgc291cmNlDQphZGRyZXNzIGl0IHdpbGwgc2VlIGlzIOKA mFDigJkgKGkuZS4sIHRoZSB1cHN0cmVhbSBsaW5rIHNlZ21lbnQgYWRkcmVzcyBvZiB0aGUgcHJv eHkpLg0KDQpCVFcsIEkgaGFkICBhIHR5cG8gaW4gbXkgbGFzdCBtZXNzYWdlIOKAkyBJIGludGVu ZGVkIHRvIGNpdGUgUkZDNDM4OS4NCg0KRnJlZA0KDQpGcm9tOiBUZWQgTGVtb24gW21haWx0bzpt ZWxsb25AZnVndWUuY29tXQ0KU2VudDogVHVlc2RheSwgT2N0b2JlciAxMywgMjAyMCAxMTowMCBB TQ0KVG86IFRlbXBsaW4gKFVTKSwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0K Q2M6IE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPjsgaWFuZmFycmVy QGdteC5jb207IEplbiBMaW5rb3ZhIDxmdXJyeTEzQGdtYWlsLmNvbT47IGRoY3dnIDxkaGN3Z0Bp ZXRmLm9yZz47IHY2b3BzIGxpc3QgPHY2b3BzQGlldGYub3JnPjsgNm1hbiA8aXB2NkBpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBbZGhjd2ddIFJlOiBbdjZvcHNdIFJlOiBRdWVzdGlvbiB0byBESENQ djYgUmVsYXkgSW1wbGVtZW50b3JzIHJlZ2FyZGluZyBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtcGQt cmVsYXktcmVxdWlyZW1lbnRzDQoNCkZyZWQsIGFjY29yZGluZyB0byBSRkM2MjIxOg0KDQoNCg0K ICAgVGhlIExEUkEgTVVTVCBjb3B5IHRoZSBJUCBzb3VyY2UgYWRkcmVzcyBmcm9tIHRoZSBjbGll bnQtb3JpZ2luYXRlZA0KDQogICBtZXNzYWdlIGludG8gdGhlIHBlZXItYWRkcmVzcyBmaWVsZCBv ZiB0aGUgUmVsYXktRm9yd2FyZCBtZXNzYWdlLg0KDQogICBUaGUgTERSQSBNVVNUIGNvcHkgdGhl IGxpbmstbGF5ZXIgc291cmNlIGFkZHJlc3MgZnJvbSB0aGUgY2xpZW50LQ0KDQogICBvcmlnaW5h dGVkIG1lc3NhZ2UgaW50byB0aGUgbGluay1sYXllciBzb3VyY2UgYWRkcmVzcyBvZiB0aGUgUmVs YXktDQoNCiAgIEZvcndhcmQgbWVzc2FnZS4NCg0KVGhpcyBpcyBhbHNvIHRydWUgZm9yIHRoZSBk ZXN0aW5hdGlvbiBhZGRyZXNzLiBTbyBpZiB0aGF0IGlzIHdoYXQgbXkgbWVhbiBieSBhbiDigJxM MiBwcm94eSzigJ0gSSBkb27igJl0IHRoaW5rIHRoYXQgdGhlIG9yaWdpbmFsIE1BQyBhZGRyZXNz IHdvdWxkIGJlIGhpZGRlbiBieSBpdC4NCg0KDQpPbiBPY3QgMTMsIDIwMjAsIGF0IDE6NDQgUE0s IFRlbXBsaW4gKFVTKSwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPG1haWx0bzpG cmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPj4gd3JvdGU6DQoNCk1pY2hhZWwsIHdoYXQgSSB3YXMg cmVmZXJyaW5nIHRvIGJlbG93IGFzICJmYWlsdXJlIiBpcyB0aGUgcHJveHkgY2FzZSB3aGVuDQp0 aGVyZSBpcyBhbiBMMiBwcm94eSBQIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgcmVsYXkgKGUuZy4s IFJGQzQ4OSkuIFRoZXJlDQpjb3VsZCBiZSBtYW55IGNsaWVudHMgQSwgQiwgQywgRCwgZXRjLiBv biBkb3duc3RyZWFtIGxpbmsgc2VnbWVudHMgb2YNCnRoZSBwcm94eSwgd2l0aCB0aGUgcmVsYXkg UiBvbiBhbiB1cHN0cmVhbSBsaW5rIHNlZ21lbnQuIFRoZSByZWxheSB3b3VsZA0KdGhlbiBub3Qg c2VlIHRoZSBpbmRpdmlkdWFsIGNsaWVudCBNQUMgYWRkcmVzc2VzIEEsIEIsIEMsIEQsIGV0Yy4g LSBpdCB3b3VsZA0Kc2VlIG9ubHkgdGhlIHByb3h5IE1BQyBhZGRyZXNzIFAgaW4gYWxsIGNhc2Vz LiBTbywgaXQgaXMgdHJ1ZSB0aGF0IGFuIFJQRg0KY2hlY2sgaW4gdGhlIHJlbGF5IHdvdWxkIGRy b3AgYSBwYWNrZXQgZnJvbSBjbGllbnQgQSBhZGRyZXNzZWQgdG8gaXRzZWxmLA0KYnV0IGl0IHdv dWxkIGFsc28gZHJvcCBhbnkgb2YgY2xpZW50IEEncyBwYWNrZXRzIGFkZHJlc3NlZCB0byBjbGll bnRzIEIsDQpDLCBELCBldGMuIFRoYXQgaXMgd2hhdCBJIG1lYW50IGJ5ICJmYWlsdXJlIiBpbiB0 aGlzIGNvbnRleHQuDQoNCkZyZWQNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogTWljaGFlbCBSaWNoYXJkc29uIFttYWlsdG86bWNyK2lldGZAc2FuZGVsbWFuLmNhXQ0KU2Vu dDogVHVlc2RheSwgT2N0b2JlciAxMywgMjAyMCAxMDowMyBBTQ0KVG86IFRlbXBsaW4gKFVTKSwg RnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPG1haWx0bzpGcmVkLkwuVGVtcGxpbkBi b2VpbmcuY29tPj47IGlhbmZhcnJlckBnbXguY29tPG1haWx0bzppYW5mYXJyZXJAZ214LmNvbT47 IEplbiBMaW5rb3ZhIDxmdXJyeTEzQGdtYWlsLmNvbTxtYWlsdG86ZnVycnkxM0BnbWFpbC5jb20+ PjsgZGhjd2cNCjxkaGN3Z0BpZXRmLm9yZzxtYWlsdG86ZGhjd2dAaWV0Zi5vcmc+PjsgdjZvcHMg bGlzdCA8djZvcHNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzQGlldGYub3JnPj47IDZtYW4gPGlwdjZA aWV0Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW0VYVEVSTkFMXSBSZTog W2RoY3dnXSBbdjZvcHNdIFJlOiBRdWVzdGlvbiB0byBESENQdjYgUmVsYXkgSW1wbGVtZW50b3Jz IHJlZ2FyZGluZyBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtcGQtcmVsYXktDQpyZXF1aXJlbWVudHMN Cg0KDQpUZW1wbGluIChVUyksIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbTxtYWls dG86RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4+IHdyb3RlOg0KDQpGb3IgbXVsdGktYWNjZXNz IGxpbmtzLCB3aGVuIHRoZSBwYWNrZXQncw0KaW5ncmVzcyBhbmQgZWdyZXNzIGludGVyZmFjZSBt YXRjaCwgYW5kIHRoZSBzb3VyY2UgTUFDIGFuZCBuZXh0LWhvcCBNQUMgYWRkcmVzc2VzDQptYXRj aC4NCg0KDQpBcyBJIHNhaWQsIHRoaXMgZ2V0cyB2ZXJ5IHRyaWNreSBpZiB0aGUgY2xpZW50IGhh cyBtdWx0aXBsZSBNQUNzLiBJZiBDbGllbnQgQSBoYXMgTUFDIGFkZHJlc3Nlcw0KYTEsIGEyLCBh MywgYTQsIGV0Yy4gaXQgYmVjb21lcyB2ZXJ5IGRpZmZpY3VsdCBmb3IgdGhlIHJlbGF5IHRvIGtu b3cgdGhhdCBhIHBhY2tldCByZWNlaXZlZA0KZnJvbSBvbmUgb2YgdGhlIE1BQyBhZGRyZXNzZXMg KGUuZy4sIGExKSBtdXN0IG5vdCBiZSBzZW50IGJhY2sgdG8gYW5vdGhlciBvZiB0aGUgTUFDDQph ZGRyZXNzZXMgKGUuZy4sIGEzKS4gSSB0aGluayBhbm90aGVyIGZhaWx1cmUgY2FzZSBpcyBpZiB0 aGVyZSBpcyBhIHByb3h5IGJldHdlZW4gdGhlIGNsaWVudA0KYW5kIHJlbGF5LiBJbiB0aGF0IGNh c2UsIHRoZSByZWxheSB3aWxsIHNlZSB0aGUgTUFDIGFkZHJlc3Mgb2YgdGhlIHByb3h5IGFuZCBu b3QgdGhlDQpNQUMgYWRkcmVzcyBvZiBjbGllbnQgQS4gQW5kLCBpZiB0aGVyZSB3ZXJlIG11bHRp cGxlIGFkZGl0aW9uYWwgY2xpZW50cyBCLCBDLCBELCBldGMuDQpzaGFyaW5nIHRoZSBzYW1lIHBy b3h5IHRoZW4gdGhlIHByb3Bvc2VkIGNoZWNrIGNvdWxkIGJsb2NrIGxlZ2l0aW1hdGUNCnRyYWZm aWMuDQoNCm9rYXksIGJ1dCBsZXQncyBiZSBjbGVhciBhYm91dCB3aGF0ICJmYWlsdXJlIiBoZXJl IG1lYW5zLg0KSWYgdGhlIGNsaWVudCBoYXMgbXVsdGlwbGUgTUFDIGFkZHJlc3NlcywgdGhlbiB0 aGUgcm91dGVyICpmYWlscyogdG8NCmVsaW1pbmF0ZSB0aGUgbG9vcC4gIEl0IGRvZXMgbm90IGRy b3AgdHJhZmZpYyBpdCBzaG91bGRuJ3QuDQpTbyB0aGlzIHBvbGljeSBkb2Vzbid0IG1ha2UgdGhl IHNpdHVhdGlvbiB3b3JzZS4NCg0KSSBkb24ndCBrbm93IHdoYXQga2luZCBvZiByZWxheSB5b3Ug YXJlIHRhbGtpbmcgYWJvdXQuDQpJZiBpdCdzIGEgTDIgc3dpdGNoaW5nIGZhYnJpYywgYW5kIGl0 IHJld3JpdGVzIG1hYyBhZGRyZXNzZXNzLCB0aGVuIHRoZXJlIGlzDQphIHByb2JsZW0uDQoNCklm IGl0J3MgYW4gTDMgcm91dGVyLCB0aGVuIHllcywgdGhlIE1BQyBhZGRyZXNzIHdpbGwgY2hhbmdl Lg0KQnV0LCB0aGF0IEwzIHJvdXRlciB3aWxsICphbHNvKiBuZWVkIGEgcm91dGUgdG8gdGhlIGNs aWVudC4NClRoYXQgZmlyc3QgTDMgcm91dGVyIHNob3VsZCBiZSB0aGUgb25lIGRyb3BwaW5nIHRo ZSB0cmFmZmljLg0KDQoNCkFzIEkgc2FpZCBiZWZvcmUsIEkgdGhpbmsgdGhlIGJldHRlciBmaXgg aXMgdG8gaW5zdHJ1bWVudCB0aGUgY2xpZW50LiBJZiB0aGUgY2xpZW50IHJlY2VpdmVzDQphIHBh Y2tldCBvbiBpdHMgcmVsYXktZmFjaW5nIGludGVyZmFjZSwgYW5kIHRoZSByb3V0aW5nIHN5c3Rl bSBkZXRlcm1pbmVzIHRoYXQgdGhlDQpwYWNrZXQgc2hvdWxkIGJlIGZvcndhcmRlZCBvdXQgdGhl IHNhbWUgaW50ZXJmYWNlIHZpYSBhIGRlZmF1bHQgcm91dGUsIHRoZSBjbGllbnQNCm11c3QgZHJv cCB0aGUgcGFja2V0LiBUaGF0IHdheSwgdGhlIHJlbGF5IG5ldmVyIHNlZXMgYSBsb29wZWQgcGFj a2V0LCBhbmQgdGhlcmUNCmlzIG5vIGV4dHJhbmVvdXMgdHJhZmZpYyBvbiB0aGUgY2xpZW50L3Jl bGF5IGludGVyZmFjZS4NCg0KSSBhZ3JlZSB0aGF0IGl0IHNob3VsZCAqYWxzbyogYmUgZml4ZWQg b24gdGhlIGNsaWVudC4NCg0KMSkgVGhlIGNsaWVudCB3aWxsIG5ldmVyIGRvIGFueSBmb3J3YXJk aW5nIGlmIHRoZSB0aGUgY2xpZW50IGhhcyBmb3J3YXJkaW5nDQogIHR1cm5lZCBvZmYuDQoNCjIp IFRoZXJlIGFyZSBtYW55IGNhc2VzIHdoZXJlIHRoZXJlIGFyZSBsZWdpdGltYXRlIHJlYXNvbnMg dG8gaGF2ZSBhbg0KICBvbmUtYXJtZWQgcm91dGVyIGxpa2UgdGhpcy4gIFNvLCB3aGF0ZXZlciB0 ZXh0IHlvdSByaWdodCBtdXN0IGJlIHN1cmUgdGhhdA0KICB0aGUgY2xpZW50IGlzIGxvb2tpbmcg YXQgdGhlIHNhbWUgcGFja2V0LCBhbmQgbm90IHRoZSBJUHNlYyB0cmFuc2Zvcm1lZCBvbmUuDQog IChUaGUgTGludXgga2VybmVsIGRvZXMgbm90IG1ha2UgdGhpcyB0cml2aWFsIHRvIGdldCByaWdo dCwgZm9yIGluc3RhbmNlKQ0KDQoNCi0tDQpNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNh bmRlbG1hbi5jYTxtYWlsdG86bWNyK0lFVEZAc2FuZGVsbWFuLmNhPj4gICAuIG8gTyAoIElQdjYg ScO4VCBjb25zdWx0aW5nICkNCiAgICAgICAgICBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MgSW5j LCBPdHRhd2EgYW5kIFdvcmxkd2lkZQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCmRoY3dnIG1haWxpbmcgbGlzdA0KZGhjd2dAaWV0Zi5vcmc8 bWFpbHRvOmRoY3dnQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9kaGN3Zw0KDQo= --_000_9428b888a7c046a38f85de8fcc260857boeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+SGkgVGVkLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+VGhpbmsgb2YgdGhlIEwyIHByb3h5IGFzIGEgbWlkZGxlYm94IHRoYXQgb2NjdXJzIGJldHdl ZW4gdGhlIGNsaWVudCBhbmQgdGhlIHJlbGF5IChldmVuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmZvciB0 aGUgUkZDNjIyMSBMRFJBIGNhc2UpLiBUaGUgY2xpZW50IGlzIG9uIGEg4oCcZG93bnN0cmVhbSBs aW5rIHNlZ21lbnTigJ0gb2YgdGhlIHByb3h5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5hbmQgdGhlIHJl bGF5IGlzIG9uIGFuIOKAnHVwc3RyZWFtIGxpbmsgc2VnbWVudOKAnSBvZiB0aGUgcHJveHkuIFdo ZW4gdGhlIExEUkEgcnVubmluZyBpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj50aGUgc2FtZSBwaHlzaWNh bCBib3ggYXMgdGhlIHJlbGF5IGdldHMgdGhlIERIQ1B2NiBTb2xpY2l0IG1lc3NhZ2UsIHRoZSBs aW5rLWxheWVyIHNvdXJjZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5hZGRyZXNzIGl0IHdpbGwgc2VlIGlz IOKAmFDigJkgKGkuZS4sIHRoZSB1cHN0cmVhbSBsaW5rIHNlZ21lbnQgYWRkcmVzcyBvZiB0aGUg cHJveHkpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QlRXLCBJ IGhhZCZuYnNwOyBhIHR5cG8gaW4gbXkgbGFzdCBtZXNzYWdlIOKAkyBJIGludGVuZGVkIHRvIGNp dGUgUkZDNDM4OS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkZy ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFRlZCBMZW1vbiBb bWFpbHRvOm1lbGxvbkBmdWd1ZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgT2N0 b2JlciAxMywgMjAyMCAxMTowMCBBTTxicj4NCjxiPlRvOjwvYj4gVGVtcGxpbiAoVVMpLCBGcmVk IEwgJmx0O0ZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNaWNo YWVsIFJpY2hhcmRzb24gJmx0O21jciYjNDM7aWV0ZkBzYW5kZWxtYW4uY2EmZ3Q7OyBpYW5mYXJy ZXJAZ214LmNvbTsgSmVuIExpbmtvdmEgJmx0O2Z1cnJ5MTNAZ21haWwuY29tJmd0OzsgZGhjd2cg Jmx0O2RoY3dnQGlldGYub3JnJmd0OzsgdjZvcHMgbGlzdCAmbHQ7djZvcHNAaWV0Zi5vcmcmZ3Q7 OyA2bWFuICZsdDtpcHY2QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2Ro Y3dnXSBSZTogW3Y2b3BzXSBSZTogUXVlc3Rpb24gdG8gREhDUHY2IFJlbGF5IEltcGxlbWVudG9y cyByZWdhcmRpbmcgZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LXBkLXJlbGF5LXJlcXVpcmVtZW50czxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+RnJlZCwgYWNjb3JkaW5nIHRvIFJGQzYyMjE6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmUgc3R5 bGU9ImJyZWFrLWJlZm9yZTogcGFnZTtjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBUaGUgTERSQSBNVVNUIGNvcHkgdGhlIElQ IHNvdXJjZSBhZGRyZXNzIGZyb20gdGhlIGNsaWVudC1vcmlnaW5hdGVkPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IG1l c3NhZ2UgaW50byB0aGUgcGVlci1hZGRyZXNzIGZpZWxkIG9mIHRoZSBSZWxheS1Gb3J3YXJkIG1l c3NhZ2UuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7IFRoZSBMRFJBIE1VU1QgY29weSB0aGUgbGluay1sYXllciBzb3Vy Y2UgYWRkcmVzcyBmcm9tIHRoZSBjbGllbnQtPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IG9yaWdpbmF0ZWQgbWVzc2Fn ZSBpbnRvIHRoZSBsaW5rLWxheWVyIHNvdXJjZSBhZGRyZXNzIG9mIHRoZSBSZWxheS08bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgRm9yd2FyZCBtZXNzYWdlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+VGhpcyBpcyBh bHNvIHRydWUgZm9yIHRoZSBkZXN0aW5hdGlvbiBhZGRyZXNzLiBTbyBpZiB0aGF0IGlzIHdoYXQg bXkgbWVhbiBieSBhbiDigJxMMiBwcm94eSzigJ0gSSBkb27igJl0IHRoaW5rIHRoYXQgdGhlIG9y aWdpbmFsIE1BQyBhZGRyZXNzIHdvdWxkIGJlIGhpZGRlbiBieSBpdC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi Pk9uIE9jdCAxMywgMjAyMCwgYXQgMTo0NCBQTSwgVGVtcGxpbiAoVVMpLCBGcmVkIEwgJmx0Ozxh IGhyZWY9Im1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tIj5GcmVkLkwuVGVtcGxpbkBi b2VpbmcuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+TWljaGFlbCwgd2hhdCBJIHdhcyByZWZl cnJpbmcgdG8gYmVsb3cgYXMgJnF1b3Q7ZmFpbHVyZSZxdW90OyBpcyB0aGUgcHJveHkgY2FzZSB3 aGVuPGJyPg0KdGhlcmUgaXMgYW4gTDIgcHJveHkgUCBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHJl bGF5IChlLmcuLCBSRkM0ODkpLiBUaGVyZTxicj4NCmNvdWxkIGJlIG1hbnkgY2xpZW50cyBBLCBC LCBDLCBELCBldGMuIG9uIGRvd25zdHJlYW0gbGluayBzZWdtZW50cyBvZjxicj4NCnRoZSBwcm94 eSwgd2l0aCB0aGUgcmVsYXkgUiBvbiBhbiB1cHN0cmVhbSBsaW5rIHNlZ21lbnQuIFRoZSByZWxh eSB3b3VsZDxicj4NCnRoZW4gbm90IHNlZSB0aGUgaW5kaXZpZHVhbCBjbGllbnQgTUFDIGFkZHJl c3NlcyBBLCBCLCBDLCBELCBldGMuIC0gaXQgd291bGQ8YnI+DQpzZWUgb25seSB0aGUgcHJveHkg TUFDIGFkZHJlc3MgUCBpbiBhbGwgY2FzZXMuIFNvLCBpdCBpcyB0cnVlIHRoYXQgYW4gUlBGPGJy Pg0KY2hlY2sgaW4gdGhlIHJlbGF5IHdvdWxkIGRyb3AgYSBwYWNrZXQgZnJvbSBjbGllbnQgQSBh ZGRyZXNzZWQgdG8gaXRzZWxmLDxicj4NCmJ1dCBpdCB3b3VsZCBhbHNvIGRyb3AgYW55IG9mIGNs aWVudCBBJ3MgcGFja2V0cyBhZGRyZXNzZWQgdG8gY2xpZW50cyBCLDxicj4NCkMsIEQsIGV0Yy4g VGhhdCBpcyB3aGF0IEkgbWVhbnQgYnkgJnF1b3Q7ZmFpbHVyZSZxdW90OyBpbiB0aGlzIGNvbnRl eHQuPGJyPg0KPGJyPg0KRnJlZDxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogTWljaGFlbCBSaWNoYXJkc29u IFs8YSBocmVmPSJtYWlsdG86bWNyJiM0MztpZXRmQHNhbmRlbG1hbi5jYSI+bWFpbHRvOm1jciYj NDM7aWV0ZkBzYW5kZWxtYW4uY2E8L2E+XTxicj4NClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMTMs IDIwMjAgMTA6MDMgQU08YnI+DQpUbzogVGVtcGxpbiAoVVMpLCBGcmVkIEwgJmx0OzxhIGhyZWY9 Im1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tIj5GcmVkLkwuVGVtcGxpbkBib2Vpbmcu Y29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86aWFuZmFycmVyQGdteC5jb20iPmlhbmZhcnJl ckBnbXguY29tPC9hPjsgSmVuIExpbmtvdmEgJmx0OzxhIGhyZWY9Im1haWx0bzpmdXJyeTEzQGdt YWlsLmNvbSI+ZnVycnkxM0BnbWFpbC5jb208L2E+Jmd0OzsgZGhjd2c8YnI+DQombHQ7PGEgaHJl Zj0ibWFpbHRvOmRoY3dnQGlldGYub3JnIj5kaGN3Z0BpZXRmLm9yZzwvYT4mZ3Q7OyB2Nm9wcyBs aXN0ICZsdDs8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciPnY2b3BzQGlldGYub3JnPC9h PiZndDs7IDZtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzppcHY2QGlldGYub3JnIj5pcHY2QGlldGYu b3JnPC9hPiZndDs8YnI+DQpTdWJqZWN0OiBbRVhURVJOQUxdIFJlOiBbZGhjd2ddIFt2Nm9wc10g UmU6IFF1ZXN0aW9uIHRvIERIQ1B2NiBSZWxheSBJbXBsZW1lbnRvcnMgcmVnYXJkaW5nIGRyYWZ0 LWlldGYtZGhjLWRoY3B2Ni1wZC1yZWxheS08YnI+DQpyZXF1aXJlbWVudHM8YnI+DQo8YnI+DQo8 YnI+DQpUZW1wbGluIChVUyksIEZyZWQgTCAmbHQ7PGEgaHJlZj0ibWFpbHRvOkZyZWQuTC5UZW1w bGluQGJvZWluZy5jb20iPkZyZWQuTC5UZW1wbGluQGJvZWluZy5jb208L2E+Jmd0OyB3cm90ZTo8 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkZvciBtdWx0aS1hY2Nlc3MgbGlua3Ms IHdoZW4gdGhlIHBhY2tldCdzPGJyPg0KaW5ncmVzcyBhbmQgZWdyZXNzIGludGVyZmFjZSBtYXRj aCwgYW5kIHRoZSBzb3VyY2UgTUFDIGFuZCBuZXh0LWhvcCBNQUMgYWRkcmVzc2VzPGJyPg0KbWF0 Y2guPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxicj4N Cjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkFzIEkgc2FpZCwgdGhpcyBnZXRzIHZlcnkgdHJp Y2t5IGlmIHRoZSBjbGllbnQgaGFzIG11bHRpcGxlIE1BQ3MuIElmIENsaWVudCBBIGhhcyBNQUMg YWRkcmVzc2VzPGJyPg0KYTEsIGEyLCBhMywgYTQsIGV0Yy4gaXQgYmVjb21lcyB2ZXJ5IGRpZmZp Y3VsdCBmb3IgdGhlIHJlbGF5IHRvIGtub3cgdGhhdCBhIHBhY2tldCByZWNlaXZlZDxicj4NCmZy b20gb25lIG9mIHRoZSBNQUMgYWRkcmVzc2VzIChlLmcuLCBhMSkgbXVzdCBub3QgYmUgc2VudCBi YWNrIHRvIGFub3RoZXIgb2YgdGhlIE1BQzxicj4NCmFkZHJlc3NlcyAoZS5nLiwgYTMpLiBJIHRo aW5rIGFub3RoZXIgZmFpbHVyZSBjYXNlIGlzIGlmIHRoZXJlIGlzIGEgcHJveHkgYmV0d2VlbiB0 aGUgY2xpZW50PGJyPg0KYW5kIHJlbGF5LiBJbiB0aGF0IGNhc2UsIHRoZSByZWxheSB3aWxsIHNl ZSB0aGUgTUFDIGFkZHJlc3Mgb2YgdGhlIHByb3h5IGFuZCBub3QgdGhlPGJyPg0KTUFDIGFkZHJl c3Mgb2YgY2xpZW50IEEuIEFuZCwgaWYgdGhlcmUgd2VyZSBtdWx0aXBsZSBhZGRpdGlvbmFsIGNs aWVudHMgQiwgQywgRCwgZXRjLjxicj4NCnNoYXJpbmcgdGhlIHNhbWUgcHJveHkgdGhlbiB0aGUg cHJvcG9zZWQgY2hlY2sgY291bGQgYmxvY2sgbGVnaXRpbWF0ZTxicj4NCnRyYWZmaWMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxicj4NCm9rYXksIGJ1dCBsZXQncyBiZSBjbGVh ciBhYm91dCB3aGF0ICZxdW90O2ZhaWx1cmUmcXVvdDsgaGVyZSBtZWFucy48YnI+DQpJZiB0aGUg Y2xpZW50IGhhcyBtdWx0aXBsZSBNQUMgYWRkcmVzc2VzLCB0aGVuIHRoZSByb3V0ZXIgKmZhaWxz KiB0bzxicj4NCmVsaW1pbmF0ZSB0aGUgbG9vcC4gJm5ic3A7SXQgZG9lcyBub3QgZHJvcCB0cmFm ZmljIGl0IHNob3VsZG4ndC48YnI+DQpTbyB0aGlzIHBvbGljeSBkb2Vzbid0IG1ha2UgdGhlIHNp dHVhdGlvbiB3b3JzZS48YnI+DQo8YnI+DQpJIGRvbid0IGtub3cgd2hhdCBraW5kIG9mIHJlbGF5 IHlvdSBhcmUgdGFsa2luZyBhYm91dC48YnI+DQpJZiBpdCdzIGEgTDIgc3dpdGNoaW5nIGZhYnJp YywgYW5kIGl0IHJld3JpdGVzIG1hYyBhZGRyZXNzZXNzLCB0aGVuIHRoZXJlIGlzPGJyPg0KYSBw cm9ibGVtLjxicj4NCjxicj4NCklmIGl0J3MgYW4gTDMgcm91dGVyLCB0aGVuIHllcywgdGhlIE1B QyBhZGRyZXNzIHdpbGwgY2hhbmdlLjxicj4NCkJ1dCwgdGhhdCBMMyByb3V0ZXIgd2lsbCAqYWxz byogbmVlZCBhIHJvdXRlIHRvIHRoZSBjbGllbnQuPGJyPg0KVGhhdCBmaXJzdCBMMyByb3V0ZXIg c2hvdWxkIGJlIHRoZSBvbmUgZHJvcHBpbmcgdGhlIHRyYWZmaWMuPGJyPg0KPGJyPg0KPGJyPg0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+QXMgSSBzYWlkIGJlZm9yZSwgSSB0aGluayB0aGUgYmV0dGVy IGZpeCBpcyB0byBpbnN0cnVtZW50IHRoZSBjbGllbnQuIElmIHRoZSBjbGllbnQgcmVjZWl2ZXM8 YnI+DQphIHBhY2tldCBvbiBpdHMgcmVsYXktZmFjaW5nIGludGVyZmFjZSwgYW5kIHRoZSByb3V0 aW5nIHN5c3RlbSBkZXRlcm1pbmVzIHRoYXQgdGhlPGJyPg0KcGFja2V0IHNob3VsZCBiZSBmb3J3 YXJkZWQgb3V0IHRoZSBzYW1lIGludGVyZmFjZSB2aWEgYSBkZWZhdWx0IHJvdXRlLCB0aGUgY2xp ZW50PGJyPg0KbXVzdCBkcm9wIHRoZSBwYWNrZXQuIFRoYXQgd2F5LCB0aGUgcmVsYXkgbmV2ZXIg c2VlcyBhIGxvb3BlZCBwYWNrZXQsIGFuZCB0aGVyZTxicj4NCmlzIG5vIGV4dHJhbmVvdXMgdHJh ZmZpYyBvbiB0aGUgY2xpZW50L3JlbGF5IGludGVyZmFjZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48YnI+DQpJIGFncmVlIHRo YXQgaXQgc2hvdWxkICphbHNvKiBiZSBmaXhlZCBvbiB0aGUgY2xpZW50Ljxicj4NCjxicj4NCjEp IFRoZSBjbGllbnQgd2lsbCBuZXZlciBkbyBhbnkgZm9yd2FyZGluZyBpZiB0aGUgdGhlIGNsaWVu dCBoYXMgZm9yd2FyZGluZzxicj4NCiZuYnNwOyZuYnNwO3R1cm5lZCBvZmYuPGJyPg0KPGJyPg0K MikgVGhlcmUgYXJlIG1hbnkgY2FzZXMgd2hlcmUgdGhlcmUgYXJlIGxlZ2l0aW1hdGUgcmVhc29u cyB0byBoYXZlIGFuPGJyPg0KJm5ic3A7Jm5ic3A7b25lLWFybWVkIHJvdXRlciBsaWtlIHRoaXMu ICZuYnNwO1NvLCB3aGF0ZXZlciB0ZXh0IHlvdSByaWdodCBtdXN0IGJlIHN1cmUgdGhhdDxicj4N CiZuYnNwOyZuYnNwO3RoZSBjbGllbnQgaXMgbG9va2luZyBhdCB0aGUgc2FtZSBwYWNrZXQsIGFu ZCBub3QgdGhlIElQc2VjIHRyYW5zZm9ybWVkIG9uZS48YnI+DQombmJzcDsmbmJzcDsoVGhlIExp bnV4IGtlcm5lbCBkb2VzIG5vdCBtYWtlIHRoaXMgdHJpdmlhbCB0byBnZXQgcmlnaHQsIGZvciBp bnN0YW5jZSk8YnI+DQo8YnI+DQo8YnI+DQotLTxicj4NCk1pY2hhZWwgUmljaGFyZHNvbiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm1jciYjNDM7SUVURkBzYW5kZWxtYW4uY2EiPm1jciYjNDM7SUVURkBz YW5kZWxtYW4uY2E8L2E+Jmd0OyAmbmJzcDsmbmJzcDsuIG8gTyAoIElQdjYgScO4VCBjb25zdWx0 aW5nICk8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MgSW5jLCBPdHRhd2EgYW5kIFdv cmxkd2lkZTxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCmRoY3dnIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpkaGN3Z0BpZXRmLm9y ZyI+ZGhjd2dAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9kaGN3ZyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9kaGN3ZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9428b888a7c046a38f85de8fcc260857boeingcom_-- From nobody Tue Oct 13 11:42: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 707E43A0FC7 for ; Tue, 13 Oct 2020 11:42:33 -0700 (PDT) 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, 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=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 fE7dXaXa_Ook for ; Tue, 13 Oct 2020 11:42:32 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 080F63A0FC4 for ; Tue, 13 Oct 2020 11:42:31 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id k6so780097ior.2 for ; Tue, 13 Oct 2020 11:42:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=nmg+rrkkxqGpa7sZPlJtXEj3GvQq4qN8DBlFuNc8x3c=; b=XAol0xTflnw6tKwyp/AY76NjNzXzXMt6gt5Gdkm39klEEyw8Pbo7dYQEfRIviBHpSF QH+N+DHDb5Oo0G+5UyxWTr3wrsfN/PiAOjF1zkKbZaOt0NAmwy4ScQsbcLtamEkdBwBN nxXVDOtOAgIyEiKm9Nn+kr8sUtp/p4/TwWhyfrvQlfhvHnh8uCk4rAmSXIxGGXJfgyqB 4yn/8HN9GRCUxDsl9jrA2LbvgS3h0WhI9rHobqOK4heCNiBBX74Rdrstr/NAvpCHuVSo +G7iLzUddZ1rUQbaqIF9WRSe3BkKdx24wjwSnbc0AUvar8zLia50yS5GHoTB64us6cHs 5tuA== 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=nmg+rrkkxqGpa7sZPlJtXEj3GvQq4qN8DBlFuNc8x3c=; b=Zf+tYu5p8hLOYpqEaMzRolI6myPKAsit9t/VG0wKr2epQNsd7feBpZHwFM4iITwy84 mrGHdLVHFj3DEsrBBVm/N434lk5iB4HcnLoxw1+7SdB3EMudMT4nFsxLWAKWJDesuInT dTbm6wP3AZDX0vG+N7IQcdOSCvfDYIcFz+WSwZObThWZ7MGSTclNtpOZpTGhTlOBQLnB Us4CIB+t6usmvRIku2Zq0DtwNbicrq0ibdn0WDLkW3qHw81W151eNketX3rjwa79MIU7 ZlCx23F0C3x/5iXbvuQn3LX/0Cvvv0NdY845NS5MoKBY4yB+e152bN6FY0nL3BrtCaT9 mG5g== X-Gm-Message-State: AOAM5303/UXjuCpz15DFlzoOncQt3tWlmjtb+KlvFh+aC/DoUo061JFY vcM72FbvK2oes3cxpW14Uz0uuA== X-Google-Smtp-Source: ABdhPJzKJc34hVgw9K98TXeelIUXpC/tE70lklUtVpQSUA7LNUaF7UqyPHtyDrTQknvGeZ6sAoYzMw== X-Received: by 2002:a6b:b2c5:: with SMTP id b188mr178559iof.90.1602614551136; Tue, 13 Oct 2020 11:42:31 -0700 (PDT) Received: from mithrandir.lan (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id o72sm687310ilb.6.2020.10.13.11.42.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Oct 2020 11:42:30 -0700 (PDT) From: Ted Lemon Message-Id: <9944583D-57D2-47D8-9A35-F5E9BCA3EE11@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3C074FA9-8B7B-4741-996D-4C54F72C398A" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.82\)) Date: Tue, 13 Oct 2020 14:42:29 -0400 In-Reply-To: <9428b888a7c046a38f85de8fcc260857@boeing.com> Cc: Michael Richardson , "ianfarrer@gmx.com" , Jen Linkova , dhcwg , v6ops list , 6man To: "Templin (US), Fred L" References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> <10487.1602608586@localhost> <378d3420690246bbae253fb15be8c9a7@boeing.com> <4478E969-8C25-46E1-9C21-B74189F23058@fugue.com> <9428b888a7c046a38f85de8fcc260857@boeing.com> X-Mailer: Apple Mail (2.3654.0.3.2.82) Archived-At: Subject: Re: [v6ops] [dhcwg] [EXTERNAL] Re: Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Tue, 13 Oct 2020 18:42:33 -0000 --Apple-Mail=_3C074FA9-8B7B-4741-996D-4C54F72C398A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Oct 13, 2020, at 2:38 PM, Templin (US), Fred L = > wrote: > Think of the L2 proxy as a middlebox that occurs between the client = and the relay (even > for the RFC6221 LDRA case). The client is on a =E2=80=9Cdownstream = link segment=E2=80=9D of the proxy, > and the relay is on an =E2=80=9Cupstream link segment=E2=80=9D of the = proxy. When the LDRA running in > the same physical box as the relay gets the DHCPv6 Solicit message, = the link-layer source > address it will see is =E2=80=98P=E2=80=99 (i.e., the upstream link = segment address of the proxy). If it=E2=80=99s an LDRA, and that=E2=80=99s the behavior, it=E2=80=99s = not following the RFC. I can=E2=80=99t speak to other types of proxies, = of course. --Apple-Mail=_3C074FA9-8B7B-4741-996D-4C54F72C398A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Oct 13, 2020, at = 2:38 PM, Templin (US), Fred L <Fred.L.Templin@boeing.com> wrote:
Think of the L2 proxy = as a middlebox that occurs between the client and the relay (even
for the RFC6221 LDRA = case). The client is on a =E2=80=9Cdownstream link segment=E2=80=9D of = the proxy,
and the relay is on an = =E2=80=9Cupstream link segment=E2=80=9D of the proxy. When the LDRA = running in
the same physical box = as the relay gets the DHCPv6 Solicit message, the link-layer source
address it will see is = =E2=80=98P=E2=80=99 (i.e., the upstream link segment address of the = proxy).

If it=E2=80=99s an LDRA, and that=E2=80=99s the behavior, = it=E2=80=99s not following the RFC. I can=E2=80=99t speak to other types = of proxies, of course.

= --Apple-Mail=_3C074FA9-8B7B-4741-996D-4C54F72C398A-- From nobody Tue Oct 13 11:57: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 B07D63A10F9; Tue, 13 Oct 2020 11:57:40 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=boeing.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 OcDT94Mq8b9C; Tue, 13 Oct 2020 11:57:38 -0700 (PDT) Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 8849D3A10DF; Tue, 13 Oct 2020 11:57:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09DIvWHV015977; Tue, 13 Oct 2020 14:57:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602615456; bh=lUzzD92RS2NRa3MOBCqzQhzRcf83Y8jmTSZO4TPghkg=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=XuxvtHrDo53bnHrL+G0NMOux9hMnEjJCDFuxbplkSSUsPN+Cyfoq4GS8GweE8aCRo 42+1APV1F9f/5uR6OMUxe/SKsx7phD6A5/2CU+r3u+G6x/s5K//e5LOnX3Vw3S7Coo CY+h5UVMGZtlXMWaiYpp94Vd7Z9PHjR8rpM5mpINNOo9NDNEmM5DROnTsqaS3LXto0 t4eddWfSGu/Jqdd658eL/K4WoSMMDuw+T/qRXxcED3NiVXdu6NBE9HCj/UQnoYcFI2 bKJvpdH4NNqYUqg3hC6Z/U0kpRp13K9IzLLrNdxbsENDoC+Jh5GU8xOofz3hHDr9Bl uqkIRGnyZYLmw== Received: from XCH16-07-11.nos.boeing.com (xch16-07-11.nos.boeing.com [144.115.66.113]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09DIvOc2014806 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Tue, 13 Oct 2020 14:57:24 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-11.nos.boeing.com (144.115.66.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Tue, 13 Oct 2020 11:57:23 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Tue, 13 Oct 2020 11:57:23 -0700 From: "Templin (US), Fred L" To: Ted Lemon CC: Michael Richardson , "ianfarrer@gmx.com" , Jen Linkova , dhcwg , v6ops list , 6man Thread-Topic: [dhcwg] [EXTERNAL] Re: [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AQHWoZACP+11iV2gnk+uDowUHAjjrKmWU22A//+Lh0A= Date: Tue, 13 Oct 2020 18:57:22 +0000 Message-ID: References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> <10487.1602608586@localhost> <378d3420690246bbae253fb15be8c9a7@boeing.com> <4478E969-8C25-46E1-9C21-B74189F23058@fugue.com> <9428b888a7c046a38f85de8fcc260857@boeing.com> <9944583D-57D2-47D8-9A35-F5E9BCA3EE11@fugue.com> In-Reply-To: <9944583D-57D2-47D8-9A35-F5E9BCA3EE11@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 1EF203FD0EA3D28B898830A8794F20C1BF92D990F91A937DE0096FE6CE86307D2000:8 Content-Type: multipart/alternative; boundary="_000_d94b3649149c433ca6853f7c977aea65boeingcom_" MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [dhcwg] [EXTERNAL] Re: Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Tue, 13 Oct 2020 18:57:48 -0000 --_000_d94b3649149c433ca6853f7c977aea65boeingcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGVkIOKAkyB0aGUgcHJveHkgaXMgbm90IGFjdGluZyBhcyBhbiBSRkM2MjIxIExEUkEg4oCTIHRo YXQgaXMgbm90IHdoYXQgaXMgYmVpbmcgaW1wbGllZC4NCkluIGZhY3QsIGxldOKAmXMgZm9yZ2V0 IGFib3V0IExEUkEgYmVjYXVzZSBpdCBpcyBub3QgcmVhbGx5IGFwcGxpY2FibGUgdG8gdGhpcyBk aXNjdXNzaW9uLg0KDQpUaGUgY2FzZSB3ZSBoYXZlIGlzIHRoYXQgdGhlIHByb3h5IOKAmFDigJkg c2VlcyB0aGUgbGluay1sYXllciBhZGRyZXNzIOKAmEPigJkgb2YgdGhlIGNsaWVudA0Kb24gYSBk b3duc3RyZWFtIGxpbmsgc2VnbWVudCBhbmQgc2VlcyB0aGUgbGluay1sYXllciBhZGRyZXNzIOKA mFLigJkgb2YgdGhlIHJlbGF5IG9uDQphbiB1cHN0cmVhbSBsaW5rIHNlZ21lbnQuIFdoZW4gdGhl IGNsaWVudCBzZW5kcyBhIERIQ1B2NiBzb2xpY2l0LCBpdCB3aWxsIGFycml2ZSBhdA0KdGhlIHBy b3h5IHdoaWNoIGNoYW5nZXMgdGhlIHNvdXJjZSBsaW5rLWxheWVyIGFkZHJlc3MgZnJvbSDigJhD 4oCZIHRvIOKAmFDigJkgYmVmb3JlDQpmb3J3YXJkaW5nIChhdCBsYXllci0yKSB0byB0aGUgcmVs YXkuIFRoZSByZWxheSAoaG93ZXZlciBpdCBpcyBpbXBsZW1lbnRlZCkgd2lsbA0KdGhlbiBzZWUg dGhlIERIQ1B2NiBTb2xpY2l0IGFycml2aW5nIHdpdGgg4oCYUOKAmSBhcyB0aGUgbGluay1sYXll ciBzb3VyY2UgYWRkcmVzcw0KYW5kIHdpbGwga25vdyBub3RoaW5nIGFib3V0IHRoZSBjbGllbnQg YWRkcmVzcyDigJhD4oCZLg0KDQpCVFcsIEkgYW0gc3RpbGwgd2FpdGluZyB0byBoZWFyIGhvdyB0 aGlzIGNvbmNlcm4gaXMgaW4gYW55IHdheSBzcGVjaWZpYyB0byBwcmVmaXgNCmRlbGVnYXRpb24s IHNpbmNlIGl0IHNlZW1zIHRvIGJlIGdlbmVyaWMgdG8gYW55IGNhc2Ugb2YgaGF2aW5nIGEg4oCc c3R1YuKAnSByb3V0ZXINCnRoYXQgbWFsaWNpb3VzbHkgYXR0YWNrcyBpdHMgb3duIHVwc3RyZWFt IGxpbmsg4oCTIG5vIG1hdHRlciBob3cgdGhhdCByb3V0ZXINCm5lZ290aWF0ZXMgaXRzIHByZWZp eGVzIHdpdGggdXBzdHJlYW0gbmV0d29yayBub2Rlcy4NCg0KRnJlZA0KDQpGcm9tOiBUZWQgTGVt b24gW21haWx0bzptZWxsb25AZnVndWUuY29tXQ0KU2VudDogVHVlc2RheSwgT2N0b2JlciAxMywg MjAyMCAxMTo0MiBBTQ0KVG86IFRlbXBsaW4gKFVTKSwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBi b2VpbmcuY29tPg0KQ2M6IE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNh PjsgaWFuZmFycmVyQGdteC5jb207IEplbiBMaW5rb3ZhIDxmdXJyeTEzQGdtYWlsLmNvbT47IGRo Y3dnIDxkaGN3Z0BpZXRmLm9yZz47IHY2b3BzIGxpc3QgPHY2b3BzQGlldGYub3JnPjsgNm1hbiA8 aXB2NkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbZGhjd2ddIFtFWFRFUk5BTF0gUmU6IFt2Nm9w c10gUmU6IFF1ZXN0aW9uIHRvIERIQ1B2NiBSZWxheSBJbXBsZW1lbnRvcnMgcmVnYXJkaW5nIGRy YWZ0LWlldGYtZGhjLWRoY3B2Ni1wZC1yZWxheS1yZXF1aXJlbWVudHMNCg0KDQpUaGlzIG1lc3Nh Z2Ugd2FzIHNlbnQgZnJvbSBvdXRzaWRlIG9mIEJvZWluZy4gUGxlYXNlIGRvIG5vdCBjbGljayBs aW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIg YW5kIGtub3cgdGhhdCB0aGUgY29udGVudCBpcyBzYWZlLg0KDQoNCg0KDQpPbiBPY3QgMTMsIDIw MjAsIGF0IDI6MzggUE0sIFRlbXBsaW4gKFVTKSwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2Vp bmcuY29tPG1haWx0bzpGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPj4gd3JvdGU6DQpUaGluayBv ZiB0aGUgTDIgcHJveHkgYXMgYSBtaWRkbGVib3ggdGhhdCBvY2N1cnMgYmV0d2VlbiB0aGUgY2xp ZW50IGFuZCB0aGUgcmVsYXkgKGV2ZW4NCmZvciB0aGUgUkZDNjIyMSBMRFJBIGNhc2UpLiBUaGUg Y2xpZW50IGlzIG9uIGEg4oCcZG93bnN0cmVhbSBsaW5rIHNlZ21lbnTigJ0gb2YgdGhlIHByb3h5 LA0KYW5kIHRoZSByZWxheSBpcyBvbiBhbiDigJx1cHN0cmVhbSBsaW5rIHNlZ21lbnTigJ0gb2Yg dGhlIHByb3h5LiBXaGVuIHRoZSBMRFJBIHJ1bm5pbmcgaW4NCnRoZSBzYW1lIHBoeXNpY2FsIGJv eCBhcyB0aGUgcmVsYXkgZ2V0cyB0aGUgREhDUHY2IFNvbGljaXQgbWVzc2FnZSwgdGhlIGxpbmst bGF5ZXIgc291cmNlDQphZGRyZXNzIGl0IHdpbGwgc2VlIGlzIOKAmFDigJkgKGkuZS4sIHRoZSB1 cHN0cmVhbSBsaW5rIHNlZ21lbnQgYWRkcmVzcyBvZiB0aGUgcHJveHkpLg0KDQpJZiBpdOKAmXMg YW4gTERSQSwgYW5kIHRoYXTigJlzIHRoZSBiZWhhdmlvciwgaXTigJlzIG5vdCBmb2xsb3dpbmcg dGhlIFJGQy4gSSBjYW7igJl0IHNwZWFrIHRvIG90aGVyIHR5cGVzIG9mIHByb3hpZXMsIG9mIGNv dXJzZS4NCg0K --_000_d94b3649149c433ca6853f7c977aea65boeingcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K c3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRlZCDigJMgdGhlIHByb3h5IGlzIG5vdCBhY3RpbmcgYXMg YW4gUkZDNjIyMSBMRFJBIOKAkyB0aGF0IGlzIG5vdCB3aGF0IGlzIGJlaW5nIGltcGxpZWQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkluIGZhY3QsIGxldOKAmXMgZm9yZ2V0IGFib3V0IExEUkEgYmVjYXVz ZSBpdCBpcyBub3QgcmVhbGx5IGFwcGxpY2FibGUgdG8gdGhpcyBkaXNjdXNzaW9uLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIGNhc2Ugd2UgaGF2ZSBpcyB0 aGF0IHRoZSBwcm94eSDigJhQ4oCZIHNlZXMgdGhlIGxpbmstbGF5ZXIgYWRkcmVzcyDigJhD4oCZ IG9mIHRoZSBjbGllbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+b24gYSBkb3duc3RyZWFtIGxpbmsgc2Vn bWVudCBhbmQgc2VlcyB0aGUgbGluay1sYXllciBhZGRyZXNzIOKAmFLigJkgb2YgdGhlIHJlbGF5 IG9uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+YW4gdXBzdHJlYW0gbGluayBzZWdtZW50LiBXaGVuIHRo ZSBjbGllbnQgc2VuZHMgYSBESENQdjYgc29saWNpdCwgaXQgd2lsbCBhcnJpdmUgYXQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+dGhlIHByb3h5IHdoaWNoIGNoYW5nZXMgdGhlIHNvdXJjZSBsaW5rLWxheWVy IGFkZHJlc3MgZnJvbSDigJhD4oCZIHRvIOKAmFDigJkgYmVmb3JlPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PmZvcndhcmRpbmcgKGF0IGxheWVyLTIpIHRvIHRoZSByZWxheS4gVGhlIHJlbGF5IChob3dldmVy IGl0IGlzIGltcGxlbWVudGVkKSB3aWxsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnRoZW4gc2VlIHRoZSBE SENQdjYgU29saWNpdCBhcnJpdmluZyB3aXRoIOKAmFDigJkgYXMgdGhlIGxpbmstbGF5ZXIgc291 cmNlIGFkZHJlc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+YW5kIHdpbGwga25vdyBub3RoaW5nIGFib3V0 IHRoZSBjbGllbnQgYWRkcmVzcyDigJhD4oCZLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+QlRXLCBJIGFtIHN0aWxsIHdhaXRpbmcgdG8gaGVhciBob3cgdGhpcyBj b25jZXJuIGlzIGluIGFueSB3YXkgc3BlY2lmaWMgdG8gcHJlZml4PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PmRlbGVnYXRpb24sIHNpbmNlIGl0IHNlZW1zIHRvIGJlIGdlbmVyaWMgdG8gYW55IGNhc2Ugb2Yg aGF2aW5nIGEg4oCcc3R1YuKAnSByb3V0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+dGhhdCBtYWxpY2lv dXNseSBhdHRhY2tzIGl0cyBvd24gdXBzdHJlYW0gbGluayDigJMgbm8gbWF0dGVyIGhvdyB0aGF0 IHJvdXRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5uZWdvdGlhdGVzIGl0cyBwcmVmaXhlcyB3aXRoIHVw c3RyZWFtIG5ldHdvcmsgbm9kZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5GcmVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBU ZWQgTGVtb24gW21haWx0bzptZWxsb25AZnVndWUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1 ZXNkYXksIE9jdG9iZXIgMTMsIDIwMjAgMTE6NDIgQU08YnI+DQo8Yj5Ubzo8L2I+IFRlbXBsaW4g KFVTKSwgRnJlZCBMICZsdDtGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tJmd0Ozxicj4NCjxiPkNj OjwvYj4gTWljaGFlbCBSaWNoYXJkc29uICZsdDttY3ImIzQzO2lldGZAc2FuZGVsbWFuLmNhJmd0 OzsgaWFuZmFycmVyQGdteC5jb207IEplbiBMaW5rb3ZhICZsdDtmdXJyeTEzQGdtYWlsLmNvbSZn dDs7IGRoY3dnICZsdDtkaGN3Z0BpZXRmLm9yZyZndDs7IHY2b3BzIGxpc3QgJmx0O3Y2b3BzQGll dGYub3JnJmd0OzsgNm1hbiAmbHQ7aXB2NkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtkaGN3Z10gW0VYVEVSTkFMXSBSZTogW3Y2b3BzXSBSZTogUXVlc3Rpb24gdG8gREhD UHY2IFJlbGF5IEltcGxlbWVudG9ycyByZWdhcmRpbmcgZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LXBk LXJlbGF5LXJlcXVpcmVtZW50czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjx0YWJsZSBjbGFz cz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0K PHRyPg0KPHRkIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlO3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1 cHQgLjc1cHQiPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxs c3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIGFsaWduPSJsZWZ0IiB3aWR0aD0iMTAwJSIgc3R5 bGU9IndpZHRoOjEwMC4wJTttYXJnaW4tbGVmdDouNzVwdDttYXJnaW4tcmlnaHQ6Ljc1cHQiPg0K PHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJiYWNrZ3JvdW5kOiM5MTBBMTk7cGFkZGluZzo1LjI1 cHQgMS41cHQgNS4yNXB0IDEuNXB0Ij48L3RkPg0KPHRkIHdpZHRoPSIxMDAlIiBzdHlsZT0id2lk dGg6MTAwLjAlO2JhY2tncm91bmQ6I0ZERjJGNDtwYWRkaW5nOjUuMjVwdCAzLjc1cHQgNS4yNXB0 IDExLjI1cHQ7d29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21z by1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3Jh cGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpl eGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjEyMTIxIj5UaGlzIG1lc3NhZ2Ugd2Fz IHNlbnQgZnJvbSBvdXRzaWRlIG9mIEJvZWluZy4gUGxlYXNlIGRvIG5vdCBjbGljayBsaW5rcyBv ciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtu b3cgdGhhdCB0aGUgY29udGVudCBpcyBzYWZlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48YnI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L3RkPg0KPC90 cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPk9uIE9jdCAxMywgMjAyMCwg YXQgMjozOCBQTSwgVGVtcGxpbiAoVVMpLCBGcmVkIEwgJmx0OzxhIGhyZWY9Im1haWx0bzpGcmVk LkwuVGVtcGxpbkBib2VpbmcuY29tIj5GcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhpbmsgb2Yg dGhlIEwyIHByb3h5IGFzIGEgbWlkZGxlYm94IHRoYXQgb2NjdXJzIGJldHdlZW4gdGhlIGNsaWVu dCBhbmQgdGhlIHJlbGF5IChldmVuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPmZv ciB0aGUgUkZDNjIyMSBMRFJBIGNhc2UpLiBUaGUgY2xpZW50IGlzIG9uIGEg4oCcZG93bnN0cmVh bSBsaW5rIHNlZ21lbnTigJ0gb2YgdGhlIHByb3h5LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5hbmQgdGhlIHJlbGF5IGlzIG9uIGFuIOKAnHVwc3RyZWFtIGxpbmsgc2VnbWVudOKA nSBvZiB0aGUgcHJveHkuIFdoZW4gdGhlIExEUkEgcnVubmluZyBpbjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj50aGUgc2FtZSBwaHlzaWNhbCBib3ggYXMgdGhlIHJlbGF5IGdldHMg dGhlIERIQ1B2NiBTb2xpY2l0IG1lc3NhZ2UsIHRoZSBsaW5rLWxheWVyIHNvdXJjZTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5hZGRyZXNzIGl0IHdpbGwgc2VlIGlzIOKAmFDigJkg KGkuZS4sIHRoZSB1cHN0cmVhbSBsaW5rIHNlZ21lbnQgYWRkcmVzcyBvZiB0aGUgcHJveHkpLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPklmIGl04oCZcyBhbiBMRFJBLCBhbmQgdGhh dOKAmXMgdGhlIGJlaGF2aW9yLCBpdOKAmXMgbm90IGZvbGxvd2luZyB0aGUgUkZDLiBJIGNhbuKA mXQgc3BlYWsgdG8gb3RoZXIgdHlwZXMgb2YgcHJveGllcywgb2YgY291cnNlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_d94b3649149c433ca6853f7c977aea65boeingcom_-- From nobody Wed Oct 14 05:15:58 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 04B1E3A098A; Wed, 14 Oct 2020 05:15:48 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -1.624 X-Spam-Level: X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.274, 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 H1lINj8Te86O; Wed, 14 Oct 2020 05:15:46 -0700 (PDT) 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 7CA3F3A0989; Wed, 14 Oct 2020 05:15:44 -0700 (PDT) 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 m1kSfgy-0000ImC; Wed, 14 Oct 2020 14:15:40 +0200 Message-Id: To: v6ops@ietf.org Cc: ianfarrer@gmx.com Cc: 6man , dhcwg From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> <9C612486-C25D-463F-8FB4-5BAAF9A96AE5@gmx.com> In-reply-to: Your message of "Tue, 13 Oct 2020 18:08:19 +0200 ." <9C612486-C25D-463F-8FB4-5BAAF9A96AE5@gmx.com> Date: Wed, 14 Oct 2020 14:15:40 +0200 Archived-At: Subject: Re: [v6ops] [dhcwg] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Wed, 14 Oct 2020 12:15:48 -0000 > [if - Theres a couple of problems that this requirement is trying > to address: > > 1, A misbehaving client (accidentally or otherwise) 2, The volume > of traffic being forwarded by the relay consumes the available > bandwidth meaning that DHCP configuration cant complete > > In both cases, the client cant be relied on to solve the problem] I wonder if the problem can be stated in a more general way. It seems to me that router should only forward a packet back to the link it came from when it got the packet directly from a host. I.e., a host may send a packet to a default router when the best next hop happens to be different router on the same link. A host may also send a packet to a default router when the host doesn't know that the destination is on-link (on NBMA links for example). In contrast, routers can be relied on to send packet to the correct next hop. If they don't, then there is something inconsistent in the routing information. Routers don't react to redirect ICMPs, so this inconsistency could waste a lot of bandwidth. One option is to only forward a packet back to the same link if we can also send a redirect ICMP (ignoring rate limiting). I.e., Section 8.2 of RFC 4861 (Neighbor Discovery) describes that a redirect ICMP can be send if "the Source Address field of the packet identifies a neighbor" This could be implemented both in the downstream router and in the upstream router. I can see two cases where this could go wrong: 1) multi-homed hosts doing something weird. In that case the host should be fixed. 2) Multiple downstream routers on a single link where the downstream routers also do not speak a routing protocol. I doubt that we need to support this configuration. From nobody Wed Oct 14 05:28:08 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 CED113A0990; Wed, 14 Oct 2020 05:28:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: v6ops@ietf.org Message-ID: <160267848680.30465.9254381369345717221@ietfa.amsl.com> Date: Wed, 14 Oct 2020 05:28:06 -0700 Archived-At: Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-01.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: Wed, 14 Oct 2020 12:28:07 -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-01.txt Pages : 20 Date : 2020-10-14 Abstract: This document summarizes the operational implications of IPv6 extension headers, and attempts to analyze reasons why packets with IPv6 extension headers may be 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-01 https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-ehs-packet-drops-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 14 05:40: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 3E18D3A09CD for ; Wed, 14 Oct 2020 05:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrQb2De_aNYo for ; Wed, 14 Oct 2020 05:40:37 -0700 (PDT) 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 B9EFA3A09D3 for ; Wed, 14 Oct 2020 05:40:36 -0700 (PDT) Received: from [IPv6:2800:810:464:b9c:4d77:be33:d267:ab18] (unknown [IPv6:2800:810:464:b9c:4d77:be33:d267:ab18]) (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 BEF1B280BB8; Wed, 14 Oct 2020 12:40:33 +0000 (UTC) To: v6ops@ietf.org References: <160267848680.30465.9254381369345717221@ietfa.amsl.com> From: Fernando Gont Message-ID: <6f1419fa-19ef-173a-5095-35fa51cc4ed2@gont.com.ar> Date: Wed, 14 Oct 2020 09:37:38 -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: <160267848680.30465.9254381369345717221@ietfa.amsl.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-ietf-v6ops-ipv6-ehs-packet-drops-01.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: Wed, 14 Oct 2020 12:40:39 -0000 Folks, This rev is meant to address Tom Petch's and Eduard Vasilenko's feedback. The rev is available at: https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-01 And the diff from the previous rev is available at: https://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-ehs-packet-drops-01.txt P.S.: As a co-author, I believe this rev should be ready for WGLC. Thanks! Regards, Fernando On 14/10/20 09:28, internet-drafts@ietf.org wrote: > > 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-01.txt > Pages : 20 > Date : 2020-10-14 > > Abstract: > This document summarizes the operational implications of IPv6 > extension headers, and attempts to analyze reasons why packets with > IPv6 extension headers may be 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-01 > https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-ehs-packet-drops-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From nobody Wed Oct 14 08:56: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 A550F3A0F5A; Wed, 14 Oct 2020 08:56:20 -0700 (PDT) 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, 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=boeing.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 SuuRmy00VrNc; Wed, 14 Oct 2020 08:56:17 -0700 (PDT) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 A58213A0F59; Wed, 14 Oct 2020 08:56:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09EFu7bN002665; Wed, 14 Oct 2020 11:56:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602690973; bh=GnAJlqNsdzxknk1HngPlSVpiqT9zU6I+BpWv8YDHuE4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=WIz8FM3GgVzkQKgqkC6IOHeRFEL3bfV+qccg9vBAqpkykSb6yQOLmV91QHbudQrB2 7HA7QBJuvQriY7+z12QHvRmJsnsPE2q5UdZroVo8TnQekg/gl7BY2hxJCXY1K+LM68 +VSrdxvGRmWhbN1QgU5D3J5rTUJC+VZxTs0ZGaeqJuo4U4BhyrM5+7lEDRjXqlEnsw h+J/4r9AH1mEC0rZYR3MIrT0lzCBe6H9sLR0WjdrfLBh4DeXBnLa5dMIXPPNy00yDI wc1iDs9/eSAJWLf+RPWhR8yygUfdg0Uz6VeK0cvt0pyjDvFXMo59bOdW4pkt+sztXv d1u6bsmSWnGJw== Received: from XCH16-07-07.nos.boeing.com (xch16-07-07.nos.boeing.com [144.115.66.109]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09EFttIj001515 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 14 Oct 2020 11:55:56 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-07.nos.boeing.com (144.115.66.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Wed, 14 Oct 2020 08:55:53 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Wed, 14 Oct 2020 08:55:53 -0700 From: "Templin (US), Fred L" To: Philip Homburg , "v6ops@ietf.org" CC: dhcwg , 6man Thread-Topic: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AdahZz7s2M1crQrvQoqZsITGBawESAAvI0+1AAebvhA= Date: Wed, 14 Oct 2020 15:55:53 +0000 Message-ID: References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> <9C612486-C25D-463F-8FB4-5BAAF9A96AE5@gmx.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 7561C0857B9B0387BEAC9BCFC02001E4A66621CADBEC1C184BBF08CA290922012000:8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [EXTERNAL] Re: [dhcwg] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Wed, 14 Oct 2020 15:56:21 -0000 Philip, > 2) Multiple downstream routers on a single link where the downstream rout= ers > also do not speak a routing protocol. I doubt that we need to support > this configuration. That depends on how you define "routing protocol". DHCPv6 PD driven by IPv6 ND router discovery would in spirit constitute a routing protocol. Thanks - Fred > -----Original Message----- > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Philip Homburg > Sent: Wednesday, October 14, 2020 5:16 AM > To: v6ops@ietf.org > Cc: dhcwg ; 6man > Subject: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Impl= ementors regarding draft-ietf-dhc-dhcpv6-pd-relay- > requirements >=20 > This message was sent from outside of Boeing. Please do not click links o= r open attachments unless you recognize the sender and > know that the content is safe. >=20 >=20 > > [if - Theres a couple of problems that this requirement is trying > > to address: > > > > 1, A misbehaving client (accidentally or otherwise) 2, The volume > > of traffic being forwarded by the relay consumes the available > > bandwidth meaning that DHCP configuration cant complete > > > > In both cases, the client cant be relied on to solve the problem] >=20 > I wonder if the problem can be stated in a more general way. >=20 > It seems to me that router should only forward a packet back to the link = it > came from when it got the packet directly from a host. >=20 > I.e., a host may send a packet to a default router when the best next hop > happens to be different router on the same link. A host may also send a > packet to a default router when the host doesn't know that the destinatio= n > is on-link (on NBMA links for example). >=20 > In contrast, routers can be relied on to send packet to the correct next = hop. > If they don't, then there is something inconsistent in the routing inform= ation. > Routers don't react to redirect ICMPs, so this inconsistency could waste = a > lot of bandwidth. >=20 > One option is to only forward a packet back to the same link if we can al= so > send a redirect ICMP (ignoring rate limiting). I.e., Section 8.2 of RFC 4= 861 > (Neighbor Discovery) describes that a redirect ICMP can be send if > "the Source Address field of the packet identifies a neighbor" >=20 > This could be implemented both in the downstream router and in the upstre= am > router. >=20 > I can see two cases where this could go wrong: > 1) multi-homed hosts doing something weird. In that case the host should = be > fixed. > 2) Multiple downstream routers on a single link where the downstream rout= ers > also do not speak a routing protocol. I doubt that we need to support > this configuration. >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From nobody Wed Oct 14 09:19: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 893E23A0ECB for ; Wed, 14 Oct 2020 09:19:51 -0700 (PDT) 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, RCVD_IN_DNSWL_BLOCKED=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=es.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 aqHZYDn5oRux for ; Wed, 14 Oct 2020 09:19:49 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 AAB843A09D9 for ; Wed, 14 Oct 2020 09:19:49 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id l8so5860191ioh.11 for ; Wed, 14 Oct 2020 09:19:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=es.net; s=esnet-google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=Mf028mEKI77IPbRspblbg/RwCEeUbpixG4lcpVhOmBQ=; b=NQq1QZ/JzyjLmBRNw4Q/hBn5GyVt9Mv55FmxP7sINZk5qUG7WhfPOstIWt0W8cnOr/ jX65ehCny6gqE7sBlaFfCLN/Vxwqz73ED+iwfVmvEdhoLIgn5qjRRMlePCRI0pbaiTgw Y0KIIuGdpmOBaeY2xxbiF631X8tHu26qyk4xDLAinNFyl4AC1BHYnyUsd4ycR7xGo93l KdZnoIUfzxgMG9tN3eXrnV2R+XLJsDmdo7Vp5UTtyYqN/4wfV7TAoueH8kYEkWXUHt0p bNT9jQch6IhZYzIWhg1MYM3org+buOUz3HfsSy3hSxgUomKpn6P9hNldzcNiQwsbyPN5 TBRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=Mf028mEKI77IPbRspblbg/RwCEeUbpixG4lcpVhOmBQ=; b=rwE38SbEf1cIMSmENCjwcobwzFeOV/pYToxNj1Jm48cF0dqO/01PIsTE7Yuo54mQ12 T7NfyUQGK+QgjMRdy3CHOiLY1iZp3FwWoa3eddCtnkyIJx0MI3+5wHHrIiZlBC7UNnYB IooGyNZnAbrucoMieshiZKjbUS7LYagDvuLNrzvtVSUvHepGFIt+uJUpSLW177PQuiys DEmn8i3UaSapFoKAkM/XhKhcfU+ATFjAFYiZ83mDYFMcdp1JZrvCQrthaYU3mdZbdVB6 z4r7F5N9O8Ph4oZcGMAVLMgE6Ac1ZdZlQtPy0Rs56vcf4DpjHW57E7N3JUV6l0eeIliE Z61A== X-Gm-Message-State: AOAM5334yjq9n917gVPZVpJzG3W/WyCULCL9JgmheLx0j+qLD4TR46XO 90QHeD+ZloWVBXQaLvoZTjn27psWF9EZav2iQ5KRKP5oevhD5OXVYK2Tfq7mCt88nRea7ToqKtN PuQD5LCACXuPuXnKXYssZ9AQ2TUWowwA65eP5/BwuVWiMLc33ZWCQe+XgrA2ZOPqu+BOlTkY= X-Google-Smtp-Source: ABdhPJyJv315VfxQ27izzEZWYAq5uGX3C7lYv03pDp+HG6d4buTKXdhI0VwgKbE63POJ1IVqRbR71Q== X-Received: by 2002:a05:6638:974:: with SMTP id o20mr197275jaj.37.1602692388217; Wed, 14 Oct 2020 09:19:48 -0700 (PDT) Received: from localhost ([2600:6c44:7580:4a01:b0e1:67ab:1edb:3b49]) by smtp.gmail.com with ESMTPSA id c63sm3866542ill.24.2020.10.14.09.19.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Oct 2020 09:19:47 -0700 (PDT) Date: Wed, 14 Oct 2020 11:19:46 -0500 From: "Dale W. Carder" To: Fernando Gont Cc: v6ops@ietf.org Message-ID: <20201014161946.GA65211@dwc-desktop.local> References: <160267848680.30465.9254381369345717221@ietfa.amsl.com> <6f1419fa-19ef-173a-5095-35fa51cc4ed2@gont.com.ar> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6f1419fa-19ef-173a-5095-35fa51cc4ed2@gont.com.ar> Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-01.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: Wed, 14 Oct 2020 16:19:52 -0000 Thus spake Fernando Gont (fernando@gont.com.ar) on Wed, Oct 14, 2020 at 09:37:38AM -0300: > The rev is available at: > https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-01 In section 7.4, is it worth referencing covert channel risk from rfc6437's section 6.1? In section 7.1, I thought there was a class of devices (routers) where if configured with a packet filter / acl that when unable to find the upper protocol information buried past the size of the lookup engine would actually forward traffic even if the policy was to deny. I could have sworn I saw this topic fly by on the v6ops list, but I can't find it (thus I don't want to mistakenly name and shame). I am not sure if I agree with the last paragraph of 6.1 which opines on the low adoption of rfc6437-style flow label hash entropy. I would expect that the current low adoption in ecmp implementations is a chicken/egg problem. If you have a product that needs to hash and you are not confident there is enough adoption in host stacks, you are still forced to hunt for entropy from the upper-protocol protocols. Otherwise all the legacy host traffic with the flow label set to 0 risks getting hashed entirely to one side or face reordering. Dale From nobody Wed Oct 14 09:51:00 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 D0D853A0832; Wed, 14 Oct 2020 09:50:58 -0700 (PDT) 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.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160269425883.24978.13599252409189625996@ietfa.amsl.com> Date: Wed, 14 Oct 2020 09:50:58 -0700 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, 14 Oct 2020 16:50:59 -0000 IESG state changed: New State: IESG Evaluation (The previous state was Waiting for AD Go-Ahead) Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-v6ops-slaac-renum/ From nobody Wed Oct 14 10:02:20 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 C13983A08C4; Wed, 14 Oct 2020 10:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, 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 ihh4lGH354Db; Wed, 14 Oct 2020 10:02:16 -0700 (PDT) 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 61D3F3A08CA; Wed, 14 Oct 2020 10:02:16 -0700 (PDT) Received: from [IPv6:2800:810:464:b9c:4d77:be33:d267:ab18] (unknown [IPv6:2800:810:464:b9c:4d77:be33:d267:ab18]) (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 981092800FF; Wed, 14 Oct 2020 17:02:12 +0000 (UTC) To: "Dale W. Carder" , Fernando Gont Cc: v6ops@ietf.org, draft-ietf-v6ops-ipv6-ehs-packet-drops.authors@ietf.org References: <160267848680.30465.9254381369345717221@ietfa.amsl.com> <6f1419fa-19ef-173a-5095-35fa51cc4ed2@gont.com.ar> <20201014161946.GA65211@dwc-desktop.local> From: Fernando Gont Message-ID: <9ef70e2f-f2af-de92-2cac-face385c097c@si6networks.com> Date: Wed, 14 Oct 2020 13:39: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: <20201014161946.GA65211@dwc-desktop.local> 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-ietf-v6ops-ipv6-ehs-packet-drops-01.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: Wed, 14 Oct 2020 17:02:20 -0000 Hello, Dale, Thanks a lot for your timely feedback! In-line.... On 14/10/20 13:19, Dale W. Carder wrote: > Thus spake Fernando Gont (fernando@gont.com.ar) on Wed, Oct 14, 2020 at 09:37:38AM -0300: >> The rev is available at: >> https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-01 > > In section 7.4, is it worth referencing covert channel risk from rfc6437's > section 6.1? Section 7.4 is about the security implications of *EHs*... so that would be off-topic, so to speak... > In section 7.1, I thought there was a class of devices (routers) where if > configured with a packet filter / acl that when unable to find the upper > protocol information buried past the size of the lookup engine would actually > forward traffic even if the policy was to deny. I could have sworn I saw > this topic fly by on the v6ops list, but I can't find it (thus I don't want > to mistakenly name and shame). I do recall reports of that. I guess we can simply note it without a reference? (I don't mind the reference myself, but some of my co-authors might differ :-) ) > I am not sure if I agree with the last paragraph of 6.1 which opines on > the low adoption of rfc6437-style flow label hash entropy. We don't argue low-entropy, but issues with the Flow Label implementation. See e.g.: https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-hashing/ > I would > expect that the current low adoption in ecmp implementations is a > chicken/egg problem. If you have a product that needs to hash and you are > not confident there is enough adoption in host stacks, you are still forced > to hunt for entropy from the upper-protocol protocols. Otherwise all the > legacy host traffic with the flow label set to 0 risks getting hashed > entirely to one side or face reordering. We're just stating that there's marginal usage of the Flow Label, which is what the work by Cunha et al seems to indicate. As to the possible consequences, part might be LBs lagging behind host implementations. But issues in the Flow Label implementation might have also discouraged its use. That said, the important info that Section 6.1 is meant to convey is that there still seems to be marginal use of the FL. And also note that issues have been found in FL implementations. -- i.e., we're not trying to infer why there's marginal use of the FL. If you think this warrants some tweaks in the text, please do let us know. 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 Oct 14 11:58: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 58C283A0FC5; Wed, 14 Oct 2020 11:58:35 -0700 (PDT) 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 YxZMN3UGQ1o2; Wed, 14 Oct 2020 11:58:33 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08F153A0C99; Wed, 14 Oct 2020 11:58:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 22842389B5; Wed, 14 Oct 2020 15:03:41 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id by1jG2OK_Bps; Wed, 14 Oct 2020 15:03:34 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 36F73389B1; Wed, 14 Oct 2020 15:03:34 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 058176F5; Wed, 14 Oct 2020 14:57:44 -0400 (EDT) From: Michael Richardson To: "Templin \(US\)\, Fred L" cc: "ianfarrer\@gmx.com" , Jen Linkova , dhcwg , v6ops list , 6man In-Reply-To: <378d3420690246bbae253fb15be8c9a7@boeing.com> References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> <10487.1602608586@localhost> <378d3420690246bbae253fb15be8c9a7@boeing.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [v6ops] [EXTERNAL] Re: [dhcwg] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Wed, 14 Oct 2020 18:58:35 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Templin (US), Fred L wrote: > Michael, what I was referring to below as "failure" is the proxy case= when > there is an L2 proxy P between the client and relay (e.g., > RFC489). There RFC4389 describes an ND Proxy. Is that really an L2 proxy? It seems like it also must be contain either an L2-bridge, or must have the L3-routing table entries if it would really be capable of passing DHCPv6-PD prefixes through it. Can you explain how such a device would normally work for a client device A,B,C,D doing DHCPv6-PD through it? And is the failure one where the router "R" fails to drop traffic it should, one where the router "R" drops traffic that it shouldn't? =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+HSicACgkQgItw+93Q 3WXTFwf/Vbqdxr2RB3J0w4WYNhlUMLty5VWzHy4VYuO++JpMkDFVaz7JeBfLWC8c jJpW0bwKkXzqN3CvYbSU+AEFxK20esxRsPvUWwe6qfK0z+sH9pbq5a18BKAEbXHX cXCHIA1AH2k/nm5prVcg9MqNpzs/NIUZM6XkJRTWU4s8vpyza6nlQ4Zm642gfcu9 UAwBpjszNQ6mMDq8CcgMtD13dS4N8aGtvKdB67BCYs5xmcitPpNQARiz4hUyFtda VETPSwNZdwXAwSVD79AZosV0hXRrjMO7bHYGcx6CgrzBhb6ky5HZ0jkdWrg6rqMp WZH00TFMgSiva+06Uh/N0B2Hnvxkjw== =Hhd1 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 14 12:19: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 7FC4D3A0FD8; Wed, 14 Oct 2020 12:19:32 -0700 (PDT) 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, 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=boeing.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 cvfr-lMcCP5A; Wed, 14 Oct 2020 12:19:30 -0700 (PDT) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 0596B3A03F5; Wed, 14 Oct 2020 12:19:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09EJJOmS021448; Wed, 14 Oct 2020 15:19:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602703167; bh=7QlWFBD8EEur4egDttqJIp5L3Yg+o+ZxFtwkq2+1/qw=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=et8vjBzoXDyoq8h7oaCglegD4PbiIWR5KHnvQwYbk2GAR/BVPP6RjeWuFrTqndwAc wSwiTs7jWum5uTY6NWiWiiYoY+n4arGGEi4ymLCf0s2Re61SQ2RnsVDGlZYXlkLN22 IKA/w2P0ctxnSi78B2d9pn0YBhn0lKU66XmIn2Ibw000SXduLnkYIu5sdUxSQkUZfF kUmVfas0Ich0dVWF1fToLHTHV5KFn36ogtk4T2huBl/eQXrFwZBTYCxhLsoiykRyiB E0dx3TMjDN4HGWqeoWvaPl91PwlVL+kSW+w7TpXd7btSxSvS/WkZbof3mM0ZW1oKAB l2SVQXdhnPBvg== Received: from XCH16-07-12.nos.boeing.com (xch16-07-12.nos.boeing.com [144.115.66.114]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09EJJDx2020102 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 14 Oct 2020 15:19:13 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-12.nos.boeing.com (144.115.66.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Wed, 14 Oct 2020 12:19:11 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Wed, 14 Oct 2020 12:19:11 -0700 From: "Templin (US), Fred L" To: Michael Richardson CC: "ianfarrer@gmx.com" , Jen Linkova , dhcwg , v6ops list , 6man Thread-Topic: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AdahZz7s2M1crQrvQoqZsITGBawESAAViWEAAA15P3AAKNIcgAAOSRqA Date: Wed, 14 Oct 2020 19:19:11 +0000 Message-ID: <1b34b9bec59e4a00af8b9d8f182d23ff@boeing.com> References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> <10487.1602608586@localhost> <378d3420690246bbae253fb15be8c9a7@boeing.com> <19627.1602701863@localhost> In-Reply-To: <19627.1602701863@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: D0A878958E8A85BD8D7668B1EBEFBD21C7D5354378FADE6292CB63E6474E2E922000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [EXTERNAL] Re: [dhcwg] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Wed, 14 Oct 2020 19:19:33 -0000 SGkgTWljaGFlbCwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBNaWNo YWVsIFJpY2hhcmRzb24gW21haWx0bzptY3IraWV0ZkBzYW5kZWxtYW4uY2FdDQo+IFNlbnQ6IFdl ZG5lc2RheSwgT2N0b2JlciAxNCwgMjAyMCAxMTo1OCBBTQ0KPiBUbzogVGVtcGxpbiAoVVMpLCBG cmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+DQo+IENjOiBpYW5mYXJyZXJAZ214LmNv bTsgSmVuIExpbmtvdmEgPGZ1cnJ5MTNAZ21haWwuY29tPjsgZGhjd2cgPGRoY3dnQGlldGYub3Jn PjsgdjZvcHMgbGlzdCA8djZvcHNAaWV0Zi5vcmc+OyA2bWFuDQo+IDxpcHY2QGlldGYub3JnPg0K PiBTdWJqZWN0OiBSZTogW0VYVEVSTkFMXSBSZTogW2RoY3dnXSBbdjZvcHNdIFJlOiBRdWVzdGlv biB0byBESENQdjYgUmVsYXkgSW1wbGVtZW50b3JzIHJlZ2FyZGluZyBkcmFmdC1pZXRmLWRoYy1k aGNwdjYtcGQtcmVsYXktDQo+IHJlcXVpcmVtZW50cw0KPiANCj4gDQo+IFRlbXBsaW4gKFVTKSwg RnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPiB3cm90ZToNCj4gICAgID4gTWljaGFl bCwgd2hhdCBJIHdhcyByZWZlcnJpbmcgdG8gYmVsb3cgYXMgImZhaWx1cmUiIGlzIHRoZSBwcm94 eSBjYXNlIHdoZW4NCj4gICAgID4gdGhlcmUgaXMgYW4gTDIgcHJveHkgUCBiZXR3ZWVuIHRoZSBj bGllbnQgYW5kIHJlbGF5IChlLmcuLA0KPiAgICAgPiBSRkM0ODkpLiBUaGVyZQ0KPiANCj4gUkZD NDM4OSBkZXNjcmliZXMgYW4gTkQgUHJveHkuDQo+IElzIHRoYXQgcmVhbGx5IGFuIEwyIHByb3h5 Pw0KDQpZZXMsIEkgYmVsaWV2ZSBpdCBpcyBhbiBMMiBwcm94eS4NCg0KPiBJdCBzZWVtcyBsaWtl IGl0IGFsc28gbXVzdCBiZSBjb250YWluIGVpdGhlciBhbiBMMi1icmlkZ2UsIG9yIG11c3QgaGF2 ZSB0aGUNCj4gTDMtcm91dGluZyB0YWJsZSBlbnRyaWVzIGlmIGl0IHdvdWxkIHJlYWxseSBiZSBj YXBhYmxlIG9mIHBhc3NpbmcgREhDUHY2LVBEDQo+IHByZWZpeGVzIHRocm91Z2ggaXQuDQoNClRo ZSBvbmx5IHRoaW5nIGl0IGhhcyB0aGF0IGluY2x1ZGVzIEwzIGluZm9ybWF0aW9uIGlzIG5laWdo Ym9yIGNhY2hlIGVudHJpZXMgdGhhdA0Ka2VlcCB0cmFjayBvZiB0aGUgY2xpZW50J3MgYWN0dWFs IEwyIGFkZHJlc3Mgb24gdGhlIGRvd25zdHJlYW0gbGluayBzZWdtZW50LA0KYnV0IHJld3JpdGVz IHRoZSBjbGllbnQncyBMMiBhZGRyZXNzIHRvIGl0cyBvd24gTDIgYWRkcmVzcyB3aGVuIGZvcndh cmRpbmcNCm9udG8gYW4gdXBzdHJlYW0gbGluayBzZWdtZW50LiAoSW4gdGhlIHJldmVyc2UgZGly ZWN0aW9uLCBpdCByZWNlaXZlcyBwYWNrZXRzDQpkZXN0aW5lZCB0byBpdHMgb3duIEwyIGFkZHJl c3MgYnV0IHRoZSBjbGllbnQncyBMMyBhZGRyZXNzIG9uIHRoZSB1cHN0cmVhbQ0KbGluayBzZWdt ZW50LCB0aGVuIHJld3JpdGVzIHRoZSBMMiBhZGRyZXNzIHRvIHRoZSBjbGllbnQncyBMMiBhZGRy ZXNzIHdoZW4NCmZvcndhcmRpbmcgb250byB0aGUgZG93bnN0cmVhbSBsaW5rIHNlZ21lbnQuKQ0K DQo+IENhbiB5b3UgZXhwbGFpbiBob3cgc3VjaCBhIGRldmljZSB3b3VsZCBub3JtYWxseSB3b3Jr IGZvciBhIGNsaWVudCBkZXZpY2UNCj4gQSxCLEMsRCBkb2luZyBESENQdjYtUEQgdGhyb3VnaCBp dD8NCg0KU3VyZS4gQSBzZW5kcyBhIERIQ1B2NiBTb2xpY2l0IHVzaW5nIGl0cyBJUHY2IGxpbmst bG9jYWwgYWRkcmVzcyBhcyB0aGUgc291cmNlLA0KYW5kIGl0cyBMMiBhZGRyZXNzIGFzIHRoZSBs aW5rLWxheWVyIHNvdXJjZS4gVGhlIHByb3h5IGNvbnZlcnRzIHRoZSBsaW5rLWxheWVyDQpzb3Vy Y2UgdG8gaXRzIG93biBMMiBhZGRyZXNzIHdoZW4gZm9yd2FyZGluZyB0aGUgREhDUHY2IHNvbGlj aXQgb250byB0aGUNCnVwc3RyZWFtIGxpbmsuIFdoZW4gdGhlIERIQ1B2NiBSZXBseSBjb21lcyBi YWNrLCB0aGUgSVB2NiBkZXN0aW5hdGlvbiBpcw0KdGhhdCBvZiBjbGllbnQgQSwgYnV0IHRoZSBs aW5rLWxheWVyIGRlc3RpbmF0aW9uIGlzIHRoZSBMMiBhZGRyZXNzIG9mIHRoZSBwcm94eS4NClRo ZSBwcm94eSB0aGVuIGNvbnZlcnRzIHRoZSBMMiBkZXN0aW5hdGlvbiB0byB0aGUgYWRkcmVzcyBv ZiBjbGllbnQgQSBhbmQNCmZvcndhcmRzIGl0IG9uIHRvIHRoZSBjbGllbnQuDQoNCj4gQW5kIGlz IHRoZSBmYWlsdXJlIG9uZSB3aGVyZSB0aGUgcm91dGVyICJSIiBmYWlscyB0byBkcm9wIHRyYWZm aWMgaXQgc2hvdWxkLA0KPiBvbmUgd2hlcmUgdGhlIHJvdXRlciAiUiIgZHJvcHMgdHJhZmZpYyB0 aGF0IGl0IHNob3VsZG4ndD8NCg0KSSB3YXMgdGhpbmtpbmcgbW9yZSBhbG9uZyB0aGUgbGluZXMg b2YgdGhlIGxhdHRlcjsgaWYgdGhlIG9ubHkgd2F5IHRoYXQgQSBoYXMNCmZvciB0YWxraW5nIHRv IEIsIEMsIEQsIGV0Yy4gaXMgYnkgZ29pbmcgdGhyb3VnaCBSLCBpdCB3b3VsZG4ndCB3b3JrIGlm IFIgd2FzDQp1bmNvbmRpdGlvbmFsbHkgZHJvcHBpbmcgZXZlcnl0aGluZy4NCg0KVGhhbmtzIC0g RnJlZA0KIA0KPiAtLQ0KPiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5j YT4gICAuIG8gTyAoIElQdjYgScO4VCBjb25zdWx0aW5nICkNCj4gICAgICAgICAgICBTYW5kZWxt YW4gU29mdHdhcmUgV29ya3MgSW5jLCBPdHRhd2EgYW5kIFdvcmxkd2lkZQ0KPiANCj4gDQo+IA0K DQo= From nobody Wed Oct 14 13:06: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 BE4EF3A101C; Wed, 14 Oct 2020 13:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 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.213, 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 53t0K5mdgT4W; Wed, 14 Oct 2020 13:06:15 -0700 (PDT) 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 4EF043A101B; Wed, 14 Oct 2020 13:06:15 -0700 (PDT) Received: by mail-pj1-x1036.google.com with SMTP id az3so350715pjb.4; Wed, 14 Oct 2020 13:06:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=bJyGi6DYe0BbVDIkYzgi/mHSRWYTGBolUwQ/SGXkRRU=; b=Pb6XKqA2r9nhDoh9otfi8WH3jGmjPLgFUZkjDjTm9t3GqSE1R6WrgMC0IWQhw1axzb haHutQWHIdc0hUV1/2iuzT65QP59Qg0QBNyNTHGk5+hEK2By5jOd+UhtrmisghmYI1pM f8i8pH30ADkdg0U2WIWRkbmW/eWJ5ifroOURWcxLPIjpg6/PEzlaruE2hWpkXUTjC2At fxejj1dSkS9G893IxwiLzmK9WEPlgLVuPPG0aS9Hu5yLftOQCRJUUqk7Fcl+WEjDqvTJ ptIf6s/BfosX8hcQ5wDU89XBHQNzI5o27YC7f1o9CUcmC9GGzCDcPs373D8l/uHJ6UrO 90YA== 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=bJyGi6DYe0BbVDIkYzgi/mHSRWYTGBolUwQ/SGXkRRU=; b=F6ri3xGON06GGJAWZz0KP9C/jvPgIc1XiOlzaEQOQS4XkQf+x1kUy8wj53tKfZCZC/ K+/t1OBqTrVaBTntDABlLgl6YHBNySuyUjYtheC2t8ewXz/nK4TUiH8BnxGQFotbqHPv F0IhNUphnmYR7AP1BZOVslEnjovh9mekLZEKN9/Axvwx5RT3uMX8onUzmxqUTPlW9Wcr wDdX46531sIrRpGt9Mpp1RBgJhHBXZMnY+mpWQjirW9GMbglvzJQob9TueCWckLmFc/Q NRH0O7IGKPWmfKe/Vi6mNWKMXNTjVJ4+/rJYvFPurthrQLCwO8I3H4EumZ1iIxJE6JDS etTQ== X-Gm-Message-State: AOAM530NhYHwSHTI/dvgD5l123C6V/PNbXDgvJa/zXDRlQ0iOgrTj0Jl ClH/H39FxqqJAw0z/b0wia4QYdHX6mSXbQ== X-Google-Smtp-Source: ABdhPJx5w9m76iSZJQKqKwKBlQzR4h10zWG+Uet6+Dn7VQYnm2xU+ZTpdNbU44c8D1mZgoQDNFnSQg== X-Received: by 2002:a17:902:465:b029:d0:89f1:9e2a with SMTP id 92-20020a1709020465b02900d089f19e2amr636167ple.6.1602705974246; Wed, 14 Oct 2020 13:06:14 -0700 (PDT) Received: from [192.168.178.20] ([151.210.132.159]) by smtp.gmail.com with ESMTPSA id n203sm507085pfd.81.2020.10.14.13.06.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Oct 2020 13:06:13 -0700 (PDT) To: Fernando Gont , "Dale W. Carder" , Fernando Gont Cc: v6ops@ietf.org, draft-ietf-v6ops-ipv6-ehs-packet-drops.authors@ietf.org References: <160267848680.30465.9254381369345717221@ietfa.amsl.com> <6f1419fa-19ef-173a-5095-35fa51cc4ed2@gont.com.ar> <20201014161946.GA65211@dwc-desktop.local> <9ef70e2f-f2af-de92-2cac-face385c097c@si6networks.com> From: Brian E Carpenter Message-ID: <0ffdf43e-957b-f01e-c121-4fa47f67a964@gmail.com> Date: Thu, 15 Oct 2020 09:06:10 +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: <9ef70e2f-f2af-de92-2cac-face385c097c@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-ietf-v6ops-ipv6-ehs-packet-drops-01.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: Wed, 14 Oct 2020 20:06:17 -0000 On 15-Oct-20 05:39, Fernando Gont wrote: ... >> I am not sure if I agree with the last paragraph of 6.1 which opines on >> the low adoption of rfc6437-style flow label hash entropy. > > We don't argue low-entropy, but issues with the Flow Label > implementation. See e.g.: > https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-hashing/ > > > >> I would >> expect that the current low adoption in ecmp implementations is a >> chicken/egg problem. If you have a product that needs to hash and you are >> not confident there is enough adoption in host stacks, you are still forced >> to hunt for entropy from the upper-protocol protocols. Otherwise all the >> legacy host traffic with the flow label set to 0 risks getting hashed >> entirely to one side or face reordering. > > We're just stating that there's marginal usage of the Flow Label, which > is what the work by Cunha et al seems to indicate. As to the possible > consequences, part might be LBs lagging behind host implementations. But > issues in the Flow Label implementation might have also discouraged its use. > > That said, the important info that Section 6.1 is meant to convey is > that there still seems to be marginal use of the FL. And also note that > issues have been found in FL implementations. -- i.e., we're not trying > to infer why there's marginal use of the FL. > > If you think this warrants some tweaks in the text, please do let us know. I just re-read that section and sadly I think it is still correct. Brian (co-author of several flow label RFCs) From nobody Wed Oct 14 14:09: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 B144B3A108B for ; Wed, 14 Oct 2020 14:09:21 -0700 (PDT) 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_DOTEDU=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=es.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 GZ9fw1DyHmYy for ; Wed, 14 Oct 2020 14:09:19 -0700 (PDT) Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) (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 3BCE53A108C for ; Wed, 14 Oct 2020 14:09:18 -0700 (PDT) Received: by mail-io1-xd44.google.com with SMTP id g7so1065288iov.13 for ; Wed, 14 Oct 2020 14:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=es.net; s=esnet-google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=jcyJTVQlOgG7HnueX9MpAH6/GMLsDU4nXnZ1JOODsIU=; b=UJAvW+gbVQM7IdjlQL/mIFVEsB/EAKe8VwFKJ2005xcYmdjYYk6nNgpA6izGO9BGfn ARqbYpgO7aqodbsX7HlAd1ZzCwW4FLFza8fDQMiJLB4wJa/1a4JKfl8RVoEdKftIhSlB 2uky9V0QJbXjoruQ0lDUB5xHaYWF7Nps24qRcIPcsoZAfnkJR43bVLORQwjfhQARoQHg 5cXTatf/TsosT1unohbLJnv+F27IZRMD9v1vSNAwk0GT3TCCRSgGUattpQKAysILiNY8 gHx15iOs9gS/yQBCRrnPYf54/UDOEBi+H1g/CBesrOvxg1nAKjat6niOJ9UPFBrgw9wY ZqHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=jcyJTVQlOgG7HnueX9MpAH6/GMLsDU4nXnZ1JOODsIU=; b=ax56i8U2C1SRcku5YjzhBPuEuGFnwgt6Ji/SuQMpuAeENSD10ZcyxclPlboHIipOdX 5Kuvpq9sILSr9c8I2MJy8bg1x4jMTSdhCaR4bkCCwBAcO1hohjxRgYwyznKUOg5Ef7LW sT3uk3M2VNSjA1/wBa3yz0vTHU8/ku4WyXG2awTxJFk5Ub9hwADiCuJiMELUQvTx+8Pt DwPuySrZDf6VN7FnL4OeIkzxB5mfvGgYcIt2uORvbT3KJck8xRZ/7yI14gINjMQlpxGj tXmE92Jiq8/JwvifKc7rtR1FY8WK/+3+Soe1vRzOjzM9BJzTb6uQVcOcVxajneiOXCPk EDwg== X-Gm-Message-State: AOAM531/xuRF+pb6yIDIKngtqfuKC1WwBok82swH+EWX8ZlYC5Yh5KgD Zd0Gc7dxuxxvjWBpvtgWM9XJOEMbAGLcWxCytY8OxNpA5W9bISsBqXIaEWg8QY+LJhk2qeGo3eO RdPuzL+9DgTfKVsWI9ei1x9EzGBLqGr20ggPKyieEn5+IxS0Ytz9FNm977HciBHh1VMAK X-Google-Smtp-Source: ABdhPJx+GZoIqsKo46etuloEo0Lbng8hOWj+Dkf7GQXSkFab+uRKW6H2orPVTrHNGqb2YlOuVduEgw== X-Received: by 2002:a6b:c94f:: with SMTP id z76mr990565iof.88.1602709757732; Wed, 14 Oct 2020 14:09:17 -0700 (PDT) Received: from localhost ([2600:6c44:7580:4a01:b0e1:67ab:1edb:3b49]) by smtp.gmail.com with ESMTPSA id f85sm583308ill.39.2020.10.14.14.09.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Oct 2020 14:09:17 -0700 (PDT) Date: Wed, 14 Oct 2020 16:09:15 -0500 From: "Dale W. Carder" To: Fernando Gont Cc: Fernando Gont , v6ops@ietf.org, draft-ietf-v6ops-ipv6-ehs-packet-drops.authors@ietf.org Message-ID: <20201014210915.GC65211@dwc-desktop.local> References: <160267848680.30465.9254381369345717221@ietfa.amsl.com> <6f1419fa-19ef-173a-5095-35fa51cc4ed2@gont.com.ar> <20201014161946.GA65211@dwc-desktop.local> <9ef70e2f-f2af-de92-2cac-face385c097c@si6networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ef70e2f-f2af-de92-2cac-face385c097c@si6networks.com> Archived-At: Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-ehs-packet-drops-01.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: Wed, 14 Oct 2020 21:09:22 -0000 Thus spake Fernando Gont (fgont@si6networks.com) on Wed, Oct 14, 2020 at 01:39:21PM -0300: > > Thanks a lot for your timely feedback! In-line.... well, you did threaten wglc ;-) > On 14/10/20 13:19, Dale W. Carder wrote: > > Thus spake Fernando Gont (fernando@gont.com.ar) on Wed, Oct 14, 2020 at 09:37:38AM -0300: > > > The rev is available at: > > > https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-01 > > > > In section 7.4, is it worth referencing covert channel risk from rfc6437's > > section 6.1? > > Section 7.4 is about the security implications of *EHs*... so that would be > off-topic, so to speak... Oh right, I get mixed up on that at times, sorry. But related, covert side channel risk is probably on the minds of those justifying filtering EH's. This is the first easy reference I found, there are likely others: Hansen, Raymond A.; Gino, Lourdes; and Savio, Dominic, "Covert6: A Tool to Corroborate the Existence of IPv6 Covert Channels" (2016). Annual ADFSL Conference on Digital Forensics, Security and Law. 13. https://commons.erau.edu/adfsl/2016/tuesday/13 > > In section 7.1, I thought there was a class of devices (routers) where if > > configured with a packet filter / acl that when unable to find the upper > > protocol information buried past the size of the lookup engine would actually > > forward traffic even if the policy was to deny. I could have sworn I saw > > this topic fly by on the v6ops list, but I can't find it (thus I don't want > > to mistakenly name and shame). > > I do recall reports of that. I guess we can simply note it without a > reference? (I don't mind the reference myself, but some of my co-authors > might differ :-) ) Maybe it was about fragment processing rather than EH? I hope this triggers someone's memory. > > I am not sure if I agree with the last paragraph of 6.1 which opines on > > the low adoption of rfc6437-style flow label hash entropy. > > We don't argue low-entropy, but issues with the Flow Label implementation. > See e.g.: https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-hashing/ > > > > > I would > > expect that the current low adoption in ecmp implementations is a > > chicken/egg problem. If you have a product that needs to hash and you are > > not confident there is enough adoption in host stacks, you are still forced > > to hunt for entropy from the upper-protocol protocols. Otherwise all the > > legacy host traffic with the flow label set to 0 risks getting hashed > > entirely to one side or face reordering. > > We're just stating that there's marginal usage of the Flow Label, which is > what the work by Cunha et al seems to indicate. As to the possible > consequences, part might be LBs lagging behind host implementations. But > issues in the Flow Label implementation might have also discouraged its use. > > That said, the important info that Section 6.1 is meant to convey is that > there still seems to be marginal use of the FL. And also note that issues > have been found in FL implementations. -- i.e., we're not trying to infer > why there's marginal use of the FL. > > If you think this warrants some tweaks in the text, please do let us know. Ok, I think it's a misinterpretation of intent. How about this slight wordsmith for 6.1, which to me softens the causality claim that I inferred. 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]. A contributing factor could be the issues that have been found in host implementations and middle-boxes [Jaeggli-2018]. Overall, I think this is a very useful doc! Dale From nobody Wed Oct 14 14:47: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 D963D3A10BE; Wed, 14 Oct 2020 14:46:53 -0700 (PDT) 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 BzvFAtas-RzC; Wed, 14 Oct 2020 14:46:52 -0700 (PDT) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (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 B55DC3A08E3; Wed, 14 Oct 2020 14:46:51 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id x7so779454wrl.3; Wed, 14 Oct 2020 14:46:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=5r3fI9lgf5nTX/6lvotxuGoSg02mwOUALuZaMvOGSLw=; b=qce8WLd2MRMJBn0xuBHtnkEo2cohd4+nRYXhny+fYE1JqELdATf1ykwrPCyKFAYtwp Jvkf3TMFs4ZpAuk1U5tTqBwFLRr5tc5Abbw8yQONaD+CYfKqaLYs0ZhbXUikLYZbUrIM GcTRi0G0DSAdTsM3oZevYn5yKEhNBaN5uYiqa78obVofHDimE5an03uV690WuYBm66Mz TXNZkFxIJGLeldWmzuPjq8IKtz8bP2iXMkj/eF0N4JRyKGVJls3ewSogzBlEEw4As3O1 cWsJSCPEKetwYwwjBYbE+WuqyV27FJDWY7g7lTMWsZ43/wmDHa7GUp/SGU7RBejE7Uol b8ZQ== 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=5r3fI9lgf5nTX/6lvotxuGoSg02mwOUALuZaMvOGSLw=; b=bu+mkDSP8Es+WVqRC2Fd1/6fr6ILX7TuOkx8G/OwqwmTxQlQgxWID/0KwSVtUYmkzD +2nwPSxVCPjYuyf95KOa5EDcwteAppmf+QGj64KeMatwQnWQbwGHDYZDrhP/vc/sRwN5 jeSRo4ItTLyWLkn0aWwoYLsi9sFXsBlOUpNtGPuEmdfmIqmNfP8x6hAdFcv1q/j9b3Xt c9ocWfSfHEYlPDNBTH7vY0THXc8TqCnD7/ycbkHAX5rvYbjkXaStFwUuoZVi8R3EL8Ln 6RpbNQ4aYpn4NXkdnPXMrWqyJtuPtyIIWi3SlrQ9M5MF+ggaoSLpPSyzPZ3cCLZVh2pp V30w== X-Gm-Message-State: AOAM532L7kIRMeveg7POM3G2+HBBB4d2ay93C+wwEWLySSBcLD+2CIl0 RHDmgy2pZD4bZLzTD7E4glE= X-Google-Smtp-Source: ABdhPJyOhg6cuTN1+V+nqHrj+ob9aTMv6k7GWjgN5lc5H+uOm7Z0hy44/EnWZrb5rtJSWCd/1hrbYA== X-Received: by 2002:adf:bbd2:: with SMTP id z18mr833362wrg.166.1602712010119; Wed, 14 Oct 2020 14:46:50 -0700 (PDT) Received: from [10.0.0.199] (c-24-5-53-184.hsd1.ca.comcast.net. [24.5.53.184]) by smtp.gmail.com with ESMTPSA id t19sm1190427wmi.26.2020.10.14.14.46.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Oct 2020 14:46:49 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_5DE75560-C61D-40CA-8C13-DC6ED2424C76"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Wed, 14 Oct 2020 14:46:44 -0700 In-Reply-To: <1b34b9bec59e4a00af8b9d8f182d23ff@boeing.com> Cc: Bob Hinden , Michael Richardson , dhcwg , IPv6 List , v6ops list To: "Templin (US), Fred L" References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> <10487.1602608586@localhost> <378d3420690246bbae253fb15be8c9a7@boeing.com> <19627.1602701863@localhost> <1b34b9bec59e4a00af8b9d8f182d23ff@boeing.com> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [v6ops] [EXTERNAL] [dhcwg] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Wed, 14 Oct 2020 21:46:54 -0000 --Apple-Mail=_5DE75560-C61D-40CA-8C13-DC6ED2424C76 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 With my chair hat on, is there a reason why this discussion is being = copied to the 6MAN w.g.? 6MAN doesn=E2=80=99t maintain DHCP related = items. Please remove ipv6@ietf.org from this thread. Bob > On Oct 14, 2020, at 12:19 PM, Templin (US), Fred L = wrote: >=20 > Hi Michael, >=20 >> -----Original Message----- >> From: Michael Richardson [mailto:mcr+ietf@sandelman.ca] >> Sent: Wednesday, October 14, 2020 11:58 AM >> To: Templin (US), Fred L >> Cc: ianfarrer@gmx.com; Jen Linkova ; dhcwg = ; v6ops list ; 6man >> >> Subject: Re: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to DHCPv6 = Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay- >> requirements >>=20 >>=20 >> Templin (US), Fred L wrote: >>> Michael, what I was referring to below as "failure" is the proxy = case when >>> there is an L2 proxy P between the client and relay (e.g., >>> RFC489). There >>=20 >> RFC4389 describes an ND Proxy. >> Is that really an L2 proxy? >=20 > Yes, I believe it is an L2 proxy. >=20 >> It seems like it also must be contain either an L2-bridge, or must = have the >> L3-routing table entries if it would really be capable of passing = DHCPv6-PD >> prefixes through it. >=20 > The only thing it has that includes L3 information is neighbor cache = entries that > keep track of the client's actual L2 address on the downstream link = segment, > but rewrites the client's L2 address to its own L2 address when = forwarding > onto an upstream link segment. (In the reverse direction, it receives = packets > destined to its own L2 address but the client's L3 address on the = upstream > link segment, then rewrites the L2 address to the client's L2 address = when > forwarding onto the downstream link segment.) >=20 >> Can you explain how such a device would normally work for a client = device >> A,B,C,D doing DHCPv6-PD through it? >=20 > Sure. A sends a DHCPv6 Solicit using its IPv6 link-local address as = the source, > and its L2 address as the link-layer source. The proxy converts the = link-layer > source to its own L2 address when forwarding the DHCPv6 solicit onto = the > upstream link. When the DHCPv6 Reply comes back, the IPv6 destination = is > that of client A, but the link-layer destination is the L2 address of = the proxy. > The proxy then converts the L2 destination to the address of client A = and > forwards it on to the client. >=20 >> And is the failure one where the router "R" fails to drop traffic it = should, >> one where the router "R" drops traffic that it shouldn't? >=20 > I was thinking more along the lines of the latter; if the only way = that A has > for talking to B, C, D, etc. is by going through R, it wouldn't work = if R was > unconditionally dropping everything. >=20 > Thanks - Fred >=20 >> -- >> Michael Richardson . o O ( IPv6 I=C3=B8T = consulting ) >> Sandelman Software Works Inc, Ottawa and Worldwide >>=20 >>=20 >>=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_5DE75560-C61D-40CA-8C13-DC6ED2424C76 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----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl+HccQACgkQrut0EXfn u6gaPwf/fyhkYQusq/SUhWgJcYfQz7Onuk1JBajjbx5aD/io8PLRUOL7ZJbS8r1i WfZ3shb4E9TTCoTnzC8vj35th76lwRu6F3ck1cgqCKR+mD75BvNmhLo+ncijtCXQ vR4hGfWW/+Gt0Mx1u18ua9jvM3eV4xNdzI3hh/3onKlCKvLejoLbRPEpJCmFhkEX ozWdUiNfFpDKnzW+rw7aGEY5TibVoffXH+sreYFDMxU0d6EtK3mbhq+Lm+kEW3GG nd5nxh2G2GJ7DvY3PX+0Q3XunEAOAzR7Rr9GAFdYGRnWXVDnBLAWomFBAgtjNPQx iQd0epRjTtTfCf2obESZKVC74af09A== =BwK2 -----END PGP SIGNATURE----- --Apple-Mail=_5DE75560-C61D-40CA-8C13-DC6ED2424C76-- From nobody Wed Oct 14 14:54:20 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 A0E703A10BF; Wed, 14 Oct 2020 14:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, 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 j8gbSjn5abMg; Wed, 14 Oct 2020 14:54:15 -0700 (PDT) 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 5F9963A08E3; Wed, 14 Oct 2020 14:54:13 -0700 (PDT) Received: from [IPv6:2800:810:464:b9c:4d77:be33:d267:ab18] (unknown [IPv6:2800:810:464:b9c:4d77:be33:d267:ab18]) (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 A63212845F4; Wed, 14 Oct 2020 21:54:09 +0000 (UTC) To: Brian E Carpenter , "Dale W. Carder" , Fernando Gont Cc: v6ops@ietf.org, draft-ietf-v6ops-ipv6-ehs-packet-drops.authors@ietf.org References: <160267848680.30465.9254381369345717221@ietfa.amsl.com> <6f1419fa-19ef-173a-5095-35fa51cc4ed2@gont.com.ar> <20201014161946.GA65211@dwc-desktop.local> <9ef70e2f-f2af-de92-2cac-face385c097c@si6networks.com> <0ffdf43e-957b-f01e-c121-4fa47f67a964@gmail.com> From: Fernando Gont Message-ID: Date: Wed, 14 Oct 2020 18:28:59 -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: <0ffdf43e-957b-f01e-c121-4fa47f67a964@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-ietf-v6ops-ipv6-ehs-packet-drops-01.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: Wed, 14 Oct 2020 21:54:19 -0000 Hi, Brian, On 14/10/20 17:06, Brian E Carpenter wrote: > On 15-Oct-20 05:39, Fernando Gont wrote: > ... >>> I am not sure if I agree with the last paragraph of 6.1 which opines on >>> the low adoption of rfc6437-style flow label hash entropy. >> >> We don't argue low-entropy, but issues with the Flow Label >> implementation. See e.g.: >> https://blog.apnic.net/2018/01/11/ipv6-flow-label-misuse-hashing/ >> >> >> >>> I would >>> expect that the current low adoption in ecmp implementations is a >>> chicken/egg problem. If you have a product that needs to hash and you are >>> not confident there is enough adoption in host stacks, you are still forced >>> to hunt for entropy from the upper-protocol protocols. Otherwise all the >>> legacy host traffic with the flow label set to 0 risks getting hashed >>> entirely to one side or face reordering. >> >> We're just stating that there's marginal usage of the Flow Label, which >> is what the work by Cunha et al seems to indicate. As to the possible >> consequences, part might be LBs lagging behind host implementations. But >> issues in the Flow Label implementation might have also discouraged its use. >> >> That said, the important info that Section 6.1 is meant to convey is >> that there still seems to be marginal use of the FL. And also note that >> issues have been found in FL implementations. -- i.e., we're not trying >> to infer why there's marginal use of the FL. >> >> If you think this warrants some tweaks in the text, please do let us know. > > I just re-read that section and sadly I think it is still correct. Thanks a lot for double-checking! 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 Oct 14 14:54:36 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 B95153A10F3; Wed, 14 Oct 2020 14:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_DOTEDU=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 KMHo073435yk; Wed, 14 Oct 2020 14:54:24 -0700 (PDT) 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 57D103A10ED; Wed, 14 Oct 2020 14:54:23 -0700 (PDT) Received: from [IPv6:2800:810:464:b9c:4d77:be33:d267:ab18] (unknown [IPv6:2800:810:464:b9c:4d77:be33:d267:ab18]) (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 389A02845F4; Wed, 14 Oct 2020 21:54:18 +0000 (UTC) To: "Dale W. Carder" Cc: Fernando Gont , v6ops@ietf.org, draft-ietf-v6ops-ipv6-ehs-packet-drops.authors@ietf.org References: <160267848680.30465.9254381369345717221@ietfa.amsl.com> <6f1419fa-19ef-173a-5095-35fa51cc4ed2@gont.com.ar> <20201014161946.GA65211@dwc-desktop.local> <9ef70e2f-f2af-de92-2cac-face385c097c@si6networks.com> <20201014210915.GC65211@dwc-desktop.local> From: Fernando Gont Message-ID: <2f3d67bd-dd68-9a51-492c-562977815368@si6networks.com> Date: Wed, 14 Oct 2020 18:44:28 -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: <20201014210915.GC65211@dwc-desktop.local> 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-ietf-v6ops-ipv6-ehs-packet-drops-01.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: Wed, 14 Oct 2020 21:54:35 -0000 On 14/10/20 18:09, Dale W. Carder wrote: > Thus spake Fernando Gont (fgont@si6networks.com) on Wed, Oct 14, 2020 at 01:39:21PM -0300: >> >> Thanks a lot for your timely feedback! In-line.... > > well, you did threaten wglc ;-) Well, that's our view as authors. But at the end of the day, it's the chairs' call, not ours :-) >> On 14/10/20 13:19, Dale W. Carder wrote: >>> Thus spake Fernando Gont (fernando@gont.com.ar) on Wed, Oct 14, 2020 at 09:37:38AM -0300: >>>> The rev is available at: >>>> https://tools.ietf.org/html/draft-ietf-v6ops-ipv6-ehs-packet-drops-01 >>> >>> In section 7.4, is it worth referencing covert channel risk from rfc6437's >>> section 6.1? >> >> Section 7.4 is about the security implications of *EHs*... so that would be >> off-topic, so to speak... > > Oh right, I get mixed up on that at times, sorry. But related, covert side > channel risk is probably on the minds of those justifying filtering EH's. > This is the first easy reference I found, there are likely others: > > Hansen, Raymond A.; Gino, Lourdes; and Savio, Dominic, "Covert6: A Tool > to Corroborate the Existence of IPv6 Covert Channels" (2016). > Annual ADFSL Conference on Digital Forensics, Security and Law. 13. > https://commons.erau.edu/adfsl/2016/tuesday/13 Not that I know of. At the end of the day, the BW may change, but there's always one more covert channel. The reasons are more concrete and straightforward. Except for veeeery :-) specific scenarios, folks don't really care about covert channels. [....] >>> I would >>> expect that the current low adoption in ecmp implementations is a >>> chicken/egg problem. If you have a product that needs to hash and you are >>> not confident there is enough adoption in host stacks, you are still forced >>> to hunt for entropy from the upper-protocol protocols. Otherwise all the >>> legacy host traffic with the flow label set to 0 risks getting hashed >>> entirely to one side or face reordering. >> >> We're just stating that there's marginal usage of the Flow Label, which is >> what the work by Cunha et al seems to indicate. As to the possible >> consequences, part might be LBs lagging behind host implementations. But >> issues in the Flow Label implementation might have also discouraged its use. >> >> That said, the important info that Section 6.1 is meant to convey is that >> there still seems to be marginal use of the FL. And also note that issues >> have been found in FL implementations. -- i.e., we're not trying to infer >> why there's marginal use of the FL. >> >> If you think this warrants some tweaks in the text, please do let us know. > > Ok, I think it's a misinterpretation of intent. How about this slight > wordsmith for 6.1, which to me softens the causality claim that I inferred. > > 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]. A contributing factor could be the issues that have > been found in host implementations and middle-boxes [Jaeggli-2018]. Works for me. Thanks! I'll wait and see if others complain about the change (I don't expect so), and will apply the change otherwise. > Overall, I think this is a very useful doc! 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 Wed Oct 14 15:24: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 73E1C3A10E3; Wed, 14 Oct 2020 15:24:32 -0700 (PDT) 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, 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=boeing.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 gNuMFGzm_5Zd; Wed, 14 Oct 2020 15:24:30 -0700 (PDT) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 492A43A10E2; Wed, 14 Oct 2020 15:24:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09EMORDD026383; Wed, 14 Oct 2020 18:24:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602714268; bh=wwpWDZiSgRpoLhQU7OJDeoT553f+JWwXTxBWMJHoxY8=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=KCHmO3XnqgQJww5ZsaN+u3e8HELTEowQPIbLPzk/JdLFGT1zPPhds6fCb6KHfwgEF wI/AFpHTj0iR+8TROzkipGxusK8VPHQ5K3RPs6r5ddcJX7M5kPhNCyYHI1vBsRbFZW 7rla8EoWwVxhgwX5pNALb6lpy4EBfuomLjxNbI+DAvazOGpezLIQx/9tiJkWVBQplH uewwTGgTRQBLjsakPGc2HxkW3fUnMn9u5iUF7g9WtIkem2o1PTkIkVUJSf+nYpmRa9 wznTF3m9UUdFzTsoC7X4E2h5GRC4vbfCgftCIlZxgG3tJv0ufD5SCbsddaQ/9sX9fo s81C4+0hUEGjA== Received: from XCH16-07-12.nos.boeing.com (xch16-07-12.nos.boeing.com [144.115.66.114]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09EMOHCv025237 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 14 Oct 2020 18:24:17 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-12.nos.boeing.com (144.115.66.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Wed, 14 Oct 2020 15:24:16 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Wed, 14 Oct 2020 15:24:16 -0700 From: "Templin (US), Fred L" To: Bob Hinden CC: Michael Richardson , dhcwg , "IPv6 List" , v6ops list Thread-Topic: [EXTERNAL] [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AQHWonjAucuWtIEDREmVeu6jycDtbQ== Date: Wed, 14 Oct 2020 22:24:16 +0000 Message-ID: <0284272facf5494f81eff3e49597a246@boeing.com> References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> <10487.1602608586@localhost> <378d3420690246bbae253fb15be8c9a7@boeing.com> <19627.1602701863@localhost> <1b34b9bec59e4a00af8b9d8f182d23ff@boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 64E28412D647CAE627D23632E4198554A5988F9FE30796C04F55E5DA8CACD13F2000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [EXTERNAL] [dhcwg] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Wed, 14 Oct 2020 22:24:33 -0000 Qm9iLCBzZXZlcmFsIG1lc3NhZ2VzIGJhY2sgaXQgd2FzIGVzdGFibGlzaGVkIHRoYXQgdGhlIGlz c3VlIGF0IHRoZSBoZWFydCBvZiB0aGlzDQpkaXNjdXNzaW9uIGlzIG5vdCBzcGVjaWZpYyB0byBE SENQdjYgbm9yIERIQ1B2Ni1QRC4gSW5zdGVhZCwgaXQgaXMgYW4gaXNzdWUgdGhhdCBpcw0KY29t bW9uIHRvIGFueSBzaXR1YXRpb24gd2hlcmUgdGhlcmUgYXJlIG11bHRpcGxlICJzdHViIiBJUHY2 IHJvdXRlcnMgb24gYQ0KZG93bnN0cmVhbSBsaW5rIGZyb20gYSAiZGVmYXVsdCIgSVB2NiByb3V0 ZXIsIG5vIG1hdHRlciBob3cgdGhlIHJvdXRpbmcNCmluZm9ybWF0aW9uIGlzIGVzdGFibGlzaGVk IG9yIG1haW50YWluZWQuIFNvIGZhciwgbm8gb25lIGhhcyBjaGFsbGVuZ2VkIG15DQphc3NlcnRp b24gdGhhdCB0aGlzIGlzIGEgZ2VuZXJpYyAoYW5kIG5vdCBhIERIQ1B2Ni1QRC1zcGVjaWZpYykg SVB2NiBpc3N1ZSBhbmQNCkkgaGF2ZSBiZWVuIHdhaXRpbmcgdG8gc2VlIGlmIGFueW9uZSB3YW50 cyB0byBjaGFsbGVuZ2UgdGhhdC4NCg0KRnJlZA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IEJvYiBIaW5kZW4gW21haWx0bzpib2IuaGluZGVuQGdtYWlsLmNvbV0NCj4g U2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDE0LCAyMDIwIDI6NDcgUE0NCj4gVG86IFRlbXBsaW4g KFVTKSwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0KPiBDYzogQm9iIEhpbmRl biA8Ym9iLmhpbmRlbkBnbWFpbC5jb20+OyBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitpZXRmQHNh bmRlbG1hbi5jYT47IGRoY3dnIDxkaGN3Z0BpZXRmLm9yZz47IElQdjYgTGlzdA0KPiA8aXB2NkBp ZXRmLm9yZz47IHY2b3BzIGxpc3QgPHY2b3BzQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW0VY VEVSTkFMXSBbZGhjd2ddIFt2Nm9wc10gUmU6IFF1ZXN0aW9uIHRvIERIQ1B2NiBSZWxheSBJbXBs ZW1lbnRvcnMgcmVnYXJkaW5nIGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1wZC1yZWxheS0NCj4gcmVx dWlyZW1lbnRzDQo+IA0KPiBXaXRoIG15IGNoYWlyIGhhdCBvbiwgaXMgdGhlcmUgYSByZWFzb24g d2h5IHRoaXMgZGlzY3Vzc2lvbiBpcyBiZWluZyBjb3BpZWQgdG8gdGhlIDZNQU4gdy5nLj8gICA2 TUFOIGRvZXNu4oCZdCBtYWludGFpbiBESENQIHJlbGF0ZWQNCj4gaXRlbXMuDQo+IA0KPiBQbGVh c2UgcmVtb3ZlIGlwdjZAaWV0Zi5vcmcgZnJvbSB0aGlzIHRocmVhZC4NCj4gDQo+IEJvYg0KPiAN Cj4gDQo+ID4gT24gT2N0IDE0LCAyMDIwLCBhdCAxMjoxOSBQTSwgVGVtcGxpbiAoVVMpLCBGcmVk IEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+IHdyb3RlOg0KPiA+DQo+ID4gSGkgTWljaGFl bCwNCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBNaWNo YWVsIFJpY2hhcmRzb24gW21haWx0bzptY3IraWV0ZkBzYW5kZWxtYW4uY2FdDQo+ID4+IFNlbnQ6 IFdlZG5lc2RheSwgT2N0b2JlciAxNCwgMjAyMCAxMTo1OCBBTQ0KPiA+PiBUbzogVGVtcGxpbiAo VVMpLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+DQo+ID4+IENjOiBpYW5mYXJy ZXJAZ214LmNvbTsgSmVuIExpbmtvdmEgPGZ1cnJ5MTNAZ21haWwuY29tPjsgZGhjd2cgPGRoY3dn QGlldGYub3JnPjsgdjZvcHMgbGlzdCA8djZvcHNAaWV0Zi5vcmc+OyA2bWFuDQo+ID4+IDxpcHY2 QGlldGYub3JnPg0KPiA+PiBTdWJqZWN0OiBSZTogW0VYVEVSTkFMXSBSZTogW2RoY3dnXSBbdjZv cHNdIFJlOiBRdWVzdGlvbiB0byBESENQdjYgUmVsYXkgSW1wbGVtZW50b3JzIHJlZ2FyZGluZyBk cmFmdC1pZXRmLWRoYy1kaGNwdjYtcGQtDQo+IHJlbGF5LQ0KPiA+PiByZXF1aXJlbWVudHMNCj4g Pj4NCj4gPj4NCj4gPj4gVGVtcGxpbiAoVVMpLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWlu Zy5jb20+IHdyb3RlOg0KPiA+Pj4gTWljaGFlbCwgd2hhdCBJIHdhcyByZWZlcnJpbmcgdG8gYmVs b3cgYXMgImZhaWx1cmUiIGlzIHRoZSBwcm94eSBjYXNlIHdoZW4NCj4gPj4+IHRoZXJlIGlzIGFu IEwyIHByb3h5IFAgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCByZWxheSAoZS5nLiwNCj4gPj4+IFJG QzQ4OSkuIFRoZXJlDQo+ID4+DQo+ID4+IFJGQzQzODkgZGVzY3JpYmVzIGFuIE5EIFByb3h5Lg0K PiA+PiBJcyB0aGF0IHJlYWxseSBhbiBMMiBwcm94eT8NCj4gPg0KPiA+IFllcywgSSBiZWxpZXZl IGl0IGlzIGFuIEwyIHByb3h5Lg0KPiA+DQo+ID4+IEl0IHNlZW1zIGxpa2UgaXQgYWxzbyBtdXN0 IGJlIGNvbnRhaW4gZWl0aGVyIGFuIEwyLWJyaWRnZSwgb3IgbXVzdCBoYXZlIHRoZQ0KPiA+PiBM My1yb3V0aW5nIHRhYmxlIGVudHJpZXMgaWYgaXQgd291bGQgcmVhbGx5IGJlIGNhcGFibGUgb2Yg cGFzc2luZyBESENQdjYtUEQNCj4gPj4gcHJlZml4ZXMgdGhyb3VnaCBpdC4NCj4gPg0KPiA+IFRo ZSBvbmx5IHRoaW5nIGl0IGhhcyB0aGF0IGluY2x1ZGVzIEwzIGluZm9ybWF0aW9uIGlzIG5laWdo Ym9yIGNhY2hlIGVudHJpZXMgdGhhdA0KPiA+IGtlZXAgdHJhY2sgb2YgdGhlIGNsaWVudCdzIGFj dHVhbCBMMiBhZGRyZXNzIG9uIHRoZSBkb3duc3RyZWFtIGxpbmsgc2VnbWVudCwNCj4gPiBidXQg cmV3cml0ZXMgdGhlIGNsaWVudCdzIEwyIGFkZHJlc3MgdG8gaXRzIG93biBMMiBhZGRyZXNzIHdo ZW4gZm9yd2FyZGluZw0KPiA+IG9udG8gYW4gdXBzdHJlYW0gbGluayBzZWdtZW50LiAoSW4gdGhl IHJldmVyc2UgZGlyZWN0aW9uLCBpdCByZWNlaXZlcyBwYWNrZXRzDQo+ID4gZGVzdGluZWQgdG8g aXRzIG93biBMMiBhZGRyZXNzIGJ1dCB0aGUgY2xpZW50J3MgTDMgYWRkcmVzcyBvbiB0aGUgdXBz dHJlYW0NCj4gPiBsaW5rIHNlZ21lbnQsIHRoZW4gcmV3cml0ZXMgdGhlIEwyIGFkZHJlc3MgdG8g dGhlIGNsaWVudCdzIEwyIGFkZHJlc3Mgd2hlbg0KPiA+IGZvcndhcmRpbmcgb250byB0aGUgZG93 bnN0cmVhbSBsaW5rIHNlZ21lbnQuKQ0KPiA+DQo+ID4+IENhbiB5b3UgZXhwbGFpbiBob3cgc3Vj aCBhIGRldmljZSB3b3VsZCBub3JtYWxseSB3b3JrIGZvciBhIGNsaWVudCBkZXZpY2UNCj4gPj4g QSxCLEMsRCBkb2luZyBESENQdjYtUEQgdGhyb3VnaCBpdD8NCj4gPg0KPiA+IFN1cmUuIEEgc2Vu ZHMgYSBESENQdjYgU29saWNpdCB1c2luZyBpdHMgSVB2NiBsaW5rLWxvY2FsIGFkZHJlc3MgYXMg dGhlIHNvdXJjZSwNCj4gPiBhbmQgaXRzIEwyIGFkZHJlc3MgYXMgdGhlIGxpbmstbGF5ZXIgc291 cmNlLiBUaGUgcHJveHkgY29udmVydHMgdGhlIGxpbmstbGF5ZXINCj4gPiBzb3VyY2UgdG8gaXRz IG93biBMMiBhZGRyZXNzIHdoZW4gZm9yd2FyZGluZyB0aGUgREhDUHY2IHNvbGljaXQgb250byB0 aGUNCj4gPiB1cHN0cmVhbSBsaW5rLiBXaGVuIHRoZSBESENQdjYgUmVwbHkgY29tZXMgYmFjaywg dGhlIElQdjYgZGVzdGluYXRpb24gaXMNCj4gPiB0aGF0IG9mIGNsaWVudCBBLCBidXQgdGhlIGxp bmstbGF5ZXIgZGVzdGluYXRpb24gaXMgdGhlIEwyIGFkZHJlc3Mgb2YgdGhlIHByb3h5Lg0KPiA+ IFRoZSBwcm94eSB0aGVuIGNvbnZlcnRzIHRoZSBMMiBkZXN0aW5hdGlvbiB0byB0aGUgYWRkcmVz cyBvZiBjbGllbnQgQSBhbmQNCj4gPiBmb3J3YXJkcyBpdCBvbiB0byB0aGUgY2xpZW50Lg0KPiA+ DQo+ID4+IEFuZCBpcyB0aGUgZmFpbHVyZSBvbmUgd2hlcmUgdGhlIHJvdXRlciAiUiIgZmFpbHMg dG8gZHJvcCB0cmFmZmljIGl0IHNob3VsZCwNCj4gPj4gb25lIHdoZXJlIHRoZSByb3V0ZXIgIlIi IGRyb3BzIHRyYWZmaWMgdGhhdCBpdCBzaG91bGRuJ3Q/DQo+ID4NCj4gPiBJIHdhcyB0aGlua2lu ZyBtb3JlIGFsb25nIHRoZSBsaW5lcyBvZiB0aGUgbGF0dGVyOyBpZiB0aGUgb25seSB3YXkgdGhh dCBBIGhhcw0KPiA+IGZvciB0YWxraW5nIHRvIEIsIEMsIEQsIGV0Yy4gaXMgYnkgZ29pbmcgdGhy b3VnaCBSLCBpdCB3b3VsZG4ndCB3b3JrIGlmIFIgd2FzDQo+ID4gdW5jb25kaXRpb25hbGx5IGRy b3BwaW5nIGV2ZXJ5dGhpbmcuDQo+ID4NCj4gPiBUaGFua3MgLSBGcmVkDQo+ID4NCj4gPj4gLS0N Cj4gPj4gTWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+ICAgLiBvIE8g KCBJUHY2IEnDuFQgY29uc3VsdGluZyApDQo+ID4+ICAgICAgICAgICBTYW5kZWxtYW4gU29mdHdh cmUgV29ya3MgSW5jLCBPdHRhd2EgYW5kIFdvcmxkd2lkZQ0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+ DQo+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxp c3QNCj4gPiBpcHY2QGlldGYub3JnDQo+ID4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiA+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN Cg== From nobody Wed Oct 14 15:27:48 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 5C5843A10E5; Wed, 14 Oct 2020 15:27:43 -0700 (PDT) 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 JVphk2qLcWUS; Wed, 14 Oct 2020 15:27:41 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 3BF343A10E2; Wed, 14 Oct 2020 15:27:41 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id i1so880470wro.1; Wed, 14 Oct 2020 15:27:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=lqFgFRDT6xSvoWW5//+X1zYpO3f7rb4jO6wl5iLQanM=; b=UrJjgZsPShSGSYvWif069dofJbjl7/hHJsv3Uq+h+1xBAAQ0zErOPNcQHRUI2CkkSt MpfeLp6gu1Fp2f1WVccBORDSv8wHv8gaCn37AdzwhxNrWCaAYLywY26Bk7TBbDHvBWyG KX8jEb+A6C+lssmDfm/jflZnAvYcAAU12Ho+/7QBF3Hnyqf7u3z0mzIuPI4S1z6a7bP7 GARPXXqMsTfQsZHQ/hw1QSd/sTY1v527gC0/wUsFIUUMCrA6W0Z1mUeokw8WNPOvttTb cRR5fZE66+Oh/aZZNEpVmNefUG/9TfEApFKRL5mys3XmEW9WzKYscTvRprsdMsEp3jkz Sw8A== 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=lqFgFRDT6xSvoWW5//+X1zYpO3f7rb4jO6wl5iLQanM=; b=OdQMvyCgcs3Pb41yluEcLnc+GxJE0lR4zy/J52fD45JmssVyGvl1gV9T8bnVdJQQIo IzaPqge8sRKbE7gyF2tX0gE9ZCgQOrLB7MUCJXiC7sCz+ysMulTRMhQSntnmdR1Gc+wU 2WyQWg2pPW077Wbf+tFiDUcJ5yGDo0yfb7V+0hftmi572aKAoPDxPUkUKcUxJoISeyiU q7D4EaIl7dFlf9IhjYpdJC2T0MrfcbhvLxKNv1MC7xaa3fTa/g5DSZNzaHBQFHBH9y/E wTB1D0totMVH6aBVSdYSvkN2AFQSccKjpVnRUCjq+GcArkSSDjgo9FAxm1tGA1z41Zpx IO3Q== X-Gm-Message-State: AOAM531MCHDLrPMC5JGe0CGihEEUDdQxbsraey34mfvI6ihcWpyaTArX PlRMWoAcfVY9m4P1SJl7aS4= X-Google-Smtp-Source: ABdhPJzHwxgqzUIpy4oH6P1G9q2Ti0pb5YeM4mnwIIQC39s2KntnHtpPOFD6qEu/yzNCMeZFtAkETg== X-Received: by 2002:a5d:4b49:: with SMTP id w9mr928368wrs.41.1602714459219; Wed, 14 Oct 2020 15:27:39 -0700 (PDT) Received: from ?IPv6:2601:647:5a00:ef0b:d1a9:870b:80a8:51e3? ([2601:647:5a00:ef0b:d1a9:870b:80a8:51e3]) by smtp.gmail.com with ESMTPSA id q5sm1153500wrs.54.2020.10.14.15.27.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Oct 2020 15:27:38 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_556C11A0-C932-4D1E-A909-9C384A46CB33"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Wed, 14 Oct 2020 15:27:34 -0700 In-Reply-To: <0284272facf5494f81eff3e49597a246@boeing.com> Cc: Bob Hinden , Michael Richardson , dhcwg , IPv6 List , v6ops list To: "Templin (US), Fred L" References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> <10487.1602608586@localhost> <378d3420690246bbae253fb15be8c9a7@boeing.com> <19627.1602701863@localhost> <1b34b9bec59e4a00af8b9d8f182d23ff@boeing.com> <0284272facf5494f81eff3e49597a246@boeing.com> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [v6ops] [EXTERNAL] [dhcwg] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Wed, 14 Oct 2020 22:27:43 -0000 --Apple-Mail=_556C11A0-C932-4D1E-A909-9C384A46CB33 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I note that the lack of =E2=80=9Cchallenge=E2=80=9D does not mean anyone = agrees. Agreement needs to be affirmative. Bob > On Oct 14, 2020, at 3:24 PM, Templin (US), Fred L = wrote: >=20 > Bob, several messages back it was established that the issue at the = heart of this > discussion is not specific to DHCPv6 nor DHCPv6-PD. Instead, it is an = issue that is > common to any situation where there are multiple "stub" IPv6 routers = on a > downstream link from a "default" IPv6 router, no matter how the = routing > information is established or maintained. So far, no one has = challenged my > assertion that this is a generic (and not a DHCPv6-PD-specific) IPv6 = issue and > I have been waiting to see if anyone wants to challenge that. >=20 > Fred >=20 >> -----Original Message----- >> From: Bob Hinden [mailto:bob.hinden@gmail.com] >> Sent: Wednesday, October 14, 2020 2:47 PM >> To: Templin (US), Fred L >> Cc: Bob Hinden ; Michael Richardson = ; dhcwg ; IPv6 List >> ; v6ops list >> Subject: Re: [EXTERNAL] [dhcwg] [v6ops] Re: Question to DHCPv6 Relay = Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay- >> requirements >>=20 >> With my chair hat on, is there a reason why this discussion is being = copied to the 6MAN w.g.? 6MAN doesn=E2=80=99t maintain DHCP related >> items. >>=20 >> Please remove ipv6@ietf.org from this thread. >>=20 >> Bob >>=20 >>=20 >>> On Oct 14, 2020, at 12:19 PM, Templin (US), Fred L = wrote: >>>=20 >>> Hi Michael, >>>=20 >>>> -----Original Message----- >>>> From: Michael Richardson [mailto:mcr+ietf@sandelman.ca] >>>> Sent: Wednesday, October 14, 2020 11:58 AM >>>> To: Templin (US), Fred L >>>> Cc: ianfarrer@gmx.com; Jen Linkova ; dhcwg = ; v6ops list ; 6man >>>> >>>> Subject: Re: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to DHCPv6 = Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd- >> relay- >>>> requirements >>>>=20 >>>>=20 >>>> Templin (US), Fred L wrote: >>>>> Michael, what I was referring to below as "failure" is the proxy = case when >>>>> there is an L2 proxy P between the client and relay (e.g., >>>>> RFC489). There >>>>=20 >>>> RFC4389 describes an ND Proxy. >>>> Is that really an L2 proxy? >>>=20 >>> Yes, I believe it is an L2 proxy. >>>=20 >>>> It seems like it also must be contain either an L2-bridge, or must = have the >>>> L3-routing table entries if it would really be capable of passing = DHCPv6-PD >>>> prefixes through it. >>>=20 >>> The only thing it has that includes L3 information is neighbor cache = entries that >>> keep track of the client's actual L2 address on the downstream link = segment, >>> but rewrites the client's L2 address to its own L2 address when = forwarding >>> onto an upstream link segment. (In the reverse direction, it = receives packets >>> destined to its own L2 address but the client's L3 address on the = upstream >>> link segment, then rewrites the L2 address to the client's L2 = address when >>> forwarding onto the downstream link segment.) >>>=20 >>>> Can you explain how such a device would normally work for a client = device >>>> A,B,C,D doing DHCPv6-PD through it? >>>=20 >>> Sure. A sends a DHCPv6 Solicit using its IPv6 link-local address as = the source, >>> and its L2 address as the link-layer source. The proxy converts the = link-layer >>> source to its own L2 address when forwarding the DHCPv6 solicit onto = the >>> upstream link. When the DHCPv6 Reply comes back, the IPv6 = destination is >>> that of client A, but the link-layer destination is the L2 address = of the proxy. >>> The proxy then converts the L2 destination to the address of client = A and >>> forwards it on to the client. >>>=20 >>>> And is the failure one where the router "R" fails to drop traffic = it should, >>>> one where the router "R" drops traffic that it shouldn't? >>>=20 >>> I was thinking more along the lines of the latter; if the only way = that A has >>> for talking to B, C, D, etc. is by going through R, it wouldn't work = if R was >>> unconditionally dropping everything. >>>=20 >>> Thanks - Fred >>>=20 >>>> -- >>>> Michael Richardson . o O ( IPv6 I=C3=B8T = consulting ) >>>> Sandelman Software Works Inc, Ottawa and Worldwide >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >=20 --Apple-Mail=_556C11A0-C932-4D1E-A909-9C384A46CB33 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----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl+He1YACgkQrut0EXfn u6icKAf+Lj6a4Ho4osgcrfsekCLYpktv8bMgYW++4n3M1DCYNT7bWpfZItEpAnXn YJ6Ockc3WnUjmJvfl4rD3lvH3ELh7aJ+SCAhyhP7d4MHpURtLwjfyJ/mR5vOhim4 pHIQSGKmYRzU9MKOGLX6tbNkyedl6Uo8rcz5LipVxFmC0uaoivE90itWjXyz8/O/ h8I2n1LlCms8HIc6cEeTDGLBNCJbpx1gsywYGYIKIJ+dMseHN38bi5kCvzdXS8xq +lDOYa1wXf3gGs8aLvcfQqxpgIOHcmhS0pxCqexfyrup7h44btrov/QLWRSc4+lh vBi0E9HC9LzTVMHNy/jAOmXTfECEcw== =Jwp2 -----END PGP SIGNATURE----- --Apple-Mail=_556C11A0-C932-4D1E-A909-9C384A46CB33-- From nobody Wed Oct 14 15:37: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 25D8B3A1093; Wed, 14 Oct 2020 15:37:34 -0700 (PDT) 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, RCVD_IN_MSPIKE_H2=-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=boeing.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 OHjzyBtbSNDE; Wed, 14 Oct 2020 15:37:31 -0700 (PDT) Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 A36173A10F3; Wed, 14 Oct 2020 15:37:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09EMbSst010887; Wed, 14 Oct 2020 18:37:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602715050; bh=3oNHEcMo4qB4rutvklx1cPUW/ddDtfO2M6m0asGRZIM=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=iCgC66q4tjWE+GCj9Z+wMMuJ49FQzukSiEx+LznczUkwuJwAEs1+JbJy45EVaNpyG vi476es3ZL8PrdLamKBVDrohV136MBCCF1eaIIEXekWMVjEC07xtqQ8SVbXTRF2ldD 1WbWNm/rbZFk8xyagibyGAty47cn0x8eSe5alefJ/Wujgf2Zn2kkG49CVJ8A6VgNic nKEiYokQ3NbWT8OBS5OcJEK4UpP8DaYxsK/C2xCJmFHnpMba6QN4+ux7NVd8EC+g+X /Rw4FThrgADxs9G8TYJWwvXP+qN9Dy0/Yvlbr7E0APzD4BT7JpSTGjvRkO6dD8L50A C7wFM3hMAlKDw== Received: from XCH16-07-10.nos.boeing.com (xch16-07-10.nos.boeing.com [144.115.66.112]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09EMbQYf010877 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Wed, 14 Oct 2020 18:37:26 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-10.nos.boeing.com (144.115.66.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Wed, 14 Oct 2020 15:37:25 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Wed, 14 Oct 2020 15:37:25 -0700 From: "Templin (US), Fred L" To: Bob Hinden CC: Michael Richardson , dhcwg , "IPv6 List" , v6ops list , "ianfarrer@gmx.com" , Ted Lemon , Jen Linkova Thread-Topic: [EXTERNAL] [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AQHWonjAucuWtIEDREmVeu6jycDtbamYItMA//+LysA= Date: Wed, 14 Oct 2020 22:37:25 +0000 Message-ID: <24082dcc5fd1472c8df16e331722da2d@boeing.com> References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> <10487.1602608586@localhost> <378d3420690246bbae253fb15be8c9a7@boeing.com> <19627.1602701863@localhost> <1b34b9bec59e4a00af8b9d8f182d23ff@boeing.com> <0284272facf5494f81eff3e49597a246@boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 53A6A254340DB4ACB8CDD8A0DA929BE10FC63F91D6EC3B0B1556AB5187DF08CB2000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [EXTERNAL] [dhcwg] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Wed, 14 Oct 2020 22:37:34 -0000 PiBJIG5vdGUgdGhhdCB0aGUgbGFjayBvZiDigJxjaGFsbGVuZ2XigJ0gZG9lcyBub3QgbWVhbiBh bnlvbmUgYWdyZWVzLiAgIEFncmVlbWVudCBuZWVkcyB0byBiZSBhZmZpcm1hdGl2ZS4NCg0KRmFp ciBlbm91Z2gsIEJvYjsgaGVyZSBpcyB0aGUgYXNzZXJ0aW9uIEkgbWFkZSB0aGF0IEkgd2FzIHJl ZmVycmluZyB0bzoNCg0KKyBCVFcsIEkgYW0gc3RpbGwgd2FpdGluZyB0byBoZWFyIGhvdyB0aGlz IGNvbmNlcm4gaXMgaW4gYW55IHdheSBzcGVjaWZpYyB0byBwcmVmaXgNCisgZGVsZWdhdGlvbiwg c2luY2UgaXQgc2VlbXMgdG8gYmUgZ2VuZXJpYyB0byBhbnkgY2FzZSBvZiBoYXZpbmcgYSDigJxz dHVi4oCdIHJvdXRlcg0KKyB0aGF0IG1hbGljaW91c2x5IGF0dGFja3MgaXRzIG93biB1cHN0cmVh bSBsaW5rIOKAkyBubyBtYXR0ZXIgaG93IHRoYXQgcm91dGVyDQorIG5lZ290aWF0ZXMgaXRzIHBy ZWZpeGVzIHdpdGggdXBzdHJlYW0gbmV0d29yayBub2Rlcy4NCg0KRG8gdGhlIGluZGl2aWR1YWxz IENDJ2Qgb24gdGhpcyBsaXN0IGFncmVlIHRoYXQgdGhpcyBpcyBhIGdlbmVyaWMgSVB2NiBpc3N1 ZSBhbmQgbm90DQphIERIQ1B2Ni1QRC1zcGVjaWZpYyBpc3N1ZT8NCg0KVGhhbmtzIC0gRnJlZA0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJvYiBIaW5kZW4gW21haWx0 bzpib2IuaGluZGVuQGdtYWlsLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDE0LCAy MDIwIDM6MjggUE0NCj4gVG86IFRlbXBsaW4gKFVTKSwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBi b2VpbmcuY29tPg0KPiBDYzogQm9iIEhpbmRlbiA8Ym9iLmhpbmRlbkBnbWFpbC5jb20+OyBNaWNo YWVsIFJpY2hhcmRzb24gPG1jcitpZXRmQHNhbmRlbG1hbi5jYT47IGRoY3dnIDxkaGN3Z0BpZXRm Lm9yZz47IElQdjYgTGlzdA0KPiA8aXB2NkBpZXRmLm9yZz47IHY2b3BzIGxpc3QgPHY2b3BzQGll dGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW0VYVEVSTkFMXSBbZGhjd2ddIFt2Nm9wc10gUmU6IFF1 ZXN0aW9uIHRvIERIQ1B2NiBSZWxheSBJbXBsZW1lbnRvcnMgcmVnYXJkaW5nIGRyYWZ0LWlldGYt ZGhjLWRoY3B2Ni1wZC1yZWxheS0NCj4gcmVxdWlyZW1lbnRzDQo+IA0KPiBJIG5vdGUgdGhhdCB0 aGUgbGFjayBvZiDigJxjaGFsbGVuZ2XigJ0gZG9lcyBub3QgbWVhbiBhbnlvbmUgYWdyZWVzLiAg IEFncmVlbWVudCBuZWVkcyB0byBiZSBhZmZpcm1hdGl2ZS4NCj4gDQo+IEJvYg0KPiANCj4gDQo+ ID4gT24gT2N0IDE0LCAyMDIwLCBhdCAzOjI0IFBNLCBUZW1wbGluIChVUyksIEZyZWQgTCA8RnJl ZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4gd3JvdGU6DQo+ID4NCj4gPiBCb2IsIHNldmVyYWwgbWVz c2FnZXMgYmFjayBpdCB3YXMgZXN0YWJsaXNoZWQgdGhhdCB0aGUgaXNzdWUgYXQgdGhlIGhlYXJ0 IG9mIHRoaXMNCj4gPiBkaXNjdXNzaW9uIGlzIG5vdCBzcGVjaWZpYyB0byBESENQdjYgbm9yIERI Q1B2Ni1QRC4gSW5zdGVhZCwgaXQgaXMgYW4gaXNzdWUgdGhhdCBpcw0KPiA+IGNvbW1vbiB0byBh bnkgc2l0dWF0aW9uIHdoZXJlIHRoZXJlIGFyZSBtdWx0aXBsZSAic3R1YiIgSVB2NiByb3V0ZXJz IG9uIGENCj4gPiBkb3duc3RyZWFtIGxpbmsgZnJvbSBhICJkZWZhdWx0IiBJUHY2IHJvdXRlciwg bm8gbWF0dGVyIGhvdyB0aGUgcm91dGluZw0KPiA+IGluZm9ybWF0aW9uIGlzIGVzdGFibGlzaGVk IG9yIG1haW50YWluZWQuIFNvIGZhciwgbm8gb25lIGhhcyBjaGFsbGVuZ2VkIG15DQo+ID4gYXNz ZXJ0aW9uIHRoYXQgdGhpcyBpcyBhIGdlbmVyaWMgKGFuZCBub3QgYSBESENQdjYtUEQtc3BlY2lm aWMpIElQdjYgaXNzdWUgYW5kDQo+ID4gSSBoYXZlIGJlZW4gd2FpdGluZyB0byBzZWUgaWYgYW55 b25lIHdhbnRzIHRvIGNoYWxsZW5nZSB0aGF0Lg0KPiA+DQo+ID4gRnJlZA0KPiA+DQo+ID4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IEJvYiBIaW5kZW4gW21haWx0bzpi b2IuaGluZGVuQGdtYWlsLmNvbV0NCj4gPj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDE0LCAy MDIwIDI6NDcgUE0NCj4gPj4gVG86IFRlbXBsaW4gKFVTKSwgRnJlZCBMIDxGcmVkLkwuVGVtcGxp bkBib2VpbmcuY29tPg0KPiA+PiBDYzogQm9iIEhpbmRlbiA8Ym9iLmhpbmRlbkBnbWFpbC5jb20+ OyBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitpZXRmQHNhbmRlbG1hbi5jYT47IGRoY3dnIDxkaGN3 Z0BpZXRmLm9yZz47IElQdjYgTGlzdA0KPiA+PiA8aXB2NkBpZXRmLm9yZz47IHY2b3BzIGxpc3Qg PHY2b3BzQGlldGYub3JnPg0KPiA+PiBTdWJqZWN0OiBSZTogW0VYVEVSTkFMXSBbZGhjd2ddIFt2 Nm9wc10gUmU6IFF1ZXN0aW9uIHRvIERIQ1B2NiBSZWxheSBJbXBsZW1lbnRvcnMgcmVnYXJkaW5n IGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1wZC1yZWxheS0NCj4gPj4gcmVxdWlyZW1lbnRzDQo+ID4+ DQo+ID4+IFdpdGggbXkgY2hhaXIgaGF0IG9uLCBpcyB0aGVyZSBhIHJlYXNvbiB3aHkgdGhpcyBk aXNjdXNzaW9uIGlzIGJlaW5nIGNvcGllZCB0byB0aGUgNk1BTiB3LmcuPyAgIDZNQU4gZG9lc27i gJl0IG1haW50YWluIERIQ1ANCj4gcmVsYXRlZA0KPiA+PiBpdGVtcy4NCj4gPj4NCj4gPj4gUGxl YXNlIHJlbW92ZSBpcHY2QGlldGYub3JnIGZyb20gdGhpcyB0aHJlYWQuDQo+ID4+DQo+ID4+IEJv Yg0KPiA+Pg0KPiA+Pg0KPiA+Pj4gT24gT2N0IDE0LCAyMDIwLCBhdCAxMjoxOSBQTSwgVGVtcGxp biAoVVMpLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+IHdyb3RlOg0KPiA+Pj4N Cj4gPj4+IEhpIE1pY2hhZWwsDQo+ID4+Pg0KPiA+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+ID4+Pj4gRnJvbTogTWljaGFlbCBSaWNoYXJkc29uIFttYWlsdG86bWNyK2lldGZAc2Fu ZGVsbWFuLmNhXQ0KPiA+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxNCwgMjAyMCAxMTo1 OCBBTQ0KPiA+Pj4+IFRvOiBUZW1wbGluIChVUyksIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9l aW5nLmNvbT4NCj4gPj4+PiBDYzogaWFuZmFycmVyQGdteC5jb207IEplbiBMaW5rb3ZhIDxmdXJy eTEzQGdtYWlsLmNvbT47IGRoY3dnIDxkaGN3Z0BpZXRmLm9yZz47IHY2b3BzIGxpc3QgPHY2b3Bz QGlldGYub3JnPjsgNm1hbg0KPiA+Pj4+IDxpcHY2QGlldGYub3JnPg0KPiA+Pj4+IFN1YmplY3Q6 IFJlOiBbRVhURVJOQUxdIFJlOiBbZGhjd2ddIFt2Nm9wc10gUmU6IFF1ZXN0aW9uIHRvIERIQ1B2 NiBSZWxheSBJbXBsZW1lbnRvcnMgcmVnYXJkaW5nIGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1wZC0N Cj4gPj4gcmVsYXktDQo+ID4+Pj4gcmVxdWlyZW1lbnRzDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+ IFRlbXBsaW4gKFVTKSwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPiB3cm90ZToN Cj4gPj4+Pj4gTWljaGFlbCwgd2hhdCBJIHdhcyByZWZlcnJpbmcgdG8gYmVsb3cgYXMgImZhaWx1 cmUiIGlzIHRoZSBwcm94eSBjYXNlIHdoZW4NCj4gPj4+Pj4gdGhlcmUgaXMgYW4gTDIgcHJveHkg UCBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHJlbGF5IChlLmcuLA0KPiA+Pj4+PiBSRkM0ODkpLiBU aGVyZQ0KPiA+Pj4+DQo+ID4+Pj4gUkZDNDM4OSBkZXNjcmliZXMgYW4gTkQgUHJveHkuDQo+ID4+ Pj4gSXMgdGhhdCByZWFsbHkgYW4gTDIgcHJveHk/DQo+ID4+Pg0KPiA+Pj4gWWVzLCBJIGJlbGll dmUgaXQgaXMgYW4gTDIgcHJveHkuDQo+ID4+Pg0KPiA+Pj4+IEl0IHNlZW1zIGxpa2UgaXQgYWxz byBtdXN0IGJlIGNvbnRhaW4gZWl0aGVyIGFuIEwyLWJyaWRnZSwgb3IgbXVzdCBoYXZlIHRoZQ0K PiA+Pj4+IEwzLXJvdXRpbmcgdGFibGUgZW50cmllcyBpZiBpdCB3b3VsZCByZWFsbHkgYmUgY2Fw YWJsZSBvZiBwYXNzaW5nIERIQ1B2Ni1QRA0KPiA+Pj4+IHByZWZpeGVzIHRocm91Z2ggaXQuDQo+ ID4+Pg0KPiA+Pj4gVGhlIG9ubHkgdGhpbmcgaXQgaGFzIHRoYXQgaW5jbHVkZXMgTDMgaW5mb3Jt YXRpb24gaXMgbmVpZ2hib3IgY2FjaGUgZW50cmllcyB0aGF0DQo+ID4+PiBrZWVwIHRyYWNrIG9m IHRoZSBjbGllbnQncyBhY3R1YWwgTDIgYWRkcmVzcyBvbiB0aGUgZG93bnN0cmVhbSBsaW5rIHNl Z21lbnQsDQo+ID4+PiBidXQgcmV3cml0ZXMgdGhlIGNsaWVudCdzIEwyIGFkZHJlc3MgdG8gaXRz IG93biBMMiBhZGRyZXNzIHdoZW4gZm9yd2FyZGluZw0KPiA+Pj4gb250byBhbiB1cHN0cmVhbSBs aW5rIHNlZ21lbnQuIChJbiB0aGUgcmV2ZXJzZSBkaXJlY3Rpb24sIGl0IHJlY2VpdmVzIHBhY2tl dHMNCj4gPj4+IGRlc3RpbmVkIHRvIGl0cyBvd24gTDIgYWRkcmVzcyBidXQgdGhlIGNsaWVudCdz IEwzIGFkZHJlc3Mgb24gdGhlIHVwc3RyZWFtDQo+ID4+PiBsaW5rIHNlZ21lbnQsIHRoZW4gcmV3 cml0ZXMgdGhlIEwyIGFkZHJlc3MgdG8gdGhlIGNsaWVudCdzIEwyIGFkZHJlc3Mgd2hlbg0KPiA+ Pj4gZm9yd2FyZGluZyBvbnRvIHRoZSBkb3duc3RyZWFtIGxpbmsgc2VnbWVudC4pDQo+ID4+Pg0K PiA+Pj4+IENhbiB5b3UgZXhwbGFpbiBob3cgc3VjaCBhIGRldmljZSB3b3VsZCBub3JtYWxseSB3 b3JrIGZvciBhIGNsaWVudCBkZXZpY2UNCj4gPj4+PiBBLEIsQyxEIGRvaW5nIERIQ1B2Ni1QRCB0 aHJvdWdoIGl0Pw0KPiA+Pj4NCj4gPj4+IFN1cmUuIEEgc2VuZHMgYSBESENQdjYgU29saWNpdCB1 c2luZyBpdHMgSVB2NiBsaW5rLWxvY2FsIGFkZHJlc3MgYXMgdGhlIHNvdXJjZSwNCj4gPj4+IGFu ZCBpdHMgTDIgYWRkcmVzcyBhcyB0aGUgbGluay1sYXllciBzb3VyY2UuIFRoZSBwcm94eSBjb252 ZXJ0cyB0aGUgbGluay1sYXllcg0KPiA+Pj4gc291cmNlIHRvIGl0cyBvd24gTDIgYWRkcmVzcyB3 aGVuIGZvcndhcmRpbmcgdGhlIERIQ1B2NiBzb2xpY2l0IG9udG8gdGhlDQo+ID4+PiB1cHN0cmVh bSBsaW5rLiBXaGVuIHRoZSBESENQdjYgUmVwbHkgY29tZXMgYmFjaywgdGhlIElQdjYgZGVzdGlu YXRpb24gaXMNCj4gPj4+IHRoYXQgb2YgY2xpZW50IEEsIGJ1dCB0aGUgbGluay1sYXllciBkZXN0 aW5hdGlvbiBpcyB0aGUgTDIgYWRkcmVzcyBvZiB0aGUgcHJveHkuDQo+ID4+PiBUaGUgcHJveHkg dGhlbiBjb252ZXJ0cyB0aGUgTDIgZGVzdGluYXRpb24gdG8gdGhlIGFkZHJlc3Mgb2YgY2xpZW50 IEEgYW5kDQo+ID4+PiBmb3J3YXJkcyBpdCBvbiB0byB0aGUgY2xpZW50Lg0KPiA+Pj4NCj4gPj4+ PiBBbmQgaXMgdGhlIGZhaWx1cmUgb25lIHdoZXJlIHRoZSByb3V0ZXIgIlIiIGZhaWxzIHRvIGRy b3AgdHJhZmZpYyBpdCBzaG91bGQsDQo+ID4+Pj4gb25lIHdoZXJlIHRoZSByb3V0ZXIgIlIiIGRy b3BzIHRyYWZmaWMgdGhhdCBpdCBzaG91bGRuJ3Q/DQo+ID4+Pg0KPiA+Pj4gSSB3YXMgdGhpbmtp bmcgbW9yZSBhbG9uZyB0aGUgbGluZXMgb2YgdGhlIGxhdHRlcjsgaWYgdGhlIG9ubHkgd2F5IHRo YXQgQSBoYXMNCj4gPj4+IGZvciB0YWxraW5nIHRvIEIsIEMsIEQsIGV0Yy4gaXMgYnkgZ29pbmcg dGhyb3VnaCBSLCBpdCB3b3VsZG4ndCB3b3JrIGlmIFIgd2FzDQo+ID4+PiB1bmNvbmRpdGlvbmFs bHkgZHJvcHBpbmcgZXZlcnl0aGluZy4NCj4gPj4+DQo+ID4+PiBUaGFua3MgLSBGcmVkDQo+ID4+ Pg0KPiA+Pj4+IC0tDQo+ID4+Pj4gTWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxt YW4uY2E+ICAgLiBvIE8gKCBJUHY2IEnDuFQgY29uc3VsdGluZyApDQo+ID4+Pj4gICAgICAgICAg U2FuZGVsbWFuIFNvZnR3YXJlIFdvcmtzIEluYywgT3R0YXdhIGFuZCBXb3JsZHdpZGUNCj4gPj4+ Pg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+DQo+ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pj4gSUVURiBJ UHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+ID4+PiBpcHY2QGlldGYub3JnDQo+ID4+ PiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pcHY2DQo+ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+DQoNCg== From nobody Wed Oct 14 16:42: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 1C52C3A1158; Wed, 14 Oct 2020 16:42:44 -0700 (PDT) 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 zft3_t3nJPPf; Wed, 14 Oct 2020 16:42:42 -0700 (PDT) Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (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 022353A1157; Wed, 14 Oct 2020 16:42:41 -0700 (PDT) Received: by mail-wm1-x342.google.com with SMTP id e2so1289436wme.1; Wed, 14 Oct 2020 16:42:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=rzlsCwwV7Pxrn0ONAQ3yyEylqn5O7j/msB7z04NWxxk=; b=qi4yzHCBoJYMJTl+el00YE+ND94DZjyPuZrgqAuTiAqdsMxJKX0poggZJ/q0CbMoH7 AzOhv3Z7EUUizjcuFFZh7c46rmlvirFkeACq6FIHe9Z6hXexw9VelB+9By/SnRL3SoJj uxzSr9JkR+E0tyKvCpcQ/9eZvJpUfokW0ql5eutCdw3MZwk4t7svSEmu/WnhJCf8T9az ssfKNkb5MgmHkh0V0lW9P/fQjdgZNCM0yNI3F+5UOtNL7djmdgcXoD1iicQrvaS6y7vt j1B6FKRlF6aVzNDweapRyrc7I/TO5fK2gAEXMQJHouh/cMcxLx1QHK+OTotOuoiT1Z3t FkCg== 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=rzlsCwwV7Pxrn0ONAQ3yyEylqn5O7j/msB7z04NWxxk=; b=LcsDHUeCeFxF/Uc6N+kY/1n2jqKTLo6VOnlRMM1sK/YcgEjADObVS6h19iJ9gcCOaO smVO9RqNdKYv9FDC8YPct2TN10RCLNMRypbQpECLgUxpCShkDPV+Q2JmS8gK5XIqpvgb J8gvKNVgHP6yKYz1Jq5It8/ZHDu8JGPT5qyIeTWnjWD8YLYuF5GdAEekjgfTOkzscrZ2 3FqI0wScYJ1FlgCbP+d/mV4JAaZRtsZYCplrxHNCrgW0egdBs1Qyas38pB7BXE55oOyn r5qGJ+lwXqL/Vf22jC9bbgTeEXZTHoBckieK0VkDtEi/QsPveDsnw39SHR++iKQj/JTb P0oQ== X-Gm-Message-State: AOAM5325qIrULTUsH41qu3O3CaVZhIVlouuI+Ex70lHrFtIs/QidQHG+ LGNANa4iiosH+e6C6qlFbPE= X-Google-Smtp-Source: ABdhPJyOc3F5VwWsrkkbsV/Gz6j6dgz6Gsji2Ghpxigo7iyNW3yzpmwaZ2yCiXp+AUoFkgCDN3z2Xw== X-Received: by 2002:a1c:6355:: with SMTP id x82mr1136654wmb.177.1602718960306; Wed, 14 Oct 2020 16:42:40 -0700 (PDT) Received: from ?IPv6:2601:647:5a00:ef0b:d1a9:870b:80a8:51e3? ([2601:647:5a00:ef0b:d1a9:870b:80a8:51e3]) by smtp.gmail.com with ESMTPSA id x1sm1311076wrl.41.2020.10.14.16.42.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Oct 2020 16:42:39 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_4C8D4EAB-F7D7-42F5-BB05-571C8265B688"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Wed, 14 Oct 2020 16:42:34 -0700 In-Reply-To: Cc: Bob Hinden , Philip Homburg , "v6ops@ietf.org" , dhcwg , IPv6 List To: "Templin (US), Fred L" References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> <9C612486-C25D-463F-8FB4-5BAAF9A96AE5@gmx.com> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [v6ops] [EXTERNAL] [dhcwg] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Wed, 14 Oct 2020 23:42:44 -0000 --Apple-Mail=_4C8D4EAB-F7D7-42F5-BB05-571C8265B688 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Fred, > On Oct 14, 2020, at 8:55 AM, Templin (US), Fred L = wrote: >=20 > Philip, >=20 >> 2) Multiple downstream routers on a single link where the downstream = routers >> also do not speak a routing protocol. I doubt that we need to = support >> this configuration. >=20 > That depends on how you define "routing protocol". DHCPv6 PD driven > by IPv6 ND router discovery would in spirit constitute a routing = protocol. DHCPv6 PD / IPv6 ND is not a routing protocol. Routing protocols are = things like OSPF, BGP, Babel, ISIS, etc. Bob >=20 > Thanks - Fred >=20 >> -----Original Message----- >> From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Philip = Homburg >> Sent: Wednesday, October 14, 2020 5:16 AM >> To: v6ops@ietf.org >> Cc: dhcwg ; 6man >> Subject: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay = Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay- >> requirements >>=20 >> This message was sent from outside of Boeing. Please do not click = links or open attachments unless you recognize the sender and >> know that the content is safe. >>=20 >>=20 >>> [if - Theres a couple of problems that this requirement is trying >>> to address: >>>=20 >>> 1, A misbehaving client (accidentally or otherwise) 2, The volume >>> of traffic being forwarded by the relay consumes the available >>> bandwidth meaning that DHCP configuration cant complete >>>=20 >>> In both cases, the client cant be relied on to solve the problem] >>=20 >> I wonder if the problem can be stated in a more general way. >>=20 >> It seems to me that router should only forward a packet back to the = link it >> came from when it got the packet directly from a host. >>=20 >> I.e., a host may send a packet to a default router when the best next = hop >> happens to be different router on the same link. A host may also send = a >> packet to a default router when the host doesn't know that the = destination >> is on-link (on NBMA links for example). >>=20 >> In contrast, routers can be relied on to send packet to the correct = next hop. >> If they don't, then there is something inconsistent in the routing = information. >> Routers don't react to redirect ICMPs, so this inconsistency could = waste a >> lot of bandwidth. >>=20 >> One option is to only forward a packet back to the same link if we = can also >> send a redirect ICMP (ignoring rate limiting). I.e., Section 8.2 of = RFC 4861 >> (Neighbor Discovery) describes that a redirect ICMP can be send if >> "the Source Address field of the packet identifies a neighbor" >>=20 >> This could be implemented both in the downstream router and in the = upstream >> router. >>=20 >> I can see two cases where this could go wrong: >> 1) multi-homed hosts doing something weird. In that case the host = should be >> fixed. >> 2) Multiple downstream routers on a single link where the downstream = routers >> also do not speak a routing protocol. I doubt that we need to = support >> this configuration. >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --Apple-Mail=_4C8D4EAB-F7D7-42F5-BB05-571C8265B688 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----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl+HjOoACgkQrut0EXfn u6jiRQgAlUZbfEL4Utg21I1b1h4n23Sf2hUPQFLiJeusGUvW532RqinguLIK3Icr tjQoUdXcqI5Ae+Jn3WUQLMMQ8gzKqhFK6a+UTibP9429AOnrbi8ktqjDTjFlvikZ 8M8WQx2w5wja+syI18NHqFpExA5glARF5oQ/nWbiw2gklS5ubRxjFcLwQpM5PZ7X 9AQhi/CPhnzKuWi74kzJRQ1hvAnsghQff38UxJUYtYlYC798ro2kEBafRrKmYnTe 2YI/7/0mjKTfGE38pbQTLYgzIsaIU/y0AZroaNN/285+DKNH8/O95Eq9wZ7Q5WD7 VD/R3F1ROtkrs5+w4QJa7Se1oQqMXg== =ta4H -----END PGP SIGNATURE----- --Apple-Mail=_4C8D4EAB-F7D7-42F5-BB05-571C8265B688-- From nobody Wed Oct 14 17:09: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 DCA973A1176; Wed, 14 Oct 2020 17:09:05 -0700 (PDT) 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 BgV3DRqSis_Q; Wed, 14 Oct 2020 17:09:04 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9961F3A1173; Wed, 14 Oct 2020 17:09:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 7200838980; Wed, 14 Oct 2020 20:14:51 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GFWW73nyxZWQ; Wed, 14 Oct 2020 20:14:47 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9C17B3897F; Wed, 14 Oct 2020 20:14:47 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 967316A5; Wed, 14 Oct 2020 20:08:56 -0400 (EDT) From: Michael Richardson To: "Templin \(US\)\, Fred L" cc: "ianfarrer\@gmx.com" , Jen Linkova , dhcwg , v6ops list , 6man In-Reply-To: <1b34b9bec59e4a00af8b9d8f182d23ff@boeing.com> References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> <10487.1602608586@localhost> <378d3420690246bbae253fb15be8c9a7@boeing.com> <19627.1602701863@localhost> <1b34b9bec59e4a00af8b9d8f182d23ff@boeing.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [v6ops] [EXTERNAL] Re: [dhcwg] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Thu, 15 Oct 2020 00:09:06 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Templin (US), Fred L wrote: >> Can you explain how such a device would normally work for a client d= evice >> A,B,C,D doing DHCPv6-PD through it? > Sure. A sends a DHCPv6 Solicit using its IPv6 link-local address as t= he source, > and its L2 address as the link-layer source. The proxy converts the l= ink-layer > source to its own L2 address when forwarding the DHCPv6 solicit onto = the > upstream link. When the DHCPv6 Reply comes back, the IPv6 destination= is > that of client A, but the link-layer destination is the L2 address of= the proxy. > The proxy then converts the L2 destination to the address of client A= and > forwards it on to the client. But, how does the proxy know how to forward the prefix that A gets on to A? The router, having seen A's L2 address on the DHCPv6-PD, and/or having done= a ND on A and receiving L2's address, will punt the traffic to the proxy. Wouldn't the proxy have to observe the DHCPv6-PDs to know what prefixes are being delegated? I didn't think that was a thing. I think that it just doesn't work. If it is a thing, then the Proxy will have an L3 route for the prefix that was delegated so that it can forward traffic from R on to A. >> And is the failure one where the router "R" fails to drop traffic it= should, >> one where the router "R" drops traffic that it shouldn't? > I was thinking more along the lines of the latter; if the only way th= at A has > for talking to B, C, D, etc. is by going through R, it wouldn't work = if R was > unconditionally dropping everything. If A and B are behind the same Proxy, and each has a prefix delegated to th= em, and they have to go all the way to R to get traffic forwarded because they see R's RAs, not ones that the Proxy has made up, then indeed, R would see the Proxy's L2 address as src/dst, and it should drop traffic. But, I would claim that the Proxy should have seen the traffic to R, intercepted it, and used it's routing table to get the Prefix-A/Prefix-B tr= affic to B. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+HkxgACgkQgItw+93Q 3WVlPwgAnvtkZoW6blUxJr66tWiUrtOFl1dkg+5Q5e2Qel9oNfEmnyYwxW4+B6Bx cVT1/+bVERRLstjWULNxbkNqfpA82fa8bPXtfZQlZaeE3UdhaXHPg4TKbRlSQhLc VUUzaXX53qv7CHllmmojSd2lbUMGniweMYpB2yOW0sKj9ETnS/MF94cFvS3ku8ky uLqmZ+U+97LccrW8nK8nDt/132XxMI4UGMQ0GIQutjrgbcAUdxNNQYC4BRkOS1Zl dB9Z6ZoOwxUWHa2Elrovq7LjVsMi4RdIuhNgq8DwWN/rov/k4E9E0rh7YH3+XjNn l/Vgizarb3BR8EJhQc0EhhoDss73bA== =DYKy -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 14 17:11:12 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 222473A1176; Wed, 14 Oct 2020 17:11:01 -0700 (PDT) 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 W1r41byH9lQa; Wed, 14 Oct 2020 17:10:59 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C483A1178; Wed, 14 Oct 2020 17:10:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 3EB0F38980; Wed, 14 Oct 2020 20:16:49 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pB6i2mReZ0dh; Wed, 14 Oct 2020 20:16:39 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B90C23897F; Wed, 14 Oct 2020 20:16:39 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A62946A5; Wed, 14 Oct 2020 20:10:48 -0400 (EDT) From: Michael Richardson To: Bob Hinden cc: "Templin \(US\)\, Fred L" , IPv6 List , v6ops list , dhcwg In-Reply-To: References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> <10487.1602608586@localhost> <378d3420690246bbae253fb15be8c9a7@boeing.com> <19627.1602701863@localhost> <1b34b9bec59e4a00af8b9d8f182d23ff@boeing.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [v6ops] [EXTERNAL] [dhcwg] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Thu, 15 Oct 2020 00:11:01 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Bob, I think that this regards an issue fits between 6man and DHC. I think that we are benefitting from the CC to 6man. (in fact, that's how I noticed I was no longer on the dhc list.) Maybe v6ops does not belong. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+Hk4gACgkQgItw+93Q 3WUrVQgAli12TtOnY8uNI4rsDxa+BOPVghkqO8oRrJiUGF9jtjQDE+NaL4pOfjC7 aSvWeHp5LROMlqQWR8vWKZ9mXxifYArysKx5VDNEXVfg+oZpM1gMMQ777J58sCk1 E17dZgOUt+Ra8sENyY0LLj0+1tvU+P/Dk8xnQeBAQdorEi+9YFqfuEt617e0e1rk D89eDV6IhQ/QuqMr5wDKL+H2bhLzLH3i+YWHdKX4NhsjiUMtlicpiVx38x/6V0gc kgn5CFUBl0gybF+osuvAUjedgg3QZAPE79ZeM1JO4oId4A1oKEYvyhokD9vNJotx y9n2Oh/iDT8GeMpGG1ttTxvgCEUtsw== =3RqB -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 14 17:48:36 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 1BF083A119C; Wed, 14 Oct 2020 17:48:27 -0700 (PDT) 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 zmmy2dAP6PKP; Wed, 14 Oct 2020 17:48:25 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 D45973A119B; Wed, 14 Oct 2020 17:48:24 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id p15so1248520wmi.4; Wed, 14 Oct 2020 17:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=r63cpTyHZBJTzV0mLYK6e0e6eIvu1bvN8F/ULZ3UWgQ=; b=U0Te++ZUUItWdp6Q63z8Df8nuLmTfvUvVSmZ9BMMFnitBJjpGakISiy8uRd3xeXocf KLymTvFA2ODxQ221VuTbDjx0sW1jGQvLUDvWWC0Pk9lQ8b/TWRBM3blfAGr2IRPxJI2v WHMIVgbS1/z6mf4eN1UDGoCrOlQDW7Ip7RfGYMU6l2jRINZcYO8YszRCbxx0bOUR/ziz jl3dHhwBHNVjYKOn9g4XtOTzAqFew0mq4AatS7TVSE0JypF5aei217vlsPhcqGpkc7tq VOyQ04Avc/I1flqgp5gIc6UO+f6f2F73WAShffuIfX8UuH7QYx1LxIo6xeYnY76tKfXk HF5Q== 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=r63cpTyHZBJTzV0mLYK6e0e6eIvu1bvN8F/ULZ3UWgQ=; b=TfQ+z+g8dv5p51ysNxENduEtCN+nUtN/XQyUnCb/9RSn/VU7/fJkCoZWfgKqjU//PI mBNawOeSYE6Sb9HYfpJM+dlyBtCFMvBT8c2mGeQB/Nf6oc7oeg3fKu/mkwX6bZU9MxwG Zvuh2vloVGjrW9C9qc7gj+thVzDxQExclSmPpEYKQjJ3zznWfzlfWuwsgoHOW8x5cw9B 7XzWkqH3lno3MGGyuxMagQfqlZlZeq6QZiMwCgRKd7+WQ1dOlv6Nxa8lO24ES4tsnF4Q AMBYbH1HJyLHS/7ncV9hIsAeq0tcZ02hO+rlhXQVSoco6L3htHYLj0HdEA9ECPlpV0Qh txEQ== X-Gm-Message-State: AOAM530vPIJHHwYsr2aXADC84wJhZ3BFPlJzJ9WaKh99zX6SVye+2Jtz qfx1UJQivUDBfKFjo5qtN28= X-Google-Smtp-Source: ABdhPJzhKt9+vR9kWauVkRBHzGaeLf6ZI0rIUoRI/oz8E99MBRy3/WwcgjF7t8eZL3+uGwrsmOVmqQ== X-Received: by 2002:a1c:9a4b:: with SMTP id c72mr1197217wme.157.1602722903156; Wed, 14 Oct 2020 17:48:23 -0700 (PDT) Received: from ?IPv6:2601:647:5a00:ef0b:d1a9:870b:80a8:51e3? ([2601:647:5a00:ef0b:d1a9:870b:80a8:51e3]) by smtp.gmail.com with ESMTPSA id w4sm1597945wmi.10.2020.10.14.17.48.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Oct 2020 17:48:22 -0700 (PDT) From: Bob Hinden Message-Id: <0267F5D5-073A-462F-86DE-87D96C152687@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_92A0CB27-EFB0-4518-A03A-549012EF8530"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Wed, 14 Oct 2020 17:48:14 -0700 In-Reply-To: <9357.1602720648@localhost> Cc: Bob Hinden , "Templin (US), Fred L" , IPv6 List , v6ops list , dhcwg To: Michael Richardson References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> <10487.1602608586@localhost> <378d3420690246bbae253fb15be8c9a7@boeing.com> <19627.1602701863@localhost> <1b34b9bec59e4a00af8b9d8f182d23ff@boeing.com> <9357.1602720648@localhost> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [v6ops] [EXTERNAL] [dhcwg] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Thu, 15 Oct 2020 00:48:27 -0000 --Apple-Mail=_92A0CB27-EFB0-4518-A03A-549012EF8530 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 14, 2020, at 5:10 PM, Michael Richardson = wrote: >=20 >=20 > Bob, I think that this regards an issue fits between 6man and DHC. > I think that we are benefitting from the CC to 6man. > (in fact, that's how I noticed I was no longer on the dhc list.) >=20 > Maybe v6ops does not belong. OK, fair enough. Bob >=20 > -- > Michael Richardson . o O ( IPv6 I=C3=B8T = consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide >=20 >=20 >=20 >=20 --Apple-Mail=_92A0CB27-EFB0-4518-A03A-549012EF8530 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----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAl+HnE4ACgkQrut0EXfn u6goBQf9Ht5Lsbn4Dg8Npt2VbL408psrLjPBSNawTN5ahIXShURLNM2raED8Yw9H ac7JsZeehCCL/LNmdGsmU6I9hqH+jjWghkJUJ5xuO1OVSLiCHFci/GDVYJCCgCcp keM0B5Sq9ccl8asmam24kPhjLr5ylRgIyQnbqM2FqrQSFgym107aQkQX4FF5NM6E Unqy8iWBsRRop1wqj/0mYdNLFhXGAx3z9fdwt0DKM21n4wF5DDqhRbiAKCOkEMkE aF6vkhqy/dMk+oZq37J67lrP/v8m7D4YCGjz8ReUxEnDbFb6BCq9Bwu6tWVqYy1x 6EoCBuW1891yA74MVEp3j/6Dsntuwg== =ZQBB -----END PGP SIGNATURE----- --Apple-Mail=_92A0CB27-EFB0-4518-A03A-549012EF8530-- From nobody Wed Oct 14 18:47: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 484AC3A11CD; Wed, 14 Oct 2020 18:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 oTkzMTItogrc; Wed, 14 Oct 2020 18:47:28 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 8F80E3A11CE; Wed, 14 Oct 2020 18:47:28 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id x20so1189370qkn.1; Wed, 14 Oct 2020 18:47:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=urTcejesMy1A1sx/u0QSzYHa0JHrpPEKYYIlT2SAQXs=; b=hlP3WuX6tYD9sv++Z07KLZNDsVv9cVb/WQ2J1cnffkr2Q1pGMABkjNWGeEUkPSONah On5tnX4pVHdp1h6LYzLTiLx0pVv15W3L1awlWNUgiK1fOONhjwltg3wncQQwksR56/c1 RjW0Ejap2gFrzYeSqp5Jz9o9FaLNRCVhc6ve4oKh7RNYQ8fOlZEYMPMf/T52ME3012C0 ssaxlNBHkPQr3AIvD9VDj5jYw+CcUuc9qJmt0A/J4k8A/svdWDgGrPXb5wkepyxJqwRH EMvgpM2XSYAVIlHGiM3OCSClOrZYE02318Ds0S8Qj2Ga6lmuNZSR/xT+Zhh6IElFiEp5 47tw== 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=urTcejesMy1A1sx/u0QSzYHa0JHrpPEKYYIlT2SAQXs=; b=TNlJnlugmaiY2gQIg0X7W+vOfxleUJdxLJyXqlqX+DxlmFRqISeBPSZ3h5GoYPk0JA QMTkbrvrPBg5i+zAwyBruhPWgGbBg47kcLlKZBjCzDzomH05PiHybptLm58lD4rWFC3o 50LDpI6MaNn8E/r9hh2CZlRyYnoFspdjXxRhX70c1jfI5UDnGAwkx7HKQXVvPIYq263i tV7yYL96hzSLqJY3zBToh32/1LRpRNTFvHUaJx1zOa0ruPyUaziAPUCwirfisegcGWzt czSiFKEndaigmP/yZSOzgtn+rV/eHg18GJ4GkdY/ZFzdcD1wiua6NfWMNtPVbNnU71hZ 6cIA== X-Gm-Message-State: AOAM533ZZoisxRgzKLwK25VTvAe+UqOdoPQP1MKUmR2aq1RkkdAyLOL+ 5/QZDTcLVtOfJ8FeSoQMogsfplsu5goiD4b5L78= X-Google-Smtp-Source: ABdhPJxyNAL5hp+lqKrp8sftIXvsQ64rERBz4yVtgXn4boz+JrrXhfUMOZbl51WR7K+ArVJ+TW653mYlsJZ7AOVLm6o= X-Received: by 2002:a37:a74e:: with SMTP id q75mr1930480qke.277.1602726447425; Wed, 14 Oct 2020 18:47:27 -0700 (PDT) MIME-Version: 1.0 References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <19432.1602258078@localhost> <644565BC-5818-4244-A34A-1B39C3FC9175@gmx.com> In-Reply-To: <644565BC-5818-4244-A34A-1B39C3FC9175@gmx.com> From: Jen Linkova Date: Thu, 15 Oct 2020 12:47:16 +1100 Message-ID: To: ianfarrer@gmx.com Cc: Michael Richardson , "Bernie Volz (volz)" , dhcwg , 6man , v6ops list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] [dhcwg] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Thu, 15 Oct 2020 01:47:31 -0000 On Wed, Oct 14, 2020 at 12:16 AM wrote: > Thanks for all of the discussion on this. We=E2=80=99ve reworked the requ= irement as follows: > > R-4 > To prevent routing loops, the relay SHOULD implement a configurable polic= y to > drop client traffic as follows: I agree with Bernie's comment that 'client traffic' is a bit unclear. Is it traffic from the client? Or to the client? Maybe 'traffic with the destination address in a prefix delegated to a clie= nt'? >For point-to-point links, when the packet's > ingress and egress interfaces match. For multi-access links, when the pac= ket's > ingress and egress interface match, and the source MAC and next-hop MAC a= ddresses > match. An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route to > destination) error message MAY be sent back to the client. The ICMP poli= cy > SHOULD be configurable. > > Thanks, > Ian > > > On 9. Oct 2020, at 17:41, Michael Richardson wr= ote: > > > > > > Jen Linkova wrote: > >> I think there is confusion re: the scenario we are talking about. I've > >> attached the diagram for the case which concerns me. > >> So: > >> - The Relay R has an interface eth0 connected to a switch S. > >> - Devices A and B are connected to the same switch and using R as a > >> default gateway. > >> - The prefix 2001:db8::/56 was delegated to a client A via the relay R= . > > > > a friendly amendment to your example to aid in human comprehension: > > } - The prefix 2001:db8:0000:0123:/64 was delegated to a client A v= ia the relay R. > > } - R installs a route for 2001:db8:0000:0123:/64 towards A via et= h0. > > > >> - The device B (which has an address NOT from the delegated prefix, > >> but from another /64 assigned to that common link, let's sat > >> 2001:db8:cafe::/64) sends a packet to an address from the delegated > > > > now, my brain can more clearly see that 2001:db8:cafe::/64 is not > > within 2001:db8:0000:0123:/64, while I had to use a few extra brain cel= ls to > > see that it wasn't in that ::/56 :-) > > > >> What I'd expect to happen (with DHCP-PD or without - e.g. if R has a > >> static route towards A, not a dynamic route produced by PD): > >> - the packet is sent to A. Well, if A does not have a route to > >> 2001:db8::42 then indeed a routing loop might happen. But if A does > >> have a route, the packet will be delivered. > > > >> What seems to be required by R4: > >> - R detects that the packet is received via eth0 and needs to be sent > >> back to eth0. R4 seems to require such packets to be dropped. > >> So if B would never be able to communicate to any address in the > >> delegated prefix, right? > > > >> Am I missing anything? > > > > I think that you got it right. > > > >>> Perhaps the missing piece of the rule is don=E2=80=99t send it back t= o where it came from, based on link layer addresses (or link if point-to-po= int). > > > >> Yes. If R4 was saying 'drop the packet if it comes from the same > >> link-layer address you are going to send it back' - it would make > >> total sense. But I don't think routers do *that*. > > > > Yes, if we made the check on L2 address, then it would work. > > And I agree that routers are exactly doing that. > > > > I think that it also works if B is a router with additional interfaces > > downstream, unless there are multiple paths. > > > > -- > > Michael Richardson . o O ( IPv6 I=C3=B8T cons= ulting ) > > Sandelman Software Works Inc, Ottawa and Worldwide > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > --=20 SY, Jen Linkova aka Furry From nobody Wed Oct 14 18:51:32 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 25A0C3A11D6; Wed, 14 Oct 2020 18:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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 feAwiB2g8-Pp; Wed, 14 Oct 2020 18:51:25 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 62F523A11D4; Wed, 14 Oct 2020 18:51:25 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id a23so1130991qkg.13; Wed, 14 Oct 2020 18:51:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=PzsrttPIu8Vc3yP8A2zoiUX0EAiDmpZRYk3uDLgOO3s=; b=bOGP02pGasNk9cvxCEwi1vnNuYYeVHxIk1wsL7XDbO3ybmFaolI0ZaAcx+gvV21dQC bK5C8Ep4iXu7USJnpCxoUJbW7lj0eAdG6fk4pB83cx2mWb6IN4H4iam0s+Fe5F8ORITc cRk4+/Fvbl45GvrOTAuKlyJ/N0/fYWxOmhPNkrccY+E9eoVpR4lt9cuDyFbAZwyOo44J OKjDfkmdNgTyNAsJ/WI8HcHMe2LRbc2CL1F6SnoZw6Pc1Afb3qUyfzJIlvn9SDFZqI9Q J2Rbmuu6n5V+KuF93O0M/60YZnXPuo8KnhSuTxFiT5QMltZ4iXXq3lfwPkk/IfdP+8xI G/ug== 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=PzsrttPIu8Vc3yP8A2zoiUX0EAiDmpZRYk3uDLgOO3s=; b=NmGP7naKbhVwjmsA0ESpEiOk0joH9+7kU8eHLaLrj3rfiG8UfLVy5ptbSQPFaZkGvq aHaeRV6TqSFKyUPqt4IMYi79JrSKFp1PKrsV0M+Uq2BXCSnU+qv0+zIR3uO3A+lpJaws 9vUhfzZ5OTZPpWBgt26B6QQp/t5Kecx0oJf3cgzRg2dw8BOWU9QRt2FusuD2ikUmTxST X4uSfU8YvTAYMIdIYGHotpTT9hYq2B9uNWEqFmv2lT/a1bd2Kn4uco9yzN/ny27gwlxm qfZcdJruA7ptx0OaWrRY7SNjdUXzdwzfHUFdpv45O4svFhlq4B/4OFjZLwDW7prpo1u/ QiiQ== X-Gm-Message-State: AOAM532qWIWKsvAfHVwehdTDf/xGSUO83hU+JY6C7U8I8MuVCs/+ng2E RwYcq5c4nOlTxmyWlQbYwUNL/rnOQ8+DX8lg0Qs= X-Google-Smtp-Source: ABdhPJyoLp5oLa6PUOd25UBTNVsy25bhB8CkVGd6SXGBGe2UM4HOKy45Bal9hO6wxtjxphcXizpnwWjf8fii+DKPjR8= X-Received: by 2002:a37:849:: with SMTP id 70mr1990301qki.332.1602726684409; Wed, 14 Oct 2020 18:51:24 -0700 (PDT) MIME-Version: 1.0 References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <19432.1602258078@localhost> <644565BC-5818-4244-A34A-1B39C3FC9175@gmx.com> In-Reply-To: From: Jen Linkova Date: Thu, 15 Oct 2020 12:51:13 +1100 Message-ID: To: "Bernie Volz (volz)" Cc: "ianfarrer@gmx.com" , Michael Richardson , dhcwg , 6man , v6ops list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] [dhcwg] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Thu, 15 Oct 2020 01:51:27 -0000 On Wed, Oct 14, 2020 at 12:44 AM Bernie Volz (volz) wrote: > If not, perhaps we just say: > > R-4 > To prevent routing loops, the relay SHOULD implement a configurable polic= y to drop traffic received from an uplink interface as follows: I'm not sure 'from an uplink interface' makes sense. In the case of a routing loop caused by an amnesiac DHCP-PD client it would be a downstream interface. The scenario when such traffic arrives from an uplink interface is 'the uplink router believes the prefix is delegated to the client but the relay does not have a route pointing to the client so it sends traffic back' - so more likely 'an amnesiac relay' case. >For point-to-point links, when the packet's ingress and egress interfaces = match. For multi-access links, when the packet's ingress and egress interfa= ce match, and the source MAC and next-hop MAC addresses match. An ICMPv6 Ty= pe 1, Code 6 (Destination Unreachable, reject route to > destination) error message MAY be sent as per [RFC4443], section 3.1. Th= e ICMP policy SHOULD be configurable. > > - Bernie > > -----Original Message----- > From: ianfarrer@gmx.com > Sent: Tuesday, October 13, 2020 9:16 AM > To: Michael Richardson ; Jen Linkova > Cc: Bernie Volz (volz) ; dhcwg ; 6man ; v6ops list > Subject: Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DHCPv6 Relay Impl= ementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements > > Hi, > > Thanks for all of the discussion on this. We=E2=80=99ve reworked the requ= irement as follows: > > R-4 > To prevent routing loops, the relay SHOULD implement a configurable polic= y to drop client traffic as follows: For point-to-point links, when the pa= cket's ingress and egress interfaces match. For multi-access links, when th= e packet's ingress and egress interface match, and the source MAC and next-= hop MAC addresses match. An ICMPv6 Type 1, Code 6 (Destination Unreachable,= reject route to > destination) error message MAY be sent back to the client. The ICMP poli= cy SHOULD be configurable. > > Thanks, > Ian > > > On 9. Oct 2020, at 17:41, Michael Richardson wr= ote: > > > > > > Jen Linkova wrote: > >> I think there is confusion re: the scenario we are talking about. > >> I've attached the diagram for the case which concerns me. > >> So: > >> - The Relay R has an interface eth0 connected to a switch S. > >> - Devices A and B are connected to the same switch and using R as a > >> default gateway. > >> - The prefix 2001:db8::/56 was delegated to a client A via the relay R= . > > > > a friendly amendment to your example to aid in human comprehension: > > } - The prefix 2001:db8:0000:0123:/64 was delegated to a client A v= ia the relay R. > > } - R installs a route for 2001:db8:0000:0123:/64 towards A via et= h0. > > > >> - The device B (which has an address NOT from the delegated prefix, > >> but from another /64 assigned to that common link, let's sat > >> 2001:db8:cafe::/64) sends a packet to an address from the delegated > > > > now, my brain can more clearly see that 2001:db8:cafe::/64 is not > > within 2001:db8:0000:0123:/64, while I had to use a few extra brain > > cells to see that it wasn't in that ::/56 :-) > > > >> What I'd expect to happen (with DHCP-PD or without - e.g. if R has a > >> static route towards A, not a dynamic route produced by PD): > >> - the packet is sent to A. Well, if A does not have a route to > >> 2001:db8::42 then indeed a routing loop might happen. But if A does > >> have a route, the packet will be delivered. > > > >> What seems to be required by R4: > >> - R detects that the packet is received via eth0 and needs to be sent > >> back to eth0. R4 seems to require such packets to be dropped. > >> So if B would never be able to communicate to any address in the > >> delegated prefix, right? > > > >> Am I missing anything? > > > > I think that you got it right. > > > >>> Perhaps the missing piece of the rule is don=E2=80=99t send it back t= o where it came from, based on link layer addresses (or link if point-to-po= int). > > > >> Yes. If R4 was saying 'drop the packet if it comes from the same > >> link-layer address you are going to send it back' - it would make > >> total sense. But I don't think routers do *that*. > > > > Yes, if we made the check on L2 address, then it would work. > > And I agree that routers are exactly doing that. > > > > I think that it also works if B is a router with additional interfaces > > downstream, unless there are multiple paths. > > > > -- > > Michael Richardson . o O ( IPv6 I=C3=B8T cons= ulting ) > > Sandelman Software Works Inc, Ottawa and Worldwide > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > --=20 SY, Jen Linkova aka Furry From nobody Thu Oct 15 03:54: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 6874A3A1370; Thu, 15 Oct 2020 03:54:13 -0700 (PDT) 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=DeDThSBx; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=XuCANCAp Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCFpkTNM5eGd; Thu, 15 Oct 2020 03:54:11 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E9733A11D1; Thu, 15 Oct 2020 03:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7588; q=dns/txt; s=iport; t=1602759251; x=1603968851; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tRsBswEfEkoNkuoHJS3LdEgYnGukhlpEJULktQo+Sz4=; b=DeDThSBxdkzezSGVomvQ3wXWyZxKXCSrmZjjcDu1MWgsppzrHcsL1ZuA /HOrU2WNsFz4p74Wgu9ImjWUoLmHl2KoHLVCVa0eV+WpUgy7gYWdTST47 /VmT+6PUQAjTdqmnh96fJMkyLHe79c2EvX83FxgVPAQPFrlKDzHxJ3cw+ 0=; IronPort-PHdr: =?us-ascii?q?9a23=3AE9UIOxIBYjNxUINWu9mcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGvK0/g1rZG47c7qEMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iK0NFgTE8H7NBXep3So5msUHR?= =?us-ascii?q?PyfQN+OuXyHNvUiMK6n+C/8pHeeUNGnj24NLhzNx6x6w7Ws5ob?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CzBwCzKYhf/4MNJK1gHgEBCxIMQIF?= =?us-ascii?q?EC4FSUQdwWS8sCoQzg0YDjSsmihGOaoEugSUDVQsBAQENAQEYCwoCBAEBgVW?= =?us-ascii?q?CdQIXgXECJTUIDgIDAQELAQEFAQEBAgEGBG2FXAyFcgEBAQMBAQEQEREMAQE?= =?us-ascii?q?sCwEEBwQCAQgOAwQBAQECAh8HAgICHwYLFQgIAgQOBSKDBAGCSwMOIAEOoGI?= =?us-ascii?q?CgTmIYXaBMoMBAQEFhSENC4IQAwaBDiqCcoNuhlYbggCBECgMEIJNPoIaQgE?= =?us-ascii?q?BgV8XD4JxM4ItkC2DI6NYVAqCapVjhQsDH6FKoQuSTgIEAgQFAg4BAQWBVgI?= =?us-ascii?q?2gVdwFTsqAYI+UBcCDY4fDBcUgzqFFIVCdDgCBgEJAQEDCXyMOwGBEAEB?= X-IronPort-AV: E=Sophos;i="5.77,378,1596499200"; d="scan'208";a="563126551" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Oct 2020 10:54:09 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 09FAs8PV024195 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Oct 2020 10:54:09 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 15 Oct 2020 05:54:08 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 15 Oct 2020 05:54:08 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 15 Oct 2020 06:54:08 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DiG0cqfD7Po6cAQ0DbIJVkMpoKOkUkTOlM1MCbQZ7u3UsFdo6OmiK5Kr7xBQ9xfOjl+P22ZfLrqS78yiTYADb2qzgjspS3iM1EoLMML7njsdkJjc1OP5Hvjkoi4ba8wJk3mS0wWrjSNqTyJq9QPvicwYzAY6nH4/Iea4AlsrYW11O5Sl9CdQqxJ7T3NnGrCs8QcEKFLI5esl1Pidc/p2x83ytat8Kvuf8fv/fzDwZRz7/KlylilmguiASEdsblzl51TkLSc0zd3/WN2BwUHdLNGc+I04ZYCjgJ5II8M6he8egFk8HcdShYzgqqtG88IX70UBZYVVvK+fqCyLFOJbEQ== 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=tRsBswEfEkoNkuoHJS3LdEgYnGukhlpEJULktQo+Sz4=; b=LQTZHU0oa6zwa0zT1UlPS9iJX/p/MqcV4CXxXwjoMfDPXOhs53KytWMvta/6w2YIKShcELdAKkTq4fGfEEz8BDFlC1QFdMdJuNL4MSee4kB/94577D7/URfAGTXphkW+oC3zQllNCnSyqKNPY+3zBVLgrLz3e8kjiDvli6mdbddW+iakeg8MrfuCcGoynH3tItTWXENuKkpUA3oLeXOT7X6GsucEELUFJHHchn0UAS9lZvT5TxIHn7gAZB6P3VqIo3+fVd6Jt+sUXJLE86N2Gx3OnIUsyEXXLJwODvvce2LLW8sMr+mArTrbrbgNGv8ZSVq7Q6yqRysDAF4yZ9kdGQ== 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=tRsBswEfEkoNkuoHJS3LdEgYnGukhlpEJULktQo+Sz4=; b=XuCANCAprjZ+0tlYjYFVUnkwPI8wJ56ErQJNHY7ckhAUlSQU2V5vNmpZY/upl2YsteHJD7b9ikBzlapBAW+Hj6ttaJIldGQj/I4tb1QcvoCAitO97Q5XYAfTlO1h+QdrG3azw605ZYhuwvIwg9kaMnzskZNx9dOGohDslBqfY9I= Received: from BYAPR11MB2549.namprd11.prod.outlook.com (2603:10b6:a02:c4::33) by BYAPR11MB2647.namprd11.prod.outlook.com (2603:10b6:a02:be::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.21; Thu, 15 Oct 2020 10:54:06 +0000 Received: from BYAPR11MB2549.namprd11.prod.outlook.com ([fe80::2cd2:d609:5fb7:4d27]) by BYAPR11MB2549.namprd11.prod.outlook.com ([fe80::2cd2:d609:5fb7:4d27%5]) with mapi id 15.20.3455.027; Thu, 15 Oct 2020 10:54:06 +0000 From: "Bernie Volz (volz)" To: Jen Linkova CC: "ianfarrer@gmx.com" , Michael Richardson , dhcwg , 6man , "v6ops list" Thread-Topic: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AQHWoWMb7h/SuZNgk0iBKtkQ2d57eamVg+CAgAJkrICAAJevlw== Date: Thu, 15 Oct 2020 10:54:06 +0000 Message-ID: <6F3C1913-D1DB-425E-8055-CFA9F98926A4@cisco.com> References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <19432.1602258078@localhost> <644565BC-5818-4244-A34A-1B39C3FC9175@gmx.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmx.com; dkim=none (message not signed) header.d=none;gmx.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [24.233.121.124] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 08e90c98-dcf6-4e2c-6cd6-08d870f8a360 x-ms-traffictypediagnostic: BYAPR11MB2647: 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: EB/H77akT/SCnNrbQ1DU9xPFq+uqjC1r+1kRhJYkG/D4qy4WoQlrQLhYm8nNzVvYQu/2vlJU6yOnCofN4FtyNeTmRJEx9WRTVr+cgi/9TdKHV+7H3nHLSbd3PsbEB0hNqU1I+iakfZwKEHEYQ6giAw4Em3GZXlToHnFNRHCYvp1fMfTmVHSMWLsFWKR5U5Y2D6W2bNMJbXun5xmEVEelhzhMuvjxFiM9ZZ+IB0K/Wnw38T7XbyhFpxWdJz5YYEM9ZfZ9EA84rs1YecXSEJCASkKP9/Jfy0OJvljqPK6VU5gHAr4nwyezZkq1JH2YKmGkmxIGRErfHOQJcx7pFon23oaRkcwsMk6zA00+pIfxhCMAE85tw2sSUqWkhNNL80tq36f0mxel6A5yeTzZid+jaPapF6ZZbIs/K4jVhuGQQTYPg+jRuFCmFJOOkajKvutGbj9womxPyvwR5+uRl4oMlQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2549.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(366004)(136003)(346002)(376002)(396003)(53546011)(26005)(36756003)(186003)(71200400001)(316002)(5660300002)(76116006)(66476007)(66446008)(66556008)(66946007)(6512007)(91956017)(2616005)(2906002)(64756008)(54906003)(86362001)(8936002)(478600001)(6486002)(966005)(4326008)(6916009)(6506007)(66574015)(83380400001)(33656002)(83080400001)(8676002)(518174003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: AbeWl3Toi+w0ljB5DEeGq6FD9aFTyQIZuXF3K6ydTdLcE+e425vMGUDWW/Ge8l3CCnCu0dSEAfxxEJ8mvWGMqlLnnvjvoD18Ww/CULYU3zg1lTUgKfhuRAFUIGymDKGJhwDxW954xutuOe8+qQhB6CRpJ4o8mf9TuXovfnZkUlIjRLVEJQ1xzzEtlnYA1tdh11Pdx6paeCRr28RYqXkiZQQOdd4UUzejGKC2jn7HFU9t8LrdKw/lVi9b0GxEECQN7SnI6LrCDIuwmpakKstRMo6cUTGB7hEaIdfze8p9XHSEPukll/fVPAID1lwku2MzXzc7VkiXDKJxSlgdq3G4MWi+FIiax0WN7pvZlzy7/DnxiwBqvxWZ37XdNK6bRNCYbkrV7M4DjtPGFPr771M1LbDa076bgjr6p2lrani4GIbebp92cdxpc3e1Eu/xv5fG3vp238SOpALzkc+rVYECy3X0c0gbhU+6O90NbaErPhNXMCcnXdpUcaCVgaIUMXWAvAEiK/qxSWU/Cx1XIly2+Ih0PVeLS0mpnxtV8tzPnqeEBGG4JWmnSp3ewnmFuwHkUVMRElLfWeCrKPbQQtZIIaAM/T1xq9Eaw03NTlmpe5zrRP4Nkt2aWyjzVRy8ynKyeW/wmWO23Y6h1y/gvxcz6w== 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: BYAPR11MB2549.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 08e90c98-dcf6-4e2c-6cd6-08d870f8a360 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2020 10:54:06.6282 (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: x1A9YzPytDRQAFxT4RxE5a777VMPTUItNi0/9Z+YSujySGKSOus7Is35HZgQsQ37 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2647 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [v6ops] [dhcwg] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Thu, 15 Oct 2020 10:54:14 -0000 QWdyZWVkIC4uLiBJIGhhZCB1c2VkIEZpZ3VyZSAxIGJ1dCB0aGF0IGlzbuKAmXQgdGhhdCB1c2Vm dWwg4oCUIHRoYXQgcGFja2V0IGlzIGZsb3dpbmcgaW4gdGhlIHVwbGluayBkaXJlY3Rpb24uIFBl cmhhcHMgd2Ugc2hvdWxkIGp1c3Qgc2F5IOKAnERIQ1AtUEQgY2xpZW50IGZhY2luZyBpbnRlcmZh Y2XigJ0/DQoNCi0gQmVybmllDQoNCj4gT24gT2N0IDE0LCAyMDIwLCBhdCA5OjUxIFBNLCBKZW4g TGlua292YSA8ZnVycnkxM0BnbWFpbC5jb20+IHdyb3RlOg0KPiANCj4g77u/T24gV2VkLCBPY3Qg MTQsIDIwMjAgYXQgMTI6NDQgQU0gQmVybmllIFZvbHogKHZvbHopIDx2b2x6QGNpc2NvLmNvbT4g d3JvdGU6DQo+PiBJZiBub3QsIHBlcmhhcHMgd2UganVzdCBzYXk6DQo+PiANCj4+IFItNA0KPj4g VG8gcHJldmVudCByb3V0aW5nIGxvb3BzLCB0aGUgcmVsYXkgU0hPVUxEIGltcGxlbWVudCBhIGNv bmZpZ3VyYWJsZSBwb2xpY3kgdG8gZHJvcCB0cmFmZmljIHJlY2VpdmVkIGZyb20gYW4gdXBsaW5r IGludGVyZmFjZSBhcyBmb2xsb3dzOg0KPiANCj4gSSdtIG5vdCBzdXJlICdmcm9tIGFuIHVwbGlu ayBpbnRlcmZhY2UnIG1ha2VzIHNlbnNlLiBJbiB0aGUgY2FzZSBvZiBhDQo+IHJvdXRpbmcgbG9v cCBjYXVzZWQgYnkgYW4gYW1uZXNpYWMgREhDUC1QRCBjbGllbnQgaXQgd291bGQgYmUgYQ0KPiBk b3duc3RyZWFtIGludGVyZmFjZS4NCj4gVGhlIHNjZW5hcmlvIHdoZW4gc3VjaCB0cmFmZmljIGFy cml2ZXMgZnJvbSBhbiB1cGxpbmsgaW50ZXJmYWNlIGlzDQo+ICd0aGUgdXBsaW5rIHJvdXRlciBi ZWxpZXZlcyB0aGUgcHJlZml4IGlzIGRlbGVnYXRlZCB0byB0aGUgY2xpZW50IGJ1dA0KPiB0aGUg cmVsYXkgZG9lcyBub3QgaGF2ZSBhIHJvdXRlIHBvaW50aW5nIHRvIHRoZSBjbGllbnQgc28gaXQg c2VuZHMNCj4gdHJhZmZpYyBiYWNrJyAtIHNvIG1vcmUgbGlrZWx5ICdhbiBhbW5lc2lhYyByZWxh eScgY2FzZS4NCj4gDQo+PiBGb3IgcG9pbnQtdG8tcG9pbnQgbGlua3MsIHdoZW4gdGhlIHBhY2tl dCdzIGluZ3Jlc3MgYW5kIGVncmVzcyBpbnRlcmZhY2VzIG1hdGNoLiBGb3IgbXVsdGktYWNjZXNz IGxpbmtzLCB3aGVuIHRoZSBwYWNrZXQncyBpbmdyZXNzIGFuZCBlZ3Jlc3MgaW50ZXJmYWNlIG1h dGNoLCBhbmQgdGhlIHNvdXJjZSBNQUMgYW5kIG5leHQtaG9wIE1BQyBhZGRyZXNzZXMgbWF0Y2gu IEFuIElDTVB2NiBUeXBlIDEsIENvZGUgNiAoRGVzdGluYXRpb24gVW5yZWFjaGFibGUsIHJlamVj dCByb3V0ZSB0bw0KPj4gZGVzdGluYXRpb24pIGVycm9yIG1lc3NhZ2UgTUFZIGJlIHNlbnQgYXMg cGVyIFtSRkM0NDQzXSwgc2VjdGlvbiAzLjEuICBUaGUgSUNNUCBwb2xpY3kgU0hPVUxEIGJlIGNv bmZpZ3VyYWJsZS4NCj4+IA0KPj4gLSBCZXJuaWUNCj4+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+IEZyb206IGlhbmZhcnJlckBnbXguY29tIDxpYW5mYXJyZXJAZ214LmNvbT4N Cj4+IFNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMTMsIDIwMjAgOToxNiBBTQ0KPj4gVG86IE1pY2hh ZWwgUmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPjsgSmVuIExpbmtvdmEgPGZ1cnJ5 MTNAZ21haWwuY29tPg0KPj4gQ2M6IEJlcm5pZSBWb2x6ICh2b2x6KSA8dm9sekBjaXNjby5jb20+ OyBkaGN3ZyA8ZGhjd2dAaWV0Zi5vcmc+OyA2bWFuIDxpcHY2QGlldGYub3JnPjsgdjZvcHMgbGlz dCA8djZvcHNAaWV0Zi5vcmc+DQo+PiBTdWJqZWN0OiBSZTogW2RoY3dnXSBbdjZvcHNdIFtFWFRF Uk5BTF0gUmU6IFF1ZXN0aW9uIHRvIERIQ1B2NiBSZWxheSBJbXBsZW1lbnRvcnMgcmVnYXJkaW5n IGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1wZC1yZWxheS1yZXF1aXJlbWVudHMNCj4+IA0KPj4gSGks DQo+PiANCj4+IFRoYW5rcyBmb3IgYWxsIG9mIHRoZSBkaXNjdXNzaW9uIG9uIHRoaXMuIFdl4oCZ dmUgcmV3b3JrZWQgdGhlIHJlcXVpcmVtZW50IGFzIGZvbGxvd3M6DQo+PiANCj4+IFItNA0KPj4g VG8gcHJldmVudCByb3V0aW5nIGxvb3BzLCB0aGUgcmVsYXkgU0hPVUxEIGltcGxlbWVudCBhIGNv bmZpZ3VyYWJsZSBwb2xpY3kgdG8gZHJvcCBjbGllbnQgdHJhZmZpYyBhcyBmb2xsb3dzOiAgRm9y IHBvaW50LXRvLXBvaW50IGxpbmtzLCB3aGVuIHRoZSBwYWNrZXQncyBpbmdyZXNzIGFuZCBlZ3Jl c3MgaW50ZXJmYWNlcyBtYXRjaC4gRm9yIG11bHRpLWFjY2VzcyBsaW5rcywgd2hlbiB0aGUgcGFj a2V0J3MgaW5ncmVzcyBhbmQgZWdyZXNzIGludGVyZmFjZSBtYXRjaCwgYW5kIHRoZSBzb3VyY2Ug TUFDIGFuZCBuZXh0LWhvcCBNQUMgYWRkcmVzc2VzIG1hdGNoLiBBbiBJQ01QdjYgVHlwZSAxLCBD b2RlIDYgKERlc3RpbmF0aW9uIFVucmVhY2hhYmxlLCByZWplY3Qgcm91dGUgdG8NCj4+IGRlc3Rp bmF0aW9uKSBlcnJvciBtZXNzYWdlIE1BWSBiZSBzZW50IGJhY2sgdG8gdGhlIGNsaWVudC4gIFRo ZSBJQ01QIHBvbGljeSBTSE9VTEQgYmUgY29uZmlndXJhYmxlLg0KPj4gDQo+PiBUaGFua3MsDQo+ PiBJYW4NCj4+IA0KPj4+PiBPbiA5LiBPY3QgMjAyMCwgYXQgMTc6NDEsIE1pY2hhZWwgUmljaGFy ZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPiB3cm90ZToNCj4+PiANCj4+PiANCj4+PiBKZW4g TGlua292YSA8ZnVycnkxM0BnbWFpbC5jb20+IHdyb3RlOg0KPj4+PiBJIHRoaW5rIHRoZXJlIGlz IGNvbmZ1c2lvbiByZTogdGhlIHNjZW5hcmlvIHdlIGFyZSB0YWxraW5nIGFib3V0Lg0KPj4+PiBJ J3ZlIGF0dGFjaGVkIHRoZSBkaWFncmFtIGZvciB0aGUgY2FzZSB3aGljaCBjb25jZXJucyBtZS4N Cj4+Pj4gU286DQo+Pj4+IC0gVGhlIFJlbGF5IFIgaGFzIGFuIGludGVyZmFjZSBldGgwIGNvbm5l Y3RlZCB0byBhIHN3aXRjaCBTLg0KPj4+PiAtIERldmljZXMgQSBhbmQgQiBhcmUgY29ubmVjdGVk IHRvIHRoZSBzYW1lIHN3aXRjaCBhbmQgdXNpbmcgUiBhcyBhDQo+Pj4+IGRlZmF1bHQgZ2F0ZXdh eS4NCj4+Pj4gLSBUaGUgcHJlZml4IDIwMDE6ZGI4OjovNTYgd2FzIGRlbGVnYXRlZCB0byBhIGNs aWVudCBBIHZpYSB0aGUgcmVsYXkgUi4NCj4+PiANCj4+PiBhIGZyaWVuZGx5IGFtZW5kbWVudCB0 byB5b3VyIGV4YW1wbGUgdG8gYWlkIGluIGh1bWFuIGNvbXByZWhlbnNpb246DQo+Pj4gICAgfSAt IFRoZSBwcmVmaXggMjAwMTpkYjg6MDAwMDowMTIzOi82NCB3YXMgZGVsZWdhdGVkIHRvIGEgY2xp ZW50IEEgdmlhIHRoZSByZWxheSBSLg0KPj4+ICAgIH0gIC0gUiBpbnN0YWxscyBhIHJvdXRlIGZv ciAyMDAxOmRiODowMDAwOjAxMjM6LzY0IHRvd2FyZHMgQSB2aWEgZXRoMC4NCj4+PiANCj4+Pj4g LSBUaGUgZGV2aWNlIEIgKHdoaWNoIGhhcyBhbiBhZGRyZXNzIE5PVCBmcm9tIHRoZSBkZWxlZ2F0 ZWQgcHJlZml4LA0KPj4+PiBidXQgZnJvbSBhbm90aGVyIC82NCBhc3NpZ25lZCB0byB0aGF0IGNv bW1vbiBsaW5rLCBsZXQncyBzYXQNCj4+Pj4gMjAwMTpkYjg6Y2FmZTo6LzY0KSBzZW5kcyBhIHBh Y2tldCB0byBhbiBhZGRyZXNzIGZyb20gdGhlIGRlbGVnYXRlZA0KPj4+IA0KPj4+IG5vdywgbXkg YnJhaW4gY2FuIG1vcmUgY2xlYXJseSBzZWUgdGhhdCAyMDAxOmRiODpjYWZlOjovNjQgaXMgbm90 DQo+Pj4gd2l0aGluIDIwMDE6ZGI4OjAwMDA6MDEyMzovNjQsIHdoaWxlIEkgaGFkIHRvIHVzZSBh IGZldyBleHRyYSBicmFpbg0KPj4+IGNlbGxzIHRvIHNlZSB0aGF0IGl0IHdhc24ndCBpbiB0aGF0 IDo6LzU2IDotKQ0KPj4+IA0KPj4+PiBXaGF0IEknZCBleHBlY3QgdG8gaGFwcGVuICh3aXRoIERI Q1AtUEQgb3Igd2l0aG91dCAtIGUuZy4gaWYgUiBoYXMgYQ0KPj4+PiBzdGF0aWMgcm91dGUgdG93 YXJkcyBBLCBub3QgYSBkeW5hbWljIHJvdXRlIHByb2R1Y2VkIGJ5IFBEKToNCj4+Pj4gLSB0aGUg cGFja2V0IGlzIHNlbnQgdG8gQS4gV2VsbCwgaWYgQSBkb2VzIG5vdCBoYXZlIGEgcm91dGUgdG8N Cj4+Pj4gMjAwMTpkYjg6OjQyIHRoZW4gaW5kZWVkIGEgcm91dGluZyBsb29wIG1pZ2h0IGhhcHBl bi4gQnV0IGlmIEEgZG9lcw0KPj4+PiBoYXZlIGEgcm91dGUsIHRoZSBwYWNrZXQgd2lsbCBiZSBk ZWxpdmVyZWQuDQo+Pj4gDQo+Pj4+IFdoYXQgc2VlbXMgdG8gYmUgcmVxdWlyZWQgYnkgUjQ6DQo+ Pj4+IC0gUiBkZXRlY3RzIHRoYXQgdGhlIHBhY2tldCBpcyByZWNlaXZlZCB2aWEgZXRoMCBhbmQg bmVlZHMgdG8gYmUgc2VudA0KPj4+PiBiYWNrIHRvIGV0aDAuIFI0IHNlZW1zIHRvIHJlcXVpcmUg c3VjaCBwYWNrZXRzIHRvIGJlIGRyb3BwZWQuDQo+Pj4+IFNvIGlmIEIgd291bGQgbmV2ZXIgYmUg YWJsZSB0byBjb21tdW5pY2F0ZSB0byBhbnkgYWRkcmVzcyBpbiB0aGUNCj4+Pj4gZGVsZWdhdGVk IHByZWZpeCwgcmlnaHQ/DQo+Pj4gDQo+Pj4+IEFtIEkgbWlzc2luZyBhbnl0aGluZz8NCj4+PiAN Cj4+PiBJIHRoaW5rIHRoYXQgeW91IGdvdCBpdCByaWdodC4NCj4+PiANCj4+Pj4+IFBlcmhhcHMg dGhlIG1pc3NpbmcgcGllY2Ugb2YgdGhlIHJ1bGUgaXMgZG9u4oCZdCBzZW5kIGl0IGJhY2sgdG8g d2hlcmUgaXQgY2FtZSBmcm9tLCBiYXNlZCBvbiBsaW5rIGxheWVyIGFkZHJlc3NlcyAob3IgbGlu ayBpZiBwb2ludC10by1wb2ludCkuDQo+Pj4gDQo+Pj4+IFllcy4gSWYgUjQgd2FzIHNheWluZyAn ZHJvcCB0aGUgcGFja2V0IGlmIGl0IGNvbWVzIGZyb20gdGhlIHNhbWUNCj4+Pj4gbGluay1sYXll ciBhZGRyZXNzIHlvdSBhcmUgZ29pbmcgdG8gc2VuZCBpdCBiYWNrJyAtIGl0IHdvdWxkIG1ha2UN Cj4+Pj4gdG90YWwgc2Vuc2UuIEJ1dCBJIGRvbid0IHRoaW5rIHJvdXRlcnMgZG8gKnRoYXQqLg0K Pj4+IA0KPj4+IFllcywgaWYgd2UgbWFkZSB0aGUgY2hlY2sgb24gTDIgYWRkcmVzcywgdGhlbiBp dCB3b3VsZCB3b3JrLg0KPj4+IEFuZCBJIGFncmVlIHRoYXQgcm91dGVycyBhcmUgZXhhY3RseSBk b2luZyB0aGF0Lg0KPj4+IA0KPj4+IEkgdGhpbmsgdGhhdCBpdCBhbHNvIHdvcmtzIGlmIEIgaXMg YSByb3V0ZXIgd2l0aCBhZGRpdGlvbmFsIGludGVyZmFjZXMNCj4+PiBkb3duc3RyZWFtLCB1bmxl c3MgdGhlcmUgYXJlIG11bHRpcGxlIHBhdGhzLg0KPj4+IA0KPj4+IC0tDQo+Pj4gTWljaGFlbCBS aWNoYXJkc29uIDxtY3IrSUVURkBzYW5kZWxtYW4uY2E+ICAgLiBvIE8gKCBJUHY2IEnDuFQgY29u c3VsdGluZyApDQo+Pj4gICAgICAgICAgU2FuZGVsbWFuIFNvZnR3YXJlIFdvcmtzIEluYywgT3R0 YXdhIGFuZCBXb3JsZHdpZGUNCj4+PiANCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+IElFVEYgSVB2NiB3 b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPj4+IGlwdjZAaWV0Zi5vcmcNCj4+PiBBZG1pbmlz dHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p cHY2DQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IA0KPiANCj4gDQo+IC0tIA0KPiBTWSwgSmVuIExpbmtv dmEgYWthIEZ1cnJ5DQo= From nobody Thu Oct 15 07:32: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 2C8A53A0115; Thu, 15 Oct 2020 07:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 1CwF2ndl93xq; Thu, 15 Oct 2020 07:31:58 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 64C7E3A0112; Thu, 15 Oct 2020 07:31:58 -0700 (PDT) Received: from lhreml747-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 5E93354C70053E55DFF5; Thu, 15 Oct 2020 15:31:56 +0100 (IST) Received: from fraeml713-chm.china.huawei.com (10.206.15.32) by lhreml747-chm.china.huawei.com (10.201.108.197) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 15 Oct 2020 15:31:55 +0100 Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml713-chm.china.huawei.com (10.206.15.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 15 Oct 2020 16:31:55 +0200 Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.1913.007; Thu, 15 Oct 2020 16:31:55 +0200 From: Giuseppe Fioccola To: "v6ops@ietf.org" CC: "v6ops-chairs@ietf.org" , "draft-vf-v6ops-ipv6-deployment@ietf.org" Thread-Topic: New Version Notification for draft-vf-v6ops-ipv6-deployment-00.txt Thread-Index: AQHWovdnldXGZSP3DkOI6d1DuX9RaamYqeYw Date: Thu, 15 Oct 2020 14:31:55 +0000 Message-ID: <19408462e0bf4f0a8776820bef8d9130@huawei.com> References: <160276863269.12225.15313625467391617602@ietfa.amsl.com> In-Reply-To: <160276863269.12225.15313625467391617602@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.48.208.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [v6ops] FW: New Version Notification for draft-vf-v6ops-ipv6-deployment-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, 15 Oct 2020 14:32:00 -0000 RGVhciBBbGwsDQpXZSBoYXZlIGp1c3QgcG9zdGVkIGEgbmV3IGluZm9ybWF0aW9uYWwgZHJhZnQg b24gSVB2NiBkZXBsb3ltZW50LiBUaGlzIGRvY3VtZW50IGFpbXMgdG8gcHJvdmlkZSB0aGUgZ2xv YmFsIHBpY3R1cmUgb2YgSVB2NiB0byBzaG93IGhvdyBJUHY2IGlzIGdyb3dpbmcgYW5kIGFsc28g YW4gb3ZlcnZpZXcgb2YgSVB2NiB0cmFuc2l0aW9uIGRlcGxveW1lbnQgc3RhdHVzLiBJbmRlZWQs IGl0IGlzIHJlcG9ydGVkIGEgc3VydmV5IG9mIHRoZSBkZXBsb3llZCBJUHY2IHRyYW5zaXRpb24g dGVjaG5vbG9naWVzLiBUaGUgZG9jdW1lbnQgYWxzbyBhaW1zIHRvIGFuYWx5emUgdGhlIGNoYWxs ZW5nZXMgYW5kIHRoZXJlZm9yZSBlbmNvdXJhZ2UgYWN0aW9ucyBhbmQgbW9yZSBpbnZlc3RpZ2F0 aW9ucyBvbiBzb21lIGFyZWFzIHRoYXQgYXJlIHN0aWxsIHVuZGVyIGRpc2N1c3Npb24uDQoNCkZv ciB0aG9zZSBpbnRlcmVzdGVkIHRvIGNvbGxhYm9yYXRlIG9uIHRoaXMgdG9waWMsIHdlIGFyZSBv cGVuIHRvIGRpc2N1c3MgYW5kIHdvcmsgdG9nZXRoZXIgdG8gaW1wcm92ZSB0aGUgZG9jdW1lbnQu DQoNCllvdXIgaW5wdXRzIGFuZCBjb21tZW50cyBhcmUgd2VsY29tZS4NCg0KQmVzdCBSZWdhcmRz LA0KDQpHaXVzZXBwZSBhbmQgUGFvbG8NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZ10gDQpTZW50OiBUaHVyc2RheSwgT2N0b2JlciAxNSwgMjAyMCAzOjMxIFBNDQpUbzogUGFv bG8gVm9scGF0byA8cGFvbG8udm9scGF0b0BodWF3ZWkuY29tPjsgR2l1c2VwcGUgRmlvY2NvbGEg PGdpdXNlcHBlLmZpb2Njb2xhQGh1YXdlaS5jb20+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yIGRyYWZ0LXZmLXY2b3BzLWlwdjYtZGVwbG95bWVudC0wMC50eHQNCg0KDQpB IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtdmYtdjZvcHMtaXB2Ni1kZXBsb3ltZW50LTAwLnR4 dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBHaXVzZXBwZSBGaW9jY29sYSBh bmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC12Zi12Nm9w cy1pcHY2LWRlcGxveW1lbnQNClJldmlzaW9uOgkwMA0KVGl0bGU6CQlJUHY2IFRyYW5zaXRpb24g RGVwbG95bWVudCBTdGF0dXMNCkRvY3VtZW50IGRhdGU6CTIwMjAtMTAtMTUNCkdyb3VwOgkJSW5k aXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTI0DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC12Zi12Nm9wcy1pcHY2LWRlcGxveW1lbnQtMDAu dHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtdmYtdjZvcHMtaXB2Ni1kZXBsb3ltZW50Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtdmYtdjZvcHMtaXB2Ni1kZXBsb3ltZW50 DQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXZmLXY2 b3BzLWlwdjYtZGVwbG95bWVudC0wMA0KDQoNCkFic3RyYWN0Og0KICAgTG9va2luZyBnbG9iYWxs eSwgSVB2NiBpcyBncm93aW5nIGZhc3RlciB0aGFuIElQdjQgYW5kIHRoaXMgbWVhbnMNCiAgIHRo YXQgdGhlIGNvbGxlY3RpdmUgd2lzZG9tIG9mIHRoZSBuZXR3b3JraW5nIGluZHVzdHJ5IGhhcyBz ZWxlY3RlZA0KICAgSVB2NiBmb3IgdGhlIGZ1dHVyZS4gIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMg YW4gb3ZlcnZpZXcgb2YgSVB2Ng0KICAgdHJhbnNpdGlvbiBkZXBsb3ltZW50IHN0YXR1cyBhbmQg YSB2aWV3IG9uIGhvdyB0aGUgdHJhbnNpdGlvbiB0byBJUHY2DQogICBpcyBwcm9ncmVzc2luZyBh bW9uZyBuZXR3b3JrIG9wZXJhdG9ycyB0aGF0IGFyZSBpbnRyb2R1Y2luZyBJUHY2IG9yDQogICBo YXZlIGFscmVhZHkgYWRvcHRlZCBhbiBJUHY2LW9ubHkgc29sdXRpb24uICBJdCBhbHNvIGFpbXMg dG8gYW5hbHl6ZQ0KICAgdGhlIHRyYW5zaXRpb24gY2hhbGxlbmdlcyBhbmQgdGhlcmVmb3JlIGVu Y291cmFnZSBhY3Rpb25zIGFuZCBtb3JlDQogICBpbnZlc3RpZ2F0aW9ucyBvbiBzb21lIGFyZWFz IHRoYXQgYXJlIHN0aWxsIHVuZGVyIGRpc2N1c3Npb24uICBUaGUNCiAgIG92ZXJhbGwgSVB2NiBp bmNlbnRpdmVzIGFyZSBhbHNvIGV4YW1pbmVkLg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3Jl dGFyaWF0DQoNCg0K From nobody Thu Oct 15 07:43: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 4904B3A0128; Thu, 15 Oct 2020 07:43:07 -0700 (PDT) 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, RCVD_IN_MSPIKE_H2=-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=boeing.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 d5ESvrIN4BJP; Thu, 15 Oct 2020 07:43:05 -0700 (PDT) Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 1AF103A0121; Thu, 15 Oct 2020 07:43:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09FEgumb002233; Thu, 15 Oct 2020 10:43:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602772982; bh=zekX303lfQ3Ivzcd80Oz4ndxJNvvW9qT/14lebJJCUU=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=oLqHaGvX+DvxciNAxWL0QDmDoxPA8TeMGnT2/xew6KReJt4ld+ZMMzfCyRegNDI6g VUKbHyglJ8P6M+7Jk7GR51SJTkqsQHKRXxhYtAVtVQHPIgJ0ck/KtfRSLlP9erUVf+ 0EsvAL3Vunfct1Ac3+ravylsmjrHOR7LXzkcZdrcxNRr6fuQOZUUfbwfoin6h1Ju1+ tvvhj5gAE8Ii8+RWLyc3w7HjbV0iP/5AYMiRZYqn2czF+uBSLmmipZV/GxEHOn4nWv qrgIsq1yXEjTXDvdBUL6iSAqXTxOcBf8BaihZ5SLJpEd4qJmp8l697rLb7x8Iea2Z8 BOOXzeQe2WreQ== Received: from XCH16-07-12.nos.boeing.com (xch16-07-12.nos.boeing.com [144.115.66.114]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09FEgfVq032049 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 15 Oct 2020 10:42:41 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-12.nos.boeing.com (144.115.66.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Thu, 15 Oct 2020 07:42:39 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Thu, 15 Oct 2020 07:42:39 -0700 From: "Templin (US), Fred L" To: Michael Richardson CC: "ianfarrer@gmx.com" , Jen Linkova , dhcwg , v6ops list , 6man Thread-Topic: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AdahZz7s2M1crQrvQoqZsITGBawESAAViWEAAA15P3AAKNIcgAAOSRqA///kqwD//4Ka8A== Date: Thu, 15 Oct 2020 14:42:39 +0000 Message-ID: References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> <10487.1602608586@localhost> <378d3420690246bbae253fb15be8c9a7@boeing.com> <19627.1602701863@localhost> <1b34b9bec59e4a00af8b9d8f182d23ff@boeing.com> <8825.1602720536@localhost> In-Reply-To: <8825.1602720536@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 9CFDDA4DAC7120B723AF42250F397BC576FEFA5C523F949D8F93BB241081D4F42000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [EXTERNAL] Re: [dhcwg] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Thu, 15 Oct 2020 14:43:08 -0000 TWljaGFlbCwNCg0KSSB3b3VsZCByZWNvbW1lbmQgdGFraW5nIGEgcXVpY2sgZ2xhbmNlIHRocm91 Z2ggUkZDNDM4OSwgd2hlcmUgeW91IHdpbGwgc2VlDQp0aGF0IHRoZSBvbmx5IEwzIGluZm9ybWF0 aW9uIGtub3duIHRvIHRoZSBORCBwcm94eSBpcyB0aGF0IHdoaWNoIGlzIGVzdGFibGlzaGVkDQpp biBuZWlnaGJvciBjYWNoZSBlbnRyaWVzIGZvciB0aGUgSVB2NiBhZGRyZXNzZXMgb24gZWl0aGVy IHNpZGUgb2YgdGhlIHByb3h5Ow0KZXZlcnl0aGluZyBlbHNlIGlzIEwyIGluZm9ybWF0aW9uLiBU aGVyZSBpcyBubyBuZWVkIGZvciB0aGUgcHJveHkgdG8gImxlYXJuIiB0aGUNCmRlbGVnYXRlZCBw cmVmaXhlcywgc28gaXQgZG9lcyBub3QgaGF2ZSB0byBzbm9vcCBhbmQgcGFyc2UgREhDUHY2LVBE DQptZXNzYWdlcy4gQnV0LCBhIHJldmVsYXRpb24gY2FtZSB0byBtZSB0aGF0IHBlcmhhcHMgdGhl IHByb3h5IGNhbiBtYWtlIHRoZQ0Kc291cmNlIEwyIGFkZHJlc3Mgb2YgQSBsb29rIGRpZmZlcmVu dCB0aGFuIHRoZSBzb3VyY2UgTDIgYWRkcmVzc2VzIG9mIEIsIEMsIEQsDQpldGMuIGZyb20gdGhl IHZpZXdwb2ludCBvZiBSLiBUaGF0IGlzIHdoYXQgTkFUcyBkbywgYW5kIEkgdGhpbmsgaXQgY2Fu IGJlIGRvbmUNCmhlcmUgdG9vLiBUaGF0IHdheSwgUiB3b3VsZCBoYXZlIGVub3VnaCBpbmZvcm1h dGlvbiBzbyBhcyB0byBhdm9pZCBibG9ja2luZw0KbGVnaXRpbWF0ZSB0cmFmZmljLg0KDQpUaGFu a3MgLSBGcmVkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWljaGFl bCBSaWNoYXJkc29uIFttYWlsdG86bWNyK2lldGZAc2FuZGVsbWFuLmNhXQ0KPiBTZW50OiBXZWRu ZXNkYXksIE9jdG9iZXIgMTQsIDIwMjAgNTowOSBQTQ0KPiBUbzogVGVtcGxpbiAoVVMpLCBGcmVk IEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+DQo+IENjOiBpYW5mYXJyZXJAZ214LmNvbTsg SmVuIExpbmtvdmEgPGZ1cnJ5MTNAZ21haWwuY29tPjsgZGhjd2cgPGRoY3dnQGlldGYub3JnPjsg djZvcHMgbGlzdCA8djZvcHNAaWV0Zi5vcmc+OyA2bWFuDQo+IDxpcHY2QGlldGYub3JnPg0KPiBT dWJqZWN0OiBSZTogW0VYVEVSTkFMXSBSZTogW2RoY3dnXSBbdjZvcHNdIFJlOiBRdWVzdGlvbiB0 byBESENQdjYgUmVsYXkgSW1wbGVtZW50b3JzIHJlZ2FyZGluZyBkcmFmdC1pZXRmLWRoYy1kaGNw djYtcGQtcmVsYXktDQo+IHJlcXVpcmVtZW50cw0KPiANCj4gDQo+IFRlbXBsaW4gKFVTKSwgRnJl ZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPiB3cm90ZToNCj4gICAgID4+IENhbiB5b3Ug ZXhwbGFpbiBob3cgc3VjaCBhIGRldmljZSB3b3VsZCBub3JtYWxseSB3b3JrIGZvciBhIGNsaWVu dCBkZXZpY2UNCj4gICAgID4+IEEsQixDLEQgZG9pbmcgREhDUHY2LVBEIHRocm91Z2ggaXQ/DQo+ IA0KPiAgICAgPiBTdXJlLiBBIHNlbmRzIGEgREhDUHY2IFNvbGljaXQgdXNpbmcgaXRzIElQdjYg bGluay1sb2NhbCBhZGRyZXNzIGFzIHRoZSBzb3VyY2UsDQo+ICAgICA+IGFuZCBpdHMgTDIgYWRk cmVzcyBhcyB0aGUgbGluay1sYXllciBzb3VyY2UuIFRoZSBwcm94eSBjb252ZXJ0cyB0aGUgbGlu ay1sYXllcg0KPiAgICAgPiBzb3VyY2UgdG8gaXRzIG93biBMMiBhZGRyZXNzIHdoZW4gZm9yd2Fy ZGluZyB0aGUgREhDUHY2IHNvbGljaXQgb250byB0aGUNCj4gICAgID4gdXBzdHJlYW0gbGluay4g V2hlbiB0aGUgREhDUHY2IFJlcGx5IGNvbWVzIGJhY2ssIHRoZSBJUHY2IGRlc3RpbmF0aW9uIGlz DQo+ICAgICA+IHRoYXQgb2YgY2xpZW50IEEsIGJ1dCB0aGUgbGluay1sYXllciBkZXN0aW5hdGlv biBpcyB0aGUgTDIgYWRkcmVzcyBvZiB0aGUgcHJveHkuDQo+ICAgICA+IFRoZSBwcm94eSB0aGVu IGNvbnZlcnRzIHRoZSBMMiBkZXN0aW5hdGlvbiB0byB0aGUgYWRkcmVzcyBvZiBjbGllbnQgQSBh bmQNCj4gICAgID4gZm9yd2FyZHMgaXQgb24gdG8gdGhlIGNsaWVudC4NCj4gDQo+IEJ1dCwgaG93 IGRvZXMgdGhlIHByb3h5IGtub3cgaG93IHRvIGZvcndhcmQgdGhlIHByZWZpeCB0aGF0IEEgZ2V0 cyBvbiB0byBBPw0KPiANCj4gVGhlIHJvdXRlciwgaGF2aW5nIHNlZW4gQSdzIEwyIGFkZHJlc3Mg b24gdGhlIERIQ1B2Ni1QRCwgYW5kL29yIGhhdmluZyBkb25lIGENCj4gTkQgb24gQSBhbmQgcmVj ZWl2aW5nIEwyJ3MgYWRkcmVzcywgd2lsbCBwdW50IHRoZSB0cmFmZmljIHRvIHRoZSBwcm94eS4N Cj4gV291bGRuJ3QgdGhlIHByb3h5IGhhdmUgdG8gb2JzZXJ2ZSB0aGUgREhDUHY2LVBEcyB0byBr bm93IHdoYXQgcHJlZml4ZXMgYXJlDQo+IGJlaW5nIGRlbGVnYXRlZD8NCj4gSSBkaWRuJ3QgdGhp bmsgdGhhdCB3YXMgYSB0aGluZy4gIEkgdGhpbmsgdGhhdCBpdCBqdXN0IGRvZXNuJ3Qgd29yay4N Cj4gDQo+IElmIGl0IGlzIGEgdGhpbmcsIHRoZW4gdGhlIFByb3h5IHdpbGwgaGF2ZSBhbiBMMyBy b3V0ZSBmb3IgdGhlIHByZWZpeCB0aGF0DQo+IHdhcyBkZWxlZ2F0ZWQgc28gdGhhdCBpdCBjYW4g Zm9yd2FyZCB0cmFmZmljIGZyb20gUiBvbiB0byBBLg0KPiANCj4gICAgID4+IEFuZCBpcyB0aGUg ZmFpbHVyZSBvbmUgd2hlcmUgdGhlIHJvdXRlciAiUiIgZmFpbHMgdG8gZHJvcCB0cmFmZmljIGl0 IHNob3VsZCwNCj4gICAgID4+IG9uZSB3aGVyZSB0aGUgcm91dGVyICJSIiBkcm9wcyB0cmFmZmlj IHRoYXQgaXQgc2hvdWxkbid0Pw0KPiANCj4gICAgID4gSSB3YXMgdGhpbmtpbmcgbW9yZSBhbG9u ZyB0aGUgbGluZXMgb2YgdGhlIGxhdHRlcjsgaWYgdGhlIG9ubHkgd2F5IHRoYXQgQSBoYXMNCj4g ICAgID4gZm9yIHRhbGtpbmcgdG8gQiwgQywgRCwgZXRjLiBpcyBieSBnb2luZyB0aHJvdWdoIFIs IGl0IHdvdWxkbid0IHdvcmsgaWYgUiB3YXMNCj4gICAgID4gdW5jb25kaXRpb25hbGx5IGRyb3Bw aW5nIGV2ZXJ5dGhpbmcuDQo+IA0KPiBJZiBBIGFuZCBCIGFyZSBiZWhpbmQgdGhlIHNhbWUgUHJv eHksIGFuZCBlYWNoIGhhcyBhIHByZWZpeCBkZWxlZ2F0ZWQgdG8gdGhlbSwgYW5kDQo+IHRoZXkg aGF2ZSB0byBnbyBhbGwgdGhlIHdheSB0byBSIHRvIGdldCB0cmFmZmljIGZvcndhcmRlZCBiZWNh dXNlIHRoZXkgc2VlDQo+IFIncyBSQXMsIG5vdCBvbmVzIHRoYXQgdGhlIFByb3h5IGhhcyBtYWRl IHVwLCB0aGVuIGluZGVlZCwgUiB3b3VsZCBzZWUgdGhlDQo+IFByb3h5J3MgTDIgYWRkcmVzcyBh cyBzcmMvZHN0LCBhbmQgaXQgc2hvdWxkIGRyb3AgdHJhZmZpYy4NCj4gDQo+IEJ1dCwgSSB3b3Vs ZCBjbGFpbSB0aGF0IHRoZSBQcm94eSBzaG91bGQgaGF2ZSBzZWVuIHRoZSB0cmFmZmljIHRvIFIs DQo+IGludGVyY2VwdGVkIGl0LCBhbmQgdXNlZCBpdCdzIHJvdXRpbmcgdGFibGUgdG8gZ2V0IHRo ZSBQcmVmaXgtQS9QcmVmaXgtQiB0cmFmZmljIHRvIEIuDQo+IA0KPiAtLQ0KPiBdICAgICAgICAg ICAgICAgTmV2ZXIgdGVsbCBtZSB0aGUgb2RkcyEgICAgICAgICAgICAgICAgIHwgaXB2NiBtZXNo IG5ldHdvcmtzIFsNCj4gXSAgIE1pY2hhZWwgUmljaGFyZHNvbiwgU2FuZGVsbWFuIFNvZnR3YXJl IFdvcmtzICAgICAgICB8ICAgIElvVCBhcmNoaXRlY3QgICBbDQo+IF0gICAgIG1jckBzYW5kZWxt YW4uY2EgIGh0dHA6Ly93d3cuc2FuZGVsbWFuLmNhLyAgICAgICAgfCAgIHJ1Ynkgb24gcmFpbHMg ICAgWw0KPiANCj4gDQo+IC0tDQo+IE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK0lFVEZAc2FuZGVs bWFuLmNhPiAgIC4gbyBPICggSVB2NiBJw7hUIGNvbnN1bHRpbmcgKQ0KPiAgICAgICAgICAgIFNh bmRlbG1hbiBTb2Z0d2FyZSBXb3JrcyBJbmMsIE90dGF3YSBhbmQgV29ybGR3aWRlDQo+IA0KPiAN Cj4gDQoNCg== From nobody Thu Oct 15 07:48: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 037C13A0147 for ; Thu, 15 Oct 2020 07:48:07 -0700 (PDT) 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=es.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 ABcD_BJLobG5 for ; Thu, 15 Oct 2020 07:48:05 -0700 (PDT) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1F893A0141 for ; Thu, 15 Oct 2020 07:48:04 -0700 (PDT) Received: by mail-il1-x130.google.com with SMTP id l16so4373817ilt.13 for ; Thu, 15 Oct 2020 07:48:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=es.net; s=esnet-google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=n+9Qk5zUjM35V58cfNNizRS2OjGFLC0KRnpdUl54Edk=; b=ihhpLoup3E/YACOvTsZCRa6SJNqFdab3R9xwvOLp7NPF/PE98LL/tdn4hKHGnnt+oJ j1dnLe3p0EUg1z/sc4C1bhZz31VoNrdqRpDk5Dl91kIphgjGVG3+5NOfA+iXkHxzcATZ iJnHruTAwC2lCtWCOLXcP572VPMGW6G+GbYvwxv0Wbb1VldSFMarh2/GZRdDEgxe56hG SIcsRtgGTzqlYfn+43pJ/PqZrD9YOYX7UYneyjAfbcPDyEg+3VrXShJiBWAu1rdeE79M LCCSrjWHnRAGqQ4faJSNPbjYNDglnSPHSiJ+bNsN9ntIwhKc/ZgabLpo0/t42FCxs7Af Kv4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=n+9Qk5zUjM35V58cfNNizRS2OjGFLC0KRnpdUl54Edk=; b=J+ouY2PKyQLNoJ+oOvDVcV0nXX/Di8xOtpm6hSL+lOR0vxHN1X0IlweRsc3G98ri0w vHuVB8uxjEqfOqZqFFws0NfZou8nVdXEbwM59Co7Ce0EBMiqYw3cI3NnyNJFyY5VHbJY SBrLxr9EHCxZ85HDsnQQzS0yV2zsxHD3Ww/G4zF3Dxolw/s4rFJUY6Ru3oWoTcs9kriO XRe3lSvrC/n6J5wZtkKafPHQPXfATetnlpsQ+t6Li6QfwearEPS+z7zpqwRlph4pefCK JFSo5QWi44vjBw9A6gKKyasSv+QJkwq+IoXZfRcxjx22BU4Zc697akCPl0pyT+fPgVtc ej7w== X-Gm-Message-State: AOAM532TRTovVewN9k4JlYALEq25WLQN6bPHwQEe7tVAmqYFcGoIBVUL RSWPsOzqYU0A05PXBtA1lp2DJHS3H7vK2NOHtyc53B0wuja6UqDCcFf2gddd3tXI4paw0F1XZ7Q DbcCWnVn0EqAIrd1szkMH9K4ogJ+ohDe8gLtcvOevmccOV+8UD236Tx6vQQqA X-Google-Smtp-Source: ABdhPJydKSpOgEEtLd65QDOGH1yNmh9rhxjjmqHFdswWpix0NFvC0eVf8pSD/0oCod3zY174nj3qWA== X-Received: by 2002:a92:cb4e:: with SMTP id f14mr3396794ilq.80.1602773283844; Thu, 15 Oct 2020 07:48:03 -0700 (PDT) Received: from localhost ([2600:6c44:7580:4a01:b0e1:67ab:1edb:3b49]) by smtp.gmail.com with ESMTPSA id y26sm2810057iol.24.2020.10.15.07.48.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Oct 2020 07:48:03 -0700 (PDT) Date: Thu, 15 Oct 2020 09:48:01 -0500 From: "Dale W. Carder" To: Giuseppe Fioccola Cc: "v6ops@ietf.org" , "draft-vf-v6ops-ipv6-deployment@ietf.org" , "v6ops-chairs@ietf.org" Message-ID: <20201015144801.GB78739@dwc-desktop.local> References: <160276863269.12225.15313625467391617602@ietfa.amsl.com> <19408462e0bf4f0a8776820bef8d9130@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19408462e0bf4f0a8776820bef8d9130@huawei.com> Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-vf-v6ops-ipv6-deployment-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, 15 Oct 2020 14:48:07 -0000 Thus spake Giuseppe Fioccola (giuseppe.fioccola@huawei.com) on Thu, Oct 15, 2020 at 02:31:55PM +0000: > Dear All, > We have just posted a new informational draft on IPv6 deployment. This document aims to provide the global picture of IPv6 to show how IPv6 is growing and also an overview of IPv6 transition deployment status. Indeed, it is reported a survey of the deployed IPv6 transition technologies. The document also aims to analyze the challenges and therefore encourage actions and more investigations on some areas that are still under discussion. > > For those interested to collaborate on this topic, we are open to discuss and work together to improve the document. > > Your inputs and comments are welcome. With admittedly only a very quick glance through it, to me it sort of looks like a copy+paste of ETSI White Paper No. 35 into RFC format. Would you mind expanding on the difference between that document and what you are hoping to do here? Dale > Name: draft-vf-v6ops-ipv6-deployment > Revision: 00 > Title: IPv6 Transition Deployment Status > Document date: 2020-10-15 > Group: Individual Submission > Pages: 24 > URL: https://www.ietf.org/archive/id/draft-vf-v6ops-ipv6-deployment-00.txt > Status: https://datatracker.ietf.org/doc/draft-vf-v6ops-ipv6-deployment/ > Htmlized: https://datatracker.ietf.org/doc/html/draft-vf-v6ops-ipv6-deployment > Htmlized: https://tools.ietf.org/html/draft-vf-v6ops-ipv6-deployment-00 From nobody Thu Oct 15 08:20: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 07E443A07CE; Thu, 15 Oct 2020 08:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 1QNkgXF3EcoZ; Thu, 15 Oct 2020 08:20:43 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 20E863A07C4; Thu, 15 Oct 2020 08:20:43 -0700 (PDT) Received: from lhreml734-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id AD35B36C3CDB3104819D; Thu, 15 Oct 2020 16:20:40 +0100 (IST) Received: from fraeml709-chm.china.huawei.com (10.206.15.37) by lhreml734-chm.china.huawei.com (10.201.108.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 15 Oct 2020 16:20:40 +0100 Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 15 Oct 2020 17:20:39 +0200 Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.1913.007; Thu, 15 Oct 2020 17:20:39 +0200 From: Giuseppe Fioccola To: "Dale W. Carder" CC: "v6ops@ietf.org" , "draft-vf-v6ops-ipv6-deployment@ietf.org" , "v6ops-chairs@ietf.org" Thread-Topic: [v6ops] FW: New Version Notification for draft-vf-v6ops-ipv6-deployment-00.txt Thread-Index: AQHWovdnldXGZSP3DkOI6d1DuX9RaamYqeYw///zAICAACe6gA== Date: Thu, 15 Oct 2020 15:20:39 +0000 Message-ID: <7741125e4deb4b7ba725d8a68d0fe7d5@huawei.com> References: <160276863269.12225.15313625467391617602@ietfa.amsl.com> <19408462e0bf4f0a8776820bef8d9130@huawei.com> <20201015144801.GB78739@dwc-desktop.local> In-Reply-To: <20201015144801.GB78739@dwc-desktop.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.48.208.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-vf-v6ops-ipv6-deployment-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, 15 Oct 2020 15:20:45 -0000 Hi Dale, Thanks for your quick feedback! Yes, this gives me the opportunity to clarify. The ETSI White Paper No. 35 = is a reference of the draft and we are also coauthors of it. The first part= of our draft starts from the same considerations of the White Paper (If it= is not considered useful to reaffirm some concepts we can simply omit them= in the next revision).=20 But we would like to go beyond and extend the second part of the document, = in particular the "Call for Action" section, that is new. To start a call f= or action on specific areas (IPv6 Performance, Security,...) and encourage = the community, we need to go ahead in IETF. Regards, Giuseppe -----Original Message----- From: Dale W. Carder [mailto:dwcarder@es.net]=20 Sent: Thursday, October 15, 2020 4:48 PM To: Giuseppe Fioccola Cc: v6ops@ietf.org; draft-vf-v6ops-ipv6-deployment@ietf.org; v6ops-chairs@i= etf.org Subject: Re: [v6ops] FW: New Version Notification for draft-vf-v6ops-ipv6-d= eployment-00.txt Thus spake Giuseppe Fioccola (giuseppe.fioccola@huawei.com) on Thu, Oct 15,= 2020 at 02:31:55PM +0000: > Dear All, > We have just posted a new informational draft on IPv6 deployment. This do= cument aims to provide the global picture of IPv6 to show how IPv6 is growi= ng and also an overview of IPv6 transition deployment status. Indeed, it is= reported a survey of the deployed IPv6 transition technologies. The docume= nt also aims to analyze the challenges and therefore encourage actions and = more investigations on some areas that are still under discussion. >=20 > For those interested to collaborate on this topic, we are open to discuss= and work together to improve the document. >=20 > Your inputs and comments are welcome. With admittedly only a very quick glance through it, to me it sort of looks= like a copy+paste of ETSI White Paper No. 35 into RFC format. =20 Would you mind expanding on the difference between that document and what y= ou are hoping to do here? Dale =20 > Name: draft-vf-v6ops-ipv6-deployment > Revision: 00 > Title: IPv6 Transition Deployment Status > Document date: 2020-10-15 > Group: Individual Submission > Pages: 24 > URL: https://www.ietf.org/archive/id/draft-vf-v6ops-ipv6-deplo= yment-00.txt > Status: https://datatracker.ietf.org/doc/draft-vf-v6ops-ipv6-depl= oyment/ > Htmlized: https://datatracker.ietf.org/doc/html/draft-vf-v6ops-ipv6= -deployment > Htmlized: https://tools.ietf.org/html/draft-vf-v6ops-ipv6-deploymen= t-00 From nobody Thu Oct 15 08:33: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 248213A0840; Thu, 15 Oct 2020 08:33:39 -0700 (PDT) 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 Ti3wWpM-0Bo0; Thu, 15 Oct 2020 08:33:37 -0700 (PDT) Received: from correo.unam.mx (smtp2.unam.mx [132.248.10.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1AAB3A00E3; Thu, 15 Oct 2020 08:33:36 -0700 (PDT) Received: from pine.servidores.unam.mx (132.248.10.10) by MAILBOX01.unam.local (172.16.2.63) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 15 Oct 2020 10:28:46 -0500 Date: Thu, 15 Oct 2020 10:32:18 -0500 From: Azael Fernandez Alcantara X-X-Sender: afaza@pine.servidores.unam.mx To: Giuseppe Fioccola CC: "v6ops@ietf.org" , "draft-vf-v6ops-ipv6-deployment@ietf.org" , "v6ops-chairs@ietf.org" , Azael In-Reply-To: <19408462e0bf4f0a8776820bef8d9130@huawei.com> Message-ID: References: <160276863269.12225.15313625467391617602@ietfa.amsl.com> <19408462e0bf4f0a8776820bef8d9130@huawei.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed X-Originating-IP: [132.248.10.10] X-ClientProxiedBy: CAS01.unam.local (172.16.2.28) To MAILBOX01.unam.local (172.16.2.63) Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-vf-v6ops-ipv6-deployment-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, 15 Oct 2020 15:33:39 -0000 Hi, I think, it would be very useful to include the effects of, and to, IPv6 deployment in the context of the Pandemic period we are facing. BEST, SALUDOS, _______ UNAM Azael On Thu, 15 Oct 2020, Giuseppe Fioccola wrote: > Dear All, > We have just posted a new informational draft on IPv6 deployment. This document aims to provide the global picture of IPv6 to show how IPv6 is growing and also an overview of IPv6 transition deployment status. Indeed, it is reported a survey of the deployed IPv6 transition technologies. The document also aims to analyze the challenges and therefore encourage actions and more investigations on some areas that are still under discussion. > > For those interested to collaborate on this topic, we are open to discuss and work together to improve the document. > > Your inputs and comments are welcome. > > Best Regards, > > Giuseppe and Paolo > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, October 15, 2020 3:31 PM > To: Paolo Volpato ; Giuseppe Fioccola > Subject: New Version Notification for draft-vf-v6ops-ipv6-deployment-00.txt > > > A new version of I-D, draft-vf-v6ops-ipv6-deployment-00.txt > has been successfully submitted by Giuseppe Fioccola and posted to the IETF repository. > > Name: draft-vf-v6ops-ipv6-deployment > Revision: 00 > Title: IPv6 Transition Deployment Status > Document date: 2020-10-15 > Group: Individual Submission > Pages: 24 > URL: https://www.ietf.org/archive/id/draft-vf-v6ops-ipv6-deployment-00.txt > Status: https://datatracker.ietf.org/doc/draft-vf-v6ops-ipv6-deployment/ > Htmlized: https://datatracker.ietf.org/doc/html/draft-vf-v6ops-ipv6-deployment > Htmlized: https://tools.ietf.org/html/draft-vf-v6ops-ipv6-deployment-00 > > > Abstract: > Looking globally, IPv6 is growing faster than IPv4 and this means > that the collective wisdom of the networking industry has selected > IPv6 for the future. This document provides an overview of IPv6 > transition deployment status and a view on how the transition to IPv6 > is progressing among network operators that are introducing IPv6 or > have already adopted an IPv6-only solution. It also aims to analyze > the transition challenges and therefore encourage actions and more > investigations on some areas that are still under discussion. The > overall IPv6 incentives are also examined. > > > > > > 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 > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Oct 15 08:38: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 9170A3A084A; Thu, 15 Oct 2020 08:38:20 -0700 (PDT) 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 JDydiAmaamO3; Thu, 15 Oct 2020 08:38:17 -0700 (PDT) Received: from correo.unam.mx (smtp2.unam.mx [132.248.10.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AD263A010A; Thu, 15 Oct 2020 08:38:17 -0700 (PDT) Received: from pine.servidores.unam.mx (132.248.10.10) by MAILBOX01.unam.local (172.16.2.63) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 15 Oct 2020 10:34:38 -0500 Date: Thu, 15 Oct 2020 10:38:10 -0500 From: Azael Fernandez Alcantara X-X-Sender: afaza@pine.servidores.unam.mx To: Giuseppe Fioccola CC: "v6ops@ietf.org" , "draft-vf-v6ops-ipv6-deployment@ietf.org" , "v6ops-chairs@ietf.org" , Azael In-Reply-To: Message-ID: References: <160276863269.12225.15313625467391617602@ietfa.amsl.com> <19408462e0bf4f0a8776820bef8d9130@huawei.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed X-Originating-IP: [132.248.10.10] X-ClientProxiedBy: CAS01.unam.local (172.16.2.28) To MAILBOX01.unam.local (172.16.2.63) Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-vf-v6ops-ipv6-deployment-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, 15 Oct 2020 15:38:21 -0000 That it is mentioned ones in the ETSI paper. But now it would be very useful until the end of confination periods. BEST, SALUDOS, _______ UNAM Azael On Thu, 15 Oct 2020, Azael Fernandez Alcantara wrote: > Hi, > > I think, it would be very useful to include the effects of, and to, IPv6 > deployment in the context of the Pandemic period we are facing. > > > BEST, > SALUDOS, > _______ > UNAM > Azael > > > On Thu, 15 Oct 2020, Giuseppe Fioccola wrote: > >> Dear All, >> We have just posted a new informational draft on IPv6 deployment. This >> document aims to provide the global picture of IPv6 to show how IPv6 is >> growing and also an overview of IPv6 transition deployment status. Indeed, >> it is reported a survey of the deployed IPv6 transition technologies. The >> document also aims to analyze the challenges and therefore encourage >> actions and more investigations on some areas that are still under >> discussion. >> >> For those interested to collaborate on this topic, we are open to discuss >> and work together to improve the document. >> >> Your inputs and comments are welcome. >> >> Best Regards, >> >> Giuseppe and Paolo >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Thursday, October 15, 2020 3:31 PM >> To: Paolo Volpato ; Giuseppe Fioccola >> >> Subject: New Version Notification for >> draft-vf-v6ops-ipv6-deployment-00.txt >> >> >> A new version of I-D, draft-vf-v6ops-ipv6-deployment-00.txt >> has been successfully submitted by Giuseppe Fioccola and posted to the >> IETF repository. >> >> Name: draft-vf-v6ops-ipv6-deployment >> Revision: 00 >> Title: IPv6 Transition Deployment Status >> Document date: 2020-10-15 >> Group: Individual Submission >> Pages: 24 >> URL: >> https://www.ietf.org/archive/id/draft-vf-v6ops-ipv6-deployment-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-vf-v6ops-ipv6-deployment/ >> Htmlized: https://datatracker.ietf.org/doc/html/draft-vf-v6ops-ipv6-deployment >> Htmlized: https://tools.ietf.org/html/draft-vf-v6ops-ipv6-deployment-00 >> >> >> Abstract: >> Looking globally, IPv6 is growing faster than IPv4 and this means >> that the collective wisdom of the networking industry has selected >> IPv6 for the future. This document provides an overview of IPv6 >> transition deployment status and a view on how the transition to IPv6 >> is progressing among network operators that are introducing IPv6 or >> have already adopted an IPv6-only solution. It also aims to analyze >> the transition challenges and therefore encourage actions and more >> investigations on some areas that are still under discussion. The >> overall IPv6 incentives are also examined. >> >> >> >> >> >> 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 >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > From nobody Thu Oct 15 09:12: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 8DE953A08B2; Thu, 15 Oct 2020 09:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 imfowTwLiDdJ; Thu, 15 Oct 2020 09:12:12 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 CBAF53A08AF; Thu, 15 Oct 2020 09:12:11 -0700 (PDT) Received: from lhreml731-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id F2D10A2B230C978E21FE; Thu, 15 Oct 2020 17:12:09 +0100 (IST) Received: from fraeml711-chm.china.huawei.com (10.206.15.60) by lhreml731-chm.china.huawei.com (10.201.108.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 15 Oct 2020 17:12:09 +0100 Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml711-chm.china.huawei.com (10.206.15.60) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 15 Oct 2020 18:12:09 +0200 Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.1913.007; Thu, 15 Oct 2020 18:12:09 +0200 From: Giuseppe Fioccola To: Azael Fernandez Alcantara CC: "v6ops@ietf.org" , "draft-vf-v6ops-ipv6-deployment@ietf.org" , "v6ops-chairs@ietf.org" , Azael Thread-Topic: [v6ops] FW: New Version Notification for draft-vf-v6ops-ipv6-deployment-00.txt Thread-Index: AQHWovdnldXGZSP3DkOI6d1DuX9RaamYqeYw////XwCAAAGkAIAAJJ3g Date: Thu, 15 Oct 2020 16:12:09 +0000 Message-ID: <459d2a3f18d549ac8c89caac1f8be311@huawei.com> References: <160276863269.12225.15313625467391617602@ietfa.amsl.com> <19408462e0bf4f0a8776820bef8d9130@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.48.208.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] FW: New Version Notification for draft-vf-v6ops-ipv6-deployment-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, 15 Oct 2020 16:12:14 -0000 Hi Azael, Yes, this is a good point. Some network operators already noted an increase= of IPv6 traffic during the pandemic period, considering the greater use of= video and streaming services provided mainly in IPv6 by most of the bigges= t content providers. But, other than that, it is worth investigating further this aspect to chec= k, for example, whether there is a positive effect on the IPv6 performance = and so on. Regards, Giuseppe -----Original Message----- From: Azael Fernandez Alcantara [mailto:afaza@unam.mx]=20 Sent: Thursday, October 15, 2020 5:38 PM To: Giuseppe Fioccola Cc: v6ops@ietf.org; draft-vf-v6ops-ipv6-deployment@ietf.org; v6ops-chairs@i= etf.org; Azael Subject: Re: [v6ops] FW: New Version Notification for draft-vf-v6ops-ipv6-d= eployment-00.txt That it is mentioned ones in the ETSI paper. But now it would be very useful until the end of confination periods. BEST, SALUDOS, _______ UNAM Azael On Thu, 15 Oct 2020, Azael Fernandez Alcantara wrote: > Hi, > > I think, it would be very useful to include the effects of, and to,=20 > IPv6 deployment in the context of the Pandemic period we are facing. > > > BEST, > SALUDOS, > _______ > UNAM > Azael > > > On Thu, 15 Oct 2020, Giuseppe Fioccola wrote: > >> Dear All, >> We have just posted a new informational draft on IPv6 deployment.=20 >> This document aims to provide the global picture of IPv6 to show how=20 >> IPv6 is growing and also an overview of IPv6 transition deployment=20 >> status. Indeed, it is reported a survey of the deployed IPv6=20 >> transition technologies. The document also aims to analyze the=20 >> challenges and therefore encourage actions and more investigations=20 >> on some areas that are still under discussion. >> >> For those interested to collaborate on this topic, we are open to=20 >> discuss and work together to improve the document. >> >> Your inputs and comments are welcome. >> >> Best Regards, >> >> Giuseppe and Paolo >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Thursday, October 15, 2020 3:31 PM >> To: Paolo Volpato ; Giuseppe Fioccola =20 >> >> Subject: New Version Notification for =20 >> draft-vf-v6ops-ipv6-deployment-00.txt >>=20 >> >> A new version of I-D, draft-vf-v6ops-ipv6-deployment-00.txt >> has been successfully submitted by Giuseppe Fioccola and posted to=20 >> the IETF repository. >> >> Name: draft-vf-v6ops-ipv6-deployment >> Revision: 00 >> Title: IPv6 Transition Deployment Status >> Document date: 2020-10-15 >> Group: Individual Submission >> Pages: 24 >> URL: >> =20 >> https://www.ietf.org/archive/id/draft-vf-v6ops-ipv6-deployment-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-vf-v6ops-ipv6-deployment/ >> Htmlized: https://datatracker.ietf.org/doc/html/draft-vf-v6ops-ip= v6-deployment >> Htmlized: https://tools.ietf.org/html/draft-vf-v6ops-ipv6-deploym= ent-00 >>=20 >> >> Abstract: >> Looking globally, IPv6 is growing faster than IPv4 and this means >> that the collective wisdom of the networking industry has selected >> IPv6 for the future. This document provides an overview of IPv6 >> transition deployment status and a view on how the transition to IPv6 >> is progressing among network operators that are introducing IPv6 or >> have already adopted an IPv6-only solution. It also aims to analyze >> the transition challenges and therefore encourage actions and more >> investigations on some areas that are still under discussion. The >> overall IPv6 incentives are also examined. >>=20 >>=20 >>=20 >>=20 >> >> Please note that it may take a couple of minutes from the time of =20 >> submission until the htmlized version and diff are available at =20 >> tools.ietf.org. >> >> The IETF Secretariat >>=20 >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 > From nobody Thu Oct 15 12:12: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 CDEA53A1307; Thu, 15 Oct 2020 12:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 niweWhZJlxPj; Thu, 15 Oct 2020 12:12:35 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 A549B3A12E0; Thu, 15 Oct 2020 12:12:19 -0700 (PDT) Received: from lhreml733-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 992E2E361A3961D81FCA; Thu, 15 Oct 2020 20:12:17 +0100 (IST) Received: from msceml703-chm.china.huawei.com (10.219.141.161) by lhreml733-chm.china.huawei.com (10.201.108.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 15 Oct 2020 20:12:17 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml703-chm.china.huawei.com (10.219.141.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 15 Oct 2020 22:12:16 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Thu, 15 Oct 2020 22:12:16 +0300 From: Vasilenko Eduard To: "Templin (US), Fred L" CC: v6ops list , IPv6 List , Michael Richardson , dhcwg Thread-Topic: [EXTERNAL] [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AQHWonqxHABI+EZs2kGHaqRqZs2WfqmZAwwg Date: Thu, 15 Oct 2020 19:12:16 +0000 Message-ID: <776c6059adab48c7b75f0c1f7654843e@huawei.com> References: <5f119ffbb67245a9b9d34a0d8f7398f4@boeing.com> <10487.1602608586@localhost> <378d3420690246bbae253fb15be8c9a7@boeing.com> <19627.1602701863@localhost> <1b34b9bec59e4a00af8b9d8f182d23ff@boeing.com> <0284272facf5494f81eff3e49597a246@boeing.com> <24082dcc5fd1472c8df16e331722da2d@boeing.com> In-Reply-To: <24082dcc5fd1472c8df16e331722da2d@boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.195.106] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] [EXTERNAL] [dhcwg] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Thu, 15 Oct 2020 19:12:38 -0000 SGkgRnJlZCwNCllvdSBuZWVkIHRoZSBjaGFsbGVuZ2UuIE9LLiBJIGhhdmUgaXQgZm9yIHlvdS4N Cg0KVHlwaWNhbCByb3V0aW5nIHByb3RvY29scyB3b3VsZCBkaXN0cmlidXRlIHRvIHRoZSAic3R1 YiIgcm91dGVyIGluZm9ybWF0aW9uIGFib3V0IHByZWZpeGVzICJzb21ld2hlcmUgaW4gdGhlIG5l dHdvcmsiLg0KUHJlZml4ZXMgZnJvbSBsb2NhbCBpbnRlcmZhY2VzIGFyZSBpbnNlcnRlZCBpbnRv IHRoZSByb3V0aW5nIHRhYmxlIGluIHRoZSB2ZXJ5IHBlcnNpc3RlbnQgd2F5Oi0pDQoNCkRIQ1At UEQgd291bGQgZGlzdHJpYnV0ZSB0byB0aGUgInN0dWIiIHJvdXRlciBpbmZvcm1hdGlvbiBhYm91 dCBwcmVmaXhlcyB0aGF0IHNob3VsZCBiZWNvbWUgbG9jYWwvaW50ZXJmYWNlIHByZWZpeGVzIG9u IHRoZSAic3R1YiIuDQpOb24tZ3JhY2VmdWwgcmVsb2FkIGNvdWxkIGxlYWQgdG8gYW1uZXNpYSBv biB0aGUgInN0dWIiLiBUaGVuIGl0IGNvdWxkIGF0dGFjayBpdHMgb3duIHVwbGluay4NCkl0IGlz IGEgbmV3IHByb2JsZW0uIEJlY2F1c2UgREhDUC1QRCBkb2VzIHBsYXkgdGhlIHJvbGUgb2YgImF1 dG9tYXRpYyBwcm92aXNpb25pbmcgc3lzdGVtIiwgbm90IHJvdXRpbmcgcHJvdG9jb2wuDQpUaGUg cHJvYmxlbSBjb3VsZCBiZSBjYWxsZWQgIm5vbi1jb25zaXN0ZW50IHJvdXRlcnMgY29uZmlndXJh dGlvbiIuDQpUaGUgZmFjdCB0aGF0IHByb3BlciBwcm90b2NvbCBmb3IgcHJlZml4IGRpc3RyaWJ1 dGlvbiBzaG91bGQgYmUgdmVyeSBzaW1pbGFyIHRvIHJvdXRpbmcgcHJvdG9jb2wgLSBpcyB0aGUg c2Vjb25kYXJ5IGhlcmUgKGl0IGlzIGltcGxlbWVudGF0aW9uKSwgYmVjYXVzZSB0aGUgcHJvYmxl bSBpdHNlbGYgaXMgbmV3Lg0KDQpFZHVhcmQNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IFRlbXBsaW4gKFVTKSwgRnJlZCBMDQo+IFNlbnQ6IDE1INC+0LrRgtGP0LHRgNGPIDIwMjAg0LMu IDE6MzcNCj4gVG86IEJvYiBIaW5kZW4gPGJvYi5oaW5kZW5AZ21haWwuY29tPg0KPiBDYzogdjZv cHMgbGlzdCA8djZvcHNAaWV0Zi5vcmc+OyBJUHY2IExpc3QgPGlwdjZAaWV0Zi5vcmc+OyBNaWNo YWVsIFJpY2hhcmRzb24NCj4gPG1jcitpZXRmQHNhbmRlbG1hbi5jYT47IGRoY3dnIDxkaGN3Z0Bp ZXRmLm9yZz4NCj4gU3ViamVjdDogUkU6IFtFWFRFUk5BTF0gW2RoY3dnXSBbdjZvcHNdIFJlOiBR dWVzdGlvbiB0byBESENQdjYgUmVsYXkNCj4gSW1wbGVtZW50b3JzIHJlZ2FyZGluZyBkcmFmdC1p ZXRmLWRoYy1kaGNwdjYtcGQtcmVsYXktcmVxdWlyZW1lbnRzDQo+IA0KPiA+IEkgbm90ZSB0aGF0 IHRoZSBsYWNrIG9mIOKAnGNoYWxsZW5nZeKAnSBkb2VzIG5vdCBtZWFuIGFueW9uZSBhZ3JlZXMu ICAgQWdyZWVtZW50DQo+IG5lZWRzIHRvIGJlIGFmZmlybWF0aXZlLg0KPiANCj4gRmFpciBlbm91 Z2gsIEJvYjsgaGVyZSBpcyB0aGUgYXNzZXJ0aW9uIEkgbWFkZSB0aGF0IEkgd2FzIHJlZmVycmlu ZyB0bzoNCj4gDQo+ICsgQlRXLCBJIGFtIHN0aWxsIHdhaXRpbmcgdG8gaGVhciBob3cgdGhpcyBj b25jZXJuIGlzIGluIGFueSB3YXkNCj4gKyBzcGVjaWZpYyB0byBwcmVmaXggZGVsZWdhdGlvbiwg c2luY2UgaXQgc2VlbXMgdG8gYmUgZ2VuZXJpYyB0byBhbnkNCj4gKyBjYXNlIG9mIGhhdmluZyBh IOKAnHN0dWLigJ0gcm91dGVyIHRoYXQgbWFsaWNpb3VzbHkgYXR0YWNrcyBpdHMgb3duDQo+ICsg dXBzdHJlYW0gbGluayDigJMgbm8gbWF0dGVyIGhvdyB0aGF0IHJvdXRlciBuZWdvdGlhdGVzIGl0 cyBwcmVmaXhlcyB3aXRoDQo+IHVwc3RyZWFtIG5ldHdvcmsgbm9kZXMuDQo+IA0KPiBEbyB0aGUg aW5kaXZpZHVhbHMgQ0MnZCBvbiB0aGlzIGxpc3QgYWdyZWUgdGhhdCB0aGlzIGlzIGEgZ2VuZXJp YyBJUHY2IGlzc3VlIGFuZCBub3QgYQ0KPiBESENQdjYtUEQtc3BlY2lmaWMgaXNzdWU/DQo+IA0K PiBUaGFua3MgLSBGcmVkDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4g RnJvbTogQm9iIEhpbmRlbiBbbWFpbHRvOmJvYi5oaW5kZW5AZ21haWwuY29tXQ0KPiA+IFNlbnQ6 IFdlZG5lc2RheSwgT2N0b2JlciAxNCwgMjAyMCAzOjI4IFBNDQo+ID4gVG86IFRlbXBsaW4gKFVT KSwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0KPiA+IENjOiBCb2IgSGluZGVu IDxib2IuaGluZGVuQGdtYWlsLmNvbT47IE1pY2hhZWwgUmljaGFyZHNvbg0KPiA+IDxtY3IraWV0 ZkBzYW5kZWxtYW4uY2E+OyBkaGN3ZyA8ZGhjd2dAaWV0Zi5vcmc+OyBJUHY2IExpc3QNCj4gPiA8 aXB2NkBpZXRmLm9yZz47IHY2b3BzIGxpc3QgPHY2b3BzQGlldGYub3JnPg0KPiA+IFN1YmplY3Q6 IFJlOiBbRVhURVJOQUxdIFtkaGN3Z10gW3Y2b3BzXSBSZTogUXVlc3Rpb24gdG8gREhDUHY2IFJl bGF5DQo+ID4gSW1wbGVtZW50b3JzIHJlZ2FyZGluZyBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtcGQt cmVsYXktIHJlcXVpcmVtZW50cw0KPiA+DQo+ID4gSSBub3RlIHRoYXQgdGhlIGxhY2sgb2Yg4oCc Y2hhbGxlbmdl4oCdIGRvZXMgbm90IG1lYW4gYW55b25lIGFncmVlcy4gICBBZ3JlZW1lbnQNCj4g bmVlZHMgdG8gYmUgYWZmaXJtYXRpdmUuDQo+ID4NCj4gPiBCb2INCj4gPg0KPiA+DQo+ID4gPiBP biBPY3QgMTQsIDIwMjAsIGF0IDM6MjQgUE0sIFRlbXBsaW4gKFVTKSwgRnJlZCBMDQo+IDxGcmVk LkwuVGVtcGxpbkBib2VpbmcuY29tPiB3cm90ZToNCj4gPiA+DQo+ID4gPiBCb2IsIHNldmVyYWwg bWVzc2FnZXMgYmFjayBpdCB3YXMgZXN0YWJsaXNoZWQgdGhhdCB0aGUgaXNzdWUgYXQgdGhlDQo+ ID4gPiBoZWFydCBvZiB0aGlzIGRpc2N1c3Npb24gaXMgbm90IHNwZWNpZmljIHRvIERIQ1B2NiBu b3IgREhDUHY2LVBELg0KPiA+ID4gSW5zdGVhZCwgaXQgaXMgYW4gaXNzdWUgdGhhdCBpcyBjb21t b24gdG8gYW55IHNpdHVhdGlvbiB3aGVyZSB0aGVyZQ0KPiA+ID4gYXJlIG11bHRpcGxlICJzdHVi IiBJUHY2IHJvdXRlcnMgb24gYSBkb3duc3RyZWFtIGxpbmsgZnJvbSBhDQo+ID4gPiAiZGVmYXVs dCIgSVB2NiByb3V0ZXIsIG5vIG1hdHRlciBob3cgdGhlIHJvdXRpbmcgaW5mb3JtYXRpb24gaXMN Cj4gPiA+IGVzdGFibGlzaGVkIG9yIG1haW50YWluZWQuIFNvIGZhciwgbm8gb25lIGhhcyBjaGFs bGVuZ2VkIG15DQo+ID4gPiBhc3NlcnRpb24gdGhhdCB0aGlzIGlzIGEgZ2VuZXJpYyAoYW5kIG5v dCBhIERIQ1B2Ni1QRC1zcGVjaWZpYykgSVB2NiBpc3N1ZSBhbmQNCj4gSSBoYXZlIGJlZW4gd2Fp dGluZyB0byBzZWUgaWYgYW55b25lIHdhbnRzIHRvIGNoYWxsZW5nZSB0aGF0Lg0KPiA+ID4NCj4g PiA+IEZyZWQNCj4gPiA+DQo+ID4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ PiBGcm9tOiBCb2IgSGluZGVuIFttYWlsdG86Ym9iLmhpbmRlbkBnbWFpbC5jb21dDQo+ID4gPj4g U2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDE0LCAyMDIwIDI6NDcgUE0NCj4gPiA+PiBUbzogVGVt cGxpbiAoVVMpLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+DQo+ID4gPj4gQ2M6 IEJvYiBIaW5kZW4gPGJvYi5oaW5kZW5AZ21haWwuY29tPjsgTWljaGFlbCBSaWNoYXJkc29uDQo+ ID4gPj4gPG1jcitpZXRmQHNhbmRlbG1hbi5jYT47IGRoY3dnIDxkaGN3Z0BpZXRmLm9yZz47IElQ djYgTGlzdA0KPiA+ID4+IDxpcHY2QGlldGYub3JnPjsgdjZvcHMgbGlzdCA8djZvcHNAaWV0Zi5v cmc+DQo+ID4gPj4gU3ViamVjdDogUmU6IFtFWFRFUk5BTF0gW2RoY3dnXSBbdjZvcHNdIFJlOiBR dWVzdGlvbiB0byBESENQdjYNCj4gPiA+PiBSZWxheSBJbXBsZW1lbnRvcnMgcmVnYXJkaW5nIGRy YWZ0LWlldGYtZGhjLWRoY3B2Ni1wZC1yZWxheS0NCj4gPiA+PiByZXF1aXJlbWVudHMNCj4gPiA+ Pg0KPiA+ID4+IFdpdGggbXkgY2hhaXIgaGF0IG9uLCBpcyB0aGVyZSBhIHJlYXNvbiB3aHkgdGhp cyBkaXNjdXNzaW9uIGlzIGJlaW5nIGNvcGllZA0KPiB0byB0aGUgNk1BTiB3LmcuPyAgIDZNQU4g ZG9lc27igJl0IG1haW50YWluIERIQ1ANCj4gPiByZWxhdGVkDQo+ID4gPj4gaXRlbXMuDQo+ID4g Pj4NCj4gPiA+PiBQbGVhc2UgcmVtb3ZlIGlwdjZAaWV0Zi5vcmcgZnJvbSB0aGlzIHRocmVhZC4N Cj4gPiA+Pg0KPiA+ID4+IEJvYg0KPiA+ID4+DQo+ID4gPj4NCj4gPiA+Pj4gT24gT2N0IDE0LCAy MDIwLCBhdCAxMjoxOSBQTSwgVGVtcGxpbiAoVVMpLCBGcmVkIEwNCj4gPEZyZWQuTC5UZW1wbGlu QGJvZWluZy5jb20+IHdyb3RlOg0KPiA+ID4+Pg0KPiA+ID4+PiBIaSBNaWNoYWVsLA0KPiA+ID4+ Pg0KPiA+ID4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+Pj4+IEZyb206IE1p Y2hhZWwgUmljaGFyZHNvbiBbbWFpbHRvOm1jcitpZXRmQHNhbmRlbG1hbi5jYV0NCj4gPiA+Pj4+ IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxNCwgMjAyMCAxMTo1OCBBTQ0KPiA+ID4+Pj4gVG86 IFRlbXBsaW4gKFVTKSwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0KPiA+ID4+ Pj4gQ2M6IGlhbmZhcnJlckBnbXguY29tOyBKZW4gTGlua292YSA8ZnVycnkxM0BnbWFpbC5jb20+ OyBkaGN3Zw0KPiA+ID4+Pj4gPGRoY3dnQGlldGYub3JnPjsgdjZvcHMgbGlzdCA8djZvcHNAaWV0 Zi5vcmc+OyA2bWFuDQo+ID4gPj4+PiA8aXB2NkBpZXRmLm9yZz4NCj4gPiA+Pj4+IFN1YmplY3Q6 IFJlOiBbRVhURVJOQUxdIFJlOiBbZGhjd2ddIFt2Nm9wc10gUmU6IFF1ZXN0aW9uIHRvDQo+ID4g Pj4+PiBESENQdjYgUmVsYXkgSW1wbGVtZW50b3JzIHJlZ2FyZGluZyBkcmFmdC1pZXRmLWRoYy1k aGNwdjYtcGQtDQo+ID4gPj4gcmVsYXktDQo+ID4gPj4+PiByZXF1aXJlbWVudHMNCj4gPiA+Pj4+ DQo+ID4gPj4+Pg0KPiA+ID4+Pj4gVGVtcGxpbiAoVVMpLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGlu QGJvZWluZy5jb20+IHdyb3RlOg0KPiA+ID4+Pj4+IE1pY2hhZWwsIHdoYXQgSSB3YXMgcmVmZXJy aW5nIHRvIGJlbG93IGFzICJmYWlsdXJlIiBpcyB0aGUgcHJveHkNCj4gPiA+Pj4+PiBjYXNlIHdo ZW4gdGhlcmUgaXMgYW4gTDIgcHJveHkgUCBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHJlbGF5DQo+ ID4gPj4+Pj4gKGUuZy4sIFJGQzQ4OSkuIFRoZXJlDQo+ID4gPj4+Pg0KPiA+ID4+Pj4gUkZDNDM4 OSBkZXNjcmliZXMgYW4gTkQgUHJveHkuDQo+ID4gPj4+PiBJcyB0aGF0IHJlYWxseSBhbiBMMiBw cm94eT8NCj4gPiA+Pj4NCj4gPiA+Pj4gWWVzLCBJIGJlbGlldmUgaXQgaXMgYW4gTDIgcHJveHku DQo+ID4gPj4+DQo+ID4gPj4+PiBJdCBzZWVtcyBsaWtlIGl0IGFsc28gbXVzdCBiZSBjb250YWlu IGVpdGhlciBhbiBMMi1icmlkZ2UsIG9yDQo+ID4gPj4+PiBtdXN0IGhhdmUgdGhlIEwzLXJvdXRp bmcgdGFibGUgZW50cmllcyBpZiBpdCB3b3VsZCByZWFsbHkgYmUNCj4gPiA+Pj4+IGNhcGFibGUg b2YgcGFzc2luZyBESENQdjYtUEQgcHJlZml4ZXMgdGhyb3VnaCBpdC4NCj4gPiA+Pj4NCj4gPiA+ Pj4gVGhlIG9ubHkgdGhpbmcgaXQgaGFzIHRoYXQgaW5jbHVkZXMgTDMgaW5mb3JtYXRpb24gaXMg bmVpZ2hib3INCj4gPiA+Pj4gY2FjaGUgZW50cmllcyB0aGF0IGtlZXAgdHJhY2sgb2YgdGhlIGNs aWVudCdzIGFjdHVhbCBMMiBhZGRyZXNzIG9uDQo+ID4gPj4+IHRoZSBkb3duc3RyZWFtIGxpbmsg c2VnbWVudCwgYnV0IHJld3JpdGVzIHRoZSBjbGllbnQncyBMMiBhZGRyZXNzDQo+ID4gPj4+IHRv IGl0cyBvd24gTDIgYWRkcmVzcyB3aGVuIGZvcndhcmRpbmcgb250byBhbiB1cHN0cmVhbSBsaW5r DQo+ID4gPj4+IHNlZ21lbnQuIChJbiB0aGUgcmV2ZXJzZSBkaXJlY3Rpb24sIGl0IHJlY2VpdmVz IHBhY2tldHMgZGVzdGluZWQNCj4gPiA+Pj4gdG8gaXRzIG93biBMMiBhZGRyZXNzIGJ1dCB0aGUg Y2xpZW50J3MgTDMgYWRkcmVzcyBvbiB0aGUgdXBzdHJlYW0NCj4gPiA+Pj4gbGluayBzZWdtZW50 LCB0aGVuIHJld3JpdGVzIHRoZSBMMiBhZGRyZXNzIHRvIHRoZSBjbGllbnQncyBMMg0KPiA+ID4+ PiBhZGRyZXNzIHdoZW4gZm9yd2FyZGluZyBvbnRvIHRoZSBkb3duc3RyZWFtIGxpbmsgc2VnbWVu dC4pDQo+ID4gPj4+DQo+ID4gPj4+PiBDYW4geW91IGV4cGxhaW4gaG93IHN1Y2ggYSBkZXZpY2Ug d291bGQgbm9ybWFsbHkgd29yayBmb3IgYQ0KPiA+ID4+Pj4gY2xpZW50IGRldmljZSBBLEIsQyxE IGRvaW5nIERIQ1B2Ni1QRCB0aHJvdWdoIGl0Pw0KPiA+ID4+Pg0KPiA+ID4+PiBTdXJlLiBBIHNl bmRzIGEgREhDUHY2IFNvbGljaXQgdXNpbmcgaXRzIElQdjYgbGluay1sb2NhbCBhZGRyZXNzDQo+ ID4gPj4+IGFzIHRoZSBzb3VyY2UsIGFuZCBpdHMgTDIgYWRkcmVzcyBhcyB0aGUgbGluay1sYXll ciBzb3VyY2UuIFRoZQ0KPiA+ID4+PiBwcm94eSBjb252ZXJ0cyB0aGUgbGluay1sYXllciBzb3Vy Y2UgdG8gaXRzIG93biBMMiBhZGRyZXNzIHdoZW4NCj4gPiA+Pj4gZm9yd2FyZGluZyB0aGUgREhD UHY2IHNvbGljaXQgb250byB0aGUgdXBzdHJlYW0gbGluay4gV2hlbiB0aGUNCj4gPiA+Pj4gREhD UHY2IFJlcGx5IGNvbWVzIGJhY2ssIHRoZSBJUHY2IGRlc3RpbmF0aW9uIGlzIHRoYXQgb2YgY2xp ZW50IEEsIGJ1dCB0aGUNCj4gbGluay1sYXllciBkZXN0aW5hdGlvbiBpcyB0aGUgTDIgYWRkcmVz cyBvZiB0aGUgcHJveHkuDQo+ID4gPj4+IFRoZSBwcm94eSB0aGVuIGNvbnZlcnRzIHRoZSBMMiBk ZXN0aW5hdGlvbiB0byB0aGUgYWRkcmVzcyBvZg0KPiA+ID4+PiBjbGllbnQgQSBhbmQgZm9yd2Fy ZHMgaXQgb24gdG8gdGhlIGNsaWVudC4NCj4gPiA+Pj4NCj4gPiA+Pj4+IEFuZCBpcyB0aGUgZmFp bHVyZSBvbmUgd2hlcmUgdGhlIHJvdXRlciAiUiIgZmFpbHMgdG8gZHJvcCB0cmFmZmljDQo+ID4g Pj4+PiBpdCBzaG91bGQsIG9uZSB3aGVyZSB0aGUgcm91dGVyICJSIiBkcm9wcyB0cmFmZmljIHRo YXQgaXQgc2hvdWxkbid0Pw0KPiA+ID4+Pg0KPiA+ID4+PiBJIHdhcyB0aGlua2luZyBtb3JlIGFs b25nIHRoZSBsaW5lcyBvZiB0aGUgbGF0dGVyOyBpZiB0aGUgb25seSB3YXkNCj4gPiA+Pj4gdGhh dCBBIGhhcyBmb3IgdGFsa2luZyB0byBCLCBDLCBELCBldGMuIGlzIGJ5IGdvaW5nIHRocm91Z2gg UiwgaXQNCj4gPiA+Pj4gd291bGRuJ3Qgd29yayBpZiBSIHdhcyB1bmNvbmRpdGlvbmFsbHkgZHJv cHBpbmcgZXZlcnl0aGluZy4NCj4gPiA+Pj4NCj4gPiA+Pj4gVGhhbmtzIC0gRnJlZA0KPiA+ID4+ Pg0KPiA+ID4+Pj4gLS0NCj4gPiA+Pj4+IE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK0lFVEZAc2Fu ZGVsbWFuLmNhPiAgIC4gbyBPICggSVB2NiBJw7hUDQo+IGNvbnN1bHRpbmcgKQ0KPiA+ID4+Pj4g ICAgICAgICAgU2FuZGVsbWFuIFNvZnR3YXJlIFdvcmtzIEluYywgT3R0YXdhIGFuZCBXb3JsZHdp ZGUNCj4gPiA+Pj4+DQo+ID4gPj4+Pg0KPiA+ID4+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+ID4gPj4+IC0tIElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCBpcHY2 QGlldGYub3JnDQo+ID4gPj4+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOg0KPiA+ID4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gPiA+Pj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+ID4gPj4+IC0tDQo+ID4gPg0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSUVURiBJUHY2IHdvcmtp bmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+IGlwdjZAaWV0Zi5vcmcNCj4gQWRtaW5pc3RyYXRpdmUg UmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0K From nobody Thu Oct 15 12:31: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 CD1803A0CBE; Thu, 15 Oct 2020 12:31:06 -0700 (PDT) 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, RCVD_IN_MSPIKE_H2=-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=boeing.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 NiTOOjx2iLLO; Thu, 15 Oct 2020 12:31:04 -0700 (PDT) Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 DF0013A1330; Thu, 15 Oct 2020 12:31:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09FJV1A0027798; Thu, 15 Oct 2020 15:31:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602790261; bh=nTM2J+hRiQef+pH2UutZ106LJN/1zHCFLWh9ppvd7O0=; h=From:To:CC:Subject:Date:From; b=pD6koPmDcQoGQD3V2foAvtvRLUeYCeu45i5KzBWtTw2brW+gt+TH/b6Cc6/EXj+ga 0PKlmJ/YxSW1GojkPUUnLdR3rsLJoB5kJR/F4xWD2JIFb8b2gKi5oGDtmYROBRQiQa jJGLruQ9IZa2MzYCdH2G7nsXA+wlGiSSFZi3x/HT/j9v9OjgP6a/TOR+U1NapjEZxU LGpy5jtYOOKMMG0ZZ+8LUEkNWf8cEhHVD1Nf7sSFD0hf9BjESUok4N0Xzfv/4Gog0k npsP+185lLb6gX+sYH8OBVp6DpIxZL8mkh8BrKqXH2pdOOCUPg1uN4f6eEVYbFCK6P i9JpC0gtB+S/g== Received: from XCH16-07-07.nos.boeing.com (xch16-07-07.nos.boeing.com [144.115.66.109]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09FJUuGj027718 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 15 Oct 2020 15:30:56 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-07.nos.boeing.com (144.115.66.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Thu, 15 Oct 2020 12:30:55 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Thu, 15 Oct 2020 12:30:55 -0700 From: "Templin (US), Fred L" To: Vasilenko Eduard CC: v6ops list , IPv6 List , Michael Richardson , dhcwg Thread-Topic: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AdajKLVVnwghNqrLQ4229LT3ce4i4A== Date: Thu, 15 Oct 2020 19:30:55 +0000 Message-ID: <65f390e222244427bd3cbc1f58a3ec95@boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 399499A39F04305249E078848074FC2B5528438B2F1393D1CB6643844044F4AC2000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [dhcwg] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Thu, 15 Oct 2020 19:31:07 -0000 RWR1YXJkLA0KDQpUaGFua3MgZm9yIHlvdXIgbWVzc2FnZS4gVGhlIHBvaW50IEkgd2FzIHRyeWlu ZyB0byBtYWtlIGlzIHRoYXQgaWYgdGhlIHVwc3RyZWFtIHJvdXRlcg0KUiBpcyBjb252aW5jZWQg LSB0aHJvdWdoIHdoYXRldmVyIG1lYW5zIC0gdGhhdCB0aGUgZG93bnN0cmVhbSBzdHViIHJvdXRl ciBTIGhvbGRzDQphbiBJUHY2IHByZWZpeCBzdWNoIGFzIDIwMDE6ZGI4OmE6Yjo6LzY0LCB0aGVu IGl0IHdpbGwgZm9yd2FyZCBhbGwgSVB2NiBwYWNrZXRzIHdpdGgNCmRlc3RpbmF0aW9uIGFkZHJl c3MgZnJvbSB0aGF0IHByZWZpeCB0byBTICpldmVuIGlmIHRoZSBwYWNrZXRzIG9yaWdpbmF0ZWQg ZnJvbSBTKi4NClRoYXQgaXMgbm90IGEgbmV3IGlzc3VlIGJyb3VnaHQgYWJvdXQgYnkgREhDUHY2 LCBzaW5jZSBpdCBpcyAgYSBmb3J3YXJkaW5nIHBsYW5lDQppc3N1ZSBhbmQgbm90IGEgY29udHJv bCBwbGFuZSBpc3N1ZS4NCg0KRnJlZA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IFZhc2lsZW5rbyBFZHVhcmQgW21haWx0bzp2YXNpbGVua28uZWR1YXJkQGh1YXdlaS5j b21dDQo+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE1LCAyMDIwIDEyOjEyIFBNDQo+IFRvOiBU ZW1wbGluIChVUyksIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4NCj4gQ2M6IHY2 b3BzIGxpc3QgPHY2b3BzQGlldGYub3JnPjsgSVB2NiBMaXN0IDxpcHY2QGlldGYub3JnPjsgTWlj aGFlbCBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+OyBkaGN3ZyA8ZGhjd2dAaWV0 Zi5vcmc+DQo+IFN1YmplY3Q6IFJFOiBbRVhURVJOQUxdIFtkaGN3Z10gW3Y2b3BzXSBSZTogUXVl c3Rpb24gdG8gREhDUHY2IFJlbGF5IEltcGxlbWVudG9ycyByZWdhcmRpbmcgZHJhZnQtaWV0Zi1k aGMtZGhjcHY2LXBkLXJlbGF5LQ0KPiByZXF1aXJlbWVudHMNCj4gDQo+IEhpIEZyZWQsDQo+IFlv dSBuZWVkIHRoZSBjaGFsbGVuZ2UuIE9LLiBJIGhhdmUgaXQgZm9yIHlvdS4NCj4gDQo+IFR5cGlj YWwgcm91dGluZyBwcm90b2NvbHMgd291bGQgZGlzdHJpYnV0ZSB0byB0aGUgInN0dWIiIHJvdXRl ciBpbmZvcm1hdGlvbiBhYm91dCBwcmVmaXhlcyAic29tZXdoZXJlIGluIHRoZSBuZXR3b3JrIi4N Cj4gUHJlZml4ZXMgZnJvbSBsb2NhbCBpbnRlcmZhY2VzIGFyZSBpbnNlcnRlZCBpbnRvIHRoZSBy b3V0aW5nIHRhYmxlIGluIHRoZSB2ZXJ5IHBlcnNpc3RlbnQgd2F5Oi0pDQo+IA0KPiBESENQLVBE IHdvdWxkIGRpc3RyaWJ1dGUgdG8gdGhlICJzdHViIiByb3V0ZXIgaW5mb3JtYXRpb24gYWJvdXQg cHJlZml4ZXMgdGhhdCBzaG91bGQgYmVjb21lIGxvY2FsL2ludGVyZmFjZSBwcmVmaXhlcyBvbiB0 aGUgInN0dWIiLg0KPiBOb24tZ3JhY2VmdWwgcmVsb2FkIGNvdWxkIGxlYWQgdG8gYW1uZXNpYSBv biB0aGUgInN0dWIiLiBUaGVuIGl0IGNvdWxkIGF0dGFjayBpdHMgb3duIHVwbGluay4NCj4gSXQg aXMgYSBuZXcgcHJvYmxlbS4gQmVjYXVzZSBESENQLVBEIGRvZXMgcGxheSB0aGUgcm9sZSBvZiAi YXV0b21hdGljIHByb3Zpc2lvbmluZyBzeXN0ZW0iLCBub3Qgcm91dGluZyBwcm90b2NvbC4NCj4g VGhlIHByb2JsZW0gY291bGQgYmUgY2FsbGVkICJub24tY29uc2lzdGVudCByb3V0ZXJzIGNvbmZp Z3VyYXRpb24iLg0KPiBUaGUgZmFjdCB0aGF0IHByb3BlciBwcm90b2NvbCBmb3IgcHJlZml4IGRp c3RyaWJ1dGlvbiBzaG91bGQgYmUgdmVyeSBzaW1pbGFyIHRvIHJvdXRpbmcgcHJvdG9jb2wgLSBp cyB0aGUgc2Vjb25kYXJ5IGhlcmUgKGl0IGlzDQo+IGltcGxlbWVudGF0aW9uKSwgYmVjYXVzZSB0 aGUgcHJvYmxlbSBpdHNlbGYgaXMgbmV3Lg0KPiANCj4gRWR1YXJkDQo+ID4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBpcHY2IFttYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgVGVtcGxpbiAoVVMpLCBGcmVkIEwNCj4gPiBTZW50OiAxNSDQvtC6 0YLRj9Cx0YDRjyAyMDIwINCzLiAxOjM3DQo+ID4gVG86IEJvYiBIaW5kZW4gPGJvYi5oaW5kZW5A Z21haWwuY29tPg0KPiA+IENjOiB2Nm9wcyBsaXN0IDx2Nm9wc0BpZXRmLm9yZz47IElQdjYgTGlz dCA8aXB2NkBpZXRmLm9yZz47IE1pY2hhZWwgUmljaGFyZHNvbg0KPiA+IDxtY3IraWV0ZkBzYW5k ZWxtYW4uY2E+OyBkaGN3ZyA8ZGhjd2dAaWV0Zi5vcmc+DQo+ID4gU3ViamVjdDogUkU6IFtFWFRF Uk5BTF0gW2RoY3dnXSBbdjZvcHNdIFJlOiBRdWVzdGlvbiB0byBESENQdjYgUmVsYXkNCj4gPiBJ bXBsZW1lbnRvcnMgcmVnYXJkaW5nIGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1wZC1yZWxheS1yZXF1 aXJlbWVudHMNCj4gPg0KPiA+ID4gSSBub3RlIHRoYXQgdGhlIGxhY2sgb2Yg4oCcY2hhbGxlbmdl 4oCdIGRvZXMgbm90IG1lYW4gYW55b25lIGFncmVlcy4gICBBZ3JlZW1lbnQNCj4gPiBuZWVkcyB0 byBiZSBhZmZpcm1hdGl2ZS4NCj4gPg0KPiA+IEZhaXIgZW5vdWdoLCBCb2I7IGhlcmUgaXMgdGhl IGFzc2VydGlvbiBJIG1hZGUgdGhhdCBJIHdhcyByZWZlcnJpbmcgdG86DQo+ID4NCj4gPiArIEJU VywgSSBhbSBzdGlsbCB3YWl0aW5nIHRvIGhlYXIgaG93IHRoaXMgY29uY2VybiBpcyBpbiBhbnkg d2F5DQo+ID4gKyBzcGVjaWZpYyB0byBwcmVmaXggZGVsZWdhdGlvbiwgc2luY2UgaXQgc2VlbXMg dG8gYmUgZ2VuZXJpYyB0byBhbnkNCj4gPiArIGNhc2Ugb2YgaGF2aW5nIGEg4oCcc3R1YuKAnSBy b3V0ZXIgdGhhdCBtYWxpY2lvdXNseSBhdHRhY2tzIGl0cyBvd24NCj4gPiArIHVwc3RyZWFtIGxp bmsg4oCTIG5vIG1hdHRlciBob3cgdGhhdCByb3V0ZXIgbmVnb3RpYXRlcyBpdHMgcHJlZml4ZXMg d2l0aA0KPiA+IHVwc3RyZWFtIG5ldHdvcmsgbm9kZXMuDQo+ID4NCj4gPiBEbyB0aGUgaW5kaXZp ZHVhbHMgQ0MnZCBvbiB0aGlzIGxpc3QgYWdyZWUgdGhhdCB0aGlzIGlzIGEgZ2VuZXJpYyBJUHY2 IGlzc3VlIGFuZCBub3QgYQ0KPiA+IERIQ1B2Ni1QRC1zcGVjaWZpYyBpc3N1ZT8NCj4gPg0KPiA+ IFRoYW5rcyAtIEZyZWQNCj4gPg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g PiA+IEZyb206IEJvYiBIaW5kZW4gW21haWx0bzpib2IuaGluZGVuQGdtYWlsLmNvbV0NCj4gPiA+ IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxNCwgMjAyMCAzOjI4IFBNDQo+ID4gPiBUbzogVGVt cGxpbiAoVVMpLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+DQo+ID4gPiBDYzog Qm9iIEhpbmRlbiA8Ym9iLmhpbmRlbkBnbWFpbC5jb20+OyBNaWNoYWVsIFJpY2hhcmRzb24NCj4g PiA+IDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+OyBkaGN3ZyA8ZGhjd2dAaWV0Zi5vcmc+OyBJUHY2 IExpc3QNCj4gPiA+IDxpcHY2QGlldGYub3JnPjsgdjZvcHMgbGlzdCA8djZvcHNAaWV0Zi5vcmc+ DQo+ID4gPiBTdWJqZWN0OiBSZTogW0VYVEVSTkFMXSBbZGhjd2ddIFt2Nm9wc10gUmU6IFF1ZXN0 aW9uIHRvIERIQ1B2NiBSZWxheQ0KPiA+ID4gSW1wbGVtZW50b3JzIHJlZ2FyZGluZyBkcmFmdC1p ZXRmLWRoYy1kaGNwdjYtcGQtcmVsYXktIHJlcXVpcmVtZW50cw0KPiA+ID4NCj4gPiA+IEkgbm90 ZSB0aGF0IHRoZSBsYWNrIG9mIOKAnGNoYWxsZW5nZeKAnSBkb2VzIG5vdCBtZWFuIGFueW9uZSBh Z3JlZXMuICAgQWdyZWVtZW50DQo+ID4gbmVlZHMgdG8gYmUgYWZmaXJtYXRpdmUuDQo+ID4gPg0K PiA+ID4gQm9iDQo+ID4gPg0KPiA+ID4NCj4gPiA+ID4gT24gT2N0IDE0LCAyMDIwLCBhdCAzOjI0 IFBNLCBUZW1wbGluIChVUyksIEZyZWQgTA0KPiA+IDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29t PiB3cm90ZToNCj4gPiA+ID4NCj4gPiA+ID4gQm9iLCBzZXZlcmFsIG1lc3NhZ2VzIGJhY2sgaXQg d2FzIGVzdGFibGlzaGVkIHRoYXQgdGhlIGlzc3VlIGF0IHRoZQ0KPiA+ID4gPiBoZWFydCBvZiB0 aGlzIGRpc2N1c3Npb24gaXMgbm90IHNwZWNpZmljIHRvIERIQ1B2NiBub3IgREhDUHY2LVBELg0K PiA+ID4gPiBJbnN0ZWFkLCBpdCBpcyBhbiBpc3N1ZSB0aGF0IGlzIGNvbW1vbiB0byBhbnkgc2l0 dWF0aW9uIHdoZXJlIHRoZXJlDQo+ID4gPiA+IGFyZSBtdWx0aXBsZSAic3R1YiIgSVB2NiByb3V0 ZXJzIG9uIGEgZG93bnN0cmVhbSBsaW5rIGZyb20gYQ0KPiA+ID4gPiAiZGVmYXVsdCIgSVB2NiBy b3V0ZXIsIG5vIG1hdHRlciBob3cgdGhlIHJvdXRpbmcgaW5mb3JtYXRpb24gaXMNCj4gPiA+ID4g ZXN0YWJsaXNoZWQgb3IgbWFpbnRhaW5lZC4gU28gZmFyLCBubyBvbmUgaGFzIGNoYWxsZW5nZWQg bXkNCj4gPiA+ID4gYXNzZXJ0aW9uIHRoYXQgdGhpcyBpcyBhIGdlbmVyaWMgKGFuZCBub3QgYSBE SENQdjYtUEQtc3BlY2lmaWMpIElQdjYgaXNzdWUgYW5kDQo+ID4gSSBoYXZlIGJlZW4gd2FpdGlu ZyB0byBzZWUgaWYgYW55b25lIHdhbnRzIHRvIGNoYWxsZW5nZSB0aGF0Lg0KPiA+ID4gPg0KPiA+ ID4gPiBGcmVkDQo+ID4gPiA+DQo+ID4gPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiA+ID4gPj4gRnJvbTogQm9iIEhpbmRlbiBbbWFpbHRvOmJvYi5oaW5kZW5AZ21haWwuY29tXQ0K PiA+ID4gPj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDE0LCAyMDIwIDI6NDcgUE0NCj4gPiA+ ID4+IFRvOiBUZW1wbGluIChVUyksIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4N Cj4gPiA+ID4+IENjOiBCb2IgSGluZGVuIDxib2IuaGluZGVuQGdtYWlsLmNvbT47IE1pY2hhZWwg UmljaGFyZHNvbg0KPiA+ID4gPj4gPG1jcitpZXRmQHNhbmRlbG1hbi5jYT47IGRoY3dnIDxkaGN3 Z0BpZXRmLm9yZz47IElQdjYgTGlzdA0KPiA+ID4gPj4gPGlwdjZAaWV0Zi5vcmc+OyB2Nm9wcyBs aXN0IDx2Nm9wc0BpZXRmLm9yZz4NCj4gPiA+ID4+IFN1YmplY3Q6IFJlOiBbRVhURVJOQUxdIFtk aGN3Z10gW3Y2b3BzXSBSZTogUXVlc3Rpb24gdG8gREhDUHY2DQo+ID4gPiA+PiBSZWxheSBJbXBs ZW1lbnRvcnMgcmVnYXJkaW5nIGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1wZC1yZWxheS0NCj4gPiA+ ID4+IHJlcXVpcmVtZW50cw0KPiA+ID4gPj4NCj4gPiA+ID4+IFdpdGggbXkgY2hhaXIgaGF0IG9u LCBpcyB0aGVyZSBhIHJlYXNvbiB3aHkgdGhpcyBkaXNjdXNzaW9uIGlzIGJlaW5nIGNvcGllZA0K PiA+IHRvIHRoZSA2TUFOIHcuZy4/ICAgNk1BTiBkb2VzbuKAmXQgbWFpbnRhaW4gREhDUA0KPiA+ ID4gcmVsYXRlZA0KPiA+ID4gPj4gaXRlbXMuDQo+ID4gPiA+Pg0KPiA+ID4gPj4gUGxlYXNlIHJl bW92ZSBpcHY2QGlldGYub3JnIGZyb20gdGhpcyB0aHJlYWQuDQo+ID4gPiA+Pg0KPiA+ID4gPj4g Qm9iDQo+ID4gPiA+Pg0KPiA+ID4gPj4NCj4gPiA+ID4+PiBPbiBPY3QgMTQsIDIwMjAsIGF0IDEy OjE5IFBNLCBUZW1wbGluIChVUyksIEZyZWQgTA0KPiA+IDxGcmVkLkwuVGVtcGxpbkBib2Vpbmcu Y29tPiB3cm90ZToNCj4gPiA+ID4+Pg0KPiA+ID4gPj4+IEhpIE1pY2hhZWwsDQo+ID4gPiA+Pj4N Cj4gPiA+ID4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4+Pj4gRnJvbTog TWljaGFlbCBSaWNoYXJkc29uIFttYWlsdG86bWNyK2lldGZAc2FuZGVsbWFuLmNhXQ0KPiA+ID4g Pj4+PiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTQsIDIwMjAgMTE6NTggQU0NCj4gPiA+ID4+ Pj4gVG86IFRlbXBsaW4gKFVTKSwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0K PiA+ID4gPj4+PiBDYzogaWFuZmFycmVyQGdteC5jb207IEplbiBMaW5rb3ZhIDxmdXJyeTEzQGdt YWlsLmNvbT47IGRoY3dnDQo+ID4gPiA+Pj4+IDxkaGN3Z0BpZXRmLm9yZz47IHY2b3BzIGxpc3Qg PHY2b3BzQGlldGYub3JnPjsgNm1hbg0KPiA+ID4gPj4+PiA8aXB2NkBpZXRmLm9yZz4NCj4gPiA+ ID4+Pj4gU3ViamVjdDogUmU6IFtFWFRFUk5BTF0gUmU6IFtkaGN3Z10gW3Y2b3BzXSBSZTogUXVl c3Rpb24gdG8NCj4gPiA+ID4+Pj4gREhDUHY2IFJlbGF5IEltcGxlbWVudG9ycyByZWdhcmRpbmcg ZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LXBkLQ0KPiA+ID4gPj4gcmVsYXktDQo+ID4gPiA+Pj4+IHJl cXVpcmVtZW50cw0KPiA+ID4gPj4+Pg0KPiA+ID4gPj4+Pg0KPiA+ID4gPj4+PiBUZW1wbGluIChV UyksIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4gd3JvdGU6DQo+ID4gPiA+Pj4+ PiBNaWNoYWVsLCB3aGF0IEkgd2FzIHJlZmVycmluZyB0byBiZWxvdyBhcyAiZmFpbHVyZSIgaXMg dGhlIHByb3h5DQo+ID4gPiA+Pj4+PiBjYXNlIHdoZW4gdGhlcmUgaXMgYW4gTDIgcHJveHkgUCBi ZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHJlbGF5DQo+ID4gPiA+Pj4+PiAoZS5nLiwgUkZDNDg5KS4g VGhlcmUNCj4gPiA+ID4+Pj4NCj4gPiA+ID4+Pj4gUkZDNDM4OSBkZXNjcmliZXMgYW4gTkQgUHJv eHkuDQo+ID4gPiA+Pj4+IElzIHRoYXQgcmVhbGx5IGFuIEwyIHByb3h5Pw0KPiA+ID4gPj4+DQo+ ID4gPiA+Pj4gWWVzLCBJIGJlbGlldmUgaXQgaXMgYW4gTDIgcHJveHkuDQo+ID4gPiA+Pj4NCj4g PiA+ID4+Pj4gSXQgc2VlbXMgbGlrZSBpdCBhbHNvIG11c3QgYmUgY29udGFpbiBlaXRoZXIgYW4g TDItYnJpZGdlLCBvcg0KPiA+ID4gPj4+PiBtdXN0IGhhdmUgdGhlIEwzLXJvdXRpbmcgdGFibGUg ZW50cmllcyBpZiBpdCB3b3VsZCByZWFsbHkgYmUNCj4gPiA+ID4+Pj4gY2FwYWJsZSBvZiBwYXNz aW5nIERIQ1B2Ni1QRCBwcmVmaXhlcyB0aHJvdWdoIGl0Lg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4g VGhlIG9ubHkgdGhpbmcgaXQgaGFzIHRoYXQgaW5jbHVkZXMgTDMgaW5mb3JtYXRpb24gaXMgbmVp Z2hib3INCj4gPiA+ID4+PiBjYWNoZSBlbnRyaWVzIHRoYXQga2VlcCB0cmFjayBvZiB0aGUgY2xp ZW50J3MgYWN0dWFsIEwyIGFkZHJlc3Mgb24NCj4gPiA+ID4+PiB0aGUgZG93bnN0cmVhbSBsaW5r IHNlZ21lbnQsIGJ1dCByZXdyaXRlcyB0aGUgY2xpZW50J3MgTDIgYWRkcmVzcw0KPiA+ID4gPj4+ IHRvIGl0cyBvd24gTDIgYWRkcmVzcyB3aGVuIGZvcndhcmRpbmcgb250byBhbiB1cHN0cmVhbSBs aW5rDQo+ID4gPiA+Pj4gc2VnbWVudC4gKEluIHRoZSByZXZlcnNlIGRpcmVjdGlvbiwgaXQgcmVj ZWl2ZXMgcGFja2V0cyBkZXN0aW5lZA0KPiA+ID4gPj4+IHRvIGl0cyBvd24gTDIgYWRkcmVzcyBi dXQgdGhlIGNsaWVudCdzIEwzIGFkZHJlc3Mgb24gdGhlIHVwc3RyZWFtDQo+ID4gPiA+Pj4gbGlu ayBzZWdtZW50LCB0aGVuIHJld3JpdGVzIHRoZSBMMiBhZGRyZXNzIHRvIHRoZSBjbGllbnQncyBM Mg0KPiA+ID4gPj4+IGFkZHJlc3Mgd2hlbiBmb3J3YXJkaW5nIG9udG8gdGhlIGRvd25zdHJlYW0g bGluayBzZWdtZW50LikNCj4gPiA+ID4+Pg0KPiA+ID4gPj4+PiBDYW4geW91IGV4cGxhaW4gaG93 IHN1Y2ggYSBkZXZpY2Ugd291bGQgbm9ybWFsbHkgd29yayBmb3IgYQ0KPiA+ID4gPj4+PiBjbGll bnQgZGV2aWNlIEEsQixDLEQgZG9pbmcgREhDUHY2LVBEIHRocm91Z2ggaXQ/DQo+ID4gPiA+Pj4N Cj4gPiA+ID4+PiBTdXJlLiBBIHNlbmRzIGEgREhDUHY2IFNvbGljaXQgdXNpbmcgaXRzIElQdjYg bGluay1sb2NhbCBhZGRyZXNzDQo+ID4gPiA+Pj4gYXMgdGhlIHNvdXJjZSwgYW5kIGl0cyBMMiBh ZGRyZXNzIGFzIHRoZSBsaW5rLWxheWVyIHNvdXJjZS4gVGhlDQo+ID4gPiA+Pj4gcHJveHkgY29u dmVydHMgdGhlIGxpbmstbGF5ZXIgc291cmNlIHRvIGl0cyBvd24gTDIgYWRkcmVzcyB3aGVuDQo+ ID4gPiA+Pj4gZm9yd2FyZGluZyB0aGUgREhDUHY2IHNvbGljaXQgb250byB0aGUgdXBzdHJlYW0g bGluay4gV2hlbiB0aGUNCj4gPiA+ID4+PiBESENQdjYgUmVwbHkgY29tZXMgYmFjaywgdGhlIElQ djYgZGVzdGluYXRpb24gaXMgdGhhdCBvZiBjbGllbnQgQSwgYnV0IHRoZQ0KPiA+IGxpbmstbGF5 ZXIgZGVzdGluYXRpb24gaXMgdGhlIEwyIGFkZHJlc3Mgb2YgdGhlIHByb3h5Lg0KPiA+ID4gPj4+ IFRoZSBwcm94eSB0aGVuIGNvbnZlcnRzIHRoZSBMMiBkZXN0aW5hdGlvbiB0byB0aGUgYWRkcmVz cyBvZg0KPiA+ID4gPj4+IGNsaWVudCBBIGFuZCBmb3J3YXJkcyBpdCBvbiB0byB0aGUgY2xpZW50 Lg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4+IEFuZCBpcyB0aGUgZmFpbHVyZSBvbmUgd2hlcmUgdGhl IHJvdXRlciAiUiIgZmFpbHMgdG8gZHJvcCB0cmFmZmljDQo+ID4gPiA+Pj4+IGl0IHNob3VsZCwg b25lIHdoZXJlIHRoZSByb3V0ZXIgIlIiIGRyb3BzIHRyYWZmaWMgdGhhdCBpdCBzaG91bGRuJ3Q/ DQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiBJIHdhcyB0aGlua2luZyBtb3JlIGFsb25nIHRoZSBsaW5l cyBvZiB0aGUgbGF0dGVyOyBpZiB0aGUgb25seSB3YXkNCj4gPiA+ID4+PiB0aGF0IEEgaGFzIGZv ciB0YWxraW5nIHRvIEIsIEMsIEQsIGV0Yy4gaXMgYnkgZ29pbmcgdGhyb3VnaCBSLCBpdA0KPiA+ ID4gPj4+IHdvdWxkbid0IHdvcmsgaWYgUiB3YXMgdW5jb25kaXRpb25hbGx5IGRyb3BwaW5nIGV2 ZXJ5dGhpbmcuDQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiBUaGFua3MgLSBGcmVkDQo+ID4gPiA+Pj4N Cj4gPiA+ID4+Pj4gLS0NCj4gPiA+ID4+Pj4gTWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBz YW5kZWxtYW4uY2E+ICAgLiBvIE8gKCBJUHY2IEnDuFQNCj4gPiBjb25zdWx0aW5nICkNCj4gPiA+ ID4+Pj4gICAgICAgICAgU2FuZGVsbWFuIFNvZnR3YXJlIFdvcmtzIEluYywgT3R0YXdhIGFuZCBX b3JsZHdpZGUNCj4gPiA+ID4+Pj4NCj4gPiA+ID4+Pj4NCj4gPiA+ID4+Pj4NCj4gPiA+ID4+Pg0K PiA+ID4gPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4gPj4+IC0tIElFVEYgSVB2NiB3b3JraW5nIGdyb3Vw IG1haWxpbmcgbGlzdCBpcHY2QGlldGYub3JnDQo+ID4gPiA+Pj4gQWRtaW5pc3RyYXRpdmUgUmVx dWVzdHM6DQo+ID4gPiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p cHY2DQo+ID4gPiA+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiA+Pj4gLS0NCj4gPiA+ID4NCj4gPg0KPiA+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+ID4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+ ID4gaXB2NkBpZXRmLm9yZw0KPiA+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K From nobody Fri Oct 16 00:20: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 2D01F3A0CD5; Fri, 16 Oct 2020 00:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 stzQCu7wgbY2; Fri, 16 Oct 2020 00:20:03 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 1DFD53A0D70; Fri, 16 Oct 2020 00:20:03 -0700 (PDT) Received: from lhreml725-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 5A32C46386CEDFDE7901; Fri, 16 Oct 2020 08:19:59 +0100 (IST) Received: from msceml704-chm.china.huawei.com (10.219.141.143) by lhreml725-chm.china.huawei.com (10.201.108.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 16 Oct 2020 08:19:57 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml704-chm.china.huawei.com (10.219.141.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Fri, 16 Oct 2020 10:19:56 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Fri, 16 Oct 2020 10:19:56 +0300 From: Vasilenko Eduard To: "Templin (US), Fred L" CC: v6ops list , IPv6 List , Michael Richardson , dhcwg Thread-Topic: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AdajKLVV2M1crQrvQoqZsITGBawESAAYtVUQ Date: Fri, 16 Oct 2020 07:19:56 +0000 Message-ID: <533e7f91ae814feeb594bc42b7cd70c9@huawei.com> References: <65f390e222244427bd3cbc1f58a3ec95@boeing.com> In-Reply-To: <65f390e222244427bd3cbc1f58a3ec95@boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.204.25] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] [dhcwg] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Fri, 16 Oct 2020 07:20:05 -0000 SGkgRnJlZCwNCkkgZG8gbm90IGZ1bGx5IGFncmVlIHRvIHlvdS4NCg0KWWVzLCBzdWNoIGRhdGEg cGxhbmUgcHJvYmxlbSAobGlrZSB5b3UgZGVzY3JpYmVkKSBjb3VsZCBoYXBwZW4gaW4gdGhlIG9y ZGluYXJ5IHJvdXRpbmcgZW52aXJvbm1lbnQuDQpUaGVvcmV0aWNhbGx5LCBpdCBjb3VsZCBiZSBj cmVhdGVkIGJ5IHJvdXRpbmcgcHJvdG9jb2wgKGluIGNvbnRyb2wgcGxhbmUpLg0KUHJhY3RpY2Fs bHksIGFsbCByb3V0aW5nIHByb3RvY29scyBhcmUgcm9idXN0IGVub3VnaCBmb3Igc3VjaCBzaXR1 YXRpb24gbm90IHRvIGhhcHBlbiAtIHRoZXkgZG8gaGF2ZSBzb21lIG1lYW5zIHRvIHN5bmNocm9u aXplIHN0YXRlcyAoYXQgbGVhc3QgdHJhY2tpbmcgIm5laWdoYm9ycyIpLg0KDQpCdXQgaXQgaXMg bm90IHJlbGF0ZWQgdG8gREhDUC1QRCBkaXNjdXNzaW9uLg0KREhDUC1QRCBpcyBzdGF0ZWxlc3Mg d2l0aG91dCBpbmZvcm1hdGlvbiBzeW5jaHJvbml6YXRpb24gYWZ0ZXIgbGluayB1cC4gRXZlbiAi bGluayB1cCIgaXMgbm90IHBvc3NpYmxlIHRvIHRyYWNrIGlmIGl0IGlzIG11bHRpLWhvcCB0aHJv dWdoIGJyaWRnZS4NCkl0IGlzIGVhc3kgdG8gY3JlYXRlIHN1Y2ggYW1uZXNpYToganVzdCBwdXNo IHBvd2VyIGJ1dHRvbiBvbiB0aGUgc3R1YiByb3V0ZXIuDQoNCkhlbmNlLCBJIGRvIG5vdCB1bmRl cnN0YW5kIHRoZSBwb2ludCBvZiB5b3VyIGdlbmVyYWxpemF0aW9uLg0KSXQgaXMgbm90IHByb3Bl ciBnZW5lcmFsaXphdGlvbiwgYmVjYXVzZSBpdCBkb2VzIG5vdCB3b3JrIGluIGFsbCBlbnZpcm9u bWVudHMuDQpFc3BlY2lhbGx5IGl0IGlzIGltcG9ydGFudCB0aGF0IGl0IGRvZXMgbm90IHdvcmsg aW4gREhDUC1QRCBlbnZpcm9ubWVudC4NCg0KRWR1YXJkDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IFRlbXBsaW4gKFVTKSwgRnJlZCBMIFttYWlsdG86RnJlZC5MLlRlbXBs aW5AYm9laW5nLmNvbV0NCj4gU2VudDogMTUg0L7QutGC0Y/QsdGA0Y8gMjAyMCDQsy4gMjI6MzEN Cj4gVG86IFZhc2lsZW5rbyBFZHVhcmQgPHZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbT4NCj4g Q2M6IHY2b3BzIGxpc3QgPHY2b3BzQGlldGYub3JnPjsgSVB2NiBMaXN0IDxpcHY2QGlldGYub3Jn PjsgTWljaGFlbCBSaWNoYXJkc29uDQo+IDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+OyBkaGN3ZyA8 ZGhjd2dAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJFOiBbZGhjd2ddIFt2Nm9wc10gUmU6IFF1ZXN0 aW9uIHRvIERIQ1B2NiBSZWxheSBJbXBsZW1lbnRvcnMNCj4gcmVnYXJkaW5nIGRyYWZ0LWlldGYt ZGhjLWRoY3B2Ni1wZC1yZWxheS1yZXF1aXJlbWVudHMNCj4gDQo+IEVkdWFyZCwNCj4gDQo+IFRo YW5rcyBmb3IgeW91ciBtZXNzYWdlLiBUaGUgcG9pbnQgSSB3YXMgdHJ5aW5nIHRvIG1ha2UgaXMg dGhhdCBpZiB0aGUgdXBzdHJlYW0NCj4gcm91dGVyIFIgaXMgY29udmluY2VkIC0gdGhyb3VnaCB3 aGF0ZXZlciBtZWFucyAtIHRoYXQgdGhlIGRvd25zdHJlYW0gc3R1Yg0KPiByb3V0ZXIgUyBob2xk cyBhbiBJUHY2IHByZWZpeCBzdWNoIGFzIDIwMDE6ZGI4OmE6Yjo6LzY0LCB0aGVuIGl0IHdpbGwg Zm9yd2FyZCBhbGwNCj4gSVB2NiBwYWNrZXRzIHdpdGggZGVzdGluYXRpb24gYWRkcmVzcyBmcm9t IHRoYXQgcHJlZml4IHRvIFMgKmV2ZW4gaWYgdGhlIHBhY2tldHMNCj4gb3JpZ2luYXRlZCBmcm9t IFMqLg0KPiBUaGF0IGlzIG5vdCBhIG5ldyBpc3N1ZSBicm91Z2h0IGFib3V0IGJ5IERIQ1B2Niwg c2luY2UgaXQgaXMgIGEgZm9yd2FyZGluZyBwbGFuZQ0KPiBpc3N1ZSBhbmQgbm90IGEgY29udHJv bCBwbGFuZSBpc3N1ZS4NCj4gDQo+IEZyZWQNCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gPiBGcm9tOiBWYXNpbGVua28gRWR1YXJkIFttYWlsdG86dmFzaWxlbmtvLmVkdWFy ZEBodWF3ZWkuY29tXQ0KPiA+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE1LCAyMDIwIDEyOjEy IFBNDQo+ID4gVG86IFRlbXBsaW4gKFVTKSwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2Vpbmcu Y29tPg0KPiA+IENjOiB2Nm9wcyBsaXN0IDx2Nm9wc0BpZXRmLm9yZz47IElQdjYgTGlzdCA8aXB2 NkBpZXRmLm9yZz47IE1pY2hhZWwNCj4gPiBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4u Y2E+OyBkaGN3ZyA8ZGhjd2dAaWV0Zi5vcmc+DQo+ID4gU3ViamVjdDogUkU6IFtFWFRFUk5BTF0g W2RoY3dnXSBbdjZvcHNdIFJlOiBRdWVzdGlvbiB0byBESENQdjYgUmVsYXkNCj4gPiBJbXBsZW1l bnRvcnMgcmVnYXJkaW5nIGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1wZC1yZWxheS0gcmVxdWlyZW1l bnRzDQo+ID4NCj4gPiBIaSBGcmVkLA0KPiA+IFlvdSBuZWVkIHRoZSBjaGFsbGVuZ2UuIE9LLiBJ IGhhdmUgaXQgZm9yIHlvdS4NCj4gPg0KPiA+IFR5cGljYWwgcm91dGluZyBwcm90b2NvbHMgd291 bGQgZGlzdHJpYnV0ZSB0byB0aGUgInN0dWIiIHJvdXRlciBpbmZvcm1hdGlvbg0KPiBhYm91dCBw cmVmaXhlcyAic29tZXdoZXJlIGluIHRoZSBuZXR3b3JrIi4NCj4gPiBQcmVmaXhlcyBmcm9tIGxv Y2FsIGludGVyZmFjZXMgYXJlIGluc2VydGVkIGludG8gdGhlIHJvdXRpbmcgdGFibGUgaW4NCj4g PiB0aGUgdmVyeSBwZXJzaXN0ZW50IHdheTotKQ0KPiA+DQo+ID4gREhDUC1QRCB3b3VsZCBkaXN0 cmlidXRlIHRvIHRoZSAic3R1YiIgcm91dGVyIGluZm9ybWF0aW9uIGFib3V0IHByZWZpeGVzIHRo YXQNCj4gc2hvdWxkIGJlY29tZSBsb2NhbC9pbnRlcmZhY2UgcHJlZml4ZXMgb24gdGhlICJzdHVi Ii4NCj4gPiBOb24tZ3JhY2VmdWwgcmVsb2FkIGNvdWxkIGxlYWQgdG8gYW1uZXNpYSBvbiB0aGUg InN0dWIiLiBUaGVuIGl0IGNvdWxkIGF0dGFjaw0KPiBpdHMgb3duIHVwbGluay4NCj4gPiBJdCBp cyBhIG5ldyBwcm9ibGVtLiBCZWNhdXNlIERIQ1AtUEQgZG9lcyBwbGF5IHRoZSByb2xlIG9mICJh dXRvbWF0aWMNCj4gcHJvdmlzaW9uaW5nIHN5c3RlbSIsIG5vdCByb3V0aW5nIHByb3RvY29sLg0K PiA+IFRoZSBwcm9ibGVtIGNvdWxkIGJlIGNhbGxlZCAibm9uLWNvbnNpc3RlbnQgcm91dGVycyBj b25maWd1cmF0aW9uIi4NCj4gPiBUaGUgZmFjdCB0aGF0IHByb3BlciBwcm90b2NvbCBmb3IgcHJl Zml4IGRpc3RyaWJ1dGlvbiBzaG91bGQgYmUgdmVyeQ0KPiA+IHNpbWlsYXIgdG8gcm91dGluZyBw cm90b2NvbCAtIGlzIHRoZSBzZWNvbmRhcnkgaGVyZSAoaXQgaXMgaW1wbGVtZW50YXRpb24pLA0K PiBiZWNhdXNlIHRoZSBwcm9ibGVtIGl0c2VsZiBpcyBuZXcuDQo+ID4NCj4gPiBFZHVhcmQNCj4g PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBpcHY2IFttYWlsdG86 aXB2Ni1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGVtcGxpbiAoVVMpLA0KPiA+ID4g RnJlZCBMDQo+ID4gPiBTZW50OiAxNSDQvtC60YLRj9Cx0YDRjyAyMDIwINCzLiAxOjM3DQo+ID4g PiBUbzogQm9iIEhpbmRlbiA8Ym9iLmhpbmRlbkBnbWFpbC5jb20+DQo+ID4gPiBDYzogdjZvcHMg bGlzdCA8djZvcHNAaWV0Zi5vcmc+OyBJUHY2IExpc3QgPGlwdjZAaWV0Zi5vcmc+OyBNaWNoYWVs DQo+ID4gPiBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+OyBkaGN3ZyA8ZGhjd2dA aWV0Zi5vcmc+DQo+ID4gPiBTdWJqZWN0OiBSRTogW0VYVEVSTkFMXSBbZGhjd2ddIFt2Nm9wc10g UmU6IFF1ZXN0aW9uIHRvIERIQ1B2NiBSZWxheQ0KPiA+ID4gSW1wbGVtZW50b3JzIHJlZ2FyZGlu ZyBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtcGQtcmVsYXktcmVxdWlyZW1lbnRzDQo+ID4gPg0KPiA+ ID4gPiBJIG5vdGUgdGhhdCB0aGUgbGFjayBvZiDigJxjaGFsbGVuZ2XigJ0gZG9lcyBub3QgbWVh biBhbnlvbmUgYWdyZWVzLg0KPiBBZ3JlZW1lbnQNCj4gPiA+IG5lZWRzIHRvIGJlIGFmZmlybWF0 aXZlLg0KPiA+ID4NCj4gPiA+IEZhaXIgZW5vdWdoLCBCb2I7IGhlcmUgaXMgdGhlIGFzc2VydGlv biBJIG1hZGUgdGhhdCBJIHdhcyByZWZlcnJpbmcgdG86DQo+ID4gPg0KPiA+ID4gKyBCVFcsIEkg YW0gc3RpbGwgd2FpdGluZyB0byBoZWFyIGhvdyB0aGlzIGNvbmNlcm4gaXMgaW4gYW55IHdheQ0K PiA+ID4gKyBzcGVjaWZpYyB0byBwcmVmaXggZGVsZWdhdGlvbiwgc2luY2UgaXQgc2VlbXMgdG8g YmUgZ2VuZXJpYyB0byBhbnkNCj4gPiA+ICsgY2FzZSBvZiBoYXZpbmcgYSDigJxzdHVi4oCdIHJv dXRlciB0aGF0IG1hbGljaW91c2x5IGF0dGFja3MgaXRzIG93bg0KPiA+ID4gKyB1cHN0cmVhbSBs aW5rIOKAkyBubyBtYXR0ZXIgaG93IHRoYXQgcm91dGVyIG5lZ290aWF0ZXMgaXRzIHByZWZpeGVz DQo+ID4gPiArIHdpdGgNCj4gPiA+IHVwc3RyZWFtIG5ldHdvcmsgbm9kZXMuDQo+ID4gPg0KPiA+ ID4gRG8gdGhlIGluZGl2aWR1YWxzIENDJ2Qgb24gdGhpcyBsaXN0IGFncmVlIHRoYXQgdGhpcyBp cyBhIGdlbmVyaWMNCj4gPiA+IElQdjYgaXNzdWUgYW5kIG5vdCBhIERIQ1B2Ni1QRC1zcGVjaWZp YyBpc3N1ZT8NCj4gPiA+DQo+ID4gPiBUaGFua3MgLSBGcmVkDQo+ID4gPg0KPiA+ID4gPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiBGcm9tOiBCb2IgSGluZGVuIFttYWlsdG86 Ym9iLmhpbmRlbkBnbWFpbC5jb21dDQo+ID4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAx NCwgMjAyMCAzOjI4IFBNDQo+ID4gPiA+IFRvOiBUZW1wbGluIChVUyksIEZyZWQgTCA8RnJlZC5M LlRlbXBsaW5AYm9laW5nLmNvbT4NCj4gPiA+ID4gQ2M6IEJvYiBIaW5kZW4gPGJvYi5oaW5kZW5A Z21haWwuY29tPjsgTWljaGFlbCBSaWNoYXJkc29uDQo+ID4gPiA+IDxtY3IraWV0ZkBzYW5kZWxt YW4uY2E+OyBkaGN3ZyA8ZGhjd2dAaWV0Zi5vcmc+OyBJUHY2IExpc3QNCj4gPiA+ID4gPGlwdjZA aWV0Zi5vcmc+OyB2Nm9wcyBsaXN0IDx2Nm9wc0BpZXRmLm9yZz4NCj4gPiA+ID4gU3ViamVjdDog UmU6IFtFWFRFUk5BTF0gW2RoY3dnXSBbdjZvcHNdIFJlOiBRdWVzdGlvbiB0byBESENQdjYNCj4g PiA+ID4gUmVsYXkgSW1wbGVtZW50b3JzIHJlZ2FyZGluZyBkcmFmdC1pZXRmLWRoYy1kaGNwdjYt cGQtcmVsYXktDQo+ID4gPiA+IHJlcXVpcmVtZW50cw0KPiA+ID4gPg0KPiA+ID4gPiBJIG5vdGUg dGhhdCB0aGUgbGFjayBvZiDigJxjaGFsbGVuZ2XigJ0gZG9lcyBub3QgbWVhbiBhbnlvbmUgYWdy ZWVzLg0KPiBBZ3JlZW1lbnQNCj4gPiA+IG5lZWRzIHRvIGJlIGFmZmlybWF0aXZlLg0KPiA+ID4g Pg0KPiA+ID4gPiBCb2INCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gPiBPbiBPY3QgMTQsIDIw MjAsIGF0IDM6MjQgUE0sIFRlbXBsaW4gKFVTKSwgRnJlZCBMDQo+ID4gPiA8RnJlZC5MLlRlbXBs aW5AYm9laW5nLmNvbT4gd3JvdGU6DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBCb2IsIHNldmVyYWwg bWVzc2FnZXMgYmFjayBpdCB3YXMgZXN0YWJsaXNoZWQgdGhhdCB0aGUgaXNzdWUgYXQNCj4gPiA+ ID4gPiB0aGUgaGVhcnQgb2YgdGhpcyBkaXNjdXNzaW9uIGlzIG5vdCBzcGVjaWZpYyB0byBESENQ djYgbm9yIERIQ1B2Ni1QRC4NCj4gPiA+ID4gPiBJbnN0ZWFkLCBpdCBpcyBhbiBpc3N1ZSB0aGF0 IGlzIGNvbW1vbiB0byBhbnkgc2l0dWF0aW9uIHdoZXJlDQo+ID4gPiA+ID4gdGhlcmUgYXJlIG11 bHRpcGxlICJzdHViIiBJUHY2IHJvdXRlcnMgb24gYSBkb3duc3RyZWFtIGxpbmsgZnJvbQ0KPiA+ ID4gPiA+IGEgImRlZmF1bHQiIElQdjYgcm91dGVyLCBubyBtYXR0ZXIgaG93IHRoZSByb3V0aW5n IGluZm9ybWF0aW9uDQo+ID4gPiA+ID4gaXMgZXN0YWJsaXNoZWQgb3IgbWFpbnRhaW5lZC4gU28g ZmFyLCBubyBvbmUgaGFzIGNoYWxsZW5nZWQgbXkNCj4gPiA+ID4gPiBhc3NlcnRpb24gdGhhdCB0 aGlzIGlzIGEgZ2VuZXJpYyAoYW5kIG5vdCBhIERIQ1B2Ni1QRC1zcGVjaWZpYykNCj4gPiA+ID4g PiBJUHY2IGlzc3VlIGFuZA0KPiA+ID4gSSBoYXZlIGJlZW4gd2FpdGluZyB0byBzZWUgaWYgYW55 b25lIHdhbnRzIHRvIGNoYWxsZW5nZSB0aGF0Lg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gRnJlZA0K PiA+ID4gPiA+DQo+ID4gPiA+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ ID4+IEZyb206IEJvYiBIaW5kZW4gW21haWx0bzpib2IuaGluZGVuQGdtYWlsLmNvbV0NCj4gPiA+ ID4gPj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDE0LCAyMDIwIDI6NDcgUE0NCj4gPiA+ID4g Pj4gVG86IFRlbXBsaW4gKFVTKSwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2VpbmcuY29tPg0K PiA+ID4gPiA+PiBDYzogQm9iIEhpbmRlbiA8Ym9iLmhpbmRlbkBnbWFpbC5jb20+OyBNaWNoYWVs IFJpY2hhcmRzb24NCj4gPiA+ID4gPj4gPG1jcitpZXRmQHNhbmRlbG1hbi5jYT47IGRoY3dnIDxk aGN3Z0BpZXRmLm9yZz47IElQdjYgTGlzdA0KPiA+ID4gPiA+PiA8aXB2NkBpZXRmLm9yZz47IHY2 b3BzIGxpc3QgPHY2b3BzQGlldGYub3JnPg0KPiA+ID4gPiA+PiBTdWJqZWN0OiBSZTogW0VYVEVS TkFMXSBbZGhjd2ddIFt2Nm9wc10gUmU6IFF1ZXN0aW9uIHRvIERIQ1B2Ng0KPiA+ID4gPiA+PiBS ZWxheSBJbXBsZW1lbnRvcnMgcmVnYXJkaW5nIGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1wZC1yZWxh eS0NCj4gPiA+ID4gPj4gcmVxdWlyZW1lbnRzDQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+IFdpdGgg bXkgY2hhaXIgaGF0IG9uLCBpcyB0aGVyZSBhIHJlYXNvbiB3aHkgdGhpcyBkaXNjdXNzaW9uIGlz DQo+ID4gPiA+ID4+IGJlaW5nIGNvcGllZA0KPiA+ID4gdG8gdGhlIDZNQU4gdy5nLj8gICA2TUFO IGRvZXNu4oCZdCBtYWludGFpbiBESENQDQo+ID4gPiA+IHJlbGF0ZWQNCj4gPiA+ID4gPj4gaXRl bXMuDQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+IFBsZWFzZSByZW1vdmUgaXB2NkBpZXRmLm9yZyBm cm9tIHRoaXMgdGhyZWFkLg0KPiA+ID4gPiA+Pg0KPiA+ID4gPiA+PiBCb2INCj4gPiA+ID4gPj4N Cj4gPiA+ID4gPj4NCj4gPiA+ID4gPj4+IE9uIE9jdCAxNCwgMjAyMCwgYXQgMTI6MTkgUE0sIFRl bXBsaW4gKFVTKSwgRnJlZCBMDQo+ID4gPiA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4gd3Jv dGU6DQo+ID4gPiA+ID4+Pg0KPiA+ID4gPiA+Pj4gSGkgTWljaGFlbCwNCj4gPiA+ID4gPj4+DQo+ ID4gPiA+ID4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPj4+PiBGcm9t OiBNaWNoYWVsIFJpY2hhcmRzb24gW21haWx0bzptY3IraWV0ZkBzYW5kZWxtYW4uY2FdDQo+ID4g PiA+ID4+Pj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDE0LCAyMDIwIDExOjU4IEFNDQo+ID4g PiA+ID4+Pj4gVG86IFRlbXBsaW4gKFVTKSwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2Vpbmcu Y29tPg0KPiA+ID4gPiA+Pj4+IENjOiBpYW5mYXJyZXJAZ214LmNvbTsgSmVuIExpbmtvdmEgPGZ1 cnJ5MTNAZ21haWwuY29tPjsgZGhjd2cNCj4gPiA+ID4gPj4+PiA8ZGhjd2dAaWV0Zi5vcmc+OyB2 Nm9wcyBsaXN0IDx2Nm9wc0BpZXRmLm9yZz47IDZtYW4NCj4gPiA+ID4gPj4+PiA8aXB2NkBpZXRm Lm9yZz4NCj4gPiA+ID4gPj4+PiBTdWJqZWN0OiBSZTogW0VYVEVSTkFMXSBSZTogW2RoY3dnXSBb djZvcHNdIFJlOiBRdWVzdGlvbiB0bw0KPiA+ID4gPiA+Pj4+IERIQ1B2NiBSZWxheSBJbXBsZW1l bnRvcnMgcmVnYXJkaW5nIGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1wZC0NCj4gPiA+ID4gPj4gcmVs YXktDQo+ID4gPiA+ID4+Pj4gcmVxdWlyZW1lbnRzDQo+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPj4+ Pg0KPiA+ID4gPiA+Pj4+IFRlbXBsaW4gKFVTKSwgRnJlZCBMIDxGcmVkLkwuVGVtcGxpbkBib2Vp bmcuY29tPiB3cm90ZToNCj4gPiA+ID4gPj4+Pj4gTWljaGFlbCwgd2hhdCBJIHdhcyByZWZlcnJp bmcgdG8gYmVsb3cgYXMgImZhaWx1cmUiIGlzIHRoZQ0KPiA+ID4gPiA+Pj4+PiBwcm94eSBjYXNl IHdoZW4gdGhlcmUgaXMgYW4gTDIgcHJveHkgUCBiZXR3ZWVuIHRoZSBjbGllbnQNCj4gPiA+ID4g Pj4+Pj4gYW5kIHJlbGF5IChlLmcuLCBSRkM0ODkpLiBUaGVyZQ0KPiA+ID4gPiA+Pj4+DQo+ID4g PiA+ID4+Pj4gUkZDNDM4OSBkZXNjcmliZXMgYW4gTkQgUHJveHkuDQo+ID4gPiA+ID4+Pj4gSXMg dGhhdCByZWFsbHkgYW4gTDIgcHJveHk/DQo+ID4gPiA+ID4+Pg0KPiA+ID4gPiA+Pj4gWWVzLCBJ IGJlbGlldmUgaXQgaXMgYW4gTDIgcHJveHkuDQo+ID4gPiA+ID4+Pg0KPiA+ID4gPiA+Pj4+IEl0 IHNlZW1zIGxpa2UgaXQgYWxzbyBtdXN0IGJlIGNvbnRhaW4gZWl0aGVyIGFuIEwyLWJyaWRnZSwg b3INCj4gPiA+ID4gPj4+PiBtdXN0IGhhdmUgdGhlIEwzLXJvdXRpbmcgdGFibGUgZW50cmllcyBp ZiBpdCB3b3VsZCByZWFsbHkgYmUNCj4gPiA+ID4gPj4+PiBjYXBhYmxlIG9mIHBhc3NpbmcgREhD UHY2LVBEIHByZWZpeGVzIHRocm91Z2ggaXQuDQo+ID4gPiA+ID4+Pg0KPiA+ID4gPiA+Pj4gVGhl IG9ubHkgdGhpbmcgaXQgaGFzIHRoYXQgaW5jbHVkZXMgTDMgaW5mb3JtYXRpb24gaXMgbmVpZ2hi b3INCj4gPiA+ID4gPj4+IGNhY2hlIGVudHJpZXMgdGhhdCBrZWVwIHRyYWNrIG9mIHRoZSBjbGll bnQncyBhY3R1YWwgTDINCj4gPiA+ID4gPj4+IGFkZHJlc3Mgb24gdGhlIGRvd25zdHJlYW0gbGlu ayBzZWdtZW50LCBidXQgcmV3cml0ZXMgdGhlDQo+ID4gPiA+ID4+PiBjbGllbnQncyBMMiBhZGRy ZXNzIHRvIGl0cyBvd24gTDIgYWRkcmVzcyB3aGVuIGZvcndhcmRpbmcgb250bw0KPiA+ID4gPiA+ Pj4gYW4gdXBzdHJlYW0gbGluayBzZWdtZW50LiAoSW4gdGhlIHJldmVyc2UgZGlyZWN0aW9uLCBp dA0KPiA+ID4gPiA+Pj4gcmVjZWl2ZXMgcGFja2V0cyBkZXN0aW5lZCB0byBpdHMgb3duIEwyIGFk ZHJlc3MgYnV0IHRoZQ0KPiA+ID4gPiA+Pj4gY2xpZW50J3MgTDMgYWRkcmVzcyBvbiB0aGUgdXBz dHJlYW0gbGluayBzZWdtZW50LCB0aGVuDQo+ID4gPiA+ID4+PiByZXdyaXRlcyB0aGUgTDIgYWRk cmVzcyB0byB0aGUgY2xpZW50J3MgTDIgYWRkcmVzcyB3aGVuDQo+ID4gPiA+ID4+PiBmb3J3YXJk aW5nIG9udG8gdGhlIGRvd25zdHJlYW0gbGluayBzZWdtZW50LikNCj4gPiA+ID4gPj4+DQo+ID4g PiA+ID4+Pj4gQ2FuIHlvdSBleHBsYWluIGhvdyBzdWNoIGEgZGV2aWNlIHdvdWxkIG5vcm1hbGx5 IHdvcmsgZm9yIGENCj4gPiA+ID4gPj4+PiBjbGllbnQgZGV2aWNlIEEsQixDLEQgZG9pbmcgREhD UHY2LVBEIHRocm91Z2ggaXQ/DQo+ID4gPiA+ID4+Pg0KPiA+ID4gPiA+Pj4gU3VyZS4gQSBzZW5k cyBhIERIQ1B2NiBTb2xpY2l0IHVzaW5nIGl0cyBJUHY2IGxpbmstbG9jYWwNCj4gPiA+ID4gPj4+ IGFkZHJlc3MgYXMgdGhlIHNvdXJjZSwgYW5kIGl0cyBMMiBhZGRyZXNzIGFzIHRoZSBsaW5rLWxh eWVyDQo+ID4gPiA+ID4+PiBzb3VyY2UuIFRoZSBwcm94eSBjb252ZXJ0cyB0aGUgbGluay1sYXll ciBzb3VyY2UgdG8gaXRzIG93biBMMg0KPiA+ID4gPiA+Pj4gYWRkcmVzcyB3aGVuIGZvcndhcmRp bmcgdGhlIERIQ1B2NiBzb2xpY2l0IG9udG8gdGhlIHVwc3RyZWFtDQo+ID4gPiA+ID4+PiBsaW5r LiBXaGVuIHRoZQ0KPiA+ID4gPiA+Pj4gREhDUHY2IFJlcGx5IGNvbWVzIGJhY2ssIHRoZSBJUHY2 IGRlc3RpbmF0aW9uIGlzIHRoYXQgb2YNCj4gPiA+ID4gPj4+IGNsaWVudCBBLCBidXQgdGhlDQo+ ID4gPiBsaW5rLWxheWVyIGRlc3RpbmF0aW9uIGlzIHRoZSBMMiBhZGRyZXNzIG9mIHRoZSBwcm94 eS4NCj4gPiA+ID4gPj4+IFRoZSBwcm94eSB0aGVuIGNvbnZlcnRzIHRoZSBMMiBkZXN0aW5hdGlv biB0byB0aGUgYWRkcmVzcyBvZg0KPiA+ID4gPiA+Pj4gY2xpZW50IEEgYW5kIGZvcndhcmRzIGl0 IG9uIHRvIHRoZSBjbGllbnQuDQo+ID4gPiA+ID4+Pg0KPiA+ID4gPiA+Pj4+IEFuZCBpcyB0aGUg ZmFpbHVyZSBvbmUgd2hlcmUgdGhlIHJvdXRlciAiUiIgZmFpbHMgdG8gZHJvcA0KPiA+ID4gPiA+ Pj4+IHRyYWZmaWMgaXQgc2hvdWxkLCBvbmUgd2hlcmUgdGhlIHJvdXRlciAiUiIgZHJvcHMgdHJh ZmZpYyB0aGF0IGl0DQo+IHNob3VsZG4ndD8NCj4gPiA+ID4gPj4+DQo+ID4gPiA+ID4+PiBJIHdh cyB0aGlua2luZyBtb3JlIGFsb25nIHRoZSBsaW5lcyBvZiB0aGUgbGF0dGVyOyBpZiB0aGUgb25s eQ0KPiA+ID4gPiA+Pj4gd2F5IHRoYXQgQSBoYXMgZm9yIHRhbGtpbmcgdG8gQiwgQywgRCwgZXRj LiBpcyBieSBnb2luZw0KPiA+ID4gPiA+Pj4gdGhyb3VnaCBSLCBpdCB3b3VsZG4ndCB3b3JrIGlm IFIgd2FzIHVuY29uZGl0aW9uYWxseSBkcm9wcGluZw0KPiBldmVyeXRoaW5nLg0KPiA+ID4gPiA+ Pj4NCj4gPiA+ID4gPj4+IFRoYW5rcyAtIEZyZWQNCj4gPiA+ID4gPj4+DQo+ID4gPiA+ID4+Pj4g LS0NCj4gPiA+ID4gPj4+PiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5j YT4gICAuIG8gTyAoIElQdjYgScO4VA0KPiA+ID4gY29uc3VsdGluZyApDQo+ID4gPiA+ID4+Pj4g ICAgICAgICAgU2FuZGVsbWFuIFNvZnR3YXJlIFdvcmtzIEluYywgT3R0YXdhIGFuZCBXb3JsZHdp ZGUNCj4gPiA+ID4gPj4+Pg0KPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4+Pj4NCj4gPiA+ID4gPj4+ DQo+ID4gPiA+ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4gPiA+Pj4gLS0tLQ0KPiA+ID4gPiA+Pj4gLS0gSUVU RiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0IGlwdjZAaWV0Zi5vcmcNCj4gPiA+ID4g Pj4+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOg0KPiA+ID4gPiA+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+ID4gPiA+ID4+PiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4gPiA+ Pj4gLS0tLQ0KPiA+ID4gPiA+Pj4gLS0NCj4gPiA+ID4gPg0KPiA+ID4NCj4gPiA+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+ID4gPiBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QgaXB2NkBpZXRm Lm9yZyBBZG1pbmlzdHJhdGl2ZQ0KPiA+ID4gUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiA+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== From nobody Fri Oct 16 08:53: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 20B0B3A0FA5; Fri, 16 Oct 2020 08:53:44 -0700 (PDT) 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, 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=boeing.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 OWxSwR9ABgse; Fri, 16 Oct 2020 08:53:41 -0700 (PDT) Received: from clt-mbsout-02.mbs.boeing.net (clt-mbsout-02.mbs.boeing.net [130.76.144.163]) (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 D51883A0475; Fri, 16 Oct 2020 08:53:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09GFrc69026793; Fri, 16 Oct 2020 11:53:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602863618; bh=VvqdxkZIdbS938/xmtgTBGA9cm2cpSKfziED3IAh/4E=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=tELmgbE94ML/oQcmOPjjYVVj9tZyupnfM2cHIdS1h2/rojGdRnzYDVq3ckqjxEG3Z UdTqVt8xZaSv5YCpOyzHV0thyZYQIwTV8ixckc3pQAB7jmmignAbIVCQxG8r1P0B8x dhMKiE3o6F8HYIesdNhHLFcCer1nld5LwMslJvibTXFt7bhdRGRhgadagJw90/2fyY Jrl41ndNB738Qulvb5oNq0bGSq6dVTWNEkbcF8gdRvKAQWGFOupQW/ktLZpqgd9mMg 1kz7NT1Y1Gy8XR+TRs9zb5ZewcyIUIHNGsP2EM1ED6w8qbfbyCGFxtYd1utkleE8g/ q7gE8kOSMOuEg== Received: from XCH16-07-12.nos.boeing.com (xch16-07-12.nos.boeing.com [144.115.66.114]) by clt-mbsout-02.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09GFrRmV025427 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 16 Oct 2020 11:53:27 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-12.nos.boeing.com (144.115.66.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Fri, 16 Oct 2020 08:53:26 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Fri, 16 Oct 2020 08:53:26 -0700 From: "Templin (US), Fred L" To: Vasilenko Eduard CC: v6ops list , IPv6 List , Michael Richardson , dhcwg Thread-Topic: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AdajKLVVnwghNqrLQ4229LT3ce4i4AAnrasAAAMwSKA= Date: Fri, 16 Oct 2020 15:53:26 +0000 Message-ID: References: <65f390e222244427bd3cbc1f58a3ec95@boeing.com> <533e7f91ae814feeb594bc42b7cd70c9@huawei.com> In-Reply-To: <533e7f91ae814feeb594bc42b7cd70c9@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: F32CE78AFCA70C8A887F5AEC1D77B0312AB368A682C3782C761F446DD954DA672000:8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [dhcwg] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Fri, 16 Oct 2020 15:53:44 -0000 RWR1YXJkLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFZhc2lsZW5r byBFZHVhcmQgW21haWx0bzp2YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb21dDQo+IFNlbnQ6IEZy aWRheSwgT2N0b2JlciAxNiwgMjAyMCAxMjoyMCBBTQ0KPiBUbzogVGVtcGxpbiAoVVMpLCBGcmVk IEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+DQo+IENjOiB2Nm9wcyBsaXN0IDx2Nm9wc0Bp ZXRmLm9yZz47IElQdjYgTGlzdCA8aXB2NkBpZXRmLm9yZz47IE1pY2hhZWwgUmljaGFyZHNvbiA8 bWNyK2lldGZAc2FuZGVsbWFuLmNhPjsgZGhjd2cgPGRoY3dnQGlldGYub3JnPg0KPiBTdWJqZWN0 OiBbRVhURVJOQUxdIFJFOiBbZGhjd2ddIFt2Nm9wc10gUmU6IFF1ZXN0aW9uIHRvIERIQ1B2NiBS ZWxheSBJbXBsZW1lbnRvcnMgcmVnYXJkaW5nIGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1wZC1yZWxh eS0NCj4gcmVxdWlyZW1lbnRzDQo+DQo+IEhpIEZyZWQsDQo+IEkgZG8gbm90IGZ1bGx5IGFncmVl IHRvIHlvdS4NCg0KV2UgYXJlIHRhbGtpbmcgcGFzdCBlYWNoIG90aGVyLCBhbmQgb25lIG9mIHVz IGRvZXMgbm90IGhhdmUgYSBjbGVhciB1bmRlcnN0YW5kaW5nDQpvZiB0aGUgaXNzdWUgYXQgdGhl IGhlYXJ0IG9mIHRoZSBkaXNjdXNzaW9uIHdoaWNoIEkgc2VlIGFzIGEgZm9yd2FyZGluZyBwbGFu ZSBpc3N1ZQ0KaGF2aW5nIG5vdGhpbmcgdG8gZG8gd2l0aCB0aGUgY29udHJvbCBwbGFuZS4NCg0K VGhhbmtzIC0gRnJlZA0KDQo+IFllcywgc3VjaCBkYXRhIHBsYW5lIHByb2JsZW0gKGxpa2UgeW91 IGRlc2NyaWJlZCkgY291bGQgaGFwcGVuIGluIHRoZSBvcmRpbmFyeSByb3V0aW5nIGVudmlyb25t ZW50Lg0KPiBUaGVvcmV0aWNhbGx5LCBpdCBjb3VsZCBiZSBjcmVhdGVkIGJ5IHJvdXRpbmcgcHJv dG9jb2wgKGluIGNvbnRyb2wgcGxhbmUpLg0KPiBQcmFjdGljYWxseSwgYWxsIHJvdXRpbmcgcHJv dG9jb2xzIGFyZSByb2J1c3QgZW5vdWdoIGZvciBzdWNoIHNpdHVhdGlvbiBub3QgdG8gaGFwcGVu IC0gdGhleSBkbyBoYXZlIHNvbWUgbWVhbnMgdG8gc3luY2hyb25pemUgc3RhdGVzDQo+IChhdCBs ZWFzdCB0cmFja2luZyAibmVpZ2hib3JzIikuDQo+IA0KPiBCdXQgaXQgaXMgbm90IHJlbGF0ZWQg dG8gREhDUC1QRCBkaXNjdXNzaW9uLg0KPiBESENQLVBEIGlzIHN0YXRlbGVzcyB3aXRob3V0IGlu Zm9ybWF0aW9uIHN5bmNocm9uaXphdGlvbiBhZnRlciBsaW5rIHVwLiBFdmVuICJsaW5rIHVwIiBp cyBub3QgcG9zc2libGUgdG8gdHJhY2sgaWYgaXQgaXMgbXVsdGktaG9wIHRocm91Z2gNCj4gYnJp ZGdlLg0KPiBJdCBpcyBlYXN5IHRvIGNyZWF0ZSBzdWNoIGFtbmVzaWE6IGp1c3QgcHVzaCBwb3dl ciBidXR0b24gb24gdGhlIHN0dWIgcm91dGVyLg0KPiANCj4gSGVuY2UsIEkgZG8gbm90IHVuZGVy c3RhbmQgdGhlIHBvaW50IG9mIHlvdXIgZ2VuZXJhbGl6YXRpb24uDQo+IEl0IGlzIG5vdCBwcm9w ZXIgZ2VuZXJhbGl6YXRpb24sIGJlY2F1c2UgaXQgZG9lcyBub3Qgd29yayBpbiBhbGwgZW52aXJv bm1lbnRzLg0KPiBFc3BlY2lhbGx5IGl0IGlzIGltcG9ydGFudCB0aGF0IGl0IGRvZXMgbm90IHdv cmsgaW4gREhDUC1QRCBlbnZpcm9ubWVudC4NCj4gDQo+IEVkdWFyZA0KPiA+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogVGVtcGxpbiAoVVMpLCBGcmVkIEwgW21haWx0bzpG cmVkLkwuVGVtcGxpbkBib2VpbmcuY29tXQ0KPiA+IFNlbnQ6IDE1INC+0LrRgtGP0LHRgNGPIDIw MjAg0LMuIDIyOjMxDQo+ID4gVG86IFZhc2lsZW5rbyBFZHVhcmQgPHZhc2lsZW5rby5lZHVhcmRA aHVhd2VpLmNvbT4NCj4gPiBDYzogdjZvcHMgbGlzdCA8djZvcHNAaWV0Zi5vcmc+OyBJUHY2IExp c3QgPGlwdjZAaWV0Zi5vcmc+OyBNaWNoYWVsIFJpY2hhcmRzb24NCj4gPiA8bWNyK2lldGZAc2Fu ZGVsbWFuLmNhPjsgZGhjd2cgPGRoY3dnQGlldGYub3JnPg0KPiA+IFN1YmplY3Q6IFJFOiBbZGhj d2ddIFt2Nm9wc10gUmU6IFF1ZXN0aW9uIHRvIERIQ1B2NiBSZWxheSBJbXBsZW1lbnRvcnMNCj4g PiByZWdhcmRpbmcgZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LXBkLXJlbGF5LXJlcXVpcmVtZW50cw0K PiA+DQo+ID4gRWR1YXJkLA0KPiA+DQo+ID4gVGhhbmtzIGZvciB5b3VyIG1lc3NhZ2UuIFRoZSBw b2ludCBJIHdhcyB0cnlpbmcgdG8gbWFrZSBpcyB0aGF0IGlmIHRoZSB1cHN0cmVhbQ0KPiA+IHJv dXRlciBSIGlzIGNvbnZpbmNlZCAtIHRocm91Z2ggd2hhdGV2ZXIgbWVhbnMgLSB0aGF0IHRoZSBk b3duc3RyZWFtIHN0dWINCj4gPiByb3V0ZXIgUyBob2xkcyBhbiBJUHY2IHByZWZpeCBzdWNoIGFz IDIwMDE6ZGI4OmE6Yjo6LzY0LCB0aGVuIGl0IHdpbGwgZm9yd2FyZCBhbGwNCj4gPiBJUHY2IHBh Y2tldHMgd2l0aCBkZXN0aW5hdGlvbiBhZGRyZXNzIGZyb20gdGhhdCBwcmVmaXggdG8gUyAqZXZl biBpZiB0aGUgcGFja2V0cw0KPiA+IG9yaWdpbmF0ZWQgZnJvbSBTKi4NCj4gPiBUaGF0IGlzIG5v dCBhIG5ldyBpc3N1ZSBicm91Z2h0IGFib3V0IGJ5IERIQ1B2Niwgc2luY2UgaXQgaXMgIGEgZm9y d2FyZGluZyBwbGFuZQ0KPiA+IGlzc3VlIGFuZCBub3QgYSBjb250cm9sIHBsYW5lIGlzc3VlLg0K PiA+DQo+ID4gRnJlZA0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ ID4gRnJvbTogVmFzaWxlbmtvIEVkdWFyZCBbbWFpbHRvOnZhc2lsZW5rby5lZHVhcmRAaHVhd2Vp LmNvbV0NCj4gPiA+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE1LCAyMDIwIDEyOjEyIFBNDQo+ ID4gPiBUbzogVGVtcGxpbiAoVVMpLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+ DQo+ID4gPiBDYzogdjZvcHMgbGlzdCA8djZvcHNAaWV0Zi5vcmc+OyBJUHY2IExpc3QgPGlwdjZA aWV0Zi5vcmc+OyBNaWNoYWVsDQo+ID4gPiBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4u Y2E+OyBkaGN3ZyA8ZGhjd2dAaWV0Zi5vcmc+DQo+ID4gPiBTdWJqZWN0OiBSRTogW0VYVEVSTkFM XSBbZGhjd2ddIFt2Nm9wc10gUmU6IFF1ZXN0aW9uIHRvIERIQ1B2NiBSZWxheQ0KPiA+ID4gSW1w bGVtZW50b3JzIHJlZ2FyZGluZyBkcmFmdC1pZXRmLWRoYy1kaGNwdjYtcGQtcmVsYXktIHJlcXVp cmVtZW50cw0KPiA+ID4NCj4gPiA+IEhpIEZyZWQsDQo+ID4gPiBZb3UgbmVlZCB0aGUgY2hhbGxl bmdlLiBPSy4gSSBoYXZlIGl0IGZvciB5b3UuDQo+ID4gPg0KPiA+ID4gVHlwaWNhbCByb3V0aW5n IHByb3RvY29scyB3b3VsZCBkaXN0cmlidXRlIHRvIHRoZSAic3R1YiIgcm91dGVyIGluZm9ybWF0 aW9uDQo+ID4gYWJvdXQgcHJlZml4ZXMgInNvbWV3aGVyZSBpbiB0aGUgbmV0d29yayIuDQo+ID4g PiBQcmVmaXhlcyBmcm9tIGxvY2FsIGludGVyZmFjZXMgYXJlIGluc2VydGVkIGludG8gdGhlIHJv dXRpbmcgdGFibGUgaW4NCj4gPiA+IHRoZSB2ZXJ5IHBlcnNpc3RlbnQgd2F5Oi0pDQo+ID4gPg0K PiA+ID4gREhDUC1QRCB3b3VsZCBkaXN0cmlidXRlIHRvIHRoZSAic3R1YiIgcm91dGVyIGluZm9y bWF0aW9uIGFib3V0IHByZWZpeGVzIHRoYXQNCj4gPiBzaG91bGQgYmVjb21lIGxvY2FsL2ludGVy ZmFjZSBwcmVmaXhlcyBvbiB0aGUgInN0dWIiLg0KPiA+ID4gTm9uLWdyYWNlZnVsIHJlbG9hZCBj b3VsZCBsZWFkIHRvIGFtbmVzaWEgb24gdGhlICJzdHViIi4gVGhlbiBpdCBjb3VsZCBhdHRhY2sN Cj4gPiBpdHMgb3duIHVwbGluay4NCj4gPiA+IEl0IGlzIGEgbmV3IHByb2JsZW0uIEJlY2F1c2Ug REhDUC1QRCBkb2VzIHBsYXkgdGhlIHJvbGUgb2YgImF1dG9tYXRpYw0KPiA+IHByb3Zpc2lvbmlu ZyBzeXN0ZW0iLCBub3Qgcm91dGluZyBwcm90b2NvbC4NCj4gPiA+IFRoZSBwcm9ibGVtIGNvdWxk IGJlIGNhbGxlZCAibm9uLWNvbnNpc3RlbnQgcm91dGVycyBjb25maWd1cmF0aW9uIi4NCj4gPiA+ IFRoZSBmYWN0IHRoYXQgcHJvcGVyIHByb3RvY29sIGZvciBwcmVmaXggZGlzdHJpYnV0aW9uIHNo b3VsZCBiZSB2ZXJ5DQo+ID4gPiBzaW1pbGFyIHRvIHJvdXRpbmcgcHJvdG9jb2wgLSBpcyB0aGUg c2Vjb25kYXJ5IGhlcmUgKGl0IGlzIGltcGxlbWVudGF0aW9uKSwNCj4gPiBiZWNhdXNlIHRoZSBw cm9ibGVtIGl0c2VsZiBpcyBuZXcuDQo+ID4gPg0KPiA+ID4gRWR1YXJkDQo+ID4gPiA+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+IEZyb206IGlwdjYgW21haWx0bzppcHY2LWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUZW1wbGluIChVUyksDQo+ID4gPiA+IEZyZWQg TA0KPiA+ID4gPiBTZW50OiAxNSDQvtC60YLRj9Cx0YDRjyAyMDIwINCzLiAxOjM3DQo+ID4gPiA+ IFRvOiBCb2IgSGluZGVuIDxib2IuaGluZGVuQGdtYWlsLmNvbT4NCj4gPiA+ID4gQ2M6IHY2b3Bz IGxpc3QgPHY2b3BzQGlldGYub3JnPjsgSVB2NiBMaXN0IDxpcHY2QGlldGYub3JnPjsgTWljaGFl bA0KPiA+ID4gPiBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+OyBkaGN3ZyA8ZGhj d2dAaWV0Zi5vcmc+DQo+ID4gPiA+IFN1YmplY3Q6IFJFOiBbRVhURVJOQUxdIFtkaGN3Z10gW3Y2 b3BzXSBSZTogUXVlc3Rpb24gdG8gREhDUHY2IFJlbGF5DQo+ID4gPiA+IEltcGxlbWVudG9ycyBy ZWdhcmRpbmcgZHJhZnQtaWV0Zi1kaGMtZGhjcHY2LXBkLXJlbGF5LXJlcXVpcmVtZW50cw0KPiA+ ID4gPg0KPiA+ID4gPiA+IEkgbm90ZSB0aGF0IHRoZSBsYWNrIG9mIOKAnGNoYWxsZW5nZeKAnSBk b2VzIG5vdCBtZWFuIGFueW9uZSBhZ3JlZXMuDQo+ID4gQWdyZWVtZW50DQo+ID4gPiA+IG5lZWRz IHRvIGJlIGFmZmlybWF0aXZlLg0KPiA+ID4gPg0KPiA+ID4gPiBGYWlyIGVub3VnaCwgQm9iOyBo ZXJlIGlzIHRoZSBhc3NlcnRpb24gSSBtYWRlIHRoYXQgSSB3YXMgcmVmZXJyaW5nIHRvOg0KPiA+ ID4gPg0KPiA+ID4gPiArIEJUVywgSSBhbSBzdGlsbCB3YWl0aW5nIHRvIGhlYXIgaG93IHRoaXMg Y29uY2VybiBpcyBpbiBhbnkgd2F5DQo+ID4gPiA+ICsgc3BlY2lmaWMgdG8gcHJlZml4IGRlbGVn YXRpb24sIHNpbmNlIGl0IHNlZW1zIHRvIGJlIGdlbmVyaWMgdG8gYW55DQo+ID4gPiA+ICsgY2Fz ZSBvZiBoYXZpbmcgYSDigJxzdHVi4oCdIHJvdXRlciB0aGF0IG1hbGljaW91c2x5IGF0dGFja3Mg aXRzIG93bg0KPiA+ID4gPiArIHVwc3RyZWFtIGxpbmsg4oCTIG5vIG1hdHRlciBob3cgdGhhdCBy b3V0ZXIgbmVnb3RpYXRlcyBpdHMgcHJlZml4ZXMNCj4gPiA+ID4gKyB3aXRoDQo+ID4gPiA+IHVw c3RyZWFtIG5ldHdvcmsgbm9kZXMuDQo+ID4gPiA+DQo+ID4gPiA+IERvIHRoZSBpbmRpdmlkdWFs cyBDQydkIG9uIHRoaXMgbGlzdCBhZ3JlZSB0aGF0IHRoaXMgaXMgYSBnZW5lcmljDQo+ID4gPiA+ IElQdjYgaXNzdWUgYW5kIG5vdCBhIERIQ1B2Ni1QRC1zcGVjaWZpYyBpc3N1ZT8NCj4gPiA+ID4N Cj4gPiA+ID4gVGhhbmtzIC0gRnJlZA0KPiA+ID4gPg0KPiA+ID4gPiA+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4gRnJvbTogQm9iIEhpbmRlbiBbbWFpbHRvOmJvYi5oaW5k ZW5AZ21haWwuY29tXQ0KPiA+ID4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxNCwgMjAy MCAzOjI4IFBNDQo+ID4gPiA+ID4gVG86IFRlbXBsaW4gKFVTKSwgRnJlZCBMIDxGcmVkLkwuVGVt cGxpbkBib2VpbmcuY29tPg0KPiA+ID4gPiA+IENjOiBCb2IgSGluZGVuIDxib2IuaGluZGVuQGdt YWlsLmNvbT47IE1pY2hhZWwgUmljaGFyZHNvbg0KPiA+ID4gPiA+IDxtY3IraWV0ZkBzYW5kZWxt YW4uY2E+OyBkaGN3ZyA8ZGhjd2dAaWV0Zi5vcmc+OyBJUHY2IExpc3QNCj4gPiA+ID4gPiA8aXB2 NkBpZXRmLm9yZz47IHY2b3BzIGxpc3QgPHY2b3BzQGlldGYub3JnPg0KPiA+ID4gPiA+IFN1Ympl Y3Q6IFJlOiBbRVhURVJOQUxdIFtkaGN3Z10gW3Y2b3BzXSBSZTogUXVlc3Rpb24gdG8gREhDUHY2 DQo+ID4gPiA+ID4gUmVsYXkgSW1wbGVtZW50b3JzIHJlZ2FyZGluZyBkcmFmdC1pZXRmLWRoYy1k aGNwdjYtcGQtcmVsYXktDQo+ID4gPiA+ID4gcmVxdWlyZW1lbnRzDQo+ID4gPiA+ID4NCj4gPiA+ ID4gPiBJIG5vdGUgdGhhdCB0aGUgbGFjayBvZiDigJxjaGFsbGVuZ2XigJ0gZG9lcyBub3QgbWVh biBhbnlvbmUgYWdyZWVzLg0KPiA+IEFncmVlbWVudA0KPiA+ID4gPiBuZWVkcyB0byBiZSBhZmZp cm1hdGl2ZS4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEJvYg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4N Cj4gPiA+ID4gPiA+IE9uIE9jdCAxNCwgMjAyMCwgYXQgMzoyNCBQTSwgVGVtcGxpbiAoVVMpLCBG cmVkIEwNCj4gPiA+ID4gPEZyZWQuTC5UZW1wbGluQGJvZWluZy5jb20+IHdyb3RlOg0KPiA+ID4g PiA+ID4NCj4gPiA+ID4gPiA+IEJvYiwgc2V2ZXJhbCBtZXNzYWdlcyBiYWNrIGl0IHdhcyBlc3Rh Ymxpc2hlZCB0aGF0IHRoZSBpc3N1ZSBhdA0KPiA+ID4gPiA+ID4gdGhlIGhlYXJ0IG9mIHRoaXMg ZGlzY3Vzc2lvbiBpcyBub3Qgc3BlY2lmaWMgdG8gREhDUHY2IG5vciBESENQdjYtUEQuDQo+ID4g PiA+ID4gPiBJbnN0ZWFkLCBpdCBpcyBhbiBpc3N1ZSB0aGF0IGlzIGNvbW1vbiB0byBhbnkgc2l0 dWF0aW9uIHdoZXJlDQo+ID4gPiA+ID4gPiB0aGVyZSBhcmUgbXVsdGlwbGUgInN0dWIiIElQdjYg cm91dGVycyBvbiBhIGRvd25zdHJlYW0gbGluayBmcm9tDQo+ID4gPiA+ID4gPiBhICJkZWZhdWx0 IiBJUHY2IHJvdXRlciwgbm8gbWF0dGVyIGhvdyB0aGUgcm91dGluZyBpbmZvcm1hdGlvbg0KPiA+ ID4gPiA+ID4gaXMgZXN0YWJsaXNoZWQgb3IgbWFpbnRhaW5lZC4gU28gZmFyLCBubyBvbmUgaGFz IGNoYWxsZW5nZWQgbXkNCj4gPiA+ID4gPiA+IGFzc2VydGlvbiB0aGF0IHRoaXMgaXMgYSBnZW5l cmljIChhbmQgbm90IGEgREhDUHY2LVBELXNwZWNpZmljKQ0KPiA+ID4gPiA+ID4gSVB2NiBpc3N1 ZSBhbmQNCj4gPiA+ID4gSSBoYXZlIGJlZW4gd2FpdGluZyB0byBzZWUgaWYgYW55b25lIHdhbnRz IHRvIGNoYWxsZW5nZSB0aGF0Lg0KPiA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+IEZyZWQNCj4gPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4g PiA+PiBGcm9tOiBCb2IgSGluZGVuIFttYWlsdG86Ym9iLmhpbmRlbkBnbWFpbC5jb21dDQo+ID4g PiA+ID4gPj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDE0LCAyMDIwIDI6NDcgUE0NCj4gPiA+ ID4gPiA+PiBUbzogVGVtcGxpbiAoVVMpLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWluZy5j b20+DQo+ID4gPiA+ID4gPj4gQ2M6IEJvYiBIaW5kZW4gPGJvYi5oaW5kZW5AZ21haWwuY29tPjsg TWljaGFlbCBSaWNoYXJkc29uDQo+ID4gPiA+ID4gPj4gPG1jcitpZXRmQHNhbmRlbG1hbi5jYT47 IGRoY3dnIDxkaGN3Z0BpZXRmLm9yZz47IElQdjYgTGlzdA0KPiA+ID4gPiA+ID4+IDxpcHY2QGll dGYub3JnPjsgdjZvcHMgbGlzdCA8djZvcHNAaWV0Zi5vcmc+DQo+ID4gPiA+ID4gPj4gU3ViamVj dDogUmU6IFtFWFRFUk5BTF0gW2RoY3dnXSBbdjZvcHNdIFJlOiBRdWVzdGlvbiB0byBESENQdjYN Cj4gPiA+ID4gPiA+PiBSZWxheSBJbXBsZW1lbnRvcnMgcmVnYXJkaW5nIGRyYWZ0LWlldGYtZGhj LWRoY3B2Ni1wZC1yZWxheS0NCj4gPiA+ID4gPiA+PiByZXF1aXJlbWVudHMNCj4gPiA+ID4gPiA+ Pg0KPiA+ID4gPiA+ID4+IFdpdGggbXkgY2hhaXIgaGF0IG9uLCBpcyB0aGVyZSBhIHJlYXNvbiB3 aHkgdGhpcyBkaXNjdXNzaW9uIGlzDQo+ID4gPiA+ID4gPj4gYmVpbmcgY29waWVkDQo+ID4gPiA+ IHRvIHRoZSA2TUFOIHcuZy4/ICAgNk1BTiBkb2VzbuKAmXQgbWFpbnRhaW4gREhDUA0KPiA+ID4g PiA+IHJlbGF0ZWQNCj4gPiA+ID4gPiA+PiBpdGVtcy4NCj4gPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ ID4+IFBsZWFzZSByZW1vdmUgaXB2NkBpZXRmLm9yZyBmcm9tIHRoaXMgdGhyZWFkLg0KPiA+ID4g PiA+ID4+DQo+ID4gPiA+ID4gPj4gQm9iDQo+ID4gPiA+ID4gPj4NCj4gPiA+ID4gPiA+Pg0KPiA+ ID4gPiA+ID4+PiBPbiBPY3QgMTQsIDIwMjAsIGF0IDEyOjE5IFBNLCBUZW1wbGluIChVUyksIEZy ZWQgTA0KPiA+ID4gPiA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4gd3JvdGU6DQo+ID4gPiA+ ID4gPj4+DQo+ID4gPiA+ID4gPj4+IEhpIE1pY2hhZWwsDQo+ID4gPiA+ID4gPj4+DQo+ID4gPiA+ ID4gPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+ID4+Pj4gRnJvbTog TWljaGFlbCBSaWNoYXJkc29uIFttYWlsdG86bWNyK2lldGZAc2FuZGVsbWFuLmNhXQ0KPiA+ID4g PiA+ID4+Pj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDE0LCAyMDIwIDExOjU4IEFNDQo+ID4g PiA+ID4gPj4+PiBUbzogVGVtcGxpbiAoVVMpLCBGcmVkIEwgPEZyZWQuTC5UZW1wbGluQGJvZWlu Zy5jb20+DQo+ID4gPiA+ID4gPj4+PiBDYzogaWFuZmFycmVyQGdteC5jb207IEplbiBMaW5rb3Zh IDxmdXJyeTEzQGdtYWlsLmNvbT47IGRoY3dnDQo+ID4gPiA+ID4gPj4+PiA8ZGhjd2dAaWV0Zi5v cmc+OyB2Nm9wcyBsaXN0IDx2Nm9wc0BpZXRmLm9yZz47IDZtYW4NCj4gPiA+ID4gPiA+Pj4+IDxp cHY2QGlldGYub3JnPg0KPiA+ID4gPiA+ID4+Pj4gU3ViamVjdDogUmU6IFtFWFRFUk5BTF0gUmU6 IFtkaGN3Z10gW3Y2b3BzXSBSZTogUXVlc3Rpb24gdG8NCj4gPiA+ID4gPiA+Pj4+IERIQ1B2NiBS ZWxheSBJbXBsZW1lbnRvcnMgcmVnYXJkaW5nIGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1wZC0NCj4g PiA+ID4gPiA+PiByZWxheS0NCj4gPiA+ID4gPiA+Pj4+IHJlcXVpcmVtZW50cw0KPiA+ID4gPiA+ ID4+Pj4NCj4gPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4gPj4+PiBUZW1wbGluIChVUyksIEZyZWQg TCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbT4gd3JvdGU6DQo+ID4gPiA+ID4gPj4+Pj4gTWlj aGFlbCwgd2hhdCBJIHdhcyByZWZlcnJpbmcgdG8gYmVsb3cgYXMgImZhaWx1cmUiIGlzIHRoZQ0K PiA+ID4gPiA+ID4+Pj4+IHByb3h5IGNhc2Ugd2hlbiB0aGVyZSBpcyBhbiBMMiBwcm94eSBQIGJl dHdlZW4gdGhlIGNsaWVudA0KPiA+ID4gPiA+ID4+Pj4+IGFuZCByZWxheSAoZS5nLiwgUkZDNDg5 KS4gVGhlcmUNCj4gPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4gPj4+PiBSRkM0Mzg5IGRlc2NyaWJl cyBhbiBORCBQcm94eS4NCj4gPiA+ID4gPiA+Pj4+IElzIHRoYXQgcmVhbGx5IGFuIEwyIHByb3h5 Pw0KPiA+ID4gPiA+ID4+Pg0KPiA+ID4gPiA+ID4+PiBZZXMsIEkgYmVsaWV2ZSBpdCBpcyBhbiBM MiBwcm94eS4NCj4gPiA+ID4gPiA+Pj4NCj4gPiA+ID4gPiA+Pj4+IEl0IHNlZW1zIGxpa2UgaXQg YWxzbyBtdXN0IGJlIGNvbnRhaW4gZWl0aGVyIGFuIEwyLWJyaWRnZSwgb3INCj4gPiA+ID4gPiA+ Pj4+IG11c3QgaGF2ZSB0aGUgTDMtcm91dGluZyB0YWJsZSBlbnRyaWVzIGlmIGl0IHdvdWxkIHJl YWxseSBiZQ0KPiA+ID4gPiA+ID4+Pj4gY2FwYWJsZSBvZiBwYXNzaW5nIERIQ1B2Ni1QRCBwcmVm aXhlcyB0aHJvdWdoIGl0Lg0KPiA+ID4gPiA+ID4+Pg0KPiA+ID4gPiA+ID4+PiBUaGUgb25seSB0 aGluZyBpdCBoYXMgdGhhdCBpbmNsdWRlcyBMMyBpbmZvcm1hdGlvbiBpcyBuZWlnaGJvcg0KPiA+ ID4gPiA+ID4+PiBjYWNoZSBlbnRyaWVzIHRoYXQga2VlcCB0cmFjayBvZiB0aGUgY2xpZW50J3Mg YWN0dWFsIEwyDQo+ID4gPiA+ID4gPj4+IGFkZHJlc3Mgb24gdGhlIGRvd25zdHJlYW0gbGluayBz ZWdtZW50LCBidXQgcmV3cml0ZXMgdGhlDQo+ID4gPiA+ID4gPj4+IGNsaWVudCdzIEwyIGFkZHJl c3MgdG8gaXRzIG93biBMMiBhZGRyZXNzIHdoZW4gZm9yd2FyZGluZyBvbnRvDQo+ID4gPiA+ID4g Pj4+IGFuIHVwc3RyZWFtIGxpbmsgc2VnbWVudC4gKEluIHRoZSByZXZlcnNlIGRpcmVjdGlvbiwg aXQNCj4gPiA+ID4gPiA+Pj4gcmVjZWl2ZXMgcGFja2V0cyBkZXN0aW5lZCB0byBpdHMgb3duIEwy IGFkZHJlc3MgYnV0IHRoZQ0KPiA+ID4gPiA+ID4+PiBjbGllbnQncyBMMyBhZGRyZXNzIG9uIHRo ZSB1cHN0cmVhbSBsaW5rIHNlZ21lbnQsIHRoZW4NCj4gPiA+ID4gPiA+Pj4gcmV3cml0ZXMgdGhl IEwyIGFkZHJlc3MgdG8gdGhlIGNsaWVudCdzIEwyIGFkZHJlc3Mgd2hlbg0KPiA+ID4gPiA+ID4+ PiBmb3J3YXJkaW5nIG9udG8gdGhlIGRvd25zdHJlYW0gbGluayBzZWdtZW50LikNCj4gPiA+ID4g PiA+Pj4NCj4gPiA+ID4gPiA+Pj4+IENhbiB5b3UgZXhwbGFpbiBob3cgc3VjaCBhIGRldmljZSB3 b3VsZCBub3JtYWxseSB3b3JrIGZvciBhDQo+ID4gPiA+ID4gPj4+PiBjbGllbnQgZGV2aWNlIEEs QixDLEQgZG9pbmcgREhDUHY2LVBEIHRocm91Z2ggaXQ/DQo+ID4gPiA+ID4gPj4+DQo+ID4gPiA+ ID4gPj4+IFN1cmUuIEEgc2VuZHMgYSBESENQdjYgU29saWNpdCB1c2luZyBpdHMgSVB2NiBsaW5r LWxvY2FsDQo+ID4gPiA+ID4gPj4+IGFkZHJlc3MgYXMgdGhlIHNvdXJjZSwgYW5kIGl0cyBMMiBh ZGRyZXNzIGFzIHRoZSBsaW5rLWxheWVyDQo+ID4gPiA+ID4gPj4+IHNvdXJjZS4gVGhlIHByb3h5 IGNvbnZlcnRzIHRoZSBsaW5rLWxheWVyIHNvdXJjZSB0byBpdHMgb3duIEwyDQo+ID4gPiA+ID4g Pj4+IGFkZHJlc3Mgd2hlbiBmb3J3YXJkaW5nIHRoZSBESENQdjYgc29saWNpdCBvbnRvIHRoZSB1 cHN0cmVhbQ0KPiA+ID4gPiA+ID4+PiBsaW5rLiBXaGVuIHRoZQ0KPiA+ID4gPiA+ID4+PiBESENQ djYgUmVwbHkgY29tZXMgYmFjaywgdGhlIElQdjYgZGVzdGluYXRpb24gaXMgdGhhdCBvZg0KPiA+ ID4gPiA+ID4+PiBjbGllbnQgQSwgYnV0IHRoZQ0KPiA+ID4gPiBsaW5rLWxheWVyIGRlc3RpbmF0 aW9uIGlzIHRoZSBMMiBhZGRyZXNzIG9mIHRoZSBwcm94eS4NCj4gPiA+ID4gPiA+Pj4gVGhlIHBy b3h5IHRoZW4gY29udmVydHMgdGhlIEwyIGRlc3RpbmF0aW9uIHRvIHRoZSBhZGRyZXNzIG9mDQo+ ID4gPiA+ID4gPj4+IGNsaWVudCBBIGFuZCBmb3J3YXJkcyBpdCBvbiB0byB0aGUgY2xpZW50Lg0K PiA+ID4gPiA+ID4+Pg0KPiA+ID4gPiA+ID4+Pj4gQW5kIGlzIHRoZSBmYWlsdXJlIG9uZSB3aGVy ZSB0aGUgcm91dGVyICJSIiBmYWlscyB0byBkcm9wDQo+ID4gPiA+ID4gPj4+PiB0cmFmZmljIGl0 IHNob3VsZCwgb25lIHdoZXJlIHRoZSByb3V0ZXIgIlIiIGRyb3BzIHRyYWZmaWMgdGhhdCBpdA0K PiA+IHNob3VsZG4ndD8NCj4gPiA+ID4gPiA+Pj4NCj4gPiA+ID4gPiA+Pj4gSSB3YXMgdGhpbmtp bmcgbW9yZSBhbG9uZyB0aGUgbGluZXMgb2YgdGhlIGxhdHRlcjsgaWYgdGhlIG9ubHkNCj4gPiA+ ID4gPiA+Pj4gd2F5IHRoYXQgQSBoYXMgZm9yIHRhbGtpbmcgdG8gQiwgQywgRCwgZXRjLiBpcyBi eSBnb2luZw0KPiA+ID4gPiA+ID4+PiB0aHJvdWdoIFIsIGl0IHdvdWxkbid0IHdvcmsgaWYgUiB3 YXMgdW5jb25kaXRpb25hbGx5IGRyb3BwaW5nDQo+ID4gZXZlcnl0aGluZy4NCj4gPiA+ID4gPiA+ Pj4NCj4gPiA+ID4gPiA+Pj4gVGhhbmtzIC0gRnJlZA0KPiA+ID4gPiA+ID4+Pg0KPiA+ID4gPiA+ ID4+Pj4gLS0NCj4gPiA+ID4gPiA+Pj4+IE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK0lFVEZAc2Fu ZGVsbWFuLmNhPiAgIC4gbyBPICggSVB2NiBJw7hUDQo+ID4gPiA+IGNvbnN1bHRpbmcgKQ0KPiA+ ID4gPiA+ID4+Pj4gICAgICAgICAgU2FuZGVsbWFuIFNvZnR3YXJlIFdvcmtzIEluYywgT3R0YXdh IGFuZCBXb3JsZHdpZGUNCj4gPiA+ID4gPiA+Pj4+DQo+ID4gPiA+ID4gPj4+Pg0KPiA+ID4gPiA+ ID4+Pj4NCj4gPiA+ID4gPiA+Pj4NCj4gPiA+ID4gPiA+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+ID4gPiA+Pj4g LS0tLQ0KPiA+ID4gPiA+ID4+PiAtLSBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxp c3QgaXB2NkBpZXRmLm9yZw0KPiA+ID4gPiA+ID4+PiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czoN Cj4gPiA+ID4gPiA+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2 DQo+ID4gPiA+ID4gPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiA+ID4gPj4+IC0tLS0NCj4gPiA+ID4gPiA+Pj4g LS0NCj4gPiA+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gPiA+IElF VEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCBpcHY2QGlldGYub3JnIEFkbWluaXN0 cmF0aXZlDQo+ID4gPiA+IFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lwdjYNCj4gPiA+ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== From nobody Fri Oct 16 11:30:47 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 13FC73A02BB; Fri, 16 Oct 2020 11:30:37 -0700 (PDT) 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 Z73IXlNtnS2R; Fri, 16 Oct 2020 11:30:35 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22E1F3A017E; Fri, 16 Oct 2020 11:30:35 -0700 (PDT) Received: from astfgl.hanazo.no (unknown [IPv6:2a02:20c8:5921:100:8cfd:38cc:741d:443d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id C1EB54E11C77; Fri, 16 Oct 2020 18:30:34 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id D4F1240D194C; Fri, 16 Oct 2020 20:30:31 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: otroan@employees.org In-Reply-To: Date: Fri, 16 Oct 2020 20:30:31 +0200 Cc: Vasilenko Eduard , Michael Richardson , v6ops list , 6man WG , dhcwg Content-Transfer-Encoding: quoted-printable Message-Id: References: <65f390e222244427bd3cbc1f58a3ec95@boeing.com> <533e7f91ae814feeb594bc42b7cd70c9@huawei.com> To: "Templin (US), Fred L" X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [v6ops] [dhcwg] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Fri, 16 Oct 2020 18:30:37 -0000 >=20 > We are talking past each other, and one of us does not have a clear = understanding > of the issue at the heart of the discussion which I see as a = forwarding plane issue > having nothing to do with the control plane. Well, the forwarding plane just does what it's told. When you set up DHCP with static routes at both ends, which are = maintained by snooping on a protocol. It's not inconceivable that there = are cases where you'd get a routing loop. Good thing we have the HLIM = field. ;-) Markus' draft is still the most authorative document discussion the = solution space: https://tools.ietf.org/html/draft-stenberg-v6ops-pd-route-maintenance-00 The CPE requirements document could have had a requirement that it = should never forward a packet received on the WAN interface back out the = WAN interface. Cheers, Ole= From nobody Fri Oct 16 11:38: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 373623A02BD for ; Fri, 16 Oct 2020 11:38:09 -0700 (PDT) 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, HTML_MESSAGE=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 (1024-bit key) header.d=qacafe.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 l-ytP0yY3jbo for ; Fri, 16 Oct 2020 11:38:07 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9714C3A03EE for ; Fri, 16 Oct 2020 11:38:06 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id f29so3576499ljo.3 for ; Fri, 16 Oct 2020 11:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qacafe.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ISddoZhrr+4TdPWE23VUSadfK7UnxHjAm5qj2c+03T8=; b=qYdKqNZXDvB6ZipeUjbBEH4END2Poj5bGO7rbKWUnIHzH37yp6DvCZgta6Sn7tSWtx ZahD2eMrvN0wLP/2sA9lzguGOGoZd5Nu9mqKLk4IAupNF7G4ialXS5HXxc2c6XrDyppu Q9kiZ/DKCLHDSShbDgP3lhlAg8wnfowQ+sDLo= 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=ISddoZhrr+4TdPWE23VUSadfK7UnxHjAm5qj2c+03T8=; b=IbqyL5Kw2XJ+nYLLFrGc3WVfoCUlFH3XOUZmg9tm+jUkot99J4qavVfSuOCKyJuPZ6 1XzUjkayRFUOsDZBijMO/zO0wqVbptRrbFfkJ7s2LC6LBQF06ayTMRbZ9xbErxfWanC9 qzF01M21LCto/VeBCd8Pd6qv/7ItTZU5iR9ZBSuVeRtPZWEWG3LjLEzMIvTdX6RX46Ux peEEmSqAnZfSsB0BhjOQTvrRRR4MV7W5d2FYoy+wvVriN8iG+X5nkWBqEzo/rcSlJebx GUL5Ri/Y+EwsSBshDmzMNN3Kfi4p+loy8lAeAQHWgVY31y5iNCrd6oSTALulCB0W9ALo yjYA== X-Gm-Message-State: AOAM530W/EDgzBuXIp5ztEQdTzFLFUBUV56Zt4ws58y2ciZkOFuWO8S6 TZwnwcGH69aUwTbmQLqsocPkdW6xw4bQmZAsbU3/ILUCC9KP5w== X-Google-Smtp-Source: ABdhPJwtAEiwpzE849jNYwUwKYSIau8SDkR5WgVIis5fAjQsltMs8q3e+toEckZVZrNTFvfNce3R+XccC785z+uAU+4= X-Received: by 2002:a2e:914d:: with SMTP id q13mr2201982ljg.299.1602873484578; Fri, 16 Oct 2020 11:38:04 -0700 (PDT) MIME-Version: 1.0 References: <65f390e222244427bd3cbc1f58a3ec95@boeing.com> <533e7f91ae814feeb594bc42b7cd70c9@huawei.com> In-Reply-To: From: Timothy Winters Date: Fri, 16 Oct 2020 14:37:53 -0400 Message-ID: To: Ole Troan Cc: "Templin (US), Fred L" , Michael Richardson , v6ops list , 6man WG , dhcwg Content-Type: multipart/alternative; boundary="000000000000ab273705b1ce10f9" Archived-At: Subject: Re: [v6ops] [dhcwg] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Fri, 16 Oct 2020 18:38:09 -0000 --000000000000ab273705b1ce10f9 Content-Type: text/plain; charset="UTF-8" Hi Ole, I was starting to think about that solution, but I was wondering about multiple CPEs in the home and what things could go wrong if we didn't allow hairpinning on the WAN. ~Tim On Fri, Oct 16, 2020 at 2:31 PM wrote: > > > > We are talking past each other, and one of us does not have a clear > understanding > > of the issue at the heart of the discussion which I see as a forwarding > plane issue > > having nothing to do with the control plane. > > Well, the forwarding plane just does what it's told. > When you set up DHCP with static routes at both ends, which are maintained > by snooping on a protocol. It's not inconceivable that there are cases > where you'd get a routing loop. Good thing we have the HLIM field. ;-) > > Markus' draft is still the most authorative document discussion the > solution space: > https://tools.ietf.org/html/draft-stenberg-v6ops-pd-route-maintenance-00 > > The CPE requirements document could have had a requirement that it should > never forward a packet received on the WAN interface back out the WAN > interface. > > Cheers, > Ole > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --000000000000ab273705b1ce10f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ole,

I was starting to think about t= hat solution, but I was wondering about multiple CPEs in the home and what = things could go wrong if we didn't allow=C2=A0hairpinning on the WAN.= =C2=A0=C2=A0

~Tim

On Fri, Oct 16, 2020 at 2:3= 1 PM <otroan@employees.org&g= t; wrote:
> <= br> > We are talking past each other, and one of us does not have a clear un= derstanding
> of the issue at the heart of the discussion which I see as a forwardin= g plane issue
> having nothing to do with the control plane.

Well, the forwarding plane just does what it's told.
When you set up DHCP with static routes at both ends, which are maintained = by snooping on a protocol. It's not inconceivable that there are cases = where you'd get a routing loop. Good thing we have the HLIM field. ;-)<= br>
Markus' draft is still the most authorative document discussion the sol= ution space:
https://tools.ietf.org/html/= draft-stenberg-v6ops-pd-route-maintenance-00

The CPE requirements document could have had a requirement that it should n= ever forward a packet received on the WAN interface back out the WAN interf= ace.

Cheers,
Ole
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--000000000000ab273705b1ce10f9-- From nobody Fri Oct 16 11:51: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 63F913A07D7 for ; Fri, 16 Oct 2020 11:51:21 -0700 (PDT) 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, HTML_MESSAGE=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=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 7u88PCk6tTph for ; Fri, 16 Oct 2020 11:51:18 -0700 (PDT) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5FB93A07F9 for ; Fri, 16 Oct 2020 11:51:18 -0700 (PDT) Received: by mail-il1-x130.google.com with SMTP id j8so3857039ilk.0 for ; Fri, 16 Oct 2020 11:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=hI+GIxCsslpmlIbxWoeG9JjwZGwg1cqCk+TS7r4yggg=; b=rmSAIrLe0UHo8ExZj0Sdkc2F9/JRanetF3UvLJn7aOH56FPzIeA/g1yn8+0FT295jT Ukc8h/vCgL0Mbe/4YW/hZhOTZVnI647rblHSa9/i1tCXFrmeIx7kdBfMfrm0z696jau0 2xVa1dYRhdQ/oinTnH+p1DufLBEjYkUl0qdtCI75bkMIDwr4ee5UzdcAZqiwZwyRuXhC PHJhcR6TqO/KpRB6ly8InqxgLi+WNW++rtf/l75SplCTJNXdb9M0hSjH6OIFEG7Iq4E/ p4OA3GIs7FyXfqOwxgt0tdfkM50reBUdb94k+zWBgHt9VaaboVK8gHbd6GTWcJe9otHl ANLA== 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=hI+GIxCsslpmlIbxWoeG9JjwZGwg1cqCk+TS7r4yggg=; b=rC3oiujt8SSMHrJPXdYJiO1QvdCMJjY66uFFqeMkKzQ0zmBicO0lv86r5171olR3QQ /wyaRLUPXKNTdSsRM70ltOqwH9llBYEHnRZYZJeu6+nIRqZmzNFt1mtnn0rlYMLFjxEk uyYVIkq1l4EbKlM7hP9cZihR7iXoDOJuERflsaJMD6LRNEIWyLD1O3Kx/kWkZMLv+6tF 28q0Y2dLMwKGv9kz9nzgvoMfY49AMslFaGhnYYb9UluB63s1PfjAjF9/+GTcV9GsI/eQ ndjXOvRtT/PsUMWDd72Gh3m1wjFnzUP2wYcERVulV4KFLfEWEPRh7KOItwAIMnnxY2tT LxGw== X-Gm-Message-State: AOAM533NuZ8J/DlT2J8BmU7e7MqLPjSfHyx9lwEvKOQuom/CosoeyLmm ShtwbzQa+DW61U8SPTcYuw0zkg== X-Google-Smtp-Source: ABdhPJx8krYjOWK3aBEIRHhQ+kKeJoiztfFSFqHeb/yWtWFZFcOP+6NTchJ4ImV3l3gfeov+GmWW2Q== X-Received: by 2002:a05:6e02:e05:: with SMTP id a5mr3505625ilk.96.1602874277939; Fri, 16 Oct 2020 11:51:17 -0700 (PDT) Received: from mithrandir.lan (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id q83sm3497868ili.16.2020.10.16.11.51.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 16 Oct 2020 11:51:17 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_45729ABD-7594-4187-80B9-05941E489AED" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.82\)) Date: Fri, 16 Oct 2020 14:51:14 -0400 In-Reply-To: Cc: "Templin (US), Fred L" , Michael Richardson , v6ops list , 6man WG , dhcwg To: Ole Troan References: <65f390e222244427bd3cbc1f58a3ec95@boeing.com> <533e7f91ae814feeb594bc42b7cd70c9@huawei.com> X-Mailer: Apple Mail (2.3654.0.3.2.82) Archived-At: Subject: Re: [v6ops] [dhcwg] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Fri, 16 Oct 2020 18:51:21 -0000 --Apple-Mail=_45729ABD-7594-4187-80B9-05941E489AED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Oct 16, 2020, at 2:30 PM, otroan@employees.org wrote: > The CPE requirements document could have had a requirement that it = should never forward a packet received on the WAN interface back out the = WAN interface. It=E2=80=99s unfortunate that it doesn=E2=80=99t have a rule that it = should never forward a packet received on the LAN interface back to the = LAN interface. I wonder what=E2=80=99s happening in practice. We have quite a lot of = devices in the world doing DHCPv6 PD. How is it that we aren=E2=80=99t = seeing reports of routing loops? Are they just humming away silently, = consuming LAN bandwidth, or are routers already doing the right thing? --Apple-Mail=_45729ABD-7594-4187-80B9-05941E489AED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Oct 16, 2020, at 2:30 PM, otroan@employees.org wrote:
The CPE requirements document could have had a requirement = that it should never forward a packet received on the WAN interface back = out the WAN interface.

It=E2=80=99s unfortunate that it doesn=E2=80=99= t have a rule that it should never forward a packet received on the LAN = interface back to the LAN interface.

I wonder what=E2=80=99s happening in = practice. We have quite a lot of devices in the world doing DHCPv6 PD. = How is it that we aren=E2=80=99t seeing reports of routing loops? Are = they just humming away silently, consuming LAN bandwidth, or are routers = already doing the right thing?

= --Apple-Mail=_45729ABD-7594-4187-80B9-05941E489AED-- From nobody Fri Oct 16 13:49: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 AA3FB3A0B06; Fri, 16 Oct 2020 13:49:13 -0700 (PDT) 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, RCVD_IN_MSPIKE_H2=-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=boeing.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 wTFmnrPzLhxD; Fri, 16 Oct 2020 13:49:12 -0700 (PDT) Received: from clt-mbsout-01.mbs.boeing.net (clt-mbsout-01.mbs.boeing.net [130.76.144.162]) (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 C04A93A09D5; Fri, 16 Oct 2020 13:49:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 09GKn8Ag022389; Fri, 16 Oct 2020 16:49:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boeing.com; s=boeing-s1912; t=1602881349; bh=Oza2jq4UMMeS/hPkvmFnrcIQCCh8udBYDmB2Lfk+UZI=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=R1PxjXPL9XBXJg1FHxF6sph3Dwysl4yAFugIvvEd8g5RbNM240jcd3BJ1x6kth+da STStjyVexgapqSkYF2+KeyddWwA3isAevKp9Ne+DBwyp47Ncj4mqgbofGTK2ctSIui KMG9Ynd7ETCU7NwwWMzClllajrTCQBmaV/kLt3xGUmvDFp9ViU0Il0jqW9NdSLiV1O Qu4jf3/lLcZcvczqjfxxM7jr2kClrrhq9d7i3tNALIGUrL0lispCpCJHk1+6pfwYq2 Fqq8CMqcMc4hMsBk50wxyWoW8jsyS5g+TAjaDl2ZO5KBvLcPzbn7Vc3mxWgbdIfWsA sPEJahnrtQ9gg== Received: from XCH16-07-12.nos.boeing.com (xch16-07-12.nos.boeing.com [144.115.66.114]) by clt-mbsout-01.mbs.boeing.net (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 09GKn06A021234 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Fri, 16 Oct 2020 16:49:00 -0400 Received: from XCH16-07-10.nos.boeing.com (144.115.66.112) by XCH16-07-12.nos.boeing.com (144.115.66.114) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Fri, 16 Oct 2020 13:48:59 -0700 Received: from XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5]) by XCH16-07-10.nos.boeing.com ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Fri, 16 Oct 2020 13:48:59 -0700 From: "Templin (US), Fred L" To: "otroan@employees.org" CC: Vasilenko Eduard , Michael Richardson , v6ops list , 6man WG , dhcwg Thread-Topic: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements Thread-Index: AdajKLVVnwghNqrLQ4229LT3ce4i4AAnrasAAAMwSKAAFDs0gAAKAuyQ Date: Fri, 16 Oct 2020 20:48:59 +0000 Message-ID: <618b9ee8ddec4957906bf715b04190a0@boeing.com> References: <65f390e222244427bd3cbc1f58a3ec95@boeing.com> <533e7f91ae814feeb594bc42b7cd70c9@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [137.137.12.6] x-tm-snts-smtp: 255C413514FF929FAB67E421D2824C624D1E7F26AFC87CF0DC962D8A80FB4E722000:8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-GCONF: 00 Archived-At: Subject: Re: [v6ops] [EXTERNAL] Re: [dhcwg] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Fri, 16 Oct 2020 20:49:14 -0000 Ole, > The CPE requirements document could have had a requirement that it should= never forward a packet received on the WAN interface > back out the WAN interface. That is what I said before, but I qualified it by saying "should never forw= ard a packet received on the WAN interface back out the WAN interface *via a default rou= te*." It could be that there are more-specific routes that would cause a packet c= oming into the WAN interface to go back out the WAN interface and that is OK; but= , not via a default route. However, the further discussion seems to suggest that the delegating router= needs to be mindful of clients that maliciously or otherwise send ping-ponged sel= f-directed packets. I was worried that the delegating router would not be able to dist= inguish CPE router A from CPE routers B, C, D in some cases. But, I am not worried = about that anymore. Thanks - Fred > -----Original Message----- > From: otroan@employees.org [mailto:otroan@employees.org] > Sent: Friday, October 16, 2020 11:31 AM > To: Templin (US), Fred L > Cc: Vasilenko Eduard ; Michael Richardson ; v6ops list ; > 6man WG ; dhcwg > Subject: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay Impl= ementors regarding draft-ietf-dhc-dhcpv6-pd-relay- > requirements >=20 > This message was sent from outside of Boeing. Please do not click links o= r open attachments unless you recognize the sender and > know that the content is safe. >=20 >=20 > > > > We are talking past each other, and one of us does not have a clear und= erstanding > > of the issue at the heart of the discussion which I see as a forwarding= plane issue > > having nothing to do with the control plane. >=20 > Well, the forwarding plane just does what it's told. > When you set up DHCP with static routes at both ends, which are maintaine= d by snooping on a protocol. It's not inconceivable that > there are cases where you'd get a routing loop. Good thing we have the HL= IM field. ;-) >=20 > Markus' draft is still the most authorative document discussion the solut= ion space: > https://tools.ietf.org/html/draft-stenberg-v6ops-pd-route-maintenance-00 >=20 > The CPE requirements document could have had a requirement that it should= never forward a packet received on the WAN interface > back out the WAN interface. >=20 > Cheers, > Ole=3D From nobody Mon Oct 19 06:26:47 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 00CEB3A097A for ; Mon, 19 Oct 2020 06:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[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 9_mZjF4AnZ9Z for ; Mon, 19 Oct 2020 06:26:44 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 DB0D53A096C for ; Mon, 19 Oct 2020 06:26:43 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id b8so12843909ioh.11 for ; Mon, 19 Oct 2020 06:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :to; bh=36DxV62swXSSHpt6kosjAwU+Ul9SNWy27XQLP1up2cU=; b=VNSHJvvvSj7kiL3iD5FCbRkVxP2GzOWpx7KXyAYI9Jg4JL3ysxPlVRjs0aO/RUUzWi +XTPQvzTXl4r9i9Myk+7AMq2Iu8hqnsbLxNQ9mIVo3kw+ny4j/Pgijtrx4rok8SCnSVS wLY+CUWJnf73bXupzJrqR8lXMksuJ5iJH86AfyeaYEUIgmt/8rd6SOFymgir+QCYi4g9 gorl7UG/Ly+6Y3Jdg6Kcbnmd4B4iKnqTd6m3EMtxvoiy0i5mRQei7y8x/ESeJEwBWkC3 Opmpvq23rq8cZFMfKqX7vv8/ABzJAj0nHWwN+xXJ3cPSqOAnM8M/m0Xe2AAbVCZEuhe1 Q4hA== 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:date :subject:message-id:to; bh=36DxV62swXSSHpt6kosjAwU+Ul9SNWy27XQLP1up2cU=; b=CHrIL33xEi8LvbCxhaK8cdQPMKguthBTRjMYG+N0paduDVeFcI21GJE0SAQF7Q3AA2 5wAq4FmhfOAUn/FtVhw8JZbNlfJoLUHgJYo2lojB5sPpuAQiqpIY8OuimKu0l2AQWb4I JRQQ3oNPIFkHpN2O7toyuL7VZNjpED2ppkj6WY7MrtWnzWtLfS0zQaG/lyXsAsiJuDNS NY2rHe7TiKDtBSWU7RanBCpAHOsZLiFmbhfioxtoieWP6VZZoptV5T5HNID8u+MIW7/Y t/Pykjop3pXNY/osAH+q2QWvBD7AmRtXqYcr3CKSXMOLILSF/AIHIAgFkVkvfGLObJvg aYbw== X-Gm-Message-State: AOAM533O7wVVVLXPF7Mtd8r0ndeZtSEDqrDAawcwDa7ie9n1HFIG76Gk VrXy3IPTPrgXKy8s+gaRMfY= X-Google-Smtp-Source: ABdhPJxS6lfeI4VnHVuj/78U0/89jM6xr2rFScag1+wnJQ+uKuZ8jLCTZ8VGbXrtFq16Zhmbs/Ctpg== X-Received: by 2002:a5e:9319:: with SMTP id k25mr10831139iom.153.1603114002899; Mon, 19 Oct 2020 06:26:42 -0700 (PDT) Received: from [192.168.1.241] (pool-108-51-40-108.washdc.fios.verizon.net. [108.51.40.108]) by smtp.gmail.com with ESMTPSA id j3sm4464163ili.20.2020.10.19.06.26.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Oct 2020 06:26:42 -0700 (PDT) From: Gyan Mishra X-Google-Original-From: Gyan Mishra Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Mon, 19 Oct 2020 09:26:41 -0400 Message-Id: <19EE82F7-8D52-4519-8087-0DF17435A3B8@gmail.com> To: v6ops@ietf.org, Mark Smith , Greg Mirsky , Jeff Tantsura X-Mailer: iPhone Mail (17H35) Archived-At: Subject: [v6ops] draft-smith-v6ops-larger-ipv6-loopback-prefix-04 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, 19 Oct 2020 13:26:45 -0000 Hi Mark What ended up happening with this draft and was the work picked up in any ot= her draft. Thanks=20 Gyan Sent from my iPhone= From nobody Mon Oct 19 09:21:12 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 1F2F23A0BC0; Mon, 19 Oct 2020 09:21:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ted Lemon via Datatracker To: Cc: draft-ietf-v6ops-slaac-renum.all@ietf.org, v6ops@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160312446708.32688.2591314931699003480@ietfa.amsl.com> Reply-To: Ted Lemon Date: Mon, 19 Oct 2020 09:21:07 -0700 Archived-At: Subject: [v6ops] Iotdir telechat review of draft-ietf-v6ops-slaac-renum-04 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: Mon, 19 Oct 2020 16:21:07 -0000 Reviewer: Ted Lemon Review result: Ready with Nits This draft does a good job of discussing typical home use scenarios, where the problems described in the document are most likely to occur. It might be worth noting that some of the assumptions about prefix stability may not be applicable to commercial IoT deployments. This is relevant because some IoT deployments make use of sleepy devices that may only wake up once per day or even less frequently. The suggested parameters would be inappropriate for such a device. At the same time such a device likely is not relying on RA, since it would not be awake for periodic refreshes. Nevertheless the operational mitigations section could use some additional verbiage about applicability so that readers do not assume that the advice given there is universally applicable. From nobody Mon Oct 19 09:21:19 2020 Return-Path: X-Original-To: expand-draft-ietf-v6ops-slaac-renum.all@virtual.ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id AA3E63A0BDA; Mon, 19 Oct 2020 09:21:07 -0700 (PDT) X-Original-To: draft-ietf-v6ops-slaac-renum.all@ietf.org Delivered-To: xfilter-draft-ietf-v6ops-slaac-renum.all@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2F23A0BC0; Mon, 19 Oct 2020 09:21:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ted Lemon via Datatracker To: Cc: draft-ietf-v6ops-slaac-renum.all@ietf.org, v6ops@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160312446708.32688.2591314931699003480@ietfa.amsl.com> Reply-To: Ted Lemon Date: Mon, 19 Oct 2020 09:21:07 -0700 Resent-From: Resent-To: fgont@si6networks.com, jan@connect.com, richard.patterson@sky.uk, fredbaker.ietf@gmail.com, rbonica@juniper.net, warren@kumari.net, rwilton@cisco.com, Owen DeLong , v6ops@ietf.org, owen@delong.com Resent-Message-Id: <20201019162107.AA3E63A0BDA@ietfa.amsl.com> Resent-Date: Mon, 19 Oct 2020 09:21:07 -0700 (PDT) Archived-At: Subject: [v6ops] Iotdir telechat review of draft-ietf-v6ops-slaac-renum-04 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: Mon, 19 Oct 2020 16:21:08 -0000 Reviewer: Ted Lemon Review result: Ready with Nits This draft does a good job of discussing typical home use scenarios, where the problems described in the document are most likely to occur. It might be worth noting that some of the assumptions about prefix stability may not be applicable to commercial IoT deployments. This is relevant because some IoT deployments make use of sleepy devices that may only wake up once per day or even less frequently. The suggested parameters would be inappropriate for such a device. At the same time such a device likely is not relying on RA, since it would not be awake for periodic refreshes. Nevertheless the operational mitigations section could use some additional verbiage about applicability so that readers do not assume that the advice given there is universally applicable. From nobody Mon Oct 19 11:49:45 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 90E093A0114; Mon, 19 Oct 2020 11:49:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-v6ops-cpe-slaac-renum@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, Owen DeLong , v6ops-chairs@ietf.org, owen@delong.com X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <160313338012.7412.6288227175776828752@ietfa.amsl.com> Date: Mon, 19 Oct 2020 11:49:40 -0700 Archived-At: Subject: [v6ops] Robert Wilton's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS and COMMENT) 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: Mon, 19 Oct 2020 18:49:41 -0000 Robert Wilton has entered the following ballot position for draft-ietf-v6ops-cpe-slaac-renum-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi, Hopefully this isn't hard to resolve, but I don't understand the meaning of the text in section 2: 2. Requirements Language 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. As such, the document points to several other specifications (preferable in RFC or stable form) to provide additional guidance to implementers regarding any protocol implementation required to produce a successful CE router that interoperates successfully with a particular subset of currently deploying and planned common IPv6 access networks. Note: the aforementioned terms are used in exactly the same way as in [RFC7084], with the above explanation copied verbatim from Section 1.1 of [RFC7084]. This paragraph tells me how these words are not used. But it doesn't seem to explain how they are meant to be interpreted. My only assumption is that these words have no special meaning in this document at all, but they than raises the question as to why not to write them all in lower case. Alternatively, following the standard RFC 2119 rules and boilerplate would also seem to make sense ... ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 3.2. LAN-side Option Lifetimes CE Routers SHOULD override the default PIO "Preferred Lifetime" and "Valid Lifetime" values from [RFC4861], and employ shorter lifetime values to improve the robustness to renumbering events, while complying with the requirements from Section 2.1 of this document and the recommendations in [RFC7772]. The reference to Section 2.1 should probably be to section 3? 7. Acknowledgments The authors would like to thank Owen DeLong, Philip Homburg, and Ted Lemon, for their valuable help in improving this document via successive detailed reviews. The authors would like to thank Mikael Abrahamsson, Brian Carpenter, Lorenzo Colitti, Alejandro D'Egidio, Fernando Frediani, Guillermo Gont, Nick Hilliard, Erik Kline, Warren Kumari, Olorunloba Olopade, Pete Resnick, Mark Smith, Job Snijders, Sander Steffann, Ole Troan, Loganaden Velvindron, Timothy Winters, Christopher Wood, and Chongfeng Xie, for providing valuable comments on earlier versions of this document. The authors would lie to thank Mikael Abrahamsson, Luis Balbinot, Tim Chown, Brian Carpenter, Owen DeLong, Gert Doering, Steinar Haug, Nick Hilliard, Philip Homburg, Lee Howard, Christian Huitema, Ted Lemon, Albert Manfredi, Jordi Palet Martinez, Richard Patterson, Michael Richardson, Mark Smith, Job Snijders, Tarko Tikan, and Ole Troan, for providing valuable comments on [I-D.gont-6man-slaac-renum], on which this document is based. Is the third paragraph definitely needed in this document? Perhaps ietf-6man-slaac-renum which is based on gont-6man-slaac-renum could contain this acknowledgement? Or perhaps you could merge the two paragraphs into one, if this is an earlier version of this document. This would also allow you to remove one of the references to similarly named documents in the references. 8.2. Informative References [I-D.gont-6man-slaac-renum] Gont, F., Zorz, J., and R. Patterson, "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events", draft-gont-6man-slaac- renum-08 (work in progress), May 2020. [I-D.ietf-6man-slaac-renum] Gont, F., Zorz, J., and R. Patterson, "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events", draft-ietf-6man-slaac- renum-01 (work in progress), August 2020. [I-D.ietf-v6ops-slaac-renum] Gont, F., Zorz, J., and R. Patterson, "Reaction of Stateless Address Autoconfiguration (SLAAC) to Flash- Renumbering Events", draft-ietf-v6ops-slaac-renum-03 (work in progress), August 2020. I was surprised that this document has informative references to three other very similarly named documents! I would think that at least the first reference is not required since it is superseded by ietf-6man-slaac-renum and thus could be elided? Regards, Rob From nobody Mon Oct 19 11:54:04 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 22FD63A0128; Mon, 19 Oct 2020 11:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=virginmedia.co.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUNZGFblFn_d; Mon, 19 Oct 2020 11:54:01 -0700 (PDT) Received: from mailrelay02.virginmedia.co.uk (mailrelay02.telewest.co.uk [193.38.82.65]) (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 8F04C3A011B; Mon, 19 Oct 2020 11:53:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=virginmedia.co.uk; i=@virginmedia.co.uk; q=dns/txt; s=mailrelays; t=1603133641; x=1634669641; h=from:to:subject:date:message-id:references:in-reply-to: mime-version:content-transfer-encoding; bh=YgZY7WOZGDmPkexlPt8d4ZuBBogpoghGSzaN+hUzcDU=; b=Qt/3GA17XfW3vHfdkx3UUMitZCp1M5i+4/fEiGibIkMZ2ENljqb34IHe MLd0xVQVsh4pBLKh0jeDIDc3T1deNbG0QG3dmbXa2wZh7Y37/Gt+vda+c Rjz8sxlFqZfZfDeEtviaz7qlGDg98hGFP7JfimfWMJ/+p51FnDEfcxiJY Q=; IronPort-SDR: fzyQRDIAFFYlFYn5T+1M5pM5lrjTFP29k4S37l3tA5HmOxrK4Ycq53ildBFCylTsJY69HOo6d9 UI+JzpBi3u9w== X-AddDisclaimer: Media X-SMTP-INT: T X-NonCorpAttach-CLI: false From: "Olopade, Olorunloba" To: 6man , "v6ops@ietf.org" Thread-Topic: New Version Notification for draft-olopade-6man-slaac-signaling-00.txt Thread-Index: AQHWpke+JPdFg9XuL0GCVbkMZbBb/qmfRCqg Date: Mon, 19 Oct 2020 18:53:56 +0000 Message-ID: <4c01bfac27744f4ba408fac1158fe7e3@UKKNOPEXCH008.systems.private> References: <160313300387.7363.3016109002772518574@ietfa.amsl.com> In-Reply-To: <160313300387.7363.3016109002772518574@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-olopade-6man-slaac-signaling-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: Mon, 19 Oct 2020 18:54:03 -0000 SGVsbG8gYWxsLA0KDQpJJ20gcHJvcG9zaW5nIGFuIGFsdGVybmF0ZSB3YXkgdG8gYWRkcmVzcyB0 aGUgU0xBQUMgZmxhc2ggcmVudW1iZXJpbmcgaXNzdWUsIGFuZCBJJ3ZlIGJlZW4gYWR2aXNlZCB0 byBwdXQgdGhpcyBpbiBhIGRyYWZ0LiBUaGlzIGlzIHRoZSBpbml0aWFsIGRyYWZ0LCBhbmQgZGVm aW5pdGVseSBuZWVkIG1vcmUgd29yaywgYnV0IHdpbGwgbGlrZSB0byBrbm93IGlmIHBlb3BsZSB0 aGluayB0aGlzIGFwcHJvYWNoIGlzIHdvcnRoIGNvbnNpZGVyaW5nLg0KDQpSZWdhcmRzLg0KDQpM b2JhIE9sb3BhZGUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50 OiAxOSBPY3RvYmVyIDIwMjAgMTk6NDMNClRvOiBPbG9wYWRlLCBPbG9ydW5sb2JhIDxMb2JhLk9s b3BhZGVAdmlyZ2lubWVkaWEuY28udWs+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LW9sb3BhZGUtNm1hbi1zbGFhYy1zaWduYWxpbmctMDAudHh0DQoNCg0KQSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW9sb3BhZGUtNm1hbi1zbGFhYy1zaWduYWxpbmctMDAu dHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IExvYmEgT2xvcGFkZSBhbmQg cG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1vbG9wYWRlLTZt YW4tc2xhYWMtc2lnbmFsaW5nDQpSZXZpc2lvbjoJMDANClRpdGxlOgkJRXhwbGljaXQgc2lnbmFs aW5nIG9mIFN0YXRlbGVzcyBBZGRyZXNzIEF1dG9jb25maWd1cmF0aW9uIChTTEFBQykgdG8gUmVu dW1iZXJpbmcgRXZlbnRzDQpEb2N1bWVudCBkYXRlOgkyMDIwLTEwLTE5DQpHcm91cDoJCUluZGl2 aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQk3DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1vbG9wYWRlLTZtYW4tc2xhYWMtc2lnbmFsaW5nLTAw LnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LW9sb3BhZGUtNm1hbi1zbGFhYy1zaWduYWxpbmcvDQpIdG1saXplZDogICAgICAgaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1vbG9wYWRlLTZtYW4tc2xhYWMt c2lnbmFsaW5nDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LW9sb3BhZGUtNm1hbi1zbGFhYy1zaWduYWxpbmctMDANCg0KDQpBYnN0cmFjdDoNCiAgIEFm dGVyIGEgcmVudW1iZXJpbmcgZXZlbnQgaW4gYW4gSVB2NiBuZXR3b3JrIHV0aWxpemluZyBTTEFB QywgaG9zdHMNCiAgIG1pZ2h0IGNvbnRpbnVlIHRvIHVzZSBzdGFsZSBhZGRyZXNzZXMsIGFzIHRo ZXkgYXJlIHVuYXdhcmUgb2YgdGhlDQogICBjaGFuZ2VzLiBMaWtld2lzZSwgcm91dGVycywgd2hv IG1heSBkZXByZWNhdGUgdGhlIHVzZSBvZiB0aGVzZQ0KICAgcHJlZml4ZXMsIGFyZSB1bmF3YXJl IG9mIHRoZWlyIHVzZSBvbiB0aGUgaG9zdHMuIFRoaXMgc2NlbmFyaW8gY291bGQNCiAgIGhhdmUg YW4gYWR2ZXJzZSBlZmZlY3Qgb24gY29tbXVuaWNhdGlvbiB3aXRoIHRoZSBob3N0LiBUaGlzIGRv Y3VtZW50DQogICBwcm9wb3NlcyBjaGFuZ2VzIHRvIHRoZSBTTEFBQyBhbGdvcml0aG0gdGhhdCB3 aWxsIGV4cGxpY2l0bHkgYWxsb3cNCiAgIHJvdXRlcnMgdG8gbGVhcm4gb2YgdGhlc2Ugc3RhbGUg cHJlZml4ZXMgdGhhdCBhcmUgc3RpbGwgYXNzaWduZWQgb24NCiAgIHRoZSBuZXR3b3JrLg0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpTYXZlIFBhcGVy IC0gRG8geW91IHJlYWxseSBuZWVkIHRvIHByaW50IHRoaXMgZS1tYWlsPw0KDQpWaXNpdCB3d3cu dmlyZ2lubWVkaWEuY29tIGZvciBtb3JlIGluZm9ybWF0aW9uLCBhbmQgbW9yZSBmdW4uDQoNClRo aXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgb3IgbWF5IGJlIGNvbmZpZGVudGlhbCBh bmQgbGVnYWxseSBwcml2aWxlZ2VkDQphbmQgYXJlIHNlbnQgc29sZWx5IGZvciB0aGUgYXR0ZW50 aW9uIG9mIHRoZSBhZGRyZXNzZWUocykuDQoNClZpcmdpbiBNZWRpYSB3aWxsIG5ldmVyIGFzayBm b3IgYWNjb3VudCBvciBmaW5hbmNpYWwgaW5mb3JtYXRpb24gdmlhIGVtYWlsLiBJZiB5b3UgYXJl IGluIHJlY2VpcHQgb2YgYSBzdXNwaWNpb3VzIGVtYWlsLCBwbGVhc2UgcmVwb3J0IHRvIHd3dy52 aXJnaW5tZWRpYS5jb20vbmV0cmVwb3J0DQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1h aWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIHN5c3RlbTogaXRzIHVzZSwg ZGlzY2xvc3VyZSBvciBjb3B5aW5nIGlzIHVuYXV0aG9yaXNlZC4gU3RhdGVtZW50cyBhbmQgb3Bp bmlvbnMgZXhwcmVzc2VkIGluIHRoaXMgZW1haWwgbWF5IG5vdCByZXByZXNlbnQgdGhvc2Ugb2Yg VmlyZ2luIE1lZGlhLiBBbnkgcmVwcmVzZW50YXRpb25zIG9yIGNvbW1pdG1lbnRzIGluIHRoaXMg ZW1haWwgYXJlIHN1YmplY3QgdG8gY29udHJhY3QuDQoNClJlZ2lzdGVyZWQgb2ZmaWNlOiA1MDAg QnJvb2sgRHJpdmUsIFJlYWRpbmcsIFJHMiA2VVUNCg0KUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIGFu ZCBXYWxlcyB3aXRoIG51bWJlciAyNTkxMjM3Cg== From nobody Mon Oct 19 12:08:06 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 5B8C63A05A6; Mon, 19 Oct 2020 12:08:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-v6ops-slaac-renum@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, Owen DeLong , v6ops@ietf.org, owen@delong.com X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <160313448535.7395.1618575323040108910@ietfa.amsl.com> Date: Mon, 19 Oct 2020 12:08:05 -0700 Archived-At: Subject: [v6ops] Robert Wilton's No Objection on draft-ietf-v6ops-slaac-renum-04: (with COMMENT) 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: Mon, 19 Oct 2020 19:08:05 -0000 Robert Wilton has entered the following ballot position for draft-ietf-v6ops-slaac-renum-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-slaac-renum/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, Thank you for this document that highlights an operational issue. My same comments regarding the acknowledgements and references as for draft-ietf-v6ops-cpe-slaac-renum-05 also apply here. Thank you to Juergen for the Opsdir review. I also broadly agree with his comments. Although tweaking the SLAAC timers helps reduce this problem somewhat, it doesn't seem to mitigate it altogether. Ideally, there would be a way for the SLAAC protocol to indicate that the advertised prefixes replace all prefixes that had previously been advertised by that device. Hopefully draft-ietf-v6ops-slaac-renum will specify suitable mitigation. I also agree with Juergen's statement regarding trying to make hosts more robust if they detect connectivity failures, particularly if there are multiple prefixes available that they could choose from. I don't know if this might be worth mentioning in section 4 on Future Work? Regards, Rob From nobody Mon Oct 19 12:35: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 13C2E3A0114 for ; Mon, 19 Oct 2020 12:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[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 g-7Qk1XOj887 for ; Mon, 19 Oct 2020 12:35:36 -0700 (PDT) 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 6C4C73A0112 for ; Mon, 19 Oct 2020 12:35:36 -0700 (PDT) Received: by mail-pf1-x432.google.com with SMTP id e15so560640pfh.6 for ; Mon, 19 Oct 2020 12:35:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=Qk/0ntkfHqdpQXeGYrut+n8mDEBOXUuO4UlxZX9f/Q8=; b=VSyIN5AKC1QUgcd4DvXGtoWvqAAY6hGZaJGkbuApzxYfgexXUY/7GqE4BjicthmvV1 ZAnX4jfKBQABUYTV+M57zal0C21S/MiC0HseUYYpgVkNMT0ejPUoMsGjzYvXrj7J5l3F O/KAoWxF92ItO/i1jFeIUx0g1ZH3sYAsTakGSzDhfa2sZWj5c1qg2aOzrzMjyd9A8oDl SivJj/L2hB6bEiDAk9qPF2GRx3VOO6YJhsgHR5j5H11ozqQkG33iVJsm5h1DJjksQZHX 7rBou/2LdPPt5GG7z+h0gXnWBa5usocjzYx+Nt15xNt388VTwlv6WQfm9h0U67pATCpY 9AJA== 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:message-id:date:to; bh=Qk/0ntkfHqdpQXeGYrut+n8mDEBOXUuO4UlxZX9f/Q8=; b=BtLV+hV5HpBI5GWrwS3WmWKdTdffpmIcged8rgmCf33u3BIryViByyzNDlZD1pxLxx WsPqVjCg88ivh7jSKBZeNMqpWCFfXTYANuIgdOMvgijS4LaDApuRsWCRgTkOmPl+0+JZ SfbVWV3TECn7SdWWvS1Ao0lv/HfjWjoy7o/06MDDRufA06iKGPNMN7AQV3YH8uG7KRO8 vCwpFPiyurRqx9EJBXRDXSg8pEgYPXf2qPjnDnwDmuJjyB/grp/FmMlU99RNm2NUzleE QrB5CzAXbt9taGLFgMbsI12Ad8ee6BESenlFlpvCeqyGMfNNN2WfxkVkfNyceXq+vZXg 5X7Q== X-Gm-Message-State: AOAM530HHiT4Xw5w7FV7umMV3Kqat8QSd+HREfCXj7ZCBiwOucBc+jCS czFx6QE/ah8HVSIRRsOFTeSAj334rf29CA== X-Google-Smtp-Source: ABdhPJyiQ3KkfDZ7upoiy3xKPelS5Tp/NNBZVElEJA84quF06KLtJKNSQF/d2L3TMbWv10LPoG3Wzg== X-Received: by 2002:aa7:9af1:0:b029:152:6101:ad12 with SMTP id y17-20020aa79af10000b02901526101ad12mr1108332pfp.40.1603136135755; Mon, 19 Oct 2020 12:35:35 -0700 (PDT) Received: from ?IPv6:2600:8802:5800:1963::1004? ([2600:8802:5800:1963::1004]) by smtp.gmail.com with ESMTPSA id e186sm558427pfh.60.2020.10.19.12.35.34 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Oct 2020 12:35:35 -0700 (PDT) From: Fred Baker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.82\)) Message-Id: Date: Mon, 19 Oct 2020 12:35:34 -0700 To: IPv6 Operations X-Mailer: Apple Mail (2.3654.0.3.2.82) Archived-At: Subject: [v6ops] WGLC on 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, 19 Oct 2020 19:35:38 -0000 I'm opening a two week WGLC on = draft-ietf-v6ops-ipv6-ehs-packet-drops-01.txt. This draft started in = 2015, and was set aside for a while. We took it as a working group draft = in July with some additional authors, it has been recently updated in = response to issues raised, and the question before the house is whether = it is ready for archival state - to become an RFC. There are a number of = questions: - do we agree with the language? (there are probably nits to be = cleaned up) - do we agree with the concepts as stated? - do we agree with the direction the draft takes us? I think the draft could use a thorough review, and having said that, am = asking for volunteers. You don't have to tell me, per se; do the review = and post it to the mailing list. Two weeks gets us to November 2.= From nobody Mon Oct 19 19:58:44 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 C9BFE3A1034; Mon, 19 Oct 2020 19:58:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sheng Jiang via Datatracker To: Cc: last-call@ietf.org, draft-ietf-v6ops-cpe-slaac-renum.all@ietf.org, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160316271478.8259.14048977655674076984@ietfa.amsl.com> Reply-To: Sheng Jiang Date: Mon, 19 Oct 2020 19:58:34 -0700 Archived-At: Subject: [v6ops] Intdir telechat review of draft-ietf-v6ops-cpe-slaac-renum-05 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, 20 Oct 2020 02:58:35 -0000 Reviewer: Sheng Jiang Review result: Ready with Issues Reviewer: Sheng Jiang Review result: Ready with Issues Hi, I have reviewed this document as part of the Internet Area directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. draft-ietf-v6ops-cpe-slaac-renum-05 Overall Summary: This draft is a document that intents to be an Informational RFC. This document gives some recommendation to improve the reaction and performance of Customer Edge Routers in the IPv6 renumbering events. It updates RFC7084. Overall this is a well written document. There is a small Nit: in the information reference, [I-D.gont-6man-slaac-renum] has been listed twice. However, I have a more fundamental question. It may be easily addressed by AD saying it was not an issue: as an informational document, it should only give information or recommendation to the readers or implementors. However, this document has a lot of "MUST", which is too strong and I think it should only appear in Standard Stack or BCP documents. If so, this document may need revise, even rework in the WG. Regards, Sheng From nobody Mon Oct 19 20:22:08 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 3C4523A1093; Mon, 19 Oct 2020 20:22:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sheng Jiang via Datatracker To: Cc: last-call@ietf.org, v6ops@ietf.org, draft-ietf-v6ops-slaac-renum.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160316412121.27287.5712211736911612350@ietfa.amsl.com> Reply-To: Sheng Jiang Date: Mon, 19 Oct 2020 20:22:01 -0700 Archived-At: Subject: [v6ops] Intdir telechat review of draft-ietf-v6ops-slaac-renum-04 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, 20 Oct 2020 03:22:01 -0000 Reviewer: Sheng Jiang Review result: Ready Reviewer: Sheng Jiang Review result: Ready Hi, I have reviewed this document as part of the Internet Area directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. draft-ietf-v6ops-slaac-renum-04 Overall Summary: This draft is a document that intents to be an Informational RFC. This document document the issue scenario that IPv6 prefixes becomes invalid without any explicit signaling and nodes still use stale addresses, and gives recommendations to improve the network operation. Overall this is a well written document. It is Ready for publish. Regards, Sheng From nobody Mon Oct 19 20:22:11 2020 Return-Path: X-Original-To: expand-draft-ietf-v6ops-slaac-renum.all@virtual.ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id C24923A1097; Mon, 19 Oct 2020 20:22:01 -0700 (PDT) X-Original-To: draft-ietf-v6ops-slaac-renum.all@ietf.org Delivered-To: xfilter-draft-ietf-v6ops-slaac-renum.all@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4523A1093; Mon, 19 Oct 2020 20:22:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sheng Jiang via Datatracker To: Cc: last-call@ietf.org, v6ops@ietf.org, draft-ietf-v6ops-slaac-renum.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160316412121.27287.5712211736911612350@ietfa.amsl.com> Reply-To: Sheng Jiang Date: Mon, 19 Oct 2020 20:22:01 -0700 Resent-From: Resent-To: fgont@si6networks.com, jan@connect.com, richard.patterson@sky.uk, rbonica@juniper.net, fredbaker.ietf@gmail.com, rwilton@cisco.com, warren@kumari.net, Owen DeLong , v6ops@ietf.org, owen@delong.com Resent-Message-Id: <20201020032201.C24923A1097@ietfa.amsl.com> Resent-Date: Mon, 19 Oct 2020 20:22:01 -0700 (PDT) Archived-At: Subject: [v6ops] Intdir telechat review of draft-ietf-v6ops-slaac-renum-04 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, 20 Oct 2020 03:22:02 -0000 Reviewer: Sheng Jiang Review result: Ready Reviewer: Sheng Jiang Review result: Ready Hi, I have reviewed this document as part of the Internet Area directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. draft-ietf-v6ops-slaac-renum-04 Overall Summary: This draft is a document that intents to be an Informational RFC. This document document the issue scenario that IPv6 prefixes becomes invalid without any explicit signaling and nodes still use stale addresses, and gives recommendations to improve the network operation. Overall this is a well written document. It is Ready for publish. Regards, Sheng From nobody Tue Oct 20 01:03: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 6E50D3A0B06; Tue, 20 Oct 2020 01:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 yFkpilQXyVYf; Tue, 20 Oct 2020 01:03:41 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 D49A93A0B04; Tue, 20 Oct 2020 01:03:40 -0700 (PDT) Received: from lhreml733-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id ADC493DF3600556E2D6E; Tue, 20 Oct 2020 09:03:37 +0100 (IST) Received: from msceml706-chm.china.huawei.com (10.219.141.145) by lhreml733-chm.china.huawei.com (10.201.108.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 20 Oct 2020 09:03:37 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml706-chm.china.huawei.com (10.219.141.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 20 Oct 2020 11:03:36 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Tue, 20 Oct 2020 11:03:36 +0300 From: Vasilenko Eduard To: "Olopade, Olorunloba" , 6man , "v6ops@ietf.org" Thread-Topic: New Version Notification for draft-olopade-6man-slaac-signaling-00.txt Thread-Index: AQHWpke+JPdFg9XuL0GCVbkMZbBb/qmfRCqggADXTgA= Date: Tue, 20 Oct 2020 08:03:36 +0000 Message-ID: <02114d0323604e848d5107db00d976a1@huawei.com> References: <160313300387.7363.3016109002772518574@ietfa.amsl.com> <4c01bfac27744f4ba408fac1158fe7e3@UKKNOPEXCH008.systems.private> In-Reply-To: <4c01bfac27744f4ba408fac1158fe7e3@UKKNOPEXCH008.systems.private> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.206.45] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] New Version Notification for draft-olopade-6man-slaac-signaling-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, 20 Oct 2020 08:03:44 -0000 Hi Loba, I was the loudest shouting that "tweaking timers" is a very bad solution. Hence, it was logical consequences that Ole did push me to develop my draft= . I am very close to publish it. I am in the context of this discussion. I ha= ve spent couple of weeks exclusively on this problem. You probably mean: "multicast RS " or "multicast NS to all routers". It is not possible to find "multicast" in your draft. Your proposal by itself is not bad. Synchronization is needed, indeed. I have proposed here (and it would be discussed in my draft) 1 additional f= lag in RA message that information is "complete". IMHO: It is a little better way for synchronization, because it does not ne= ed additional messages to synchronize states. But such type of solutions are considered by me as "long-term". It needs ho= st support. It could not happen very soon. Something for short-term is needed too. Additionally, you have not discussed solutions for all use cases presented = by Fernando in draft-ietf-v6ops-slaac-renum. For example: abrupt prefix change on the router (without deprecation) Or abrupt VLAN change on L2 (802.1X) Or prefix is just disconnected from Carrier, because uplink is down (replac= ement is not proposed yet) Or situation in multi-homing when many PA prefixes from different Carriers = are announced and some could be disconnected from carrier. But maybe it was not your goal to develop comprehensive solution for "ND pr= efix robustness" (the last term is the name of my draft) Eduard > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Olopade, > Olorunloba > Sent: 19 =CF=CB=D4=D1=C2=D2=D1 2020 =C7. 21:54 > To: 6man ; v6ops@ietf.org > Subject: Re: [v6ops] New Version Notification for draft-olopade-6man-slaa= c- > signaling-00.txt >=20 > Hello all, >=20 > I'm proposing an alternate way to address the SLAAC flash renumbering iss= ue, > and I've been advised to put this in a draft. This is the initial draft, = and definitely > need more work, but will like to know if people think this approach is wo= rth > considering. >=20 > Regards. >=20 > Loba Olopade >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 19 October 2020 19:43 > To: Olopade, Olorunloba > Subject: New Version Notification for draft-olopade-6man-slaac-signaling-= 00.txt >=20 >=20 > A new version of I-D, draft-olopade-6man-slaac-signaling-00.txt > has been successfully submitted by Loba Olopade and posted to the IETF > repository. >=20 > Name: draft-olopade-6man-slaac-signaling > Revision: 00 > Title: Explicit signaling of Stateless Address Autoconfiguration (SLAAC) > to Renumbering Events > Document date: 2020-10-19 > Group: Individual Submission > Pages: 7 > URL: https://www.ietf.org/archive/id/draft-olopade-6man-slaac- > signaling-00.txt > Status: https://datatracker.ietf.org/doc/draft-olopade-6man-slaac= - > signaling/ > Htmlized: https://datatracker.ietf.org/doc/html/draft-olopade-6man-= slaac- > signaling > Htmlized: https://tools.ietf.org/html/draft-olopade-6man-slaac-sign= aling-00 >=20 >=20 > Abstract: > After a renumbering event in an IPv6 network utilizing SLAAC, hosts > might continue to use stale addresses, as they are unaware of the > changes. Likewise, routers, who may deprecate the use of these > prefixes, are unaware of their use on the hosts. This scenario could > have an adverse effect on communication with the host. This document > proposes changes to the SLAAC algorithm that will explicitly allow > routers to learn of these stale prefixes that are still assigned on > the network. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 > -------------------------------------------------------------------- > Save Paper - Do you really need to print this e-mail? >=20 > Visit www.virginmedia.com for more information, and more fun. >=20 > This email and any attachments are or may be confidential and legally pri= vileged > and are sent solely for the attention of the addressee(s). >=20 > Virgin Media will never ask for account or financial information via emai= l. If you > are in receipt of a suspicious email, please report to > www.virginmedia.com/netreport >=20 > If you have received this email in error, please delete it from your syst= em: its > use, disclosure or copying is unauthorised. Statements and opinions expre= ssed in > this email may not represent those of Virgin Media. Any representations o= r > commitments in this email are subject to contract. >=20 > Registered office: 500 Brook Drive, Reading, RG2 6UU >=20 > Registered in England and Wales with number 2591237 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Tue Oct 20 05:04: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 ED4EF3A11D8 for ; Tue, 20 Oct 2020 05:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.671 X-Spam-Level: ** X-Spam-Status: No, score=2.671 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, SPOOFED_FREEMAIL=1.999, 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 50WMBwimpMe8 for ; Tue, 20 Oct 2020 05:04:18 -0700 (PDT) Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B7EA3A11D7 for ; Tue, 20 Oct 2020 05:04:17 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 09KC4GTG018491 for ; Tue, 20 Oct 2020 14:04:16 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 3AB20204C1D for ; Tue, 20 Oct 2020 14:04:16 +0200 (CEST) Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 2517C204C1B for ; Tue, 20 Oct 2020 14:04:16 +0200 (CEST) Received: from [10.8.35.150] (is154594.intra.cea.fr [10.8.35.150]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 09KC4G8G026036 for ; Tue, 20 Oct 2020 14:04:16 +0200 To: "v6ops@ietf.org" From: Alexandre Petrescu Message-ID: Date: Tue, 20 Oct 2020 14:04:16 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.3.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------A53B116BC7593BA37053DDE2" Content-Language: fr Archived-At: Subject: [v6ops] smartphone v6-v4 conversions affect video-conf quality? 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, 20 Oct 2020 12:04:21 -0000 This is a multi-part message in MIME format. --------------A53B116BC7593BA37053DDE2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I am trying to find out whether current IPv6-IPv4 conversions affect the quality of video calls? I assume a setting where an IPv6 smartphone (maybe Verizon?) connects to an IPv4 vide-call service such as Skype, or Microsoft Teams, or webex. I wonder whether such a smartphone would get a better quality of video if the video-call service was on IPv6, and thus no IPv4-IPv6 conversion. (in my trials I could identify that most video-call services like webex etc are on IPv4 only, with the only exception being gather.town; also I could identify that operator Bouygues' smartphones on 4G are on IPv6 with a v4-v6 conversion; but I could not test right now these smartphones on gather.town, which is down by the way https://ietf.gather.town/z6N2SDxHebMdDAfo/IETF-108) Alex --------------A53B116BC7593BA37053DDE2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Hi,

I am trying to find out whether current IPv6-IPv4 conversions affect the quality of video calls?

I assume a setting where an IPv6 smartphone (maybe Verizon?) connects to an IPv4 vide-call service such as Skype, or Microsoft Teams, or webex.

I wonder whether such a smartphone would get a better quality of video if the video-call service was on IPv6, and thus no IPv4-IPv6 conversion.

(in my trials I could identify that most video-call services like webex etc are on IPv4 only, with the only exception being gather.town; also I could identify that operator Bouygues' smartphones on 4G are on IPv6 with a v4-v6 conversion; but I could not test right now these smartphones on gather.town, which is down by the way https://ietf.gather.town/z6N2SDxHebMdDAfo/IETF-108)

Alex

--------------A53B116BC7593BA37053DDE2-- From nobody Tue Oct 20 05:36: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 A8C443A0992 for ; Tue, 20 Oct 2020 05:36:04 -0700 (PDT) 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 (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 n5cjlu8cqRts for ; Tue, 20 Oct 2020 05:36:00 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 8E21F3A0982 for ; Tue, 20 Oct 2020 05:36:00 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C0DEBAF; Tue, 20 Oct 2020 14:35:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1603197357; bh=VkPoPRAIQvLfzwh3/ibCkDyrSROpC4E/jJtI5XQofEY=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=hQLmXhESp2slpDz7PUeH2Ti6kEfqLkYAArKM794AQ0rPd7eHxOep4PnVquihmh2kE OIdFOuN4d+J+5yeDKiAcpA2EmAa6nsff9x0Y81oZYf8rqQPmLbCm0mFSEEh6loAGU+ BYeWlHZr9lRH/Cx4UhsMUP9X+hdJ6f1WjkwdaxX4= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id BD7AD9F; Tue, 20 Oct 2020 14:35:57 +0200 (CEST) Date: Tue, 20 Oct 2020 14:35:57 +0200 (CEST) From: Mikael Abrahamsson To: Alexandre Petrescu cc: "v6ops@ietf.org" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [v6ops] smartphone v6-v4 conversions affect video-conf quality? 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, 20 Oct 2020 12:36:05 -0000 On Tue, 20 Oct 2020, Alexandre Petrescu wrote: > I wonder whether such a smartphone would get a better quality of video > if the video-call service was on IPv6, and thus no IPv4-IPv6 conversion. That depends on the network in question, if there is higher RTT going through for instance NAT64 device. The actual L4 user payload of the packets will be identical for both cases, the NAT64 doesn't change that. -- Mikael Abrahamsson email: swmike@swm.pp.se From henri@unicamp.br Tue Oct 20 06:05: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 5B6D83A0C0F for ; Tue, 20 Oct 2020 06:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.877 X-Spam-Level: X-Spam-Status: No, score=-0.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, 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=fca-unicamp-br.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 R7XTtLgxV_V7 for ; Tue, 20 Oct 2020 06:05:41 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 8DE903A0B95 for ; Tue, 20 Oct 2020 06:05:41 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id y20so3138190iod.5 for ; Tue, 20 Oct 2020 06:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fca-unicamp-br.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc; bh=U01n4gMfxTN2bHcg+rW1jgh2pFrHnM0yaxn5F/laN3Q=; b=o7v332Re+hIS2j6sHi/oN5oCv59cld8DAiwQY7PGxwcMVC+nQ/JVWe3J0oZJPI+jL5 xxcGL6fkOTTmerQi0O/O669WEgbiFvqMRnx+6t3hx40giB7nf4Xk3Zab4IRCncyE6EG8 EY0uthyQC+qOVUjIwpTnu3Pb+XgjTFccupzev5XV5O41qjkSL1HaOcKChCw6ZfeBZy/R 2T7Tzqum6f+npbfLZFuqp3+rPgPC7juizxvApbKnRTd9zQQR5oo1vtMoh1CTc2P2UGeP 46nuYYtalP0tI5dFP4VLyUaw+tymN16Etb7i62rT2UXNxeXkQeJFd5sxPp0fH36sE12p 5XJg== 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:cc; bh=U01n4gMfxTN2bHcg+rW1jgh2pFrHnM0yaxn5F/laN3Q=; b=ld78r70GEIU12g0DCXSHiVFfqiMhAQJ00FI2P0tZTPxUeaT8wQ4AyyOBSmQFopiCJe CzjHRxP1+HmWPVYrbp+GoHy4QLP9rN/2F/OmNzvVy+RohqtZ/+sBOXOrlJ4v3z0nox4I NCisL3cX1x6wXconGHSo2dRLKyQZ1oM6selhEel5Sp/W7pWT20ct+0PLlKmn8TjZlBof yezHLLeWX5Gpc/PLiiDZxLqBBG+Qpzlatd5D6zATe3cPsrVybuYgFxAN9Fmf6tU8QqXy anIctAPCMr4ma4ls0nbUPUoqJuc82lTSUNe5j39ilG/5UYtbl8pS2o2R0tpll/RCgdF0 9Eng== X-Gm-Message-State: AOAM530VbeBSkKisKV14ySpkq6pynvf0xfPLUmq/+JfiEdDuqDyw/RiP PBhH9W22NKiTNp/jGHlmtutalZa5qrXB5a5VHLRnhw== X-Received: by 2002:a02:70c2:: with SMTP id f185mt566061jac.88.1603199140201; Tue, 20 Oct 2020 06:05:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Henri Alves de Godoy Date: Tue, 20 Oct 2020 10:05:26 -0300 Message-ID: Cc: Alexandre Petrescu , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="00000000000042642905b219e3b8" Archived-At: Subject: Re: [v6ops] smartphone v6-v4 conversions affect video-conf quality? 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, 20 Oct 2020 13:09:24 -0000 --00000000000042642905b219e3b8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alexandre, This subject is very interesting and I recently made some measurements using 464XLAT to access the web and the differences in microseconds between an ipv4 and ipv6 access were imperceptible for an end user. (4 to 10 =CE=BC= s). The problem that makes any attempt to measure difficult is that many video applications are not yet entirely on IPv6. The authentication systems of the services are still in IPv4 and few like Microsoft Teams do not have their IPv6 video transmission as far as I could verify. Henri Alves Godoy Information Technology and Communication School of Applied Sciences University of Campinas - UNICAMP Fone: + 55 (19) 3701-6682 Em ter., 20 de out. de 2020 =C3=A0s 09:36, Mikael Abrahamsson escreveu: > On Tue, 20 Oct 2020, Alexandre Petrescu wrote: > > > I wonder whether such a smartphone would get a better quality of video > > if the video-call service was on IPv6, and thus no IPv4-IPv6 conversion= . > > That depends on the network in question, if there is higher RTT going > through for instance NAT64 device. The actual L4 user payload of the > packets will be identical for both cases, the NAT64 doesn't change that. > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 --=20 Henri Alves Godoy Tecnologia da Informa=C3=A7=C3=A3o e Comunica=C3=A7=C3=A3o Faculdade de Ci=C3=AAncias Aplicadas - FCA Universidade Estadual de Campinas - UNICAMP Fone: (19) 3701-6682 --00000000000042642905b219e3b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alexandre,

This= subject is very interesting and I recently made some measurements using 46= 4XLAT to access the web and the differences in microseconds between an ipv4= and ipv6 access were imperceptible for an end user. (4 to 10=C2=A0=CE=BCs).<= /div>

The problem that makes any=C2=A0attempt to measure= difficult is that many video applications are not yet entirely on IPv6. Th= e authentication systems of the services are still in IPv4 and few like Mic= rosoft Teams do not have their IPv6 video transmission as far as I could ve= rify.

Henri Alves Godoy
Information= Technology and Communication
School of Applied Sciences
University of Campinas - UNICAMP
Fone: + 55 (19) 3701-6682<= /div>

Em ter., 20 de out. de 2020 =C3=A0= s 09:36, Mikael Abrahamsson <swmike=3D40swm.pp.se@dmarc.ietf.org> escreveu:
On Tue, 20 Oct 2020, Alexandre Pet= rescu wrote:

> I wonder whether such a smartphone would get a better quality of video=
> if the video-call service was on IPv6, and thus no IPv4-IPv6 conversio= n.

That depends on the network in question, if there is higher RTT going
through for instance NAT64 device. The actual L4 user payload of the
packets will be identical for both cases, the NAT64 doesn't change that= .

--
Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se

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


--
--=C2=A0
Henri A= lves Godoy
Tecnologia da Informa=C3=A7=C3=A3o e Comunica=C3=A7=C3= =A3o
Faculdade de Ci=C3=AAncias Aplicadas - FCA
Univers= idade Estadual de Campinas - UNICAMP
Fone: (19) 3701-6682
--00000000000042642905b219e3b8-- From nobody Tue Oct 20 06:17: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 4987D3A0B39 for ; Tue, 20 Oct 2020 06:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.877 X-Spam-Level: X-Spam-Status: No, score=-0.877 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, 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=fca-unicamp-br.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 2nIqy8llQybw for ; Tue, 20 Oct 2020 06:17:10 -0700 (PDT) Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) (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 6BDE83A0B38 for ; Tue, 20 Oct 2020 06:17:10 -0700 (PDT) Received: by mail-io1-xd44.google.com with SMTP id b15so3152785iod.13 for ; Tue, 20 Oct 2020 06:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fca-unicamp-br.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc; bh=0uLwM6X38nMjFdFkPf0A9KPfW2TQzV66xx0K7A2vrqA=; b=rbi089R/kE0FPd3mI0kaml1ozpF9suP1Kq0lv/oeZB3y2ojtmnCd7R+U1Q50NP8j3M 87VRzcl5ownnDKVRznUwrHM4IH0MiIfM46q6h96LxCEoksqXqhEYXGuSzMjFlWIjdeuc uRFjbyo9Y24znqZBQg37RZGDAk8cFxdSz2OYRg1yq0fnFhqOEBRPjSTtahwltvkx46pA nv1GKh8D8NfWrj83L4//mJRjCbL7WYqGbGlS60DFZ1eDY8QmX2MBRSa1yB3AbbcOcLRw ej92lPpw8G1U2mqWeCyftRP2e9pqR6PRHPSv6Hrx7IimBgNayv4YC8/31umT5Zwnmwr5 HLVg== 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:cc; bh=0uLwM6X38nMjFdFkPf0A9KPfW2TQzV66xx0K7A2vrqA=; b=sr9afDY6efFdHm/JXUXtmyz8xN9NfyXkCXu6Lk7PWmkY3t9wkDzVSFUPu1Q5pz3Fss mtbC00dJ95Yo52qdNPK4B3nijSJiMoGQLMJyBPw+HCivQ4NVaYmob1YqxdV3btB+ti3I zVs1lFXI7H4BHcS+6BZtwWsxOOJxuhCXEvzktdKZeh8+PSwhtxG68SPn7KnvBt7bYXBu ru7g7GcheaC9OKNnjik79huBV5F0D/bV2BxvUx1DZfeUN1wdP3LrVe3oOVfXDbosJesP kdZDlqV/XCODLEWEKpn1lSpDEqnOgBSg2oBvKHvriUJATsTxQ2JR5xyrgPGEfhZfEiqj gZ7Q== X-Gm-Message-State: AOAM531icLshCG28Z402LIpYzX0GX72JNHyP9opH4RqIkdYPFRKvCxaM Okj1MCcsYeaLM3Valf91sLQLI5U35Gg/GKdTDJTxzA== X-Received: by 2002:a6b:2cc5:: with SMTP id s188mt205363ios.63.1603199829052; Tue, 20 Oct 2020 06:17:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Henri Alves de Godoy Date: Tue, 20 Oct 2020 10:16:54 -0300 Message-ID: Cc: Alexandre Petrescu , "v6ops@ietf.org" Content-Type: multipart/alternative; boundary="00000000000051094305b21a0c60" Archived-At: Subject: Re: [v6ops] smartphone v6-v4 conversions affect video-conf quality? 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, 20 Oct 2020 13:17:13 -0000 --00000000000051094305b21a0c60 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alexandre, This subject is very interesting and I recently made some measurements using 464XLAT to access the web and the differences in microseconds between an ipv4 and ipv6 access were imperceptible for an end user. (4 to 10 =CE=BC= s). The problem that makes any attempt to measure difficult is that many video applications are not yet entirely on IPv6. The authentication systems of the services are still in IPv4 and few like Microsoft Teams do not have their IPv6 video transmission as far as I could verify. Henri Alves Godoy Information Technology and Communication School of Applied Sciences University of Campinas - UNICAMP Fone: + 55 (19) 3701-6682 > > > > Em ter., 20 de out. de 2020 =C3=A0s 09:36, Mikael Abrahamsson 40swm.pp.se@dmarc.ietf.org> escreveu: > >> On Tue, 20 Oct 2020, Alexandre Petrescu wrote: >> >> > I wonder whether such a smartphone would get a better quality of video >> > if the video-call service was on IPv6, and thus no IPv4-IPv6 conversio= n. >> >> That depends on the network in question, if there is higher RTT going >> through for instance NAT64 device. The actual L4 user payload of the >> packets will be identical for both cases, the NAT64 doesn't change that. >> >> -- >> Mikael Abrahamsson email: swmike@swm.pp.se >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > --00000000000051094305b21a0c60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alexandre,
=

This subject is very interesting and I recently made so= me measurements using 464XLAT to access the web and the differences in micr= oseconds between an ipv4 and ipv6 access were imperceptible for an end user= . (4 to 10=C2=A0=CE=BCs).

The problem that makes any= =C2=A0attempt to measure difficult is that many video applications are not = yet entirely on IPv6. The authentication systems of the services are still = in IPv4 and few like Microsoft Teams do not have their IPv6 video transmiss= ion as far as I could verify.

Henri Alves God= oy
Information Technology and Communication
School of A= pplied Sciences
University of Campinas - UNICAMP
Fo= ne: + 55 (19) 3701-6682

<= br>

Em ter., 20 de out. de 2020 =C3=A0s 09:36,= Mikael Abrahamsson <swmike=3D40swm.pp.se@dmarc.ietf.org> escreveu:
On Tue, 20 Oct 2020, Ale= xandre Petrescu wrote:

> I wonder whether such a smartphone would get a better quality of video=
> if the video-call service was on IPv6, and thus no IPv4-IPv6 conversio= n.

That depends on the network in question, if there is higher RTT going
through for instance NAT64 device. The actual L4 user payload of the
packets will be identical for both cases, the NAT64 doesn't change that= .

--
Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se

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

--00000000000051094305b21a0c60-- From nobody Tue Oct 20 07:31: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 E10873A0C8B; Tue, 20 Oct 2020 07:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.623 X-Spam-Level: X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.275, 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 gQ1PZSiQI2iV; Tue, 20 Oct 2020 07:31:33 -0700 (PDT) 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 212573A0CA1; Tue, 20 Oct 2020 07:31:33 -0700 (PDT) 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 m1kUsfc-0000E1C; Tue, 20 Oct 2020 16:31:24 +0200 Message-Id: To: v6ops@ietf.org Cc: "Olopade, Olorunloba" , 6man From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <160313300387.7363.3016109002772518574@ietfa.amsl.com> <4c01bfac27744f4ba408fac1158fe7e3@UKKNOPEXCH008.systems.private> In-reply-to: Your message of "Mon, 19 Oct 2020 18:53:56 +0000 ." <4c01bfac27744f4ba408fac1158fe7e3@UKKNOPEXCH008.systems.private> Date: Tue, 20 Oct 2020 16:31:24 +0200 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-olopade-6man-slaac-signaling-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, 20 Oct 2020 14:31:35 -0000 In your letter dated Mon, 19 Oct 2020 18:53:56 +0000 you wrote: >I'm proposing an alternate way to address the SLAAC flash renumbering issue, a >nd I've been advised to put this in a draft. This is the initial draft, and de >finitely need more work, but will like to know if people think this approach i >s worth considering. The mechanism proposed in this draft could work if carefully specified to deal with edge cases (for example "poor man's multihoming"). However, for this to work changes are required to both routers and hosts. If the router is a CPE, then we already have quite mature solutions that don't require changes to hosts. This would do nothing for hosts behind old CPEs. This draft could provide a solution of hosts that get moved to a different VLAN. However, the need to update both hosts and router makes it more attractive to find a solution that only requires hosts to be changed. From nobody Tue Oct 20 12:38: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 9DE8C3A1396; Tue, 20 Oct 2020 12:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, 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 VjYxiur7nd8Q; Tue, 20 Oct 2020 12:37:59 -0700 (PDT) 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 A6F4C3A134A; Tue, 20 Oct 2020 12:37:55 -0700 (PDT) Received: from [IPv6:2800:810:464:b9c:69b8:4602:916c:a007] (unknown [IPv6:2800:810:464:b9c:69b8:4602:916c:a007]) (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 31C5C283ACC; Tue, 20 Oct 2020 19:37:50 +0000 (UTC) To: Robert Wilton , The IESG Cc: draft-ietf-v6ops-cpe-slaac-renum@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, Owen DeLong References: <160313338012.7412.6288227175776828752@ietfa.amsl.com> From: Fernando Gont Message-ID: <36e00b8f-1cde-5691-caea-1678fccba3b1@si6networks.com> Date: Tue, 20 Oct 2020 16:34: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: <160313338012.7412.6288227175776828752@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Robert Wilton's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS and COMMENT) 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, 20 Oct 2020 19:38:06 -0000 Hello, Robert, Thanks so much for your feedback! In-line.... On 19/10/20 15:49, Robert Wilton via Datatracker wrote: [....] > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Hi, > > Hopefully this isn't hard to resolve, but I don't understand the meaning of the > text in section 2: > > 2. Requirements Language > > 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. As > such, the document points to several other specifications (preferable > in RFC or stable form) to provide additional guidance to implementers > regarding any protocol implementation required to produce a > successful CE router that interoperates successfully with a > particular subset of currently deploying and planned common IPv6 > access networks. > > Note: the aforementioned terms are used in exactly the same way as in > [RFC7084], with the above explanation copied verbatim from > Section 1.1 of [RFC7084]. > > This paragraph tells me how these words are not used. But it doesn't seem to > explain how they are meant to be interpreted. > > My only assumption is that these words have no special meaning in this document > at all, but they than raises the question as to why not to write them all in > lower case. Alternatively, following the standard RFC 2119 rules and > boilerplate would also seem to make sense ... These words are used in exactly the same way as RFC7084, the RFC this document is meant to update. In a way, caps are employed to flag the advice. But since the use of caps might be otherwise confusing for folks that might interpret them as in RFC2119, we include the above text (as RFC7084 did). > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > 3.2. LAN-side Option Lifetimes > > CE Routers SHOULD override the default PIO "Preferred Lifetime" and > "Valid Lifetime" values from [RFC4861], and employ shorter lifetime > values to improve the robustness to renumbering events, while > complying with the requirements from Section 2.1 of this document and > the recommendations in [RFC7772]. > > The reference to Section 2.1 should probably be to section 3? It should reference Section 3.1. -- somehow the reference was hardcoded (as opposed to an xml reference), and hence it wasn't updated when we updated the draft. (Good grief! We'll fix this). > 7. Acknowledgments > > The authors would like to thank Owen DeLong, Philip Homburg, and Ted > Lemon, for their valuable help in improving this document via > successive detailed reviews. > > The authors would like to thank Mikael Abrahamsson, Brian Carpenter, > Lorenzo Colitti, Alejandro D'Egidio, Fernando Frediani, Guillermo > Gont, Nick Hilliard, Erik Kline, Warren Kumari, Olorunloba Olopade, > Pete Resnick, Mark Smith, Job Snijders, Sander Steffann, Ole Troan, > Loganaden Velvindron, Timothy Winters, Christopher Wood, and > Chongfeng Xie, for providing valuable comments on earlier versions of > this document. > > The authors would lie to thank Mikael Abrahamsson, Luis Balbinot, Tim > Chown, Brian Carpenter, Owen DeLong, Gert Doering, Steinar Haug, Nick > Hilliard, Philip Homburg, Lee Howard, Christian Huitema, Ted Lemon, > Albert Manfredi, Jordi Palet Martinez, Richard Patterson, Michael > Richardson, Mark Smith, Job Snijders, Tarko Tikan, and Ole Troan, for > providing valuable comments on [I-D.gont-6man-slaac-renum], on which > this document is based. > > Is the third paragraph definitely needed in this document? Perhaps > ietf-6man-slaac-renum which is based on gont-6man-slaac-renum could contain > this acknowledgement? Or perhaps you could merge the two paragraphs into one, > if this is an earlier version of this document. This would also allow you to > remove one of the references to similarly named documents in the references. Clarification: draft-gont-6man-slaac-renum originally contained what became three separate documents: * draft-ietf-6man-slaac-renum * draft-ietf-v6ops-slaac-renum * draft-ietf-v6ops-cpe-slaac-renum So the early feedback on draft-gont-6man-slaac-renum has benefited all three document. My personal policy regarding Acknowledgements is to be as generous as possible, since I appreciate the time and effort spent by participants to help improve the documents. That said, I try to be factually correct regarding what they have reviewed, for at least two reasons: * I don't want to pretend that some participant has reviewed something that he/she has not reviewed (e.g., I don't want to pretend that the document passed their filter). * I don't even know if claiming that a participant has reviewed a document he/she has not might have implications in the presence of IPRs or other kind of similar stuff. That's why the Acks are spelled out like that. > 8.2. Informative References > > [I-D.gont-6man-slaac-renum] > Gont, F., Zorz, J., and R. Patterson, "Improving the > Robustness of Stateless Address Autoconfiguration (SLAAC) > to Flash Renumbering Events", draft-gont-6man-slaac- > renum-08 (work in progress), May 2020. > > [I-D.ietf-6man-slaac-renum] > Gont, F., Zorz, J., and R. Patterson, "Improving the > Robustness of Stateless Address Autoconfiguration (SLAAC) > to Flash Renumbering Events", draft-ietf-6man-slaac- > renum-01 (work in progress), August 2020. > > [I-D.ietf-v6ops-slaac-renum] > Gont, F., Zorz, J., and R. Patterson, "Reaction of > Stateless Address Autoconfiguration (SLAAC) to Flash- > Renumbering Events", draft-ietf-v6ops-slaac-renum-03 (work > in progress), August 2020. > > I was surprised that this document has informative references to three other > very similarly named documents! I would think that at least the first > reference is not required since it is superseded by ietf-6man-slaac-renum and > thus could be elided? In retrospective, we should have probably named the files differently (lesson learned!). Refs #2 and #3 are needed, since those two are complementing documents to the present one. Reference #1 is included because the Acks reference such individual version (as per explained above). Thoughts? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Oct 20 13:00: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 0389F3A1350; Tue, 20 Oct 2020 13:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, 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 PfW-wxbIJhQR; Tue, 20 Oct 2020 13:00:03 -0700 (PDT) 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 CF4D13A1351; Tue, 20 Oct 2020 13:00:00 -0700 (PDT) Received: from [IPv6:2800:810:464:b9c:69b8:4602:916c:a007] (unknown [IPv6:2800:810:464:b9c:69b8:4602:916c:a007]) (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 475EC2839E9; Tue, 20 Oct 2020 19:59:56 +0000 (UTC) To: Sheng Jiang , int-dir@ietf.org Cc: last-call@ietf.org, draft-ietf-v6ops-cpe-slaac-renum.all@ietf.org, v6ops@ietf.org References: <160316271478.8259.14048977655674076984@ietfa.amsl.com> From: Fernando Gont Message-ID: <0372f5d1-a076-2870-478a-1e8709d51553@si6networks.com> Date: Tue, 20 Oct 2020 16:43:10 -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: <160316271478.8259.14048977655674076984@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Intdir telechat review 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, 20 Oct 2020 20:00:05 -0000 Hello, Sheng, Thanks so much for your comments! In-line.... On 19/10/20 23:58, Sheng Jiang via Datatracker wrote: [...] > Overall Summary: > > This draft is a document that intents to be an Informational RFC. This > document gives some recommendation to improve the reaction and performance of > Customer Edge Routers in the IPv6 renumbering events. It updates RFC7084. > > Overall this is a well written document. There is a small Nit: in the > information reference, [I-D.gont-6man-slaac-renum] has been listed twice. Note: [I-D.gont-6man-slaac-renum] is referenced to Ack the folks that reviewed that document, on which the present one is based. > However, I have a more fundamental question. It may be easily addressed by AD > saying it was not an issue: as an informational document, it should only give > information or recommendation to the readers or implementors. However, this > document has a lot of "MUST", which is too strong and I think it should only > appear in Standard Stack or BCP documents. If so, this document may need > revise, even rework in the WG. Please see Section 2. Those terms are *not* being employed as in RFC2119, and are employed in the same was as in RFC7084, which this document means to update. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Oct 20 13:00: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 7CFCA3A135A; Tue, 20 Oct 2020 13:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, 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 z58EsVX4ORvc; Tue, 20 Oct 2020 13:00:04 -0700 (PDT) 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 3F9C53A1353; Tue, 20 Oct 2020 13:00:04 -0700 (PDT) Received: from [IPv6:2800:810:464:b9c:69b8:4602:916c:a007] (unknown [IPv6:2800:810:464:b9c:69b8:4602:916c:a007]) (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 A8C75283ACC; Tue, 20 Oct 2020 20:00:00 +0000 (UTC) To: Sheng Jiang , int-dir@ietf.org Cc: last-call@ietf.org, v6ops@ietf.org, draft-ietf-v6ops-slaac-renum.all@ietf.org References: <160316412121.27287.5712211736911612350@ietfa.amsl.com> From: Fernando Gont Message-ID: Date: Tue, 20 Oct 2020 16:44:47 -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: <160316412121.27287.5712211736911612350@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Intdir telechat review of draft-ietf-v6ops-slaac-renum-04 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, 20 Oct 2020 20:00:08 -0000 Hello, Sheng, Thanks so much for your comments! In-line.... On 20/10/20 00:22, Sheng Jiang via Datatracker wrote: [....] > > Overall Summary: > > This draft is a document that intents to be an Informational RFC. This > document document the issue scenario that IPv6 prefixes becomes invalid without > any explicit signaling and nodes still use stale addresses, and gives > recommendations to improve the network operation. > > Overall this is a well written document. It is Ready for publish. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Oct 20 13:00:21 2020 Return-Path: X-Original-To: expand-draft-ietf-v6ops-slaac-renum.all@virtual.ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 1A5A63A136D; Tue, 20 Oct 2020 13:00:08 -0700 (PDT) X-Original-To: xfilter-draft-ietf-v6ops-slaac-renum.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-v6ops-slaac-renum.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFCA3A135A; Tue, 20 Oct 2020 13:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, 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 z58EsVX4ORvc; Tue, 20 Oct 2020 13:00:04 -0700 (PDT) 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 3F9C53A1353; Tue, 20 Oct 2020 13:00:04 -0700 (PDT) Received: from [IPv6:2800:810:464:b9c:69b8:4602:916c:a007] (unknown [IPv6:2800:810:464:b9c:69b8:4602:916c:a007]) (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 A8C75283ACC; Tue, 20 Oct 2020 20:00:00 +0000 (UTC) To: Sheng Jiang , int-dir@ietf.org Cc: last-call@ietf.org, v6ops@ietf.org, draft-ietf-v6ops-slaac-renum.all@ietf.org References: <160316412121.27287.5712211736911612350@ietfa.amsl.com> From: Fernando Gont Message-ID: Date: Tue, 20 Oct 2020 16:44:47 -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: <160316412121.27287.5712211736911612350@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Resent-From: Resent-To: fgont@si6networks.com, jan@connect.com, richard.patterson@sky.uk, fredbaker.ietf@gmail.com, rbonica@juniper.net, warren@kumari.net, rwilton@cisco.com, Owen DeLong , v6ops@ietf.org, owen@delong.com Resent-Message-Id: <20201020200008.1A5A63A136D@ietfa.amsl.com> Resent-Date: Tue, 20 Oct 2020 13:00:08 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Intdir telechat review of draft-ietf-v6ops-slaac-renum-04 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, 20 Oct 2020 20:00:12 -0000 Hello, Sheng, Thanks so much for your comments! In-line.... On 20/10/20 00:22, Sheng Jiang via Datatracker wrote: [....] > > Overall Summary: > > This draft is a document that intents to be an Informational RFC. This > document document the issue scenario that IPv6 prefixes becomes invalid without > any explicit signaling and nodes still use stale addresses, and gives > recommendations to improve the network operation. > > Overall this is a well written document. It is Ready for publish. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Oct 20 13:00: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 A42093A1387; Tue, 20 Oct 2020 13:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, 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 dDZA6oWSxSHS; Tue, 20 Oct 2020 13:00:10 -0700 (PDT) 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 806253A1356; Tue, 20 Oct 2020 13:00:09 -0700 (PDT) Received: from [IPv6:2800:810:464:b9c:69b8:4602:916c:a007] (unknown [IPv6:2800:810:464:b9c:69b8:4602:916c:a007]) (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 2A3AE284055; Tue, 20 Oct 2020 20:00:04 +0000 (UTC) To: Ted Lemon , iot-directorate@ietf.org Cc: draft-ietf-v6ops-slaac-renum.all@ietf.org, v6ops@ietf.org, last-call@ietf.org References: <160312446708.32688.2591314931699003480@ietfa.amsl.com> From: Fernando Gont Message-ID: <43eebbf0-c08f-435b-78ff-d5595d06cbcc@si6networks.com> Date: Tue, 20 Oct 2020 16:51:39 -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: <160312446708.32688.2591314931699003480@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Iotdir telechat review of draft-ietf-v6ops-slaac-renum-04 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, 20 Oct 2020 20:00:16 -0000 Hello, Ted, Thanks a lot for your comments (past and present ;-) )! In-line.... On 19/10/20 13:21, Ted Lemon via Datatracker wrote: > Reviewer: Ted Lemon Review result: Ready with Nits > > This draft does a good job of discussing typical home use scenarios, > where the problems described in the document are most likely to > occur. It might be worth noting that some of the assumptions about > prefix stability may not be applicable to commercial IoT > deployments. Could you please elaborate a bit more? > This is relevant because some IoT deployments make use of sleepy > devices that may only wake up once per day or even less frequently. > The suggested parameters would be inappropriate for such a device. Just me double-checking: Do you mean it would be to short for them? Please note that the default router lifetime is 1800 seconds. So a host that sleeps for longer than that will presumably not have a default router when it wakes up, and would need to do a "refresh" procedure (RS/RA exchange) before it would be able to send a packet, anyway. > At the same time such a device likely is not relying on RA, since it > would not be awake for periodic refreshes. Nevertheless the > operational mitigations section could use some additional verbiage > about applicability so that readers do not assume that the advice > given there is universally applicable. Please clarify the above, and based on that, we could craft some text if necessary. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Oct 20 13:00:31 2020 Return-Path: X-Original-To: expand-draft-ietf-v6ops-slaac-renum.all@virtual.ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 8FB1B3A13FE; Tue, 20 Oct 2020 13:00:16 -0700 (PDT) X-Original-To: xfilter-draft-ietf-v6ops-slaac-renum.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-v6ops-slaac-renum.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42093A1387; Tue, 20 Oct 2020 13:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, 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 dDZA6oWSxSHS; Tue, 20 Oct 2020 13:00:10 -0700 (PDT) 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 806253A1356; Tue, 20 Oct 2020 13:00:09 -0700 (PDT) Received: from [IPv6:2800:810:464:b9c:69b8:4602:916c:a007] (unknown [IPv6:2800:810:464:b9c:69b8:4602:916c:a007]) (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 2A3AE284055; Tue, 20 Oct 2020 20:00:04 +0000 (UTC) To: Ted Lemon , iot-directorate@ietf.org Cc: draft-ietf-v6ops-slaac-renum.all@ietf.org, v6ops@ietf.org, last-call@ietf.org References: <160312446708.32688.2591314931699003480@ietfa.amsl.com> From: Fernando Gont Message-ID: <43eebbf0-c08f-435b-78ff-d5595d06cbcc@si6networks.com> Date: Tue, 20 Oct 2020 16:51:39 -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: <160312446708.32688.2591314931699003480@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Resent-From: Resent-To: fgont@si6networks.com, jan@connect.com, richard.patterson@sky.uk, fredbaker.ietf@gmail.com, rbonica@juniper.net, warren@kumari.net, rwilton@cisco.com, Owen DeLong , v6ops@ietf.org, owen@delong.com Resent-Message-Id: <20201020200016.8FB1B3A13FE@ietfa.amsl.com> Resent-Date: Tue, 20 Oct 2020 13:00:16 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Iotdir telechat review of draft-ietf-v6ops-slaac-renum-04 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, 20 Oct 2020 20:00:20 -0000 Hello, Ted, Thanks a lot for your comments (past and present ;-) )! In-line.... On 19/10/20 13:21, Ted Lemon via Datatracker wrote: > Reviewer: Ted Lemon Review result: Ready with Nits > > This draft does a good job of discussing typical home use scenarios, > where the problems described in the document are most likely to > occur. It might be worth noting that some of the assumptions about > prefix stability may not be applicable to commercial IoT > deployments. Could you please elaborate a bit more? > This is relevant because some IoT deployments make use of sleepy > devices that may only wake up once per day or even less frequently. > The suggested parameters would be inappropriate for such a device. Just me double-checking: Do you mean it would be to short for them? Please note that the default router lifetime is 1800 seconds. So a host that sleeps for longer than that will presumably not have a default router when it wakes up, and would need to do a "refresh" procedure (RS/RA exchange) before it would be able to send a packet, anyway. > At the same time such a device likely is not relying on RA, since it > would not be awake for periodic refreshes. Nevertheless the > operational mitigations section could use some additional verbiage > about applicability so that readers do not assume that the advice > given there is universally applicable. Please clarify the above, and based on that, we could craft some text if necessary. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Oct 20 14:32:07 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 096B83A13DE; Tue, 20 Oct 2020 14:32:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-v6ops-slaac-renum@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, Owen DeLong , v6ops@ietf.org, owen@delong.com X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <160322952602.3916.9135001094597388319@ietfa.amsl.com> Date: Tue, 20 Oct 2020 14:32:06 -0700 Archived-At: Subject: [v6ops] Roman Danyliw's No Objection on draft-ietf-v6ops-slaac-renum-04: (with COMMENT) 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, 20 Oct 2020 21:32:06 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-v6ops-slaac-renum-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-slaac-renum/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to Klaas Wiereng for the SECDIR review. ** Section 6. As Section 3.2 is proposing tuning the parameters in RFC4861, it is likely worth reiterating that these security considerations still apply ** Editorial -- Section 1. Editorial. s/and and/and/ -- Section 2.2. Most of this text was already stated in Section 1. From nobody Tue Oct 20 14:58: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 303233A13FC; Tue, 20 Oct 2020 14:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, 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 ZB67-P9sMeWN; Tue, 20 Oct 2020 14:58:48 -0700 (PDT) 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 636983A13FA; Tue, 20 Oct 2020 14:58:45 -0700 (PDT) Received: from [IPv6:2800:810:464:b9c:69b8:4602:916c:a007] (unknown [IPv6:2800:810:464:b9c:69b8:4602:916c:a007]) (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 99CF72845ED; Tue, 20 Oct 2020 21:58:41 +0000 (UTC) To: Roman Danyliw , The IESG Cc: draft-ietf-v6ops-slaac-renum@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, Owen DeLong References: <160322952602.3916.9135001094597388319@ietfa.amsl.com> From: Fernando Gont Message-ID: Date: Tue, 20 Oct 2020 18:57:34 -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: <160322952602.3916.9135001094597388319@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Roman Danyliw's No Objection on draft-ietf-v6ops-slaac-renum-04: (with COMMENT) 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, 20 Oct 2020 21:58:51 -0000 Hello, Roman, Thanks so much for your comments! In-line... On 20/10/20 18:32, Roman Danyliw via Datatracker wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks to Klaas Wiereng for the SECDIR review. > > ** Section 6. As Section 3.2 is proposing tuning the parameters in RFC4861, it > is likely worth reiterating that these security considerations still apply Not sure what you mean. The security considerations in RFC4861, or something else? > > ** Editorial > -- Section 1. Editorial. s/and and/and/ Thanks! Will fix this. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Oct 20 15:07: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 163173A1407; Tue, 20 Oct 2020 15:07:30 -0700 (PDT) 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 (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPLTUxFSI_ps; Tue, 20 Oct 2020 15:07:28 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.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 AB0033A1404; Tue, 20 Oct 2020 15:07:28 -0700 (PDT) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 09KM7LX5001326; Tue, 20 Oct 2020 18:07:21 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 09KM7LX5001326 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1603231641; bh=fgw6xtlX3+JHZS5N8x9Jc+Iza6XOeNjX6EdtlBe/Rps=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=PhOBlufGxj52grK8QuhwRu1HRY978Edd+Tbdxd7ABcYo5VXIUHugooq4gWSR/vqLR Znmz2dK4KW2KGQ3LsCqEqfm4/3Ug4EaOCZB/H2SjpN4sYDvy8ZHys0CqpRiDzk1H2W c/3h+R2pZgMa2asIeR8fHal+qDXnxph0SiwjLTJY= Received: from MORRIS.ad.sei.cmu.edu (morris.ad.sei.cmu.edu [147.72.252.46]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 09KM7Kxk016801; Tue, 20 Oct 2020 18:07:20 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Tue, 20 Oct 2020 18:07:20 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Tue, 20 Oct 2020 18:07:20 -0400 From: Roman Danyliw To: Fernando Gont , The IESG CC: Owen DeLong , "v6ops@ietf.org" , "v6ops-chairs@ietf.org" , "draft-ietf-v6ops-slaac-renum@ietf.org" Thread-Topic: Roman Danyliw's No Objection on draft-ietf-v6ops-slaac-renum-04: (with COMMENT) Thread-Index: AQHWpyiIQLBsyj8O3kCPbnX4mKk3aamhTMQA//++8cA= Date: Tue, 20 Oct 2020 22:07:20 +0000 Message-ID: <2b620a6c7c4f4d24b0c26f915263052a@cert.org> References: <160322952602.3916.9135001094597388319@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.203.69] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Roman Danyliw's No Objection on draft-ietf-v6ops-slaac-renum-04: (with COMMENT) 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, 20 Oct 2020 22:07:30 -0000 SGkgRmVybmFuZG8hDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaWVz ZyA8aWVzZy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgRmVybmFuZG8gR29udA0KPiBT ZW50OiBUdWVzZGF5LCBPY3RvYmVyIDIwLCAyMDIwIDU6NTggUE0NCj4gVG86IFJvbWFuIERhbnls aXcgPHJkZEBjZXJ0Lm9yZz47IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiBDYzogT3dlbiBE ZUxvbmcgPG93ZW5AZGVsb25nLmNvbT47IHY2b3BzQGlldGYub3JnOyB2Nm9wcy0NCj4gY2hhaXJz QGlldGYub3JnOyBkcmFmdC1pZXRmLXY2b3BzLXNsYWFjLXJlbnVtQGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJlOiBSb21hbiBEYW55bGl3J3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtdjZvcHMt c2xhYWMtcmVudW0tMDQ6DQo+ICh3aXRoIENPTU1FTlQpDQo+IA0KPiBIZWxsbywgUm9tYW4sDQo+ IA0KPiBUaGFua3Mgc28gbXVjaCBmb3IgeW91ciBjb21tZW50cyEgSW4tbGluZS4uLg0KPiANCj4g T24gMjAvMTAvMjAgMTg6MzIsIFJvbWFuIERhbnlsaXcgdmlhIERhdGF0cmFja2VyIHdyb3RlOg0K PiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBDT01NRU5UOg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPg0K PiA+IFRoYW5rcyB0byBLbGFhcyBXaWVyZW5nIGZvciB0aGUgU0VDRElSIHJldmlldy4NCj4gPg0K PiA+ICoqIFNlY3Rpb24gNi4gIEFzIFNlY3Rpb24gMy4yIGlzIHByb3Bvc2luZyB0dW5pbmcgdGhl IHBhcmFtZXRlcnMgaW4NCj4gPiBSRkM0ODYxLCBpdCBpcyBsaWtlbHkgd29ydGggcmVpdGVyYXRp bmcgdGhhdCB0aGVzZSBzZWN1cml0eQ0KPiA+IGNvbnNpZGVyYXRpb25zIHN0aWxsIGFwcGx5DQo+ IA0KPiBOb3Qgc3VyZSB3aGF0IHlvdSBtZWFuLiBUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMg aW4gUkZDNDg2MSwgb3Igc29tZXRoaW5nDQo+IGVsc2U/DQoNClllcywgYW5kIHRoaXMgaXMgbWlu b3IsIEkgbWVhbnQgdG8gcmVzdGF0ZSB0aGUgb2J2aW91cyB0aGF0IFJGQzQ4NjEgYXBwbGllcyAo aW5zdGVhZCBvZiBhIGJhcmUgc3RhdGVtZW50IHRoYXQgbm8gbmV3IHNlY3VyaXR5KS4NCg0KUmVn YXJkcywNClJvbWFuDQoNCj4gDQo+ID4NCj4gPiAqKiBFZGl0b3JpYWwNCj4gPiAtLSBTZWN0aW9u IDEuICBFZGl0b3JpYWwuIHMvYW5kIGFuZC9hbmQvDQo+IA0KPiBUaGFua3MhIFdpbGwgZml4IHRo aXMuDQo+IA0KPiBUaGFua3MhDQoNCg0KPiBDaGVlcnMsDQo+IC0tDQo+IEZlcm5hbmRvIEdvbnQN Cj4gU0k2IE5ldHdvcmtzDQo+IGUtbWFpbDogZmdvbnRAc2k2bmV0d29ya3MuY29tDQo+IFBHUCBG aW5nZXJwcmludDogNjY2NiAzMUM2IEQ0ODQgNjNCMiA4RkIxIEUzQzQgQUUyNSAwRDU1IDFENEUg NzQ5Mg0KPiANCj4gDQo+IA0KDQo= From nobody Tue Oct 20 15:23:36 2020 Return-Path: X-Original-To: expand-draft-ietf-v6ops-slaac-renum.all@virtual.ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id E17473A1433; Tue, 20 Oct 2020 15:23:27 -0700 (PDT) X-Original-To: xfilter-draft-ietf-v6ops-slaac-renum.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-v6ops-slaac-renum.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0E33A1428 for ; Tue, 20 Oct 2020 15:23:27 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_DNS_FOR_FROM=0.001, 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=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 mN1HZHUcG8Sj for ; Tue, 20 Oct 2020 15:23:25 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 230CC3A1437 for ; Tue, 20 Oct 2020 15:23:24 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id h12so475115qtu.1 for ; Tue, 20 Oct 2020 15:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Fr2mIUXFUzRocMNncdWwdWq50eMFKw5EGo49YKxpRd4=; b=k1+08mZfCJe2uQIeC9I671DLbKf2gBrK/YoS4WqvgH11hrel/FNgKknuMlBMntazQs aI555tq4LSyCLK5rOyNYI00pMBMopjVvyuthRSTH9OBJlFmncBvwYTDq+I5yWSwcPjow Qf7PSZ3hkTqv/KFVAt9VJqo6+8t9wWjuxF43m3nPii830E4nM1bwoyio1rNxefvRzF8b HLIfuK6iqePNGtiyMIl2Du6IKCXze/psgnq5FJuKJ17qN/DyIAON4CoOpEN3uYkh6oqG XokjAnSbmGR3s65vJ/A07rQaMNz0ZHkgZojVF6YVBkOezMYg2lbUXUMcsKENn4Hwj1ya yHew== 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=Fr2mIUXFUzRocMNncdWwdWq50eMFKw5EGo49YKxpRd4=; b=lKhzMmI9IM9TlAJRg1eVahPUb2OufKuGoWcueUkPbt8xx4CzR9YMdTsWtE9qFPFiVQ nmI4stsVfuUPnDIax0CoxfBvoTteUtr5LjFZNkyTr1kkjEbCh0XM/v8WuiXNbCUuvF0i c05oWMTrnuEfAN/rr2wFRQBXeEIMI7AUuqa1xqyBa6RFWVjQuIqR6NHd5KQbrV/rMP6A W9PggrDsDMG1XbBPfBvX8RVPq6KarASIGZcc3oMST1uApqOiO1NiWBlDFfEzpwfJ/p/O CTcch2ypDGSg4S89WzOcEqOTQcuWg10t+txw1F/PXruq/2927Xu2tJn1WijJWsVO/Fat T2Qg== X-Gm-Message-State: AOAM530LZLvgLt8tjpLPtwK3lHc92UnheQKWsai1zUEBvDf9g8SDxhFq Q/SAfVV0dMdZ4HK1BvL72qa2dg== X-Google-Smtp-Source: ABdhPJzLLnbMaAb8u6c1VkfgguBlZC5NdhUQIO3DSuFIkAstJqWF1YWst7AjuKaH9yq0wa96rmJBPg== X-Received: by 2002:ac8:48c7:: with SMTP id l7mr332029qtr.275.1603232603893; Tue, 20 Oct 2020 15:23:23 -0700 (PDT) Received: from mithrandir.lan (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id u11sm16253qtk.61.2020.10.20.15.23.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Oct 2020 15:23:23 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_7986EBD0-D2F1-4F77-9776-5F60000D7816" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.91\)) Date: Tue, 20 Oct 2020 18:23:21 -0400 In-Reply-To: <43eebbf0-c08f-435b-78ff-d5595d06cbcc@si6networks.com> Cc: iot-directorate@ietf.org, draft-ietf-v6ops-slaac-renum.all@ietf.org, v6ops list , last-call@ietf.org To: Fernando Gont References: <160312446708.32688.2591314931699003480@ietfa.amsl.com> <43eebbf0-c08f-435b-78ff-d5595d06cbcc@si6networks.com> X-Mailer: Apple Mail (2.3654.0.3.2.91) Resent-From: Resent-To: fgont@si6networks.com, jan@connect.com, richard.patterson@sky.uk, rbonica@juniper.net, fredbaker.ietf@gmail.com, warren@kumari.net, rwilton@cisco.com, Owen DeLong , v6ops@ietf.org, owen@delong.com Resent-Message-Id: <20201020222327.E17473A1433@ietfa.amsl.com> Resent-Date: Tue, 20 Oct 2020 15:23:27 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Iotdir telechat review of draft-ietf-v6ops-slaac-renum-04 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, 20 Oct 2020 22:23:28 -0000 --Apple-Mail=_7986EBD0-D2F1-4F77-9776-5F60000D7816 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Oct 20, 2020, at 3:51 PM, Fernando Gont = wrote: >> This is relevant because some IoT deployments make use of sleepy = devices that may only wake up once per day or even less frequently. The = suggested parameters would be inappropriate for such a device. >=20 > Just me double-checking: Do you mean it would be to short for them? >=20 > Please note that the default router lifetime is 1800 seconds. So a = host > that sleeps for longer than that will presumably not have a default = router when it wakes up, and would need to do a "refresh" procedure = (RS/RA exchange) before it would be able to send a packet, anyway. Right, in a situation like this, where the network is pretty stable, it = would make sense to use longer lifetimes. Also bear in mind that the = communication on this network might be between two hosts on the same = link=E2=80=94one a data collector and one a reporting device. So the = router lifetime might not be an issue. If the communication is going = off-network, a longer router lifetime would be required. >> At the same time such a device likely is not relying on RA, since it >> would not be awake for periodic refreshes. Nevertheless the = operational mitigations section could use some additional verbiage about = applicability so that readers do not assume that the advice given there = is universally applicable. >=20 > Please clarify the above, and based on that, we could craft some text = if > necessary. What I=E2=80=99m suggesting is simply that you mention that the defaults = you are recommending are really most applicable in home networks, and = may not be applicable in various commercial networks, including the IoT = deployment I used as an example. IOW, make it clear that these defaults = are not universally applicable. There=E2=80=99s no text right now that = says that (unless I missed it). --Apple-Mail=_7986EBD0-D2F1-4F77-9776-5F60000D7816 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Oct 20, 2020, at 3:51 PM, Fernando Gont <fgont@si6networks.com> wrote:
This is relevant because some IoT = deployments make use of sleepy devices that may only wake up once per = day or even less frequently. The suggested parameters would be = inappropriate for such a device.

Just me = double-checking: Do you mean it would be to short for them?

Please note = that the default router lifetime is 1800 seconds. So a host
that sleeps = for longer than that will presumably not have a default router when it = wakes up, and would need to do a "refresh" procedure (RS/RA exchange) = before it would be able to send a packet, = anyway.

Right, in a situation like this, where the network is pretty = stable, it would make sense to use longer lifetimes. Also bear in mind = that the communication on this network might be between two hosts on the = same link=E2=80=94one a data collector and one a reporting device. So = the router lifetime might not be an issue. If the communication is going = off-network, a longer router lifetime would be required.

At the same time such a device likely is not = relying on RA, since it
would not be awake for periodic = refreshes. Nevertheless the operational mitigations section could use = some additional verbiage about applicability so that readers do not = assume that the advice given there is universally applicable.

Please clarify the above, and based on that, = we could craft some text if
necessary.

What I=E2=80=99m suggesting is simply = that you mention that the defaults you are recommending are really most = applicable in home networks, and may not be applicable in various = commercial networks, including the IoT deployment I used as an example. =  IOW, make it clear that these defaults are not universally = applicable. There=E2=80=99s no text right now that says that (unless I = missed it).

= --Apple-Mail=_7986EBD0-D2F1-4F77-9776-5F60000D7816-- From nobody Tue Oct 20 15:23: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 2B9413A1443 for ; Tue, 20 Oct 2020 15:23:30 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaDtfx5uqXRs for ; Tue, 20 Oct 2020 15:23:25 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 57C3C3A143B for ; Tue, 20 Oct 2020 15:23:24 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id m65so393872qte.11 for ; Tue, 20 Oct 2020 15:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Fr2mIUXFUzRocMNncdWwdWq50eMFKw5EGo49YKxpRd4=; b=k1+08mZfCJe2uQIeC9I671DLbKf2gBrK/YoS4WqvgH11hrel/FNgKknuMlBMntazQs aI555tq4LSyCLK5rOyNYI00pMBMopjVvyuthRSTH9OBJlFmncBvwYTDq+I5yWSwcPjow Qf7PSZ3hkTqv/KFVAt9VJqo6+8t9wWjuxF43m3nPii830E4nM1bwoyio1rNxefvRzF8b HLIfuK6iqePNGtiyMIl2Du6IKCXze/psgnq5FJuKJ17qN/DyIAON4CoOpEN3uYkh6oqG XokjAnSbmGR3s65vJ/A07rQaMNz0ZHkgZojVF6YVBkOezMYg2lbUXUMcsKENn4Hwj1ya yHew== 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=Fr2mIUXFUzRocMNncdWwdWq50eMFKw5EGo49YKxpRd4=; b=AiG5LP7WVdGER8AsW9QuzpWCxlVC81JEYBFGxH2+lTSilb567GUaxtdITGaVfDDxuo kIdqooAe9DjLiOVRFguVve/rwETnHoX90cHLwuGwgRjswWsEL6lt2u9m3GWacnxweqFn EX1kHqV4mrBpnSlJy5W25DMNE5OXI6Bf/a9QSisAcfDoeCAumwTfxA1s9mq9cyJ1SPCz t4zAGqiN5EZxNGy64p7ROnTL7RISZGqMEv1e6EHhWGmrvfm64ikFsdS4hyO6CCT/sZ99 K6DAHVGQy47Hu+Sf3iF5KtQJPjhlIeD3EKHLQpUAlH6/V/qmhWzNwLtOshSoSv36GNuw GBjA== X-Gm-Message-State: AOAM532edddj8OyuEtfrOl7A/UWItlnGXtAG0LwECysDAxZXdLvnjLLn XbRAP4IWdR+0SfBMR0I3eBCiyw== X-Google-Smtp-Source: ABdhPJzLLnbMaAb8u6c1VkfgguBlZC5NdhUQIO3DSuFIkAstJqWF1YWst7AjuKaH9yq0wa96rmJBPg== X-Received: by 2002:ac8:48c7:: with SMTP id l7mr332029qtr.275.1603232603893; Tue, 20 Oct 2020 15:23:23 -0700 (PDT) Received: from mithrandir.lan (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id u11sm16253qtk.61.2020.10.20.15.23.23 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Oct 2020 15:23:23 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_7986EBD0-D2F1-4F77-9776-5F60000D7816" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.91\)) Date: Tue, 20 Oct 2020 18:23:21 -0400 In-Reply-To: <43eebbf0-c08f-435b-78ff-d5595d06cbcc@si6networks.com> Cc: iot-directorate@ietf.org, draft-ietf-v6ops-slaac-renum.all@ietf.org, v6ops list , last-call@ietf.org To: Fernando Gont References: <160312446708.32688.2591314931699003480@ietfa.amsl.com> <43eebbf0-c08f-435b-78ff-d5595d06cbcc@si6networks.com> X-Mailer: Apple Mail (2.3654.0.3.2.91) Archived-At: Subject: Re: [v6ops] Iotdir telechat review of draft-ietf-v6ops-slaac-renum-04 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, 20 Oct 2020 22:23:32 -0000 --Apple-Mail=_7986EBD0-D2F1-4F77-9776-5F60000D7816 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Oct 20, 2020, at 3:51 PM, Fernando Gont = wrote: >> This is relevant because some IoT deployments make use of sleepy = devices that may only wake up once per day or even less frequently. The = suggested parameters would be inappropriate for such a device. >=20 > Just me double-checking: Do you mean it would be to short for them? >=20 > Please note that the default router lifetime is 1800 seconds. So a = host > that sleeps for longer than that will presumably not have a default = router when it wakes up, and would need to do a "refresh" procedure = (RS/RA exchange) before it would be able to send a packet, anyway. Right, in a situation like this, where the network is pretty stable, it = would make sense to use longer lifetimes. Also bear in mind that the = communication on this network might be between two hosts on the same = link=E2=80=94one a data collector and one a reporting device. So the = router lifetime might not be an issue. If the communication is going = off-network, a longer router lifetime would be required. >> At the same time such a device likely is not relying on RA, since it >> would not be awake for periodic refreshes. Nevertheless the = operational mitigations section could use some additional verbiage about = applicability so that readers do not assume that the advice given there = is universally applicable. >=20 > Please clarify the above, and based on that, we could craft some text = if > necessary. What I=E2=80=99m suggesting is simply that you mention that the defaults = you are recommending are really most applicable in home networks, and = may not be applicable in various commercial networks, including the IoT = deployment I used as an example. IOW, make it clear that these defaults = are not universally applicable. There=E2=80=99s no text right now that = says that (unless I missed it). --Apple-Mail=_7986EBD0-D2F1-4F77-9776-5F60000D7816 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Oct 20, 2020, at 3:51 PM, Fernando Gont <fgont@si6networks.com> wrote:
This is relevant because some IoT = deployments make use of sleepy devices that may only wake up once per = day or even less frequently. The suggested parameters would be = inappropriate for such a device.

Just me = double-checking: Do you mean it would be to short for them?

Please note = that the default router lifetime is 1800 seconds. So a host
that sleeps = for longer than that will presumably not have a default router when it = wakes up, and would need to do a "refresh" procedure (RS/RA exchange) = before it would be able to send a packet, = anyway.

Right, in a situation like this, where the network is pretty = stable, it would make sense to use longer lifetimes. Also bear in mind = that the communication on this network might be between two hosts on the = same link=E2=80=94one a data collector and one a reporting device. So = the router lifetime might not be an issue. If the communication is going = off-network, a longer router lifetime would be required.

At the same time such a device likely is not = relying on RA, since it
would not be awake for periodic = refreshes. Nevertheless the operational mitigations section could use = some additional verbiage about applicability so that readers do not = assume that the advice given there is universally applicable.

Please clarify the above, and based on that, = we could craft some text if
necessary.

What I=E2=80=99m suggesting is simply = that you mention that the defaults you are recommending are really most = applicable in home networks, and may not be applicable in various = commercial networks, including the IoT deployment I used as an example. =  IOW, make it clear that these defaults are not universally = applicable. There=E2=80=99s no text right now that says that (unless I = missed it).

= --Apple-Mail=_7986EBD0-D2F1-4F77-9776-5F60000D7816-- From nobody Tue Oct 20 16:14: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 34CED3A05A6; Tue, 20 Oct 2020 16:14:35 -0700 (PDT) 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=virginmedia.co.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrIjnwfb7bSJ; Tue, 20 Oct 2020 16:14:32 -0700 (PDT) Received: from mailrelay01.virginmedia.co.uk (mailrelay01.telewest.co.uk [193.38.119.32]) (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 EA3763A045E; Tue, 20 Oct 2020 16:14:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=virginmedia.co.uk; i=@virginmedia.co.uk; q=dns/txt; s=mailrelays; t=1603235672; x=1634771672; h=from:to:subject:date:message-id:references:in-reply-to: mime-version:content-transfer-encoding; bh=F+gITeESofcXrz+WhrSnGrhES7D9t1pAzjPqwpBjD9Q=; b=iPu7JSg88noJCHWD1LITz8thgupNwWOPZm65J/mGcai2mbUJepjFJizL ibCskzTo5dEwHsxpm6tOrEdSG+a1JgMzuSJlVK2K+O48sUFXKKr8vvvdJ GWJk+2mu6xxj6q0DMoRNyeqk0FbF4Y/fNmKngS96ps5JnEX1majlHkApj c=; IronPort-SDR: Hgd/JWMRlmdUAIYOcIt5PgpzWNWzVpFEmfNzWUac6hLXZqxvLWaqx+osVqgMiBD1NJ/ED2UgBF Tc3FxoPGH+YQ== X-AddDisclaimer: Media X-SMTP-INT: T X-NonCorpAttach-CLI: false From: "Olopade, Olorunloba" To: Vasilenko Eduard , 6man , "v6ops@ietf.org" Thread-Topic: New Version Notification for draft-olopade-6man-slaac-signaling-00.txt Thread-Index: AQHWpke+JPdFg9XuL0GCVbkMZbBb/qmfRCqggADXTgCAAOWTUA== Date: Tue, 20 Oct 2020 23:14:23 +0000 Message-ID: <161b04264ec24ba9862dcb72392b466e@UKKNOPEXCH008.systems.private> References: <160313300387.7363.3016109002772518574@ietfa.amsl.com> <4c01bfac27744f4ba408fac1158fe7e3@UKKNOPEXCH008.systems.private> <02114d0323604e848d5107db00d976a1@huawei.com> In-Reply-To: <02114d0323604e848d5107db00d976a1@huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="koi8-r" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-olopade-6man-slaac-signaling-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, 20 Oct 2020 23:14:35 -0000 SGVsbG8gRWR1YXJkLAoKWWVzLCBJIGRvIG1lYW4gTXVsdGljYXN0IFJTLiAKClllcywgd2UgZG8g bmVlZCBzeW5jaHJvbmlzYXRpb24uIEkgYmVsaWV2ZSBzb21lIGZvcm0gb2YgImZlZWRiYWNrIiBp cyBuZWVkZWQgdG8gYWNoaWV2ZSBhICJzdGFibGUgc3lzdGVtIi4gVGhpcyBpcyB0aGUgcHJlbWlz ZSBJJ20gd29ya2luZyBvbi4gV2l0aCBTTEFBQyBhcyBpdCBjdXJyZW50bHkgaXMsIHdlIGRvbid0 IGhhdmUgYSBtZWFucyBvZiBmZWVkaW5nIGJhY2sgaW5mb3JtYXRpb24gZnJvbSBob3N0cyB0byBy b3V0ZXJzLiBUaGF0IGFyZWEgaXMgd2hhdCBJJ20gdHJ5aW5nIHRvIGFkZHJlc3MgaW4gdGhpcyBk cmFmdC4gQnkgaW5jbHVkaW5nIGluZm9ybWF0aW9uIGluIFJTIG1lc3NhZ2VzLCByb3V0ZXJzIGNh biBsZWFybiBhYm91dCB0aGUgc3RhdGUgb2YgdGhlIGhvc3QuCgpUaGlzIGlzIGFuIGluaXRpYWwg ZHJhZnQuIFNvIEkgd2Fzbid0IGF0dGVtcHRpbmcgdG8gZG9jdW1lbnQgdGhlIGNvbXBsZXRlIHNv bHV0aW9uIGF0IHRoaXMgdGltZS4gQnV0IHdhbnRlZCB0byBzZWUgaWYgb3RoZXJzIHdvdWxkIHNl ZSB0aGUgYmVuZWZpdCBvZiBtb3ZpbmcgaW4gdGhpcyBkaXJlY3Rpb24uIEluIG15IG9waW5pb24s IEkgd2lsbCBsaWtlIHRvIHNlZSAyIGNoYW5nZXMgdG8gaW5jcmVhc2UgU0xBQUMgcm9idXN0bmVz cy4gVGhpcyBhbmQgYSBtZWFucyBmb3IgdGhlIHJvdXRlciB0byBpbmRpY2F0ZSB0aGF0IGl0IGlz IHNlbmRpbmcgImNvbXBsZXRlIiAgaW5mb3JtYXRpb24gKGxpa2UgeW91IGFyZSBpbmRpY2F0aW5n IHdpdGggdGhlIGZsYWcpLiAKCkJ1dCBpZiB3ZSBhcmUgdG8gbG9vayBpbnRvIHRoZSB2YXJpb3Vz IHVzZSBjYXNlcywgYSBjb21tb24gZmFjdG9yIHdvdWxkIGJlIHRoZSBmb3JtaW5nIG9mIGEgbmV3 IGFkZHJlc3MuIEhlbmNlLCBteSBwcm9wb3NhbCBsZXZlcmFnZXMgb24gdGhpcywgYnkgc2VuZGlu ZyB0aGUgUlMsIGFzIHRoZSBhZGRyZXNzIHRyYW5zaXRpb25zIGZyb20gdGVudGF0aXZlIHRvIHBy ZWZlcnJlZC4gU28sIEkgYmVsaWV2ZSBhbGwgdGhlIHVzZSBjYXNlcyBzaG91bGQgYmUgY292ZXJl ZC4gCgpBbHRob3VnaCwgSSdtIGhhdmluZyBhIGNoYW5nZSBvZiBoZWFydCBvbiBob3cgdG8gYWNo aWV2ZSB0aGlzLiBJIG5vdyB0aGluayB0aGF0IHVzaW5nIG9wdGlvbnMgaW4gUlMgaXMgYmV0dGVy IHRoYW4gcmVseWluZyBvbiB0aGUgc291cmNlIGFkZHJlc3MuIFRoZSBrZXkgZGlmZmVyZW5jZSBp cyB0aGF0IHRoZSBjdXJyZW50IHByb3Bvc2FsIGlzIGxpbWl0ZWQgdG8gUElPIGluZm9ybWF0aW9u LiBXZSBhbHNvIG5lZWQgdG8gY29uc2lkZXIgaG93IHRvIGRvIGdhcmJhZ2UgY29sbGVjdGlvbiBm b3IgUklPIGFuZCBSRE5TUwoKSSBhZ3JlZSB0aGF0IHRoaXMgYXJlIGxvbmcgdGVybSBzb2x1dGlv bnMuIEZvciB0aGUgc2hvcnQgdGVybSwgSSB0aGluayB3ZSBhcmUgc3R1Y2sgd2l0aCBqdXN0IGxv d2VyaW5nIHRoZSB0aW1lcnMuCgoKLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KRnJvbTogdjZv cHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVmFzaWxlbmtv IEVkdWFyZApTZW50OiAyMCBPY3RvYmVyIDIwMjAgMDk6MDQKVG86IE9sb3BhZGUsIE9sb3J1bmxv YmEgPExvYmEuT2xvcGFkZT00MHZpcmdpbm1lZGlhLmNvLnVrQGRtYXJjLmlldGYub3JnPjsgNm1h biA8aXB2NkBpZXRmLm9yZz47IHY2b3BzQGlldGYub3JnClN1YmplY3Q6IFJlOiBbdjZvcHNdIE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtb2xvcGFkZS02bWFuLXNsYWFjLXNpZ25h bGluZy0wMC50eHQKCkhpIExvYmEsCkkgd2FzIHRoZSBsb3VkZXN0IHNob3V0aW5nIHRoYXQgInR3 ZWFraW5nIHRpbWVycyIgaXMgYSB2ZXJ5IGJhZCBzb2x1dGlvbi4KSGVuY2UsIGl0IHdhcyBsb2dp Y2FsIGNvbnNlcXVlbmNlcyB0aGF0IE9sZSBkaWQgcHVzaCBtZSB0byBkZXZlbG9wIG15IGRyYWZ0 LgpJIGFtIHZlcnkgY2xvc2UgdG8gcHVibGlzaCBpdC4gSSBhbSBpbiB0aGUgY29udGV4dCBvZiB0 aGlzIGRpc2N1c3Npb24uIEkgaGF2ZSBzcGVudCBjb3VwbGUgb2Ygd2Vla3MgZXhjbHVzaXZlbHkg b24gdGhpcyBwcm9ibGVtLgoKWW91IHByb2JhYmx5IG1lYW46ICJtdWx0aWNhc3QgUlMgIiBvciAi bXVsdGljYXN0IE5TIHRvIGFsbCByb3V0ZXJzIi4KSXQgaXMgbm90IHBvc3NpYmxlIHRvIGZpbmQg Im11bHRpY2FzdCIgaW4geW91ciBkcmFmdC4KCllvdXIgcHJvcG9zYWwgYnkgaXRzZWxmIGlzIG5v dCBiYWQuIFN5bmNocm9uaXphdGlvbiBpcyBuZWVkZWQsIGluZGVlZC4KSSBoYXZlIHByb3Bvc2Vk IGhlcmUgKGFuZCBpdCB3b3VsZCBiZSBkaXNjdXNzZWQgaW4gbXkgZHJhZnQpIDEgYWRkaXRpb25h bCBmbGFnIGluIFJBIG1lc3NhZ2UgdGhhdCBpbmZvcm1hdGlvbiBpcyAiY29tcGxldGUiLgpJTUhP OiBJdCBpcyBhIGxpdHRsZSBiZXR0ZXIgd2F5IGZvciBzeW5jaHJvbml6YXRpb24sIGJlY2F1c2Ug aXQgZG9lcyBub3QgbmVlZCBhZGRpdGlvbmFsIG1lc3NhZ2VzIHRvIHN5bmNocm9uaXplIHN0YXRl cy4KCkJ1dCBzdWNoIHR5cGUgb2Ygc29sdXRpb25zIGFyZSBjb25zaWRlcmVkIGJ5IG1lIGFzICJs b25nLXRlcm0iLiBJdCBuZWVkcyBob3N0IHN1cHBvcnQuIEl0IGNvdWxkIG5vdCBoYXBwZW4gdmVy eSBzb29uLgpTb21ldGhpbmcgZm9yIHNob3J0LXRlcm0gaXMgbmVlZGVkIHRvby4KCkFkZGl0aW9u YWxseSwgeW91IGhhdmUgbm90IGRpc2N1c3NlZCBzb2x1dGlvbnMgZm9yIGFsbCB1c2UgY2FzZXMg cHJlc2VudGVkIGJ5IEZlcm5hbmRvIGluIGRyYWZ0LWlldGYtdjZvcHMtc2xhYWMtcmVudW0uCkZv ciBleGFtcGxlOiBhYnJ1cHQgcHJlZml4IGNoYW5nZSBvbiB0aGUgcm91dGVyICh3aXRob3V0IGRl cHJlY2F0aW9uKSBPciBhYnJ1cHQgVkxBTiBjaGFuZ2Ugb24gTDIgKDgwMi4xWCkgT3IgcHJlZml4 IGlzIGp1c3QgZGlzY29ubmVjdGVkIGZyb20gQ2FycmllciwgYmVjYXVzZSB1cGxpbmsgaXMgZG93 biAocmVwbGFjZW1lbnQgaXMgbm90IHByb3Bvc2VkIHlldCkgT3Igc2l0dWF0aW9uIGluIG11bHRp LWhvbWluZyB3aGVuIG1hbnkgUEEgcHJlZml4ZXMgZnJvbSBkaWZmZXJlbnQgQ2FycmllcnMgYXJl IGFubm91bmNlZCBhbmQgc29tZSBjb3VsZCBiZSBkaXNjb25uZWN0ZWQgZnJvbSBjYXJyaWVyLgpC dXQgbWF5YmUgaXQgd2FzIG5vdCB5b3VyIGdvYWwgdG8gZGV2ZWxvcCBjb21wcmVoZW5zaXZlIHNv bHV0aW9uIGZvciAiTkQgcHJlZml4IHJvYnVzdG5lc3MiICh0aGUgbGFzdCB0ZXJtIGlzIHRoZSBu YW1lIG9mIG15IGRyYWZ0KQoKRWR1YXJkCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPiBG cm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBP bG9wYWRlLCAKPiBPbG9ydW5sb2JhCj4gU2VudDogMTkgz8vU0cLS0SAyMDIwIMcuIDIxOjU0Cj4g VG86IDZtYW4gPGlwdjZAaWV0Zi5vcmc+OyB2Nm9wc0BpZXRmLm9yZwo+IFN1YmplY3Q6IFJlOiBb djZvcHNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgCj4gZHJhZnQtb2xvcGFkZS02bWFu LXNsYWFjLSBzaWduYWxpbmctMDAudHh0Cj4gCj4gSGVsbG8gYWxsLAo+IAo+IEknbSBwcm9wb3Np bmcgYW4gYWx0ZXJuYXRlIHdheSB0byBhZGRyZXNzIHRoZSBTTEFBQyBmbGFzaCByZW51bWJlcmlu ZyAKPiBpc3N1ZSwgYW5kIEkndmUgYmVlbiBhZHZpc2VkIHRvIHB1dCB0aGlzIGluIGEgZHJhZnQu IFRoaXMgaXMgdGhlIAo+IGluaXRpYWwgZHJhZnQsIGFuZCBkZWZpbml0ZWx5IG5lZWQgbW9yZSB3 b3JrLCBidXQgd2lsbCBsaWtlIHRvIGtub3cgaWYgCj4gcGVvcGxlIHRoaW5rIHRoaXMgYXBwcm9h Y2ggaXMgd29ydGggY29uc2lkZXJpbmcuCj4gCj4gUmVnYXJkcy4KPiAKPiBMb2JhIE9sb3BhZGUK PiAKPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+IEZyb206IGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10KPiBTZW50OiAxOSBPY3Rv YmVyIDIwMjAgMTk6NDMKPiBUbzogT2xvcGFkZSwgT2xvcnVubG9iYSA8TG9iYS5PbG9wYWRlQHZp cmdpbm1lZGlhLmNvLnVrPgo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig Cj4gZHJhZnQtb2xvcGFkZS02bWFuLXNsYWFjLXNpZ25hbGluZy0wMC50eHQKPiAKPiAKPiBBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtb2xvcGFkZS02bWFuLXNsYWFjLXNpZ25hbGluZy0wMC50 eHQKPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IExvYmEgT2xvcGFkZSBhbmQg cG9zdGVkIHRvIHRoZSBJRVRGIAo+IHJlcG9zaXRvcnkuCj4gCj4gTmFtZToJCWRyYWZ0LW9sb3Bh ZGUtNm1hbi1zbGFhYy1zaWduYWxpbmcKPiBSZXZpc2lvbjoJMDAKPiBUaXRsZToJCUV4cGxpY2l0 IHNpZ25hbGluZyBvZiBTdGF0ZWxlc3MgQWRkcmVzcyBBdXRvY29uZmlndXJhdGlvbiAoU0xBQUMp Cj4gdG8gUmVudW1iZXJpbmcgRXZlbnRzCj4gRG9jdW1lbnQgZGF0ZToJMjAyMC0xMC0xOQo+IEdy b3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uCj4gUGFnZXM6CQk3Cj4gVVJMOiAgICAgICAgICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtb2xvcGFkZS02bWFuLXNsYWFj LQo+IHNpZ25hbGluZy0wMC50eHQKPiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtb2xvcGFkZS02bWFuLXNsYWFjLQo+IHNpZ25hbGluZy8KPiBI dG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFm dC1vbG9wYWRlLTZtYW4tc2xhYWMtCj4gc2lnbmFsaW5nCj4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1vbG9wYWRlLTZtYW4tc2xhYWMtc2lnbmFsaW5n LTAwCj4gCj4gCj4gQWJzdHJhY3Q6Cj4gICAgQWZ0ZXIgYSByZW51bWJlcmluZyBldmVudCBpbiBh biBJUHY2IG5ldHdvcmsgdXRpbGl6aW5nIFNMQUFDLCBob3N0cwo+ICAgIG1pZ2h0IGNvbnRpbnVl IHRvIHVzZSBzdGFsZSBhZGRyZXNzZXMsIGFzIHRoZXkgYXJlIHVuYXdhcmUgb2YgdGhlCj4gICAg Y2hhbmdlcy4gTGlrZXdpc2UsIHJvdXRlcnMsIHdobyBtYXkgZGVwcmVjYXRlIHRoZSB1c2Ugb2Yg dGhlc2UKPiAgICBwcmVmaXhlcywgYXJlIHVuYXdhcmUgb2YgdGhlaXIgdXNlIG9uIHRoZSBob3N0 cy4gVGhpcyBzY2VuYXJpbyBjb3VsZAo+ICAgIGhhdmUgYW4gYWR2ZXJzZSBlZmZlY3Qgb24gY29t bXVuaWNhdGlvbiB3aXRoIHRoZSBob3N0LiBUaGlzIGRvY3VtZW50Cj4gICAgcHJvcG9zZXMgY2hh bmdlcyB0byB0aGUgU0xBQUMgYWxnb3JpdGhtIHRoYXQgd2lsbCBleHBsaWNpdGx5IGFsbG93Cj4g ICAgcm91dGVycyB0byBsZWFybiBvZiB0aGVzZSBzdGFsZSBwcmVmaXhlcyB0aGF0IGFyZSBzdGls bCBhc3NpZ25lZCBvbgo+ICAgIHRoZSBuZXR3b3JrLgo+IAo+IAo+IAo+IAo+IFBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIAo+ IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZy4KPiAKPiBUaGUgSUVURiBTZWNyZXRhcmlhdAo+IAo+IAo+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tCj4gU2F2ZSBQYXBlciAtIERvIHlvdSByZWFsbHkgbmVlZCB0byBwcmludCB0 aGlzIGUtbWFpbD8KPiAKPiBWaXNpdCB3d3cudmlyZ2lubWVkaWEuY29tIGZvciBtb3JlIGluZm9y bWF0aW9uLCBhbmQgbW9yZSBmdW4uCj4gCj4gVGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRz IGFyZSBvciBtYXkgYmUgY29uZmlkZW50aWFsIGFuZCBsZWdhbGx5IAo+IHByaXZpbGVnZWQgYW5k IGFyZSBzZW50IHNvbGVseSBmb3IgdGhlIGF0dGVudGlvbiBvZiB0aGUgYWRkcmVzc2VlKHMpLgo+ IAo+IFZpcmdpbiBNZWRpYSB3aWxsIG5ldmVyIGFzayBmb3IgYWNjb3VudCBvciBmaW5hbmNpYWwg aW5mb3JtYXRpb24gdmlhIAo+IGVtYWlsLiBJZiB5b3UgYXJlIGluIHJlY2VpcHQgb2YgYSBzdXNw aWNpb3VzIGVtYWlsLCBwbGVhc2UgcmVwb3J0IHRvIAo+IHd3dy52aXJnaW5tZWRpYS5jb20vbmV0 cmVwb3J0Cj4gCj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxl YXNlIGRlbGV0ZSBpdCBmcm9tIHlvdXIgCj4gc3lzdGVtOiBpdHMgdXNlLCBkaXNjbG9zdXJlIG9y IGNvcHlpbmcgaXMgdW5hdXRob3Jpc2VkLiBTdGF0ZW1lbnRzIGFuZCAKPiBvcGluaW9ucyBleHBy ZXNzZWQgaW4gdGhpcyBlbWFpbCBtYXkgbm90IHJlcHJlc2VudCB0aG9zZSBvZiBWaXJnaW4gCj4g TWVkaWEuIEFueSByZXByZXNlbnRhdGlvbnMgb3IgY29tbWl0bWVudHMgaW4gdGhpcyBlbWFpbCBh cmUgc3ViamVjdCB0byBjb250cmFjdC4KPiAKPiBSZWdpc3RlcmVkIG9mZmljZTogNTAwIEJyb29r IERyaXZlLCBSZWFkaW5nLCBSRzIgNlVVCj4gCj4gUmVnaXN0ZXJlZCBpbiBFbmdsYW5kIGFuZCBX YWxlcyB3aXRoIG51bWJlciAyNTkxMjM3IAo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCj4gdjZvcHMgbWFpbGluZyBsaXN0Cj4gdjZvcHNAaWV0Zi5vcmcK PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzCgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwp2Nm9wcyBtYWlsaW5nIGxpc3QK djZvcHNAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9w cwotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KU2F2ZSBQYXBlciAtIERvIHlvdSByZWFsbHkgbmVlZCB0byBwcmludCB0 aGlzIGUtbWFpbD8NCg0KVmlzaXQgd3d3LnZpcmdpbm1lZGlhLmNvbSBmb3IgbW9yZSBpbmZvcm1h dGlvbiwgYW5kIG1vcmUgZnVuLg0KDQpUaGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJl IG9yIG1heSBiZSBjb25maWRlbnRpYWwgYW5kIGxlZ2FsbHkgcHJpdmlsZWdlZA0KYW5kIGFyZSBz ZW50IHNvbGVseSBmb3IgdGhlIGF0dGVudGlvbiBvZiB0aGUgYWRkcmVzc2VlKHMpLg0KDQpWaXJn aW4gTWVkaWEgd2lsbCBuZXZlciBhc2sgZm9yIGFjY291bnQgb3IgZmluYW5jaWFsIGluZm9ybWF0 aW9uIHZpYSBlbWFpbC4gSWYgeW91IGFyZSBpbiByZWNlaXB0IG9mIGEgc3VzcGljaW91cyBlbWFp bCwgcGxlYXNlIHJlcG9ydCB0byB3d3cudmlyZ2lubWVkaWEuY29tL25ldHJlcG9ydA0KDQpJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGZy b20geW91ciBzeXN0ZW06IGl0cyB1c2UsIGRpc2Nsb3N1cmUgb3IgY29weWluZyBpcyB1bmF1dGhv cmlzZWQuIFN0YXRlbWVudHMgYW5kIG9waW5pb25zIGV4cHJlc3NlZCBpbiB0aGlzIGVtYWlsIG1h eSBub3QgcmVwcmVzZW50IHRob3NlIG9mIFZpcmdpbiBNZWRpYS4gQW55IHJlcHJlc2VudGF0aW9u cyBvciBjb21taXRtZW50cyBpbiB0aGlzIGVtYWlsIGFyZSBzdWJqZWN0IHRvIGNvbnRyYWN0Lg0K DQpSZWdpc3RlcmVkIG9mZmljZTogNTAwIEJyb29rIERyaXZlLCBSZWFkaW5nLCBSRzIgNlVVDQoN ClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBhbmQgV2FsZXMgd2l0aCBudW1iZXIgMjU5MTIzNwo= From nobody Tue Oct 20 16:19: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 9D7083A07BD; Tue, 20 Oct 2020 16:19:13 -0700 (PDT) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=virginmedia.co.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4CPXA_1v8z7; Tue, 20 Oct 2020 16:19:11 -0700 (PDT) Received: from mailrelay01.virginmedia.co.uk (mailrelay01.telewest.co.uk [193.38.119.32]) (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 8853B3A07B7; Tue, 20 Oct 2020 16:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=virginmedia.co.uk; i=@virginmedia.co.uk; q=dns/txt; s=mailrelays; t=1603235951; x=1634771951; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version:content-transfer-encoding; bh=Y3qQAZYTvc705ES29nYDzYMotVkTFfYJk62FYcxH/4k=; b=QE2XFhoBP2ZVHp/iXXSvIznhFb5fO4tE2tuDrkOtH4NJ+DU8gixo1aDK /nLbWgt+g5OtbYdpMGxgE3E1R2QeMbmRCpo9bSGBnaQoijpBPJmaemojC aWThJXl/PThOmYGfTQimI2Pwyts1Bo/YqI4X37qdZyC6aPvCc/qtcqoAs 8=; IronPort-SDR: Vr+IlthqSI/7WlnwXoa90XXtxNGROnoCkwFPNCkEsG0OO5Vh5vx1sfxV139maCeGtMdOVNv6Ii x72bkx98GGYg== X-AddDisclaimer: Media X-SMTP-INT: T X-NonCorpAttach-CLI: false From: "Olopade, Olorunloba" To: Philip Homburg , "v6ops@ietf.org" CC: 6man Thread-Topic: [v6ops] New Version Notification for draft-olopade-6man-slaac-signaling-00.txt Thread-Index: AQHWpu3EqPfc7oeAUkOb/UoGeTcid6mhIDaA Date: Tue, 20 Oct 2020 23:18:54 +0000 Message-ID: <6253db31b1274f1297efc74371cc15f9@UKKNOPEXCH008.systems.private> References: <160313300387.7363.3016109002772518574@ietfa.amsl.com> <4c01bfac27744f4ba408fac1158fe7e3@UKKNOPEXCH008.systems.private> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] New Version Notification for draft-olopade-6man-slaac-signaling-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, 20 Oct 2020 23:19:14 -0000 Hello Philip, Not sure which mature solutions you are referring to. Are these standardise= d? In my opinion, to comprehensively deal with robustness issue with SLAAC, we= need to make changes to both hosts and routers. = -----Original Message----- From: pch-b9D3CB0F5@u-1.phicoh.com [mailto:pch-b9D3CB0F5@u-1.phicoh.com] On= Behalf Of Philip Homburg Sent: 20 October 2020 15:31 To: v6ops@ietf.org Cc: Olopade, Olorunloba ; 6man Subject: Re: [v6ops] New Version Notification for draft-olopade-6man-slaac-= signaling-00.txt = In your letter dated Mon, 19 Oct 2020 18:53:56 +0000 you wrote: >I'm proposing an alternate way to address the SLAAC flash renumbering = >issue, a nd I've been advised to put this in a draft. This is the = >initial draft, and de finitely need more work, but will like to know if = >people think this approach i s worth considering. The mechanism proposed in this draft could work if carefully specified to d= eal with edge cases (for example "poor man's multihoming"). However, for this to work changes are required to both routers and hosts. If the router is a CPE, then we already have quite mature solutions that do= n't require changes to hosts. This would do nothing for hosts behind old CPEs. = This draft could provide a solution of hosts that get moved to a different = VLAN. However, the need to update both hosts and router makes it more attra= ctive to find a solution that only requires hosts to be changed. -------------------------------------------------------------------- Save Paper - Do you really need to print this e-mail? Visit www.virginmedia.com for more information, and more fun. This email and any attachments are or may be confidential and legally privi= leged and are sent solely for the attention of the addressee(s). Virgin Media will never ask for account or financial information via email.= If you are in receipt of a suspicious email, please report to www.virginme= dia.com/netreport If you have received this email in error, please delete it from your system= : its use, disclosure or copying is unauthorised. Statements and opinions e= xpressed in this email may not represent those of Virgin Media. Any represe= ntations or commitments in this email are subject to contract. Registered office: 500 Brook Drive, Reading, RG2 6UU Registered in England and Wales with number 2591237 From nobody Tue Oct 20 16:40:40 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 BBD463A09C0; Tue, 20 Oct 2020 16:40:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-v6ops-slaac-renum@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, Owen DeLong , v6ops@ietf.org, owen@delong.com X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <160323723374.19211.14841316122738197736@ietfa.amsl.com> Date: Tue, 20 Oct 2020 16:40:33 -0700 Archived-At: Subject: [v6ops] Benjamin Kaduk's Discuss on draft-ietf-v6ops-slaac-renum-04: (with DISCUSS and COMMENT) 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, 20 Oct 2020 23:40:34 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-v6ops-slaac-renum-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-slaac-renum/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- In Section 2.3 we make a claim about item 'e)' of section 5.5.3 of RFC 4862, in particular that it says that 'an RA may never reduce the RemainingLifetime" to less than two hours', but the relevant text from RFC 4862 seems to be: 2. If RemainingLifetime is less than or equal to 2 hours, ignore the Prefix Information option with regards to the valid lifetime, unless the Router Advertisement from which this option was obtained has been authenticated (e.g., via Secure Neighbor Discovery [RFC3971]). If the Router Advertisement was authenticated, the valid lifetime of the corresponding address should be set to the Valid Lifetime in the received option. which clearly allows an *authenticated* RA to reduce the "RemainingLifetime" to smaller values. (Text with a similar not-quite-accurate statement appears in Section 2.4 of this document as well.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I look forward to seeing the more comprehensive solution/advice in draft-ietf-6man-slaac-renum and draft-ietf-6man-cpe-slaac-renum progress. I note that https://www.rfc-editor.org/materials/abbrev.expansion.txt does not mark "CPE" as "well-known", implying that we should probably expand it on first use. Section 1 Scenarios where this problem may arise include, but are not limited to, the following: o The most common IPv6 deployment scenario for residential or small office networks is that in which a CPE router employs DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC8415] to request a prefix from an Internet Service Provider (ISP), and a sub-prefix of the leased (nit/editorial) this construction looks like "scenarios where Q might happen include: A common scenario for X is Y. Sometimes, Y can be a scenario where Q happens." Pedantically, the list contents don't match the list introduction, since the extra introductory material doesn't match the classifier attempting to describe it. o A router (e.g. Customer Edge router) may advertise autoconfiguration prefixes corresponding to prefixes learned via DHCPv6-PD with constant PIO lifetimes that are not synchronized with the DHCPv6-PD lease time (as required in Section 6.3 of [RFC8415]). [...] nit: I suggest the parenthetical be "even though Section 6.3 of [RFC8415] requires such synchronization", since the present formulation is potentially unclear about which behavior is the required one. This means that in the aforementioned scenarios, the stale addresses would be retained and also actively employed for new communications instances for an unacceptably long period of time (one month, and one week, respectively), leading to interoperability problems, instead of hosts transitioning to the newly-advertised prefix(es) in a timelier manner. I am not 100% sure that "would" is always applicable, as I could imagine situations that conform to the above-listed scenarios yet have qualifying factors that result in non-use of the stale addresses. Perhaps "could" is more appropriate? Section 2.2 IPv6 SLAAC employs the following default PIO lifetime values: o Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days) o Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days) We noted these values previously, in the Introduction. Is it useful to repeat them in both locations? Under problematic circumstances, such as where the corresponding network information has become stale without any explicit signal from the network (as described in Section 1), it will take a host 7 days (one week) to deprecate the corresponding addresses, and 30 days (one I suggest "up to" [7 days ...]. Section 2.5 At times, the prefix lease time is fed as a constant value to the SLAAC router implementation, meaning that, eventually, the prefix lifetime advertised on the LAN side will span *past* the DHCPv6-PD lease time. This is clearly incorrect, since the SLAAC router implementation would be allowing the use of such prefixes for a longer time than it has been granted usage of those prefixes via DHCPv6-PD. I recognize that this is an informational document and we're not obligated to give advice, but we've given advice elsewhere in the document and it feels weird to end the section on such a grim note. Should we say something about such implementations ideally getting updated to reflect the specification? Section 3.2 NOTES: A CPE router advertising a sub-prefix of a prefixed leased via DHCPv6-PD will periodically refresh the Preferred Lifetime and the nit: s/prefixed leased/prefix leased/ Section 6 This document does not introduce any new security issues. (side note) we sort-of recommend using different values for AdvPreferredLifetime/AdvValidLifetime, which would presumably affect the tradeoffs for robustness vs. susceptibility to attack. But the values from RFC 4861 are just "defaults", so there's a reasonable claim to be made that the relevant security considerations should have been covered in 4861 itself and we don't need to say more here. Section 8.1 It's not clear to me that the one place we cite RFC 4941 qualifies as a normative reference. Section 8.2 The use of "[Linux]" as a slug for referencing a post to netdev is perhaps debatable. The way in which we cite RFC 6724 seems similar to the way in which we cite, e.g., RFC 8028 (which is listed as normative). From nobody Tue Oct 20 17:37: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 517393A0BFA; Tue, 20 Oct 2020 17:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, 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 qGHOxffYL6nO; Tue, 20 Oct 2020 17:37:15 -0700 (PDT) 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 2E6CE3A0BFF; Tue, 20 Oct 2020 17:37:11 -0700 (PDT) Received: from [IPv6:2800:810:464:b9c:69b8:4602:916c:a007] (unknown [IPv6:2800:810:464:b9c:69b8:4602:916c:a007]) (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 5EAB2283A50; Wed, 21 Oct 2020 00:37:07 +0000 (UTC) To: Roman Danyliw , The IESG Cc: Owen DeLong , "v6ops@ietf.org" , "v6ops-chairs@ietf.org" , "draft-ietf-v6ops-slaac-renum@ietf.org" References: <160322952602.3916.9135001094597388319@ietfa.amsl.com> <2b620a6c7c4f4d24b0c26f915263052a@cert.org> From: Fernando Gont Message-ID: Date: Tue, 20 Oct 2020 20:05:11 -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: <2b620a6c7c4f4d24b0c26f915263052a@cert.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Roman Danyliw's No Objection on draft-ietf-v6ops-slaac-renum-04: (with COMMENT) 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, 21 Oct 2020 00:37:20 -0000 Hello, Roman, On 20/10/20 19:07, Roman Danyliw wrote: > Hi Fernando! > >> -----Original Message----- >> From: iesg On Behalf Of Fernando Gont >> Sent: Tuesday, October 20, 2020 5:58 PM >> To: Roman Danyliw ; The IESG >> Cc: Owen DeLong ; v6ops@ietf.org; v6ops- >> chairs@ietf.org; draft-ietf-v6ops-slaac-renum@ietf.org >> Subject: Re: Roman Danyliw's No Objection on draft-ietf-v6ops-slaac-renum-04: >> (with COMMENT) >> >> Hello, Roman, >> >> Thanks so much for your comments! In-line... >> >> On 20/10/20 18:32, Roman Danyliw via Datatracker wrote: >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> Thanks to Klaas Wiereng for the SECDIR review. >>> >>> ** Section 6. As Section 3.2 is proposing tuning the parameters in >>> RFC4861, it is likely worth reiterating that these security >>> considerations still apply >> >> Not sure what you mean. The security considerations in RFC4861, or something >> else? > > Yes, and this is minor, I meant to restate the obvious that RFC4861 applies (instead of a bare statement that no new security). Would you consider your comment addresses if we tweak the Security Considerations text as: This document discusses a problem that may arise in scenarios where flash-renumbering events occur, and proposes workarounds to mitigate the aforementioned problems. This document does not introduce any new security issues, and thus the same security considerations as for [RFC4861] apply. ? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Oct 20 17:37:37 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 0F7213A0C10; Tue, 20 Oct 2020 17:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, 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 iz1iGiYlJ02k; Tue, 20 Oct 2020 17:37:16 -0700 (PDT) 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 866423A0C01; Tue, 20 Oct 2020 17:37:15 -0700 (PDT) Received: from [IPv6:2800:810:464:b9c:69b8:4602:916c:a007] (unknown [IPv6:2800:810:464:b9c:69b8:4602:916c:a007]) (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 5225A283A8B; Wed, 21 Oct 2020 00:37:12 +0000 (UTC) To: Ted Lemon Cc: iot-directorate@ietf.org, draft-ietf-v6ops-slaac-renum.all@ietf.org, v6ops list , last-call@ietf.org References: <160312446708.32688.2591314931699003480@ietfa.amsl.com> <43eebbf0-c08f-435b-78ff-d5595d06cbcc@si6networks.com> From: Fernando Gont Message-ID: <90fe62d8-cb16-90ff-c8af-e6b4cfba74a0@si6networks.com> Date: Tue, 20 Oct 2020 20:24:55 -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] Iotdir telechat review of draft-ietf-v6ops-slaac-renum-04 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, 21 Oct 2020 00:37:21 -0000 Hello, Ted, On 20/10/20 19:23, Ted Lemon wrote: > On Oct 20, 2020, at 3:51 PM, Fernando Gont > wrote: >>> This is relevant because some IoT deployments make use of sleepy >>> devices that may only wake up once per day or even less frequently. >>> The suggested parameters would be inappropriate for such a device. >> >> Just me double-checking: Do you mean it would be to short for them? >> >> Please note that the default router lifetime is 1800 seconds. So a host >> that sleeps for longer than that will presumably not have a default >> router when it wakes up, and would need to do a "refresh" procedure >> (RS/RA exchange) before it would be able to send a packet, anyway. > > Right, in a situation like this, where the network is pretty stable, it > would make sense to use longer lifetimes. Also bear in mind that the > communication on this network might be between two hosts on the same > link—one a data collector and one a reporting device. So the router > lifetime might not be an issue. If the communication is going > off-network, a longer router lifetime would be required. (food for thought) It would seem to me that from a robustness principle, the nodes should be able to deal with this type of scenarios gracefully. That said, if you're communicating on the local link, you'd employ link-locals (and hence don't care about the RAs and associated parameters). And if you do mean to communicate off-link, thenthe first concern would be the Router Lifetime, rather than the prefix lifetimes. >>> At the same time such a device likely is not relying on RA, since it >>> would not be awake for periodic refreshes. Nevertheless the >>> operational mitigations section could use some additional verbiage >>> about applicability so that readers do not assume that the advice >>> given there is universally applicable. >> >> Please clarify the above, and based on that, we could craft some text if >> necessary. > > What I’m suggesting is simply that you mention that the defaults you are > recommending are really most applicable in home networks, and may not be > applicable in various commercial networks, including the IoT deployment > I used as an example.  IOW, make it clear that these defaults are not > universally applicable. There’s no text right now that says that (unless > I missed it). I'd argue that they are applicable to most general cases, not just home networks. e.g., I know of several enterprise deployments that employ "shorter than RFC4861" RAs. e.g., radvd employs 4 hours/1 day for the PL/VL. An operator may always manually override these values, anyway. In any case, how about adding this to the "Notes" in Section 3.2: --- cut here ---- The aforementioned values for AdvPreferredLifetime and AdvValidLifetime are expected to be appropriate for most general network scenarios. However, operators should analyze what specific values for these configuration variables would better suit their specific network scenarios. ---- cut here ---- ...or the like? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Oct 20 17:37:40 2020 Return-Path: X-Original-To: expand-draft-ietf-v6ops-slaac-renum.all@virtual.ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7B7E53A0BFF; Tue, 20 Oct 2020 17:37:21 -0700 (PDT) X-Original-To: xfilter-draft-ietf-v6ops-slaac-renum.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-v6ops-slaac-renum.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7213A0C10; Tue, 20 Oct 2020 17:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, 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 iz1iGiYlJ02k; Tue, 20 Oct 2020 17:37:16 -0700 (PDT) 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 866423A0C01; Tue, 20 Oct 2020 17:37:15 -0700 (PDT) Received: from [IPv6:2800:810:464:b9c:69b8:4602:916c:a007] (unknown [IPv6:2800:810:464:b9c:69b8:4602:916c:a007]) (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 5225A283A8B; Wed, 21 Oct 2020 00:37:12 +0000 (UTC) To: Ted Lemon Cc: iot-directorate@ietf.org, draft-ietf-v6ops-slaac-renum.all@ietf.org, v6ops list , last-call@ietf.org References: <160312446708.32688.2591314931699003480@ietfa.amsl.com> <43eebbf0-c08f-435b-78ff-d5595d06cbcc@si6networks.com> From: Fernando Gont Message-ID: <90fe62d8-cb16-90ff-c8af-e6b4cfba74a0@si6networks.com> Date: Tue, 20 Oct 2020 20:24:55 -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 Resent-From: Resent-To: fgont@si6networks.com, jan@connect.com, richard.patterson@sky.uk, rbonica@juniper.net, fredbaker.ietf@gmail.com, warren@kumari.net, rwilton@cisco.com, Owen DeLong , v6ops@ietf.org, owen@delong.com Resent-Message-Id: <20201021003721.7B7E53A0BFF@ietfa.amsl.com> Resent-Date: Tue, 20 Oct 2020 17:37:21 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Iotdir telechat review of draft-ietf-v6ops-slaac-renum-04 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, 21 Oct 2020 00:37:22 -0000 Hello, Ted, On 20/10/20 19:23, Ted Lemon wrote: > On Oct 20, 2020, at 3:51 PM, Fernando Gont > wrote: >>> This is relevant because some IoT deployments make use of sleepy >>> devices that may only wake up once per day or even less frequently. >>> The suggested parameters would be inappropriate for such a device. >> >> Just me double-checking: Do you mean it would be to short for them? >> >> Please note that the default router lifetime is 1800 seconds. So a host >> that sleeps for longer than that will presumably not have a default >> router when it wakes up, and would need to do a "refresh" procedure >> (RS/RA exchange) before it would be able to send a packet, anyway. > > Right, in a situation like this, where the network is pretty stable, it > would make sense to use longer lifetimes. Also bear in mind that the > communication on this network might be between two hosts on the same > link—one a data collector and one a reporting device. So the router > lifetime might not be an issue. If the communication is going > off-network, a longer router lifetime would be required. (food for thought) It would seem to me that from a robustness principle, the nodes should be able to deal with this type of scenarios gracefully. That said, if you're communicating on the local link, you'd employ link-locals (and hence don't care about the RAs and associated parameters). And if you do mean to communicate off-link, thenthe first concern would be the Router Lifetime, rather than the prefix lifetimes. >>> At the same time such a device likely is not relying on RA, since it >>> would not be awake for periodic refreshes. Nevertheless the >>> operational mitigations section could use some additional verbiage >>> about applicability so that readers do not assume that the advice >>> given there is universally applicable. >> >> Please clarify the above, and based on that, we could craft some text if >> necessary. > > What I’m suggesting is simply that you mention that the defaults you are > recommending are really most applicable in home networks, and may not be > applicable in various commercial networks, including the IoT deployment > I used as an example.  IOW, make it clear that these defaults are not > universally applicable. There’s no text right now that says that (unless > I missed it). I'd argue that they are applicable to most general cases, not just home networks. e.g., I know of several enterprise deployments that employ "shorter than RFC4861" RAs. e.g., radvd employs 4 hours/1 day for the PL/VL. An operator may always manually override these values, anyway. In any case, how about adding this to the "Notes" in Section 3.2: --- cut here ---- The aforementioned values for AdvPreferredLifetime and AdvValidLifetime are expected to be appropriate for most general network scenarios. However, operators should analyze what specific values for these configuration variables would better suit their specific network scenarios. ---- cut here ---- ...or the like? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Oct 20 19:10:57 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 5B6193A09F8; Tue, 20 Oct 2020 19:10:53 -0700 (PDT) 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 (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUeTjVFabZEf; Tue, 20 Oct 2020 19:10:51 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.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 6A9983A09F6; Tue, 20 Oct 2020 19:10:51 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 09L2AkCx004779; Tue, 20 Oct 2020 22:10:46 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 09L2AkCx004779 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1603246246; bh=OxmJRH6pSDQuhKkLqTCcvaU2y/W22P7l0VLSwlmuIss=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=P+Ss/X2YbYU39BrjDeRKkIVNHiQjde15UtIMiu9mRSUTcY5Kgs9A7nksrSLgvQ6uE +jvbbSx6RPoQvVd1EbZacN6BznUcf1vyxEX0W8jOFkOUkaOBMTrwdPmygOcak0b0nN /O2LOfe54VHOnSl6SCkYDy7SvLahpfiAafYW0Mg4= Received: from MURIEL.ad.sei.cmu.edu (muriel.ad.sei.cmu.edu [147.72.252.47]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 09L2AfD5027905; Tue, 20 Oct 2020 22:10:41 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Tue, 20 Oct 2020 22:10:41 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.1979.003; Tue, 20 Oct 2020 22:10:41 -0400 From: Roman Danyliw To: Fernando Gont , The IESG CC: Owen DeLong , "v6ops@ietf.org" , "v6ops-chairs@ietf.org" , "draft-ietf-v6ops-slaac-renum@ietf.org" Thread-Topic: Roman Danyliw's No Objection on draft-ietf-v6ops-slaac-renum-04: (with COMMENT) Thread-Index: AQHWpyiIQLBsyj8O3kCPbnX4mKk3aamhTMQA//++8cCAAFP0gP//8Hdw Date: Wed, 21 Oct 2020 02:10:40 +0000 Message-ID: References: <160322952602.3916.9135001094597388319@ietfa.amsl.com> <2b620a6c7c4f4d24b0c26f915263052a@cert.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.203.69] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [v6ops] Roman Danyliw's No Objection on draft-ietf-v6ops-slaac-renum-04: (with COMMENT) 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, 21 Oct 2020 02:10:54 -0000 SGkgRmVybmFuZG8hDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRmVy bmFuZG8gR29udCA8ZmdvbnRAc2k2bmV0d29ya3MuY29tPg0KPiBTZW50OiBUdWVzZGF5LCBPY3Rv YmVyIDIwLCAyMDIwIDc6MDUgUE0NCj4gVG86IFJvbWFuIERhbnlsaXcgPHJkZEBjZXJ0Lm9yZz47 IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiBDYzogT3dlbiBEZUxvbmcgPG93ZW5AZGVsb25n LmNvbT47IHY2b3BzQGlldGYub3JnOyB2Nm9wcy0NCj4gY2hhaXJzQGlldGYub3JnOyBkcmFmdC1p ZXRmLXY2b3BzLXNsYWFjLXJlbnVtQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBSb21hbiBEYW55 bGl3J3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtdjZvcHMtc2xhYWMtcmVudW0tMDQ6DQo+ ICh3aXRoIENPTU1FTlQpDQo+IA0KPiBIZWxsbywgUm9tYW4sDQo+IA0KPiBPbiAyMC8xMC8yMCAx OTowNywgUm9tYW4gRGFueWxpdyB3cm90ZToNCj4gPiBIaSBGZXJuYW5kbyENCj4gPg0KPiA+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBpZXNnIDxpZXNnLWJvdW5jZXNA aWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBGZXJuYW5kbyBHb250DQo+ID4+IFNlbnQ6IFR1ZXNkYXks IE9jdG9iZXIgMjAsIDIwMjAgNTo1OCBQTQ0KPiA+PiBUbzogUm9tYW4gRGFueWxpdyA8cmRkQGNl cnQub3JnPjsgVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+DQo+ID4+IENjOiBPd2VuIERlTG9uZyA8 b3dlbkBkZWxvbmcuY29tPjsgdjZvcHNAaWV0Zi5vcmc7IHY2b3BzLQ0KPiA+PiBjaGFpcnNAaWV0 Zi5vcmc7IGRyYWZ0LWlldGYtdjZvcHMtc2xhYWMtcmVudW1AaWV0Zi5vcmcNCj4gPj4gU3ViamVj dDogUmU6IFJvbWFuIERhbnlsaXcncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi12Nm9wcy1z bGFhYy1yZW51bS0NCj4gMDQ6DQo+ID4+ICh3aXRoIENPTU1FTlQpDQo+ID4+DQo+ID4+IEhlbGxv LCBSb21hbiwNCj4gPj4NCj4gPj4gVGhhbmtzIHNvIG11Y2ggZm9yIHlvdXIgY29tbWVudHMhIElu LWxpbmUuLi4NCj4gPj4NCj4gPj4gT24gMjAvMTAvMjAgMTg6MzIsIFJvbWFuIERhbnlsaXcgdmlh IERhdGF0cmFja2VyIHdyb3RlOg0KPiA+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+IC0tDQo+ID4+PiBD T01NRU5UOg0KPiA+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4+IC0tDQo+ID4+Pg0KPiA+Pj4gVGhhbmtz IHRvIEtsYWFzIFdpZXJlbmcgZm9yIHRoZSBTRUNESVIgcmV2aWV3Lg0KPiA+Pj4NCj4gPj4+ICoq IFNlY3Rpb24gNi4gIEFzIFNlY3Rpb24gMy4yIGlzIHByb3Bvc2luZyB0dW5pbmcgdGhlIHBhcmFt ZXRlcnMgaW4NCj4gPj4+IFJGQzQ4NjEsIGl0IGlzIGxpa2VseSB3b3J0aCByZWl0ZXJhdGluZyB0 aGF0IHRoZXNlIHNlY3VyaXR5DQo+ID4+PiBjb25zaWRlcmF0aW9ucyBzdGlsbCBhcHBseQ0KPiA+ Pg0KPiA+PiBOb3Qgc3VyZSB3aGF0IHlvdSBtZWFuLiBUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlv bnMgaW4gUkZDNDg2MSwgb3INCj4gPj4gc29tZXRoaW5nIGVsc2U/DQo+ID4NCj4gPiBZZXMsIGFu ZCB0aGlzIGlzIG1pbm9yLCBJIG1lYW50IHRvIHJlc3RhdGUgdGhlIG9idmlvdXMgdGhhdCBSRkM0 ODYxIGFwcGxpZXMNCj4gKGluc3RlYWQgb2YgYSBiYXJlIHN0YXRlbWVudCB0aGF0IG5vIG5ldyBz ZWN1cml0eSkuDQo+IA0KPiBXb3VsZCB5b3UgY29uc2lkZXIgeW91ciBjb21tZW50IGFkZHJlc3Nl cyBpZiB3ZSB0d2VhayB0aGUgU2VjdXJpdHkNCj4gQ29uc2lkZXJhdGlvbnMgdGV4dCBhczoNCj4g DQo+ICAgICBUaGlzIGRvY3VtZW50IGRpc2N1c3NlcyBhIHByb2JsZW0gdGhhdCBtYXkgYXJpc2Ug aW4gc2NlbmFyaW9zIHdoZXJlDQo+ICAgICBmbGFzaC1yZW51bWJlcmluZyBldmVudHMgb2NjdXIs IGFuZCBwcm9wb3NlcyB3b3JrYXJvdW5kcyB0byBtaXRpZ2F0ZQ0KPiAgICAgdGhlIGFmb3JlbWVu dGlvbmVkIHByb2JsZW1zLiAgVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBpbnRyb2R1Y2UgYW55DQo+ ICAgICBuZXcgc2VjdXJpdHkgaXNzdWVzLCBhbmQgdGh1cyB0aGUgc2FtZSBzZWN1cml0eSBjb25z aWRlcmF0aW9ucyBhcw0KPiAgICAgZm9yIFtSRkM0ODYxXSBhcHBseQ0KDQpUaGF0IHRleHQgbG9v a3MgZ29vZCBhbmQgd291bGQgYWRkcmVzcyBteSBmZWVkYmFjay4gIFRoYW5rIHlvdSENCg0KUmVn YXJkcywNClJvbWFuDQoNCg0K From nobody Tue Oct 20 19:48:58 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 B18063A0ADD for ; Tue, 20 Oct 2020 19:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 7t385aKlY-1P for ; Tue, 20 Oct 2020 19:48:51 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 E93E83A09B5 for ; Tue, 20 Oct 2020 19:48:50 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id u62so1130344iod.8 for ; Tue, 20 Oct 2020 19:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=BfSP0pp00XhRw391zkvpKMpa1OR4EsyqMzC+HBS5Mfs=; b=YFwVzLw1jJ1Qos6uWsZaNuQciKxvTcx1M9y+oRuPPoX4tZS5vUuObtK5r5ysJCnkyE 7LU9+lyE7bj0Qy8kzCHU7H/L8gdaZ5mkDFMjMIzLcYYorKtPSyVTXhabRYBlL3yq3JyU bogmXl9avyj8GjzAPFJWErokHgpHs8xE/CZMytYxUCqfOYaagNkFFybwnzJw4lhJYQUr PCKDMHNMGkvQRUfdFoLe6nNLJjYmQo2u/4cRV5OBXRHqyHRiz/YsjCNZNc0HHEreU1AD 4QMyMvarLNDO1SNtbhTc3/pTIURe/dGdnAlLZVzBu1LKDAErjV4ECAQCjyFLlnf0ESmR 4U0w== 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=BfSP0pp00XhRw391zkvpKMpa1OR4EsyqMzC+HBS5Mfs=; b=DrKnxqRyOqBkIAnQAJ4bEmiqkSuIWb1CF966Ixz0ymcg3xfOdvRmjnYeTpXMB5bwpx vhnogTcWiX3fM9rkttAioqX4Jx6nmjYHybabVpQ4O0DZeNum7qgD6nc7ynf3vQEuOi1M L6speZR3H/3Iw/UeLGSOQjcXfEESCDrU5rk+JIFobaMb9drtUw0pVy5QVyA1oMAstBxL qTvfMTYIDT9E4t4/Bj74CuFBfOnCSi5FnUrTCfuLL4Vq6hfuB4IxRFh1QlGcSBHY8/pV /RbYTh8FJ3iXNGCYvR1carCSD0L2yAU+8k10fT75Kv8dsmbsCHad/F0JirhP2kv7XQ5R pvIw== X-Gm-Message-State: AOAM5317ESHNFHtb0ghrc+nTk3qXw+E+eMBlSXa/uzE+RNNxey4rDXVc PwWhP4zORHitQlfZarSXu/VPRQ== X-Google-Smtp-Source: ABdhPJwjQEZOuhnUBd72r6RvTcqcbMBP7ldmVAvtR7bIUDMUcNycoL0l7JU0pyU2/VAkfs4KZib61A== X-Received: by 2002:a02:9381:: with SMTP id z1mr1023701jah.67.1603248530045; Tue, 20 Oct 2020 19:48:50 -0700 (PDT) Received: from mithrandir.lan (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id c9sm514666iow.1.2020.10.20.19.48.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Oct 2020 19:48:49 -0700 (PDT) From: Ted Lemon Message-Id: <93D28703-4EC0-4BB6-AD7E-287D86EAEE95@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6F5AE56E-7A9B-4E64-B7A5-A67CFE9BD251" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.91\)) Date: Tue, 20 Oct 2020 22:48:47 -0400 In-Reply-To: <90fe62d8-cb16-90ff-c8af-e6b4cfba74a0@si6networks.com> Cc: iot-directorate@ietf.org, draft-ietf-v6ops-slaac-renum.all@ietf.org, v6ops list , last-call@ietf.org To: Fernando Gont References: <160312446708.32688.2591314931699003480@ietfa.amsl.com> <43eebbf0-c08f-435b-78ff-d5595d06cbcc@si6networks.com> <90fe62d8-cb16-90ff-c8af-e6b4cfba74a0@si6networks.com> X-Mailer: Apple Mail (2.3654.0.3.2.91) Archived-At: Subject: Re: [v6ops] Iotdir telechat review of draft-ietf-v6ops-slaac-renum-04 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, 21 Oct 2020 02:48:53 -0000 --Apple-Mail=_6F5AE56E-7A9B-4E64-B7A5-A67CFE9BD251 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 20, 2020, at 7:24 PM, Fernando Gont = wrote: > The aforementioned values for AdvPreferredLifetime and = AdvValidLifetime are expected to be appropriate for most general network = scenarios. However, operators should analyze what specific values for = these configuration variables would better suit their specific network = scenarios. That seems pretty vague. It would be better to say something like: The aforementioned values for AdvPreferredLifetime and AdvValidLifetime = are expected to be an appropriate default for most networks. In some = networks, particularly where the operator has complete control of prefix = allocation and where hosts on the network may spend long periods = sleeping (e.g., sensors with limited battery), longer default values may = be appropriate. --Apple-Mail=_6F5AE56E-7A9B-4E64-B7A5-A67CFE9BD251 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Oct 20, 2020, at 7:24 PM, Fernando Gont <fgont@si6networks.com> wrote:
The aforementioned values for AdvPreferredLifetime and = AdvValidLifetime are expected to be appropriate for most general network = scenarios. However, operators should analyze what specific values for = these configuration variables would better suit their specific network = scenarios.

That seems pretty vague. It would be better to say something = like:

The = aforementioned values for AdvPreferredLifetime and AdvValidLifetime are = expected to be an appropriate default for most networks. In some = networks, particularly where the operator has complete control of prefix = allocation and where hosts on the network may spend long periods = sleeping (e.g., sensors with limited battery), longer default values may = be appropriate.

= --Apple-Mail=_6F5AE56E-7A9B-4E64-B7A5-A67CFE9BD251-- From nobody Tue Oct 20 19:49:03 2020 Return-Path: X-Original-To: expand-draft-ietf-v6ops-slaac-renum.all@virtual.ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 1B0783A0ACB; Tue, 20 Oct 2020 19:48:53 -0700 (PDT) X-Original-To: xfilter-draft-ietf-v6ops-slaac-renum.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-v6ops-slaac-renum.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14953A0AD9 for ; Tue, 20 Oct 2020 19:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 cgcSTTyXkdLm for ; Tue, 20 Oct 2020 19:48:51 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 EA6103A0AC4 for ; Tue, 20 Oct 2020 19:48:50 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id q9so1137775iow.6 for ; Tue, 20 Oct 2020 19:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=BfSP0pp00XhRw391zkvpKMpa1OR4EsyqMzC+HBS5Mfs=; b=YFwVzLw1jJ1Qos6uWsZaNuQciKxvTcx1M9y+oRuPPoX4tZS5vUuObtK5r5ysJCnkyE 7LU9+lyE7bj0Qy8kzCHU7H/L8gdaZ5mkDFMjMIzLcYYorKtPSyVTXhabRYBlL3yq3JyU bogmXl9avyj8GjzAPFJWErokHgpHs8xE/CZMytYxUCqfOYaagNkFFybwnzJw4lhJYQUr PCKDMHNMGkvQRUfdFoLe6nNLJjYmQo2u/4cRV5OBXRHqyHRiz/YsjCNZNc0HHEreU1AD 4QMyMvarLNDO1SNtbhTc3/pTIURe/dGdnAlLZVzBu1LKDAErjV4ECAQCjyFLlnf0ESmR 4U0w== 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=BfSP0pp00XhRw391zkvpKMpa1OR4EsyqMzC+HBS5Mfs=; b=cRHV5xZ/yYhK9iK1QqXoD4zZVP+4/WpT/uaVmkqhnI1IbAVrwvArV/yGBQUvSJ+Hxy lk0yiQfISabnuxLN0Rw2O2MwlAGoxGISs6Fn5F9dlDXyOIn+raTA5XUvu6jmxFYGnNxh 4lVoMyEkuwW6oqSklEvVolwIlbAK1OlXc1xfJgEuQwfU6oF4OoCPlmkV34h821dM3lSQ hJXwJOe3dld1fo7pDR7MMxwTQlbSaoDpwiZNZ0tAFmAejEoMfXH6DvAIqS2qTgbNvxv4 9jNP6IlTYk0EAuVWcqt3WIEo3w/tM9J3L8NEE0uE/dMyR1mFK/ZKU/0H9BMTnOp05Tvx uA2Q== X-Gm-Message-State: AOAM530qVtJgz84JEj+xm/dkvi2erlvH3OqtCPey1ir29sJcfJzQ1JUC 73oIqvSKxUgTt670s7ubG6d6AQ== X-Google-Smtp-Source: ABdhPJwjQEZOuhnUBd72r6RvTcqcbMBP7ldmVAvtR7bIUDMUcNycoL0l7JU0pyU2/VAkfs4KZib61A== X-Received: by 2002:a02:9381:: with SMTP id z1mr1023701jah.67.1603248530045; Tue, 20 Oct 2020 19:48:50 -0700 (PDT) Received: from mithrandir.lan (c-24-91-177-160.hsd1.ma.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id c9sm514666iow.1.2020.10.20.19.48.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Oct 2020 19:48:49 -0700 (PDT) From: Ted Lemon Message-Id: <93D28703-4EC0-4BB6-AD7E-287D86EAEE95@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6F5AE56E-7A9B-4E64-B7A5-A67CFE9BD251" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.91\)) Date: Tue, 20 Oct 2020 22:48:47 -0400 In-Reply-To: <90fe62d8-cb16-90ff-c8af-e6b4cfba74a0@si6networks.com> Cc: iot-directorate@ietf.org, draft-ietf-v6ops-slaac-renum.all@ietf.org, v6ops list , last-call@ietf.org To: Fernando Gont References: <160312446708.32688.2591314931699003480@ietfa.amsl.com> <43eebbf0-c08f-435b-78ff-d5595d06cbcc@si6networks.com> <90fe62d8-cb16-90ff-c8af-e6b4cfba74a0@si6networks.com> X-Mailer: Apple Mail (2.3654.0.3.2.91) Resent-From: Resent-To: fgont@si6networks.com, jan@connect.com, richard.patterson@sky.uk, rbonica@juniper.net, fredbaker.ietf@gmail.com, warren@kumari.net, rwilton@cisco.com, Owen DeLong , v6ops@ietf.org, owen@delong.com Resent-Message-Id: <20201021024853.1B0783A0ACB@ietfa.amsl.com> Resent-Date: Tue, 20 Oct 2020 19:48:53 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Iotdir telechat review of draft-ietf-v6ops-slaac-renum-04 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, 21 Oct 2020 02:48:53 -0000 --Apple-Mail=_6F5AE56E-7A9B-4E64-B7A5-A67CFE9BD251 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 20, 2020, at 7:24 PM, Fernando Gont = wrote: > The aforementioned values for AdvPreferredLifetime and = AdvValidLifetime are expected to be appropriate for most general network = scenarios. However, operators should analyze what specific values for = these configuration variables would better suit their specific network = scenarios. That seems pretty vague. It would be better to say something like: The aforementioned values for AdvPreferredLifetime and AdvValidLifetime = are expected to be an appropriate default for most networks. In some = networks, particularly where the operator has complete control of prefix = allocation and where hosts on the network may spend long periods = sleeping (e.g., sensors with limited battery), longer default values may = be appropriate. --Apple-Mail=_6F5AE56E-7A9B-4E64-B7A5-A67CFE9BD251 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Oct 20, 2020, at 7:24 PM, Fernando Gont <fgont@si6networks.com> wrote:
The aforementioned values for AdvPreferredLifetime and = AdvValidLifetime are expected to be appropriate for most general network = scenarios. However, operators should analyze what specific values for = these configuration variables would better suit their specific network = scenarios.

That seems pretty vague. It would be better to say something = like:

The = aforementioned values for AdvPreferredLifetime and AdvValidLifetime are = expected to be an appropriate default for most networks. In some = networks, particularly where the operator has complete control of prefix = allocation and where hosts on the network may spend long periods = sleeping (e.g., sensors with limited battery), longer default values may = be appropriate.

= --Apple-Mail=_6F5AE56E-7A9B-4E64-B7A5-A67CFE9BD251-- From nobody Tue Oct 20 20:04:32 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 CA4C63A0B17; Tue, 20 Oct 2020 20:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, 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 eeqYAxDEQl60; Tue, 20 Oct 2020 20:04:22 -0700 (PDT) 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 DF2CC3A0B16; Tue, 20 Oct 2020 20:04:21 -0700 (PDT) Received: from [IPv6:2800:810:464:b9c:69b8:4602:916c:a007] (unknown [IPv6:2800:810:464:b9c:69b8:4602:916c:a007]) (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 0C274283A50; Wed, 21 Oct 2020 03:04:17 +0000 (UTC) To: Benjamin Kaduk , The IESG Cc: draft-ietf-v6ops-slaac-renum@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, Owen DeLong References: <160323723374.19211.14841316122738197736@ietfa.amsl.com> From: Fernando Gont Message-ID: <89bee4d0-1a69-f165-3486-f9e2275be7a7@si6networks.com> Date: Tue, 20 Oct 2020 21:47: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: <160323723374.19211.14841316122738197736@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Benjamin Kaduk's Discuss on draft-ietf-v6ops-slaac-renum-04: (with DISCUSS and COMMENT) 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, 21 Oct 2020 03:04:26 -0000 Hello, Ben, Thanks so much for your detailed review! In-line..... On 20/10/20 20:40, Benjamin Kaduk via Datatracker wrote: [....] > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > In Section 2.3 we make a claim about item 'e)' of section 5.5.3 of RFC > 4862, in particular that it says that 'an RA may never reduce the > RemainingLifetime" to less than two hours', but the relevant text from RFC > 4862 seems to be: > > 2. If RemainingLifetime is less than or equal to 2 hours, ignore > the Prefix Information option with regards to the valid > lifetime, unless the Router Advertisement from which this > option was obtained has been authenticated (e.g., via Secure > Neighbor Discovery [RFC3971]). If the Router Advertisement > was authenticated, the valid lifetime of the corresponding > address should be set to the Valid Lifetime in the received > option. > > which clearly allows an *authenticated* RA to reduce the > "RemainingLifetime" to smaller values. (Text with a similar > not-quite-accurate statement appears in Section 2.4 of this document as > well.) I know of no-real world deployment where RAs are authenticated. That said, would noting "unauthenticated RA" in our draft address your comment? > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I look forward to seeing the more comprehensive solution/advice in > draft-ietf-6man-slaac-renum and draft-ietf-6man-cpe-slaac-renum > progress. > > I note that https://www.rfc-editor.org/materials/abbrev.expansion.txt > does not mark "CPE" as "well-known", implying that we should probably > expand it on first use. Our bad. We should use "CE Router" rather than "CPE", which is the term employed in RFC7084. Will fix this. > Section 1 > > Scenarios where this problem may arise include, but are not limited > to, the following: > > o The most common IPv6 deployment scenario for residential or small > office networks is that in which a CPE router employs DHCPv6 > Prefix Delegation (DHCPv6-PD) [RFC8415] to request a prefix from > an Internet Service Provider (ISP), and a sub-prefix of the leased > > (nit/editorial) this construction looks like "scenarios where Q might > happen include: A common scenario for X is Y. Sometimes, Y can be a > scenario where Q happens." Pedantically, the list contents don't match > the list introduction, since the extra introductory material doesn't > match the classifier attempting to describe it. You're right. How about fixing this as: "The most common IPv6 deployment scenario for residential or small office networks, where a CE router..." > o A router (e.g. Customer Edge router) may advertise > autoconfiguration prefixes corresponding to prefixes learned via > DHCPv6-PD with constant PIO lifetimes that are not synchronized > with the DHCPv6-PD lease time (as required in Section 6.3 of > [RFC8415]). [...] > > nit: I suggest the parenthetical be "even though Section 6.3 of > [RFC8415] requires such synchronization", since the present formulation > is potentially unclear about which behavior is the required one. Will apply this suggested edit. Thanks! > This means that in the aforementioned scenarios, the stale addresses > would be retained and also actively employed for new communications > instances for an unacceptably long period of time (one month, and one > week, respectively), leading to interoperability problems, instead of > hosts transitioning to the newly-advertised prefix(es) in a timelier > manner. > > I am not 100% sure that "would" is always applicable, as I could imagine > situations that conform to the above-listed scenarios yet have > qualifying factors that result in non-use of the stale addresses. Could you please elaborate? > Perhaps "could" is more appropriate? Addresses will certainly be retained. I guess one might say "would be retained and could also be...actively employed...."? > Section 2.2 > > IPv6 SLAAC employs the following default PIO lifetime values: > > o Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days) > > o Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days) > > We noted these values previously, in the Introduction. Is it useful to > repeat them in both locations? If anything, I'd remove them from the Introduction, and point to Section 2.2 from there... > Under problematic circumstances, such as where the corresponding > network information has become stale without any explicit signal from > the network (as described in Section 1), it will take a host 7 days > (one week) to deprecate the corresponding addresses, and 30 days (one > > I suggest "up to" [7 days ...]. Saying "up to" would suggest that that's the worst case scenario as opposed to the regular case. Put another way: what'd be the scenario where it would take less than that? > Section 2.5 > > At times, the prefix lease time is fed as a constant value to the > SLAAC router implementation, meaning that, eventually, the prefix > lifetime advertised on the LAN side will span *past* the DHCPv6-PD > lease time. This is clearly incorrect, since the SLAAC router > implementation would be allowing the use of such prefixes for a > longer time than it has been granted usage of those prefixes via > DHCPv6-PD. > > I recognize that this is an informational document and we're not > obligated to give advice, but we've given advice elsewhere in the > document and it feels weird to end the section on such a grim note. > Should we say something about such implementations ideally getting > updated to reflect the specification? This document is meant to describe the problem, and provide operational advice. As such, there's not really anything one can operationally do with this implementation issue -- unless you're thinking of "replace the device with one that has a different implementation". draft-ietf-v6ops-cpe-slaac-renum provides advice in this respect (i.e., implementation). Thoughts? > Section 3.2 > > NOTES: > A CPE router advertising a sub-prefix of a prefixed leased via > DHCPv6-PD will periodically refresh the Preferred Lifetime and the > > nit: s/prefixed leased/prefix leased/ Thanks! Will fix. > > Section 6 > > This document does not introduce any > new security issues. > > (side note) we sort-of recommend using different values for > AdvPreferredLifetime/AdvValidLifetime, which would presumably affect the > tradeoffs for robustness vs. susceptibility to attack. But the values > from RFC 4861 are just "defaults", so there's a reasonable claim to be > made that the relevant security considerations should have been covered > in 4861 itself and we don't need to say more here. Roman made a similar comment, and my suggestion was to tweak the text to: This document discusses a problem that may arise in scenarios where flash-renumbering events occur, and proposes workarounds to mitigate the aforementioned problems. This document does not introduce any new security issues, and thus the same security considerations as for [RFC4861] apply. Thoughts? > Section 8.1 > > It's not clear to me that the one place we cite RFC 4941 qualifies as a > normative reference. Agreed. I will move it to the Informative references. > Section 8.2 > > The use of "[Linux]" as a slug for referencing a post to netdev is > perhaps debatable. It's a link to a patch that has been committed to the tree (in the same URL, you'll find the note that the patch has been accepted). I could provide a link to the corresponding commit on the git repo? (fwiw, we didn't mean "[Linux]" to convey anything special... it was just the obvious choice for the reference). > The way in which we cite RFC 6724 seems similar to the way in which we > cite, e.g., RFC 8028 (which is listed as normative). Agreed. We'll make RFC6724 normative. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Oct 20 20:04: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 9FA653A0B60; Tue, 20 Oct 2020 20:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, 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 TJxbaYEwizKS; Tue, 20 Oct 2020 20:04:27 -0700 (PDT) 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 4A8853A0B16; Tue, 20 Oct 2020 20:04:27 -0700 (PDT) Received: from [IPv6:2800:810:464:b9c:69b8:4602:916c:a007] (unknown [IPv6:2800:810:464:b9c:69b8:4602:916c:a007]) (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 05C43283707; Wed, 21 Oct 2020 03:04:23 +0000 (UTC) To: Ted Lemon Cc: iot-directorate@ietf.org, draft-ietf-v6ops-slaac-renum.all@ietf.org, v6ops list , last-call@ietf.org References: <160312446708.32688.2591314931699003480@ietfa.amsl.com> <43eebbf0-c08f-435b-78ff-d5595d06cbcc@si6networks.com> <90fe62d8-cb16-90ff-c8af-e6b4cfba74a0@si6networks.com> <93D28703-4EC0-4BB6-AD7E-287D86EAEE95@fugue.com> From: Fernando Gont Message-ID: Date: Wed, 21 Oct 2020 00:03:11 -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: <93D28703-4EC0-4BB6-AD7E-287D86EAEE95@fugue.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Iotdir telechat review of draft-ietf-v6ops-slaac-renum-04 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, 21 Oct 2020 03:04:32 -0000 On 20/10/20 23:48, Ted Lemon wrote: > On Oct 20, 2020, at 7:24 PM, Fernando Gont > wrote: >> The aforementioned values for AdvPreferredLifetime and >> AdvValidLifetime are expected to be appropriate for most general >> network scenarios. However, operators should analyze what specific >> values for these configuration variables would better suit their >> specific network scenarios. > > That seems pretty vague. It would be better to say something like: > > The aforementioned values for AdvPreferredLifetime and AdvValidLifetime > are expected to be an appropriate default for most networks. In some > networks, particularly where the operator has complete control of prefix > allocation and where hosts on the network may spend long periods > sleeping (e.g., sensors with limited battery), longer default values may > be appropriate. Thanks a lot for the suggested text! Unless folks argue otherwise, I will incorporate it into the next rev. Thanks again! 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 Oct 20 20:04:46 2020 Return-Path: X-Original-To: expand-draft-ietf-v6ops-slaac-renum.all@virtual.ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 76F1F3A0B37; Tue, 20 Oct 2020 20:04:32 -0700 (PDT) X-Original-To: xfilter-draft-ietf-v6ops-slaac-renum.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-v6ops-slaac-renum.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA653A0B60; Tue, 20 Oct 2020 20:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, 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 TJxbaYEwizKS; Tue, 20 Oct 2020 20:04:27 -0700 (PDT) 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 4A8853A0B16; Tue, 20 Oct 2020 20:04:27 -0700 (PDT) Received: from [IPv6:2800:810:464:b9c:69b8:4602:916c:a007] (unknown [IPv6:2800:810:464:b9c:69b8:4602:916c:a007]) (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 05C43283707; Wed, 21 Oct 2020 03:04:23 +0000 (UTC) To: Ted Lemon Cc: iot-directorate@ietf.org, draft-ietf-v6ops-slaac-renum.all@ietf.org, v6ops list , last-call@ietf.org References: <160312446708.32688.2591314931699003480@ietfa.amsl.com> <43eebbf0-c08f-435b-78ff-d5595d06cbcc@si6networks.com> <90fe62d8-cb16-90ff-c8af-e6b4cfba74a0@si6networks.com> <93D28703-4EC0-4BB6-AD7E-287D86EAEE95@fugue.com> From: Fernando Gont Message-ID: Date: Wed, 21 Oct 2020 00:03:11 -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: <93D28703-4EC0-4BB6-AD7E-287D86EAEE95@fugue.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Resent-From: Resent-To: fgont@si6networks.com, jan@connect.com, richard.patterson@sky.uk, rbonica@juniper.net, fredbaker.ietf@gmail.com, warren@kumari.net, rwilton@cisco.com, Owen DeLong , v6ops@ietf.org, owen@delong.com Resent-Message-Id: <20201021030432.76F1F3A0B37@ietfa.amsl.com> Resent-Date: Tue, 20 Oct 2020 20:04:32 -0700 (PDT) Archived-At: Subject: Re: [v6ops] Iotdir telechat review of draft-ietf-v6ops-slaac-renum-04 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, 21 Oct 2020 03:04:38 -0000 On 20/10/20 23:48, Ted Lemon wrote: > On Oct 20, 2020, at 7:24 PM, Fernando Gont > wrote: >> The aforementioned values for AdvPreferredLifetime and >> AdvValidLifetime are expected to be appropriate for most general >> network scenarios. However, operators should analyze what specific >> values for these configuration variables would better suit their >> specific network scenarios. > > That seems pretty vague. It would be better to say something like: > > The aforementioned values for AdvPreferredLifetime and AdvValidLifetime > are expected to be an appropriate default for most networks. In some > networks, particularly where the operator has complete control of prefix > allocation and where hosts on the network may spend long periods > sleeping (e.g., sensors with limited battery), longer default values may > be appropriate. Thanks a lot for the suggested text! Unless folks argue otherwise, I will incorporate it into the next rev. Thanks again! 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 Oct 20 21:53:57 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 2304D3A0EF6; Tue, 20 Oct 2020 21:53:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-v6ops-cpe-slaac-renum@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, Owen DeLong , v6ops-chairs@ietf.org, owen@delong.com X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <160325603610.17357.6914550111489766157@ietfa.amsl.com> Date: Tue, 20 Oct 2020 21:53:56 -0700 Archived-At: Subject: [v6ops] Benjamin Kaduk's No Objection on draft-ietf-v6ops-cpe-slaac-renum-05: (with COMMENT) 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, 21 Oct 2020 04:53:56 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-v6ops-cpe-slaac-renum-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am not sure that we should avoid having the conversation about intended status; consider, for example, "CE Routers SHOULD override the default [...] values from [RFC4861]" (RFC 4861 is a Draft Standard). (The question was raised in the genart review thread by virtue of skew between the datatracker state and the document header, but it looks like the WG chair changed the status in the datatracker and there was no further discussion of the topic on the list.) The diff between Abstract and Introduction is interesting: there is a parenthetical "(such as when a Customer Edge Router crashes and reboots without knowledge of the previously-employed configuration information)" only in the abstract that might also be useful in the introduction, and the abstract uses 'hosts' where the introduction uses 'nodes'. (There are a couple other incidental wording differences that the authors might wish to consider normalizing on one wording for, as well as the expected additional text in the introduction that is not appropriate for an abstract.) Section 2 purpose of establishing industry-common baseline functionality. As such, the document points to several other specifications (preferable in RFC or stable form) to provide additional guidance to implementers I'm not sure that there's value in saying "preferable" [sic] in the final RFC; it's not like there would be a further chance to change the reference to have such a property anymore. Section 3.1 This means that the advertised "Preferred Lifetime" and "Valid Lifetime" MUST be dynamically adjusted such that they never span past the remaining preferred and valid lifetimes of the corresponding prefixes delegated via DHCPv6-PD on the WAN-side. (nitty/editorial) Perhaps it is obvious to most readers, but perhaps it is not universally clear that the "advertised" part refers to "advertised by the CPE in SLAAC PIOs"; if I wanted to reword to remove ambiguity, I might go with something like 'This means that the "Preferred Lifetime" and "Valid Lifetime" advertised in PIOs by the CE router MUST be dynamically adjusted [...]'. The next paragraph (for the DHCPv6 case) uses a similar wording, but the first paragraph of that sentence is a bit more clear about "employed with DHCPv6 on the LAN-side" that also serves to reduce the potential ambiguity. I'm happy to see or propose a similar rewording for the DHCPv6 case if that would be useful, but don't mind if we leave both paragraphs unchnaged, either. CE Routers providing stateful address configuration via DHCPv6 SHOULD set the DHCPv6 IA Address Option preferred-lifetime to the lesser of the remaining preferred lifetime and ND_PREFERRED_LIMIT, and the valid-lifetime of the same option to the lesser of the remaining valid lifetime and ND_VALID_LIMIT. Is it worth mentioning that ND_PREFERRED_LIMIT and ND_VALID_LIMIT are defined in Section 4? Section 3.2 * CE Routers need not employ the (possibly long) DHCPv6-PD lifetimes for the Valid Lifetime and Preferred Lifetime of PIOs (nit) do we want "received" in there anywhere (e.g., "received DHCPv6-PD lifetimes")? * Similarly, CE Routers need not employ the (possibly long) DHCPv6-PD lifetimes for the valid-lifetime and preferred- (Likewise, we could use "received" or "WAN-side" here.) Section 3.3 In order to phase-out stale SLAAC configuration information: [...] If a CE Router provides LAN-side DHCPv6 (address assignment or prefix delegation), then: [...] (editorial) Can/should these sentences use a parallel structure (e.g., "If a CE Router provides SLAAC configuration information, then [...]")? * In Replies to DHCPv6 Request, Renew, Rebind messages, send 0 lifetimes for any address assignments or prefix delegations for the deprecated prefixes for at least the valid-lifetime previously employed for them, or for a period of ND_VALID_LIMIT if the recommended lifetimes from Section 3.2 are employed. Is it deliberate to say nothing at all about Advertise messages (which are sent in response to Solicit messages, not any of the listed ones)? * The requirement in this section is conveyed as a "SHOULD" (as opposed to a "MUST"), since we acknowledge that the requirement to store information on stable storage may represent a challenge for some implementations. (editorial/style) It's not entirely clear that we gain much from the use of the first person, here. E.g., we could say 'conveyed as a "SHOULD" (as opposed to a "MUST"), since the requirement to store information on stable storage may represent a challenge for some implementations'. Section 6 I suggest noting that the security considerations from RFC 7084 continue to apply. (Also, basically the same comment I had for draft-ietf-v6ops-slaac-renum applies, which still does not imply any changes to the text.) Section 8.1 Since we say that we are *not* using the BCP 14 keywords in the sense of RFC 2119, it does not seem that RFC 2119 needs to be a normative reference. Section 8.2 It would feel more natural, at least to me, if RFC 7084 was listed as a normative reference. (In the sense that we are Updating it to make incremental additions, but you need the whole combined assembly of both documents in order to have a functional setup.) From nobody Wed Oct 21 00:00: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 919923A111A; Wed, 21 Oct 2020 00:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, 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 LwyILOIA671Y; Tue, 20 Oct 2020 23:59:58 -0700 (PDT) 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 BB75E3A1021; Tue, 20 Oct 2020 23:59:57 -0700 (PDT) Received: from [IPv6:2800:810:464:b9c:69b8:4602:916c:a007] (unknown [IPv6:2800:810:464:b9c:69b8:4602:916c:a007]) (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 096642814D9; Wed, 21 Oct 2020 06:59:51 +0000 (UTC) To: Benjamin Kaduk , The IESG Cc: draft-ietf-v6ops-cpe-slaac-renum@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, Owen DeLong References: <160325603610.17357.6914550111489766157@ietfa.amsl.com> From: Fernando Gont Message-ID: <58f8bb8c-55b8-f0dd-2b6e-4d15f37b144e@si6networks.com> Date: Wed, 21 Oct 2020 03:59:28 -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: <160325603610.17357.6914550111489766157@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Benjamin Kaduk's No Objection on draft-ietf-v6ops-cpe-slaac-renum-05: (with COMMENT) 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, 21 Oct 2020 07:00:03 -0000 Hello, Ben, On 21/10/20 01:53, Benjamin Kaduk via Datatracker wrote: [....] > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I am not sure that we should avoid having the conversation about > intended status; consider, for example, "CE Routers SHOULD override the > default [...] values from [RFC4861]" (RFC 4861 is a Draft Standard). (The > question was raised in the genart review thread by virtue of skew between > the datatracker state and the document header, but it looks like the WG chair > changed the status in the datatracker and there was no further discussion of > the topic on the list.) FWIW, the "Intended status" in the datatracker was simply an error. -- the document has always targeted "Informational", since the document it is updating is also Informational. My understanding is that [RFC4861] specifies a default value for some parameters, which are not necessarily the "recommended" values. For the most part, this document follows the style and track of RFC7084. > The diff between Abstract and Introduction is interesting: there is a > parenthetical "(such as when a Customer Edge Router crashes and reboots > without knowledge of the previously-employed configuration information)" > only in the abstract that might also be useful in the introduction, and > the abstract uses 'hosts' where the introduction uses 'nodes'. (There > are a couple other incidental wording differences that the authors might > wish to consider normalizing on one wording for, as well as the expected > additional text in the introduction that is not appropriate for an > abstract.) Will do. > Section 2 > > purpose of establishing industry-common baseline functionality. As > such, the document points to several other specifications (preferable > in RFC or stable form) to provide additional guidance to implementers > > I'm not sure that there's value in saying "preferable" [sic] in the > final RFC; it's not like there would be a further chance to change the > reference to have such a property anymore. I think we should s/preferable/preferably/. That said, what the document means is that in these cases, other documents such as e.g. RIPE BCOPs might be referenced. > > Section 3.1 > > This means that > the advertised "Preferred Lifetime" and "Valid Lifetime" MUST be > dynamically adjusted such that they never span past the remaining > preferred and valid lifetimes of the corresponding prefixes delegated > via DHCPv6-PD on the WAN-side. > > (nitty/editorial) Perhaps it is obvious to most readers, but perhaps it > is not universally clear that the "advertised" part refers to > "advertised by the CPE in SLAAC PIOs"; if I wanted to reword to remove > ambiguity, I might go with something like 'This means that the > "Preferred Lifetime" and "Valid Lifetime" advertised in PIOs by the CE > router MUST be dynamically adjusted [...]'. > The next paragraph (for the DHCPv6 case) uses a similar wording, but the > first paragraph of that sentence is a bit more clear about "employed > with DHCPv6 on the LAN-side" that also serves to reduce the potential > ambiguity. I'm happy to see or propose a similar rewording for the > DHCPv6 case if that would be useful, but don't mind if we leave both > paragraphs unchnaged, either. If you think such changes would improve the document, please feel free to propose tweaks/text. (Thanks!) > CE Routers providing stateful address configuration via DHCPv6 SHOULD > set the DHCPv6 IA Address Option preferred-lifetime to the lesser of > the remaining preferred lifetime and ND_PREFERRED_LIMIT, and the > valid-lifetime of the same option to the lesser of the remaining > valid lifetime and ND_VALID_LIMIT. > > Is it worth mentioning that ND_PREFERRED_LIMIT and ND_VALID_LIMIT are > defined in Section 4? I wouldn't mind noting that if you think that would improve the document. In such case, how about adding NOTE: ND_PREFERRED_LIMIT and ND_VALID_LIMIT are defined in Sectonn 4 of this document. ? > > Section 3.2 > > * CE Routers need not employ the (possibly long) DHCPv6-PD > lifetimes for the Valid Lifetime and Preferred Lifetime of PIOs > > (nit) do we want "received" in there anywhere (e.g., "received DHCPv6-PD > lifetimes")? Will do. > * Similarly, CE Routers need not employ the (possibly long) > DHCPv6-PD lifetimes for the valid-lifetime and preferred- > > (Likewise, we could use "received" or "WAN-side" here.) Will do. > Section 3.3 > > In order to phase-out stale SLAAC configuration information: > [...] > If a CE Router provides LAN-side DHCPv6 (address assignment or prefix > delegation), then: > [...] > > (editorial) Can/should these sentences use a parallel structure (e.g., > "If a CE Router provides SLAAC configuration information, then [...]")? It is assumed that all CE Routers provide SLAAC configuration information, since it's the only mandatory mechanism for doing so (DHCPv6 is optional). > * In Replies to DHCPv6 Request, Renew, Rebind messages, send 0 > lifetimes for any address assignments or prefix delegations for > the deprecated prefixes for at least the valid-lifetime > previously employed for them, or for a period of ND_VALID_LIMIT > if the recommended lifetimes from Section 3.2 are employed. > > Is it deliberate to say nothing at all about Advertise messages (which > are sent in response to Solicit messages, not any of the listed ones)? Unless I'm missing something: yes, that's deliberate. Essentially, what we are saying is that messages that can convey lease information should advertise the stale prefix as stale. (Advertise messages do not convey that kind of information). > * The requirement in this section is conveyed as a "SHOULD" (as > opposed to a "MUST"), since we acknowledge that the requirement > to store information on stable storage may represent a > challenge for some implementations. > > (editorial/style) It's not entirely clear that we gain much from the use > of the first person, here. E.g., we could say 'conveyed as a "SHOULD" > (as opposed to a "MUST"), since the requirement to store information on > stable storage may represent a challenge for some implementations'. Will apply the suggested edit. (Thanks!). > Section 6 > > I suggest noting that the security considerations from RFC 7084 continue > to apply. (Also, basically the same comment I had for > draft-ietf-v6ops-slaac-renum applies, which still does not imply any > changes to the text.) Would tweaking the last sentence of the Security Considerations as: "It does not introduce new security issues, and therefore the security considerations for [RFC7084] also apply to this document." address this? > Section 8.1 > > Since we say that we are *not* using the BCP 14 keywords in the sense of > RFC 2119, it does not seem that RFC 2119 needs to be a normative > reference. Fair enough. Will move RFC2119 to the Informational references. > Section 8.2 > > It would feel more natural, at least to me, if RFC 7084 was listed as a > normative reference. (In the sense that we are Updating it to make > incremental additions, but you need the whole combined assembly of both > documents in order to have a functional setup.) Agreed. Will do. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Oct 21 00:39: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 0B6033A1225; Wed, 21 Oct 2020 00:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 8fMYFyvgvoHe; Wed, 21 Oct 2020 00:39:25 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 A07D23A121B; Wed, 21 Oct 2020 00:39:24 -0700 (PDT) Received: from lhreml726-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 405E6B96C051343547DA; Wed, 21 Oct 2020 08:39:21 +0100 (IST) Received: from msceml702-chm.china.huawei.com (10.219.141.160) by lhreml726-chm.china.huawei.com (10.201.108.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 21 Oct 2020 08:39:21 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml702-chm.china.huawei.com (10.219.141.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 21 Oct 2020 10:39:20 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Wed, 21 Oct 2020 10:39:20 +0300 From: Vasilenko Eduard To: "Olopade, Olorunloba" , 6man , "v6ops@ietf.org" Thread-Topic: New Version Notification for draft-olopade-6man-slaac-signaling-00.txt Thread-Index: AQHWpke+JPdFg9XuL0GCVbkMZbBb/qmfRCqggADXTgCAAOWTUIAAoH1A Date: Wed, 21 Oct 2020 07:39:20 +0000 Message-ID: <4faaca17276d4cf6a4306421935fb7f1@huawei.com> References: <160313300387.7363.3016109002772518574@ietfa.amsl.com> <4c01bfac27744f4ba408fac1158fe7e3@UKKNOPEXCH008.systems.private> <02114d0323604e848d5107db00d976a1@huawei.com> <161b04264ec24ba9862dcb72392b466e@UKKNOPEXCH008.systems.private> In-Reply-To: <161b04264ec24ba9862dcb72392b466e@UKKNOPEXCH008.systems.private> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.197.73] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] New Version Notification for draft-olopade-6man-slaac-signaling-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: Wed, 21 Oct 2020 07:39:27 -0000 > a common factor would be the forming of a new address. [Ed: ] Nope. Prefix could be for DHCP (A flag cleared). New address would b= e given not inside ND engine (DHCP demon is different in Unix). By the way, on the problem statement: similar problem could happen for DHCP= too. Timers would be better (hours against days), but it is not acceptable= for user anyway (far from 50ms standards of the previous age). DHCP corner= case is just have not been found in live, not yet. In reality we have here= general prefix robustness problem of ND - it is not related only to SLAAC. My "Complete" flag would resolve this problem too - enough information to d= eprecate DHCP after 1st RA. How host should do DHCP address deprecation in your solution? Feedback from= DHCP demon to ND? > So, I believe all the use cases should be covered. [Ed: ] Nope. You see above. > I agree that this are long term solutions. For the short term, I think we= are stuck with just lowering the timers. [Ed: ] Nope. I would show. > We also need to consider how to do garbage collection for RIO and RDNSS [Ed: ] RIO is better to deprecate for "telco broadband services" because of= multi-prefix (many PA prefixes) environment. I would show why - MHMP is a = little complex story. RIO make sense only for Enterprise environment (with single address space, = probably PI) - I have put this statement in the draft. Ed/ > -----Original Message----- > From: Olopade, Olorunloba [mailto:Loba.Olopade@virginmedia.co.uk] > Sent: 21 =CF=CB=D4=D1=C2=D2=D1 2020 =C7. 2:14 > To: Vasilenko Eduard ; 6man ; > v6ops@ietf.org > Subject: RE: New Version Notification for draft-olopade-6man-slaac-signal= ing- > 00.txt >=20 > Hello Eduard, >=20 > Yes, I do mean Multicast RS. >=20 > Yes, we do need synchronisation. I believe some form of "feedback" is nee= ded > to achieve a "stable system". This is the premise I'm working on. With SL= AAC as > it currently is, we don't have a means of feeding back information from h= osts to > routers. That area is what I'm trying to address in this draft. By includ= ing > information in RS messages, routers can learn about the state of the host= . >=20 > This is an initial draft. So I wasn't attempting to document the complete= solution > at this time. But wanted to see if others would see the benefit of moving= in this > direction. In my opinion, I will like to see 2 changes to increase SLAAC > robustness. This and a means for the router to indicate that it is sendin= g > "complete" information (like you are indicating with the flag). >=20 > But if we are to look into the various use cases, a common factor would b= e the > forming of a new address. Hence, my proposal leverages on this, by sendin= g the > RS, as the address transitions from tentative to preferred. So, I believe= all the > use cases should be covered. >=20 > Although, I'm having a change of heart on how to achieve this. I now thin= k that > using options in RS is better than relying on the source address. The key > difference is that the current proposal is limited to PIO information. We= also > need to consider how to do garbage collection for RIO and RDNSS [Ed: ] RIO is better to deprecate. I would show why. >=20 > I agree that this are long term solutions. For the short term, I think we= are stuck > with just lowering the timers. >=20 >=20 > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Vasilenko Eduard > Sent: 20 October 2020 09:04 > To: Olopade, Olorunloba > ; 6man = ; > v6ops@ietf.org > Subject: Re: [v6ops] New Version Notification for draft-olopade-6man-slaa= c- > signaling-00.txt >=20 > Hi Loba, > I was the loudest shouting that "tweaking timers" is a very bad solution. > Hence, it was logical consequences that Ole did push me to develop my dra= ft. > I am very close to publish it. I am in the context of this discussion. I = have spent > couple of weeks exclusively on this problem. >=20 > You probably mean: "multicast RS " or "multicast NS to all routers". > It is not possible to find "multicast" in your draft. >=20 > Your proposal by itself is not bad. Synchronization is needed, indeed. > I have proposed here (and it would be discussed in my draft) 1 additional= flag in > RA message that information is "complete". > IMHO: It is a little better way for synchronization, because it does not = need > additional messages to synchronize states. >=20 > But such type of solutions are considered by me as "long-term". It needs = host > support. It could not happen very soon. > Something for short-term is needed too. >=20 > Additionally, you have not discussed solutions for all use cases presente= d by > Fernando in draft-ietf-v6ops-slaac-renum. > For example: abrupt prefix change on the router (without deprecation) Or = abrupt > VLAN change on L2 (802.1X) Or prefix is just disconnected from Carrier, b= ecause > uplink is down (replacement is not proposed yet) Or situation in multi-ho= ming > when many PA prefixes from different Carriers are announced and some coul= d > be disconnected from carrier. > But maybe it was not your goal to develop comprehensive solution for "ND > prefix robustness" (the last term is the name of my draft) >=20 > Eduard > > -----Original Message----- > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Olopade, > > Olorunloba > > Sent: 19 =CF=CB=D4=D1=C2=D2=D1 2020 =C7. 21:54 > > To: 6man ; v6ops@ietf.org > > Subject: Re: [v6ops] New Version Notification for > > draft-olopade-6man-slaac- signaling-00.txt > > > > Hello all, > > > > I'm proposing an alternate way to address the SLAAC flash renumbering > > issue, and I've been advised to put this in a draft. This is the > > initial draft, and definitely need more work, but will like to know if > > people think this approach is worth considering. > > > > Regards. > > > > Loba Olopade > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: 19 October 2020 19:43 > > To: Olopade, Olorunloba > > Subject: New Version Notification for > > draft-olopade-6man-slaac-signaling-00.txt > > > > > > A new version of I-D, draft-olopade-6man-slaac-signaling-00.txt > > has been successfully submitted by Loba Olopade and posted to the IETF > > repository. > > > > Name: draft-olopade-6man-slaac-signaling > > Revision: 00 > > Title: Explicit signaling of Stateless Address Autoconfiguration (SLAA= C) > > to Renumbering Events > > Document date: 2020-10-19 > > Group: Individual Submission > > Pages: 7 > > URL: https://www.ietf.org/archive/id/draft-olopade-6man-slaa= c- > > signaling-00.txt > > Status: https://datatracker.ietf.org/doc/draft-olopade-6man-sla= ac- > > signaling/ > > Htmlized: https://datatracker.ietf.org/doc/html/draft-olopade-6ma= n- > slaac- > > signaling > > Htmlized: https://tools.ietf.org/html/draft-olopade-6man-slaac-si= gnaling- > 00 > > > > > > Abstract: > > After a renumbering event in an IPv6 network utilizing SLAAC, hosts > > might continue to use stale addresses, as they are unaware of the > > changes. Likewise, routers, who may deprecate the use of these > > prefixes, are unaware of their use on the hosts. This scenario could > > have an adverse effect on communication with the host. This document > > proposes changes to the SLAAC algorithm that will explicitly allow > > routers to learn of these stale prefixes that are still assigned on > > the network. > > > > > > > > > > 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.i= etf.org. > > > > The IETF Secretariat > > > > > > -------------------------------------------------------------------- > > Save Paper - Do you really need to print this e-mail? > > > > Visit www.virginmedia.com for more information, and more fun. > > > > This email and any attachments are or may be confidential and legally > > privileged and are sent solely for the attention of the addressee(s). > > > > Virgin Media will never ask for account or financial information via > > email. If you are in receipt of a suspicious email, please report to > > www.virginmedia.com/netreport > > > > If you have received this email in error, please delete it from your > > system: its use, disclosure or copying is unauthorised. Statements and > > opinions expressed in this email may not represent those of Virgin > > Media. Any representations or commitments in this email are subject to > contract. > > > > Registered office: 500 Brook Drive, Reading, RG2 6UU > > > > Registered in England and Wales with number 2591237 > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -------------------------------------------------------------------- > Save Paper - Do you really need to print this e-mail? >=20 > Visit www.virginmedia.com for more information, and more fun. >=20 > This email and any attachments are or may be confidential and legally pri= vileged > and are sent solely for the attention of the addressee(s). >=20 > Virgin Media will never ask for account or financial information via emai= l. If you > are in receipt of a suspicious email, please report to > www.virginmedia.com/netreport >=20 > If you have received this email in error, please delete it from your syst= em: its > use, disclosure or copying is unauthorised. Statements and opinions expre= ssed in > this email may not represent those of Virgin Media. Any representations o= r > commitments in this email are subject to contract. >=20 > Registered office: 500 Brook Drive, Reading, RG2 6UU >=20 > Registered in England and Wales with number 2591237 From nobody Wed Oct 21 02:14:58 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 360DF3A13E9; Wed, 21 Oct 2020 02:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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_H4=0.001, RCVD_IN_MSPIKE_WL=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=BMPfYKwr; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Qozc9R1n Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGOkOQsZALh4; Wed, 21 Oct 2020 02:14:54 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681D53A13E7; Wed, 21 Oct 2020 02:14:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14788; q=dns/txt; s=iport; t=1603271694; x=1604481294; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=M0gsjZEUfR/Pvt5JI+uYWzRmLHjQb6CuQn8j0mEgdNY=; b=BMPfYKwrQ1uc2d8nwddA8YWTntitGWfcer1xQL4JVjH86Vdb23zVvZpg FntoFiJ9HiTBt/NLyfy1Q942l/9vfBzYXiEgB0Mh+N+ZuaP4tcShDpDrt Jm0TJmKURSxeuoSims3Kchzhy+j4P3s2H6MkEuwJcc8JrZocd8UlbYijt w=; X-IPAS-Result: =?us-ascii?q?A0D/AQBj+49f/5JdJa1gHQEBAQEJARIBBQUBQIE+BQELA?= =?us-ascii?q?YFRUQeBSS8sCoQyg0kDjVCYeoJTA1ULAQEBDQEBLQIEAQGESgIXgW4CJTcGD?= =?us-ascii?q?gIDAQEBAwIDAQEBAQUBAQECAQYEbYVhDIVyAQEBAQIBEhERDAEBNwEEBwQCA?= =?us-ascii?q?QgOAwQBAQECAiYCAgIwFQgIAgQBDQUIEweFUAMOIAEDol8CgTmIaHaBMoMEA?= =?us-ascii?q?QEFhSQYghAJgQ4qAYJxgmASPEKCRIQTG4FBP2YrQ4JNPoQVKhWDADOCLJAeE?= =?us-ascii?q?oMkjQiVLIF8CoJqmxaDFooNlDeOVIRlgXyaCoQuAgQCBAUCDgEBBYFqJIFXc?= =?us-ascii?q?BU7gmlQFwINjh8MFxSDOopWdDgCBgoBAQMJfIsHgTQBgRABAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3AMLCEiBVXDwxSRDRy8oMI/3cMHQzV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBN+FuelF1ezbr7/nQ28bp52GtSNKfJ9NUk?= =?us-ascii?q?oDjsMb10wlDdWeAEL2ZPjtc2QhHctEWVMkmhPzMUVcFMvkIVGHpHq04G0JG0?= =?us-ascii?q?v5OBZqIf72AcjZiMHkn+y38ofYNgNPgjf1aLhuLRKw+APWsMRegYZrJqsrjB?= =?us-ascii?q?XTpX4dcOVNzmQuLlWWzBs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,400,1596499200"; d="scan'208";a="560316747" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Oct 2020 09:14:50 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 09L9EoYj003632 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Oct 2020 09:14:50 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 21 Oct 2020 04:14:49 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 21 Oct 2020 04:14:49 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 21 Oct 2020 04:14:49 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ECb+YQzYseGHY+YYxuDTGtJiVTqgS1jCh9oSpfa/LiB+f/tN5E1O7hkqESPhppPN+VpAc2giLB05SdVGAvM8HoaDj78Q29lFyth5/1wmNzer3QSYGnwXNZ+HDXwE7MIArFVZEfAVCJIEU4a95WdF95WS6piZ0Xaa2TTCLox2Eg6eCdj28ODttXksLszhAG4iKDGuozHTO4ok/ZV+5XQ8mhLsM8UUOEDtia/tibx78F9zWpEJnij8o+tUe1PXFfyiowdoIrqk8+4TOGF6dYVt0431nHCLa9tpV+BNiWC/iNXwP2EDlLjEqMs0/YRgsItDfiwRvdrd+7tUaZ9HjVmiRA== 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=M0gsjZEUfR/Pvt5JI+uYWzRmLHjQb6CuQn8j0mEgdNY=; b=DCX2A0yPt4efmKim5FnLGJdxpvV9xnzdIaj/nLAUG7rSzpWD6q1qzzPh/VEIAoWd5ZcHVPmgKTTY23iYfkTwlcM+tvffryDCgH2rp7QFDqWymEK4hJabQDjOsz3uTAqVmwmCDeiftf4JPY+Hz9xxzStAGDX0ubVSCq3MhH3Tp0ipeBUgnbrSD325LDcU4vf25lfhCyj3D+KAJJfwbc/6LoDpABTrkVlPw02irrcs00zQYdMVjH1qbeT3xx696vtVkTIeJWdjKTXtA1vl/nU45o80Z1bYOICXEQvDLY5MXREzvfiu+keR2E3gohL5kKEO0+mKQXNRnfyz8yWCF1ZrXQ== 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=M0gsjZEUfR/Pvt5JI+uYWzRmLHjQb6CuQn8j0mEgdNY=; b=Qozc9R1nIgRMLtcfkRdzQEOWRWy8AciHrb62P+FvibTuWUQbdA78I7d0xz0fPub7xzNmgeFBwUpeuAk85oupm9qRRf4bxrW/Gos80I801YHyaV6gIsPIUGSW0WEbjyzrsZC4h8JlcIfHL5zHJdDY7SHGddoXvfbq8x4IaC6eimk= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4510.namprd11.prod.outlook.com (2603:10b6:208:17b::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.25; Wed, 21 Oct 2020 09:14:48 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241%4]) with mapi id 15.20.3477.028; Wed, 21 Oct 2020 09:14:48 +0000 From: "Rob Wilton (rwilton)" To: Fernando Gont , The IESG CC: "draft-ietf-v6ops-cpe-slaac-renum@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops@ietf.org" , Owen DeLong Thread-Topic: Robert Wilton's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS and COMMENT) Thread-Index: AQHWpkimbtOSrm9F/0yD/Q4zVGHMSqmg44QAgADVaPA= Date: Wed, 21 Oct 2020 09:14:48 +0000 Message-ID: References: <160313338012.7412.6288227175776828752@ietfa.amsl.com> <36e00b8f-1cde-5691-caea-1678fccba3b1@si6networks.com> In-Reply-To: <36e00b8f-1cde-5691-caea-1678fccba3b1@si6networks.com> Accept-Language: en-US Content-Language: en-US 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=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9f012d48-423f-4c48-6584-08d875a1c261 x-ms-traffictypediagnostic: MN2PR11MB4510: 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: NUn2aUyI2LSiEfX1LetV3W280jm49m3+Qk8OUYo5uppgCFI1ykmtcO1eAdlqu2lnxd7faEsQgvrvEcpVaTiBPWG5MzU73ul3DS5ViSeQZEfaKAHIXFGDY0PpwAcZG0MfTgRtN203nTTC3zFzPjbJis9yEcXcbu9ncOiJ7jXzbFbYp4LJzY2wtq9TBF8YbG4TCJ48CNEsXrrdTgPxY4h+mo4441BzajJV35kh7RIvXjiukqPsMgqe3j1NbGsY+u3E3DSM3Xg5ZIagQUbfTGp54nZLdFo9iMtRg9U6bRJ4TrM7D89JbkNCLhjJ57mE89mTIS0dO0NRvumjhCAQrXR+XA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(39860400002)(136003)(396003)(366004)(66446008)(8676002)(66946007)(66556008)(8936002)(76116006)(66476007)(64756008)(71200400001)(66574015)(83380400001)(55016002)(7696005)(5660300002)(186003)(4326008)(33656002)(9686003)(2906002)(110136005)(53546011)(86362001)(26005)(478600001)(52536014)(54906003)(316002)(6506007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: WsidHU9C1a33B1Lk7YHBedwBsu8ZWM5tRcVpKDWPtcOC8JW6vdBjuMsEswgH6h9oRV874a1U/cbDNHOGU5lEuUYUhRe93SvnX/Lb93va40/XIQ1vQMN0uQcAFZKbqsGbfrAhnAjJOEbY4urR54xswIvFbmxfZji9rCRsulopo/Tjx5JadPBOS4WycrAveZG7PZkmDeQxuKZY7CW6rURkj5p3D0IyL9yfvbgM/Q1GSYQoDPT0rkq796IVF6WlDCd7UjLIFfiorGIWjZwPCIwKz1m8RuyxD/c4cPHfZoPF3gCBQipJXErRNXIYzp50/MjLwjhvRoFDlglrLoq+UKzoXSwja8o5TUKJAM/7JyI/6lRsgycXDPbkBMLcYbRqZIBfLDTlSWIFs198vTi3+X4uqT3ZFgJ1DT7UsccwVKe7gfK8zz31L/OFBYfQ+EawKdT5AkvSedb5qeepdqZjC+aHy0qjzwknPwqGiRuiY37UOJeWU2K+iO3neVu+Kmzv/zxqndfSfD5WeBEas8839qeBHtUB2FQDEO56EDsRnGgeNkBQ4X6hKIifuNk+k91Z8Va6X3ZqhMqaQdhOsxcu9knZ9EAaU2NuhF1F9DkSveUwDq7a9mJs7RDmmN5v11zO28en/S0ayIw7vRxWtVSoyCw09w== 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: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9f012d48-423f-4c48-6584-08d875a1c261 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2020 09:14:48.2063 (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: /tkKGnBPjL00NAG8V/5gf6Fof1vkfIN8aHvTVWHOoKQDDYhoxyU0hv9Ia6PxcvNsa3U10O834Df8Pn/Xi4CQ8g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4510 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [v6ops] Robert Wilton's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS and COMMENT) 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, 21 Oct 2020 09:14:57 -0000 SGkgRmVybmFuZG8sDQoNClBsZWFzZSBzZWUgaW5saW5lIC4uLg0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IEZlcm5hbmRvIEdvbnQgPGZnb250QHNpNm5ldHdvcmtzLmNv bT4NCj4gU2VudDogMjAgT2N0b2JlciAyMDIwIDIwOjM1DQo+IFRvOiBSb2IgV2lsdG9uIChyd2ls dG9uKSA8cndpbHRvbkBjaXNjby5jb20+OyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCj4gQ2M6 IGRyYWZ0LWlldGYtdjZvcHMtY3BlLXNsYWFjLXJlbnVtQGlldGYub3JnOyB2Nm9wcy1jaGFpcnNA aWV0Zi5vcmc7DQo+IHY2b3BzQGlldGYub3JnOyBPd2VuIERlTG9uZyA8b3dlbkBkZWxvbmcuY29t Pg0KPiBTdWJqZWN0OiBSZTogUm9iZXJ0IFdpbHRvbidzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi12 Nm9wcy1jcGUtc2xhYWMtcmVudW0tDQo+IDA1OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0K PiANCj4gSGVsbG8sIFJvYmVydCwNCj4gDQo+IFRoYW5rcyBzbyBtdWNoIGZvciB5b3VyIGZlZWRi YWNrISBJbi1saW5lLi4uLg0KPiANCj4gT24gMTkvMTAvMjAgMTU6NDksIFJvYmVydCBXaWx0b24g dmlhIERhdGF0cmFja2VyIHdyb3RlOg0KPiBbLi4uLl0NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4g RElTQ1VTUzoNCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4NCj4gPiBIaSwNCj4gPg0KPiA+IEhvcGVm dWxseSB0aGlzIGlzbid0IGhhcmQgdG8gcmVzb2x2ZSwgYnV0IEkgZG9uJ3QgdW5kZXJzdGFuZCB0 aGUgbWVhbmluZw0KPiBvZiB0aGUNCj4gPiB0ZXh0IGluIHNlY3Rpb24gMjoNCj4gPg0KPiA+ICAg ICAgMi4gIFJlcXVpcmVtZW50cyBMYW5ndWFnZQ0KPiA+DQo+ID4gICAgICAgICBUYWtlIGNhcmVm dWwgbm90ZTogVW5saWtlIG90aGVyIElFVEYgZG9jdW1lbnRzLCB0aGUga2V5IHdvcmRzDQo+ICJN VVNUIiwNCj4gPiAgICAgICAgICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFM TCBOT1QiLCAiU0hPVUxEIiwgIlNIT1VMRA0KPiBOT1QiLA0KPiA+ICAgICAgICAgIlJFQ09NTUVO REVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMgZG9jdW1lbnQgYXJlIG5vdA0KPiB1 c2VkIGFzDQo+ID4gICAgICAgICBkZXNjcmliZWQgaW4gW1JGQzIxMTldLiAgVGhpcyBkb2N1bWVu dCB1c2VzIHRoZXNlIGtleXdvcmRzIG5vdA0KPiA+ICAgICAgICAgc3RyaWN0bHkgZm9yIHRoZSBw dXJwb3NlIG9mIGludGVyb3BlcmFiaWxpdHksIGJ1dCByYXRoZXIgZm9yIHRoZQ0KPiA+ICAgICAg ICAgcHVycG9zZSBvZiBlc3RhYmxpc2hpbmcgaW5kdXN0cnktY29tbW9uIGJhc2VsaW5lIGZ1bmN0 aW9uYWxpdHkuDQo+IEFzDQo+ID4gICAgICAgICBzdWNoLCB0aGUgZG9jdW1lbnQgcG9pbnRzIHRv IHNldmVyYWwgb3RoZXIgc3BlY2lmaWNhdGlvbnMNCj4gKHByZWZlcmFibGUNCj4gPiAgICAgICAg IGluIFJGQyBvciBzdGFibGUgZm9ybSkgdG8gcHJvdmlkZSBhZGRpdGlvbmFsIGd1aWRhbmNlIHRv DQo+IGltcGxlbWVudGVycw0KPiA+ICAgICAgICAgcmVnYXJkaW5nIGFueSBwcm90b2NvbCBpbXBs ZW1lbnRhdGlvbiByZXF1aXJlZCB0byBwcm9kdWNlIGENCj4gPiAgICAgICAgIHN1Y2Nlc3NmdWwg Q0Ugcm91dGVyIHRoYXQgaW50ZXJvcGVyYXRlcyBzdWNjZXNzZnVsbHkgd2l0aCBhDQo+ID4gICAg ICAgICBwYXJ0aWN1bGFyIHN1YnNldCBvZiBjdXJyZW50bHkgZGVwbG95aW5nIGFuZCBwbGFubmVk IGNvbW1vbiBJUHY2DQo+ID4gICAgICAgICBhY2Nlc3MgbmV0d29ya3MuDQo+ID4NCj4gPiAgICAg ICAgIE5vdGU6IHRoZSBhZm9yZW1lbnRpb25lZCB0ZXJtcyBhcmUgdXNlZCBpbiBleGFjdGx5IHRo ZSBzYW1lIHdheQ0KPiBhcyBpbg0KPiA+ICAgICAgICAgW1JGQzcwODRdLCB3aXRoIHRoZSBhYm92 ZSBleHBsYW5hdGlvbiBjb3BpZWQgdmVyYmF0aW0gZnJvbQ0KPiA+ICAgICAgICAgU2VjdGlvbiAx LjEgb2YgW1JGQzcwODRdLg0KPiA+DQo+ID4gVGhpcyBwYXJhZ3JhcGggdGVsbHMgbWUgaG93IHRo ZXNlIHdvcmRzIGFyZSBub3QgdXNlZC4gQnV0IGl0IGRvZXNuJ3QNCj4gc2VlbSB0bw0KPiA+IGV4 cGxhaW4gaG93IHRoZXkgYXJlIG1lYW50IHRvIGJlIGludGVycHJldGVkLg0KPiA+DQo+ID4gTXkg b25seSBhc3N1bXB0aW9uIGlzIHRoYXQgdGhlc2Ugd29yZHMgaGF2ZSBubyBzcGVjaWFsIG1lYW5p bmcgaW4gdGhpcw0KPiBkb2N1bWVudA0KPiA+IGF0IGFsbCwgYnV0IHRoZXkgdGhhbiByYWlzZXMg dGhlIHF1ZXN0aW9uIGFzIHRvIHdoeSBub3QgdG8gd3JpdGUgdGhlbQ0KPiBhbGwgaW4NCj4gPiBs b3dlciBjYXNlLiAgQWx0ZXJuYXRpdmVseSwgZm9sbG93aW5nIHRoZSBzdGFuZGFyZCBSRkMgMjEx OSBydWxlcyBhbmQNCj4gPiBib2lsZXJwbGF0ZSB3b3VsZCBhbHNvIHNlZW0gdG8gbWFrZSBzZW5z ZSAuLi4NCj4gDQo+IFRoZXNlIHdvcmRzIGFyZSB1c2VkIGluIGV4YWN0bHkgdGhlIHNhbWUgd2F5 IGFzIFJGQzcwODQsIHRoZSBSRkMgdGhpcw0KPiBkb2N1bWVudCBpcyBtZWFudCB0byB1cGRhdGUu DQpbUlddIA0KDQpZZXMsIEkgYXBwcmVjaWF0ZSB0aGF0LiAgQnV0IEkgZG9uJ3QgdGhpbmsgdGhh dCB0aGlzIHRleHQgbWFrZXMgYW55IG1vcmUgc2Vuc2UgdG8gbWUgaW4gUkZDNzA4NCBlaXRoZXIh DQoNCkZyb20gbXkgcmVhZGluZyBvbiB0aGlzIGRvY3VtZW50LCBJIHdvdWxkIHRoaW5rIHRoYXQg dXNpbmcgdGhlIHN0YW5kYXJkIFJGQyAyMTE5IGJvaWxlcnBsYXRlIGlzIHRoZSBiZXN0IHNvbHV0 aW9uLCBhbmQgbXkgcmVhZGluZyBvZiBSRkMgMjExOSBpcyB0aGF0IGl0IGlzIGZsZXhpYmxlIGVu b3VnaCB0byBjb3ZlciBob3cgdGhlIHRlcm1zIGFyZSBiZWluZyB1c2VkIGhlcmUuDQoNCkluIHBh cnRpY3VsYXIsIFJGQyAyMTE5IHN0YXRlcyAiTm90ZSB0aGF0IHRoZSBmb3JjZSBvZiB0aGVzZSB3 b3JkcyBpcyBtb2RpZmllZCBieSB0aGUgcmVxdWlyZW1lbnQgbGV2ZWwgb2YgdGhlIGRvY3VtZW50 IGluIHdoaWNoIHRoZXkgYXJlIHVzZWQuIiwgYW5kIHRoZSB0ZXh0IGluIHNlY3Rpb24gNiBhbGxv d3MgdGhlIHRlcm1zIHRvIGJlIHVzZWQgYm90aCB3aGVyZSBpdCBpcyAicmVxdWlyZWQgZm9yIGlu dGVyb3BlcmF0aW9uIiBhbmQgYWxzbyAidG8gbGltaXQgYmVoYXZpb3VyIHdoaWNoIGhhcyBwb3Rl bnRpYWwgdG8gY2F1c2UgaGFybSIuDQoNCk9yLCB0byBwdXQgaXQgYW5vdGhlciB3YXksIEkgZG9u J3QgcmVhbGx5IHVuZGVyc3RhbmQgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBob3cgdGhlIHRlcm1z IGFyZSBpbnRlbmRlZCB0byBiZSB1c2VkIGhlcmUsIGFuZCBob3cgdGhleSBhcmUgbm9ybWFsbHkg aW50ZXJwcmV0ZWQuICBGdXJ0aGVyIHRvIHRoaXMgdGhvdWdodCwgaXQgYWxzbyBpc24ndCBjbGVh ciB0byBtZSB3aGV0aGVyIHRoZSB0ZXJtcyBhcmUgbWVhbnQgdG8gYmUgaW50ZXJwcmV0ZWQgdGhl IHNhbWUgd2F5IGJvdGggaW4gdGhlIGZpcnN0IHBhcnQgb2Ygc2VjdGlvbiAzIHRoYXQgaXMgbGlz dGluZyByZXF1aXJlbWVudHMsIGFuZCBhbHNvIHNlY3Rpb25zIDMuMSwgMy4yLCBhbmQgMy4zIHRo ZSBkZWZpbmVzIHRoZSBkZXRhaWxzLg0KDQpTbywgSSByZWFsbHkgdGhpbmsgdGhhdCB1c2luZyB0 aGUgc3RhbmRhcmQgYm9pbGVycGxhdGUgaXMgdGhlIGJlc3QgYW5zd2VyIGhlcmUsIG9yIGlmIHRo ZSB0ZXJtcyBhcmUgZGVmaW5lZCB3aXRoIGRpZmZlcmVudCBtZWFuaW5ncyB0aGF0IHRoZSB0ZXh0 IG5lZWRzIHRvIGJlIG1vcmUgZXhwbGljaXQgYWJvdXQgaG93IGV4YWN0bHkgdGhlIHRlcm1zIGRp ZmZlciBvciBhcmUgZXhwZWN0ZWQgdG8gYmUgaW50ZXJwcmV0ZWQuICBJLmUuIHJhdGhlciB0aGF0 IHNheWluZyB0aGF0IHRoZXkgYXJlIG5vdCBpbnRlcnByZXRlZCB0aGUgc2FtZSBhcyAyMTE5LCBz YXkgdGhhdCB0aGV5IGFyZSBpbnRlcnByZXRlZCB0aGUgc2FtZSBhcyAyMTE5LCBleGNlcHQgZm9y IFggJiBZIC4uLiAgT3IgYWx0ZXJuYXRpdmVseSwgbGlzdCB0aGUgcHJlY2lzZSBtZWFuaW5ncyB0 aGF0IHRoZSB0ZXJtcyB0YWtlIGluIHRoaXMgZG9jdW1lbnQgaWYgdGhleSBkb24ndCBmb2xsb3cg dGhlIGRlZmluaXRpb25zIGluIDIxMTkuDQoNCg0KPiANCj4gSW4gYSB3YXksIGNhcHMgYXJlIGVt cGxveWVkIHRvIGZsYWcgdGhlIGFkdmljZS4gQnV0IHNpbmNlIHRoZSB1c2Ugb2YNCj4gY2FwcyBt aWdodCBiZSBvdGhlcndpc2UgY29uZnVzaW5nIGZvciBmb2xrcyB0aGF0IG1pZ2h0IGludGVycHJl dCB0aGVtIGFzDQo+IGluIFJGQzIxMTksIHdlIGluY2x1ZGUgdGhlIGFib3ZlIHRleHQgKGFzIFJG QzcwODQgZGlkKS4NCj4gDQo+IA0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBDT01NRU5UOg0KPiA+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gPg0KPiA+DQo+ID4gICAgICAzLjIuICBMQU4tc2lkZSBPcHRpb24g TGlmZXRpbWVzDQo+ID4NCj4gPiAgICAgICAgIENFIFJvdXRlcnMgU0hPVUxEIG92ZXJyaWRlIHRo ZSBkZWZhdWx0IFBJTyAiUHJlZmVycmVkIExpZmV0aW1lIg0KPiBhbmQNCj4gPiAgICAgICAgICJW YWxpZCBMaWZldGltZSIgdmFsdWVzIGZyb20gW1JGQzQ4NjFdLCBhbmQgZW1wbG95IHNob3J0ZXIN Cj4gbGlmZXRpbWUNCj4gPiAgICAgICAgIHZhbHVlcyB0byBpbXByb3ZlIHRoZSByb2J1c3RuZXNz IHRvIHJlbnVtYmVyaW5nIGV2ZW50cywgd2hpbGUNCj4gPiAgICAgICAgIGNvbXBseWluZyB3aXRo IHRoZSByZXF1aXJlbWVudHMgZnJvbSBTZWN0aW9uIDIuMSBvZiB0aGlzDQo+IGRvY3VtZW50IGFu ZA0KPiA+ICAgICAgICAgdGhlIHJlY29tbWVuZGF0aW9ucyBpbiBbUkZDNzc3Ml0uDQo+ID4NCj4g PiBUaGUgcmVmZXJlbmNlIHRvIFNlY3Rpb24gMi4xIHNob3VsZCBwcm9iYWJseSBiZSB0byBzZWN0 aW9uIDM/DQo+IA0KPiBJdCBzaG91bGQgcmVmZXJlbmNlIFNlY3Rpb24gMy4xLiAtLSBzb21laG93 IHRoZSByZWZlcmVuY2Ugd2FzIGhhcmRjb2RlZA0KPiAoYXMgb3Bwb3NlZCB0byBhbiB4bWwgcmVm ZXJlbmNlKSwgYW5kIGhlbmNlIGl0IHdhc24ndCB1cGRhdGVkIHdoZW4gd2UNCj4gdXBkYXRlZCB0 aGUgZHJhZnQuIChHb29kIGdyaWVmISBXZSdsbCBmaXggdGhpcykuDQo+IA0KPiANCj4gDQo+ID4g ICAgICA3LiAgQWNrbm93bGVkZ21lbnRzDQo+ID4NCj4gPiAgICAgICAgIFRoZSBhdXRob3JzIHdv dWxkIGxpa2UgdG8gdGhhbmsgT3dlbiBEZUxvbmcsIFBoaWxpcCBIb21idXJnLCBhbmQNCj4gVGVk DQo+ID4gICAgICAgICBMZW1vbiwgZm9yIHRoZWlyIHZhbHVhYmxlIGhlbHAgaW4gaW1wcm92aW5n IHRoaXMgZG9jdW1lbnQgdmlhDQo+ID4gICAgICAgICBzdWNjZXNzaXZlIGRldGFpbGVkIHJldmll d3MuDQo+ID4NCj4gPiAgICAgICAgIFRoZSBhdXRob3JzIHdvdWxkIGxpa2UgdG8gdGhhbmsgTWlr YWVsIEFicmFoYW1zc29uLCBCcmlhbg0KPiBDYXJwZW50ZXIsDQo+ID4gICAgICAgICBMb3Jlbnpv IENvbGl0dGksIEFsZWphbmRybyBEJ0VnaWRpbywgRmVybmFuZG8gRnJlZGlhbmksDQo+IEd1aWxs ZXJtbw0KPiA+ICAgICAgICAgR29udCwgTmljayBIaWxsaWFyZCwgRXJpayBLbGluZSwgV2FycmVu IEt1bWFyaSwgT2xvcnVubG9iYQ0KPiBPbG9wYWRlLA0KPiA+ICAgICAgICAgUGV0ZSBSZXNuaWNr LCBNYXJrIFNtaXRoLCBKb2IgU25pamRlcnMsIFNhbmRlciBTdGVmZmFubiwgT2xlDQo+IFRyb2Fu LA0KPiA+ICAgICAgICAgTG9nYW5hZGVuIFZlbHZpbmRyb24sIFRpbW90aHkgV2ludGVycywgQ2hy aXN0b3BoZXIgV29vZCwgYW5kDQo+ID4gICAgICAgICBDaG9uZ2ZlbmcgWGllLCBmb3IgcHJvdmlk aW5nIHZhbHVhYmxlIGNvbW1lbnRzIG9uIGVhcmxpZXINCj4gdmVyc2lvbnMgb2YNCj4gPiAgICAg ICAgIHRoaXMgZG9jdW1lbnQuDQo+ID4NCj4gPiAgICAgICAgIFRoZSBhdXRob3JzIHdvdWxkIGxp ZSB0byB0aGFuayBNaWthZWwgQWJyYWhhbXNzb24sIEx1aXMNCj4gQmFsYmlub3QsIFRpbQ0KPiA+ ICAgICAgICAgQ2hvd24sIEJyaWFuIENhcnBlbnRlciwgT3dlbiBEZUxvbmcsIEdlcnQgRG9lcmlu ZywgU3RlaW5hciBIYXVnLA0KPiBOaWNrDQo+ID4gICAgICAgICBIaWxsaWFyZCwgUGhpbGlwIEhv bWJ1cmcsIExlZSBIb3dhcmQsIENocmlzdGlhbiBIdWl0ZW1hLCBUZWQNCj4gTGVtb24sDQo+ID4g ICAgICAgICBBbGJlcnQgTWFuZnJlZGksIEpvcmRpIFBhbGV0IE1hcnRpbmV6LCBSaWNoYXJkIFBh dHRlcnNvbiwNCj4gTWljaGFlbA0KPiA+ICAgICAgICAgUmljaGFyZHNvbiwgTWFyayBTbWl0aCwg Sm9iIFNuaWpkZXJzLCBUYXJrbyBUaWthbiwgYW5kIE9sZQ0KPiBUcm9hbiwgZm9yDQo+ID4gICAg ICAgICBwcm92aWRpbmcgdmFsdWFibGUgY29tbWVudHMgb24gW0ktRC5nb250LTZtYW4tc2xhYWMt cmVudW1dLCBvbg0KPiB3aGljaA0KPiA+ICAgICAgICAgdGhpcyBkb2N1bWVudCBpcyBiYXNlZC4N Cj4gPg0KPiA+IElzIHRoZSB0aGlyZCBwYXJhZ3JhcGggZGVmaW5pdGVseSBuZWVkZWQgaW4gdGhp cyBkb2N1bWVudD8gIFBlcmhhcHMNCj4gPiBpZXRmLTZtYW4tc2xhYWMtcmVudW0gd2hpY2ggaXMg YmFzZWQgb24gZ29udC02bWFuLXNsYWFjLXJlbnVtIGNvdWxkDQo+IGNvbnRhaW4NCj4gPiB0aGlz IGFja25vd2xlZGdlbWVudD8gIE9yIHBlcmhhcHMgeW91IGNvdWxkIG1lcmdlIHRoZSB0d28gcGFy YWdyYXBocw0KPiBpbnRvIG9uZSwNCj4gPiBpZiB0aGlzIGlzIGFuIGVhcmxpZXIgdmVyc2lvbiBv ZiB0aGlzIGRvY3VtZW50LiAgVGhpcyB3b3VsZCBhbHNvIGFsbG93DQo+IHlvdSB0bw0KPiA+IHJl bW92ZSBvbmUgb2YgdGhlIHJlZmVyZW5jZXMgdG8gc2ltaWxhcmx5IG5hbWVkIGRvY3VtZW50cyBp biB0aGUNCj4gcmVmZXJlbmNlcy4NCj4gDQo+IENsYXJpZmljYXRpb246DQo+IGRyYWZ0LWdvbnQt Nm1hbi1zbGFhYy1yZW51bSBvcmlnaW5hbGx5IGNvbnRhaW5lZCB3aGF0IGJlY2FtZSB0aHJlZQ0K PiBzZXBhcmF0ZSBkb2N1bWVudHM6DQo+ICogZHJhZnQtaWV0Zi02bWFuLXNsYWFjLXJlbnVtDQo+ ICogZHJhZnQtaWV0Zi12Nm9wcy1zbGFhYy1yZW51bQ0KPiAqIGRyYWZ0LWlldGYtdjZvcHMtY3Bl LXNsYWFjLXJlbnVtDQo+IA0KPiBTbyB0aGUgZWFybHkgZmVlZGJhY2sgb24gZHJhZnQtZ29udC02 bWFuLXNsYWFjLXJlbnVtIGhhcyBiZW5lZml0ZWQgYWxsDQo+IHRocmVlIGRvY3VtZW50LiBNeSBw ZXJzb25hbCBwb2xpY3kgcmVnYXJkaW5nIEFja25vd2xlZGdlbWVudHMgaXMgdG8gYmUNCj4gYXMg Z2VuZXJvdXMgYXMgcG9zc2libGUsIHNpbmNlIEkgYXBwcmVjaWF0ZSB0aGUgdGltZSBhbmQgZWZm b3J0IHNwZW50IGJ5DQo+IHBhcnRpY2lwYW50cyB0byBoZWxwIGltcHJvdmUgdGhlIGRvY3VtZW50 cy4NCj4gDQo+IFRoYXQgc2FpZCwgSSB0cnkgdG8gYmUgZmFjdHVhbGx5IGNvcnJlY3QgcmVnYXJk aW5nIHdoYXQgdGhleSBoYXZlDQo+IHJldmlld2VkLCBmb3IgYXQgbGVhc3QgdHdvIHJlYXNvbnM6 DQo+ICogSSBkb24ndCB3YW50IHRvIHByZXRlbmQgdGhhdCBzb21lIHBhcnRpY2lwYW50IGhhcyBy ZXZpZXdlZCBzb21ldGhpbmcNCj4gdGhhdCBoZS9zaGUgaGFzIG5vdCByZXZpZXdlZCAoZS5nLiwg SSBkb24ndCB3YW50IHRvIHByZXRlbmQgdGhhdCB0aGUNCj4gZG9jdW1lbnQgcGFzc2VkIHRoZWly IGZpbHRlcikuDQo+ICogSSBkb24ndCBldmVuIGtub3cgaWYgY2xhaW1pbmcgdGhhdCBhIHBhcnRp Y2lwYW50IGhhcyByZXZpZXdlZCBhDQo+IGRvY3VtZW50IGhlL3NoZSBoYXMgbm90IG1pZ2h0IGhh dmUgaW1wbGljYXRpb25zIGluIHRoZSBwcmVzZW5jZSBvZiBJUFJzDQo+IG9yIG90aGVyIGtpbmQg b2Ygc2ltaWxhciBzdHVmZi4NCj4gDQo+IFRoYXQncyB3aHkgdGhlIEFja3MgYXJlIHNwZWxsZWQg b3V0IGxpa2UgdGhhdC4NCltSV10gDQpPa2F5LCBJIGFncmVlIHRoYXQgYWNrbm93bGVkZ2luZyBw ZW9wbGUgZm9yIHRoZSB3b3JrIGFuZCBlZmZvcnQgdGhhdCB0aGV5IGhhdmUgcHV0IGluIGlzIHJp Z2h0IGFuZCBpbXBvcnRhbnQuDQoNClBlcmhhcHMgY2hhbmdlOg0KDQogInByb3ZpZGluZyB2YWx1 YWJsZSBjb21tZW50cyBvbiBbSS1ELmdvbnQtNm1hbi1zbGFhYy1yZW51bV0sIG9uDQogIHdoaWNo IHRoaXMgZG9jdW1lbnQgaXMgYmFzZWQuIg0KDQp0bzoNCg0KICJwcm92aWRpbmcgdmFsdWFibGUg Y29tbWVudHMgb24gZWFybGllciB3b3JrIGZyb20gd2hpY2ggdGhpcw0KICBkb2N1bWVudCBpcyBk ZXJpdmVkLiINCg0KVGhhdCBjb3VsZCB0aGVuIGFsbG93IHlvdSB0byBkcm9wIHRoZSByZWZlcmVu Y2UgdG8gZ29udC02bWFuLXNsYWFjLXJlbnVtPw0KDQo+IA0KPiANCj4gDQo+ID4gICAgICA4LjIu ICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzDQo+ID4NCj4gPiAgICAgICAgIFtJLUQuZ29udC02bWFu LXNsYWFjLXJlbnVtXQ0KPiA+ICAgICAgICAgICAgICAgICAgICBHb250LCBGLiwgWm9yeiwgSi4s IGFuZCBSLiBQYXR0ZXJzb24sICJJbXByb3ZpbmcgdGhlDQo+ID4gICAgICAgICAgICAgICAgICAg IFJvYnVzdG5lc3Mgb2YgU3RhdGVsZXNzIEFkZHJlc3MgQXV0b2NvbmZpZ3VyYXRpb24NCj4gKFNM QUFDKQ0KPiA+ICAgICAgICAgICAgICAgICAgICB0byBGbGFzaCBSZW51bWJlcmluZyBFdmVudHMi LCBkcmFmdC1nb250LTZtYW4tc2xhYWMtDQo+ID4gICAgICAgICAgICAgICAgICAgIHJlbnVtLTA4 ICh3b3JrIGluIHByb2dyZXNzKSwgTWF5IDIwMjAuDQo+ID4NCj4gPiAgICAgICAgIFtJLUQuaWV0 Zi02bWFuLXNsYWFjLXJlbnVtXQ0KPiA+ICAgICAgICAgICAgICAgICAgICBHb250LCBGLiwgWm9y eiwgSi4sIGFuZCBSLiBQYXR0ZXJzb24sICJJbXByb3ZpbmcgdGhlDQo+ID4gICAgICAgICAgICAg ICAgICAgIFJvYnVzdG5lc3Mgb2YgU3RhdGVsZXNzIEFkZHJlc3MgQXV0b2NvbmZpZ3VyYXRpb24N Cj4gKFNMQUFDKQ0KPiA+ICAgICAgICAgICAgICAgICAgICB0byBGbGFzaCBSZW51bWJlcmluZyBF dmVudHMiLCBkcmFmdC1pZXRmLTZtYW4tc2xhYWMtDQo+ID4gICAgICAgICAgICAgICAgICAgIHJl bnVtLTAxICh3b3JrIGluIHByb2dyZXNzKSwgQXVndXN0IDIwMjAuDQo+ID4NCj4gPiAgICAgICAg IFtJLUQuaWV0Zi12Nm9wcy1zbGFhYy1yZW51bV0NCj4gPiAgICAgICAgICAgICAgICAgICAgR29u dCwgRi4sIFpvcnosIEouLCBhbmQgUi4gUGF0dGVyc29uLCAiUmVhY3Rpb24gb2YNCj4gPiAgICAg ICAgICAgICAgICAgICAgU3RhdGVsZXNzIEFkZHJlc3MgQXV0b2NvbmZpZ3VyYXRpb24gKFNMQUFD KSB0byBGbGFzaC0NCj4gPiAgICAgICAgICAgICAgICAgICAgUmVudW1iZXJpbmcgRXZlbnRzIiwg ZHJhZnQtaWV0Zi12Nm9wcy1zbGFhYy1yZW51bS0wMw0KPiAod29yaw0KPiA+ICAgICAgICAgICAg ICAgICAgICBpbiBwcm9ncmVzcyksIEF1Z3VzdCAyMDIwLg0KPiA+DQo+ID4gSSB3YXMgc3VycHJp c2VkIHRoYXQgdGhpcyBkb2N1bWVudCBoYXMgaW5mb3JtYXRpdmUgcmVmZXJlbmNlcyB0byB0aHJl ZQ0KPiBvdGhlcg0KPiA+IHZlcnkgc2ltaWxhcmx5IG5hbWVkIGRvY3VtZW50cyEgIEkgd291bGQg dGhpbmsgdGhhdCBhdCBsZWFzdCB0aGUgZmlyc3QNCj4gPiByZWZlcmVuY2UgaXMgbm90IHJlcXVp cmVkIHNpbmNlIGl0IGlzIHN1cGVyc2VkZWQgYnkgaWV0Zi02bWFuLXNsYWFjLQ0KPiByZW51bSBh bmQNCj4gPiB0aHVzIGNvdWxkIGJlIGVsaWRlZD8NCj4gDQo+IEluIHJldHJvc3BlY3RpdmUsIHdl IHNob3VsZCBoYXZlIHByb2JhYmx5IG5hbWVkIHRoZSBmaWxlcyBkaWZmZXJlbnRseQ0KPiAobGVz c29uIGxlYXJuZWQhKS4NCj4gDQo+IFJlZnMgIzIgYW5kICMzIGFyZSBuZWVkZWQsIHNpbmNlIHRo b3NlIHR3byBhcmUgY29tcGxlbWVudGluZyBkb2N1bWVudHMNCj4gdG8gdGhlIHByZXNlbnQgb25l Lg0KW1JXXSANCkFncmVlZC4NCg0KPiANCj4gUmVmZXJlbmNlICMxIGlzIGluY2x1ZGVkIGJlY2F1 c2UgdGhlIEFja3MgcmVmZXJlbmNlIHN1Y2ggaW5kaXZpZHVhbA0KPiB2ZXJzaW9uIChhcyBwZXIg ZXhwbGFpbmVkIGFib3ZlKS4NCj4gDQo+IFRob3VnaHRzPw0KW1JXXSANCg0KUGxlYXNlIHNlZSBt eSBzdWdnZXN0aW9uIGFib3ZlIG9uIHRoZSBhY2tzIHNlY3Rpb24uICBJZiB5b3Ugd2VyZSB0byBt YWtlIHRoYXQgY2hhbmdlIHRoZW4gaXQgd291bGQgYWxsb3cgeW91IHRvIGRyb3AgdGhpcyByZWZl cmVuY2UuICBJdCBqdXN0IGZlZWxzIG9kZCBmb3IgYSBkb2N1bWVudCB0byBoYXZlIGFuIGluZm9y bWF0aXZlIHJlZmVyZW5jZSB0byB3aGF0IGlzIGxvZ2ljYWxseSBhbiBwYXJ0aWFsIGVhcmxpZXIg dmVyc2lvbiBvZiB0aGUgc2FtZSB3b3JrLg0KDQpCdXQgb3RoZXIgdGhhbiB0aGUgZGlzY3VzcyBw b2ludCwgdGhlc2UgYXJlIGp1c3QgY29tbWVudHMsIGFuZCB5b3UgaGF2ZSB0aGUgbGliZXJ0eSB0 byBrZWVwIHRoZSBhY2tzIGFuZCByZWZlcmVuY2VzIGFzIGlzIGlmIHlvdSBwcmVmZXIuDQoNClRo YW5rcywNClJvYg0KDQoNCj4gDQo+IFRoYW5rcyENCj4gDQo+IENoZWVycywNCj4gLS0NCj4gRmVy bmFuZG8gR29udA0KPiBTSTYgTmV0d29ya3MNCj4gZS1tYWlsOiBmZ29udEBzaTZuZXR3b3Jrcy5j b20NCj4gUEdQIEZpbmdlcnByaW50OiA2NjY2IDMxQzYgRDQ4NCA2M0IyIDhGQjEgRTNDNCBBRTI1 IDBENTUgMUQ0RSA3NDkyDQo+IA0KPiANCj4gDQoNCg== From nobody Wed Oct 21 04:44: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 B8E443A1773; Wed, 21 Oct 2020 04:43:54 -0700 (PDT) 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 nAEwI9JbaAa9; Wed, 21 Oct 2020 04:43:53 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo.hq.phicoh.net [130.37.15.35]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3433A1778; Wed, 21 Oct 2020 04:43:49 -0700 (PDT) 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 m1kVCWw-0000GLC; Wed, 21 Oct 2020 13:43:46 +0200 Message-Id: To: v6ops@ietf.org Cc: "Olopade, Olorunloba" , 6man From: Philip Homburg Sender: pch-b9D3CB0F5@u-1.phicoh.com References: <160313300387.7363.3016109002772518574@ietfa.amsl.com> <4c01bfac27744f4ba408fac1158fe7e3@UKKNOPEXCH008.systems.private> <6253db31b1274f1297efc74371cc15f9@UKKNOPEXCH008.systems.private> In-reply-to: Your message of "Tue, 20 Oct 2020 23:18:54 +0000 ." <6253db31b1274f1297efc74371cc15f9@UKKNOPEXCH008.systems.private> Date: Wed, 21 Oct 2020 13:43:45 +0200 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-olopade-6man-slaac-signaling-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: Wed, 21 Oct 2020 11:43:55 -0000 > Not sure which mature solutions you are referring to. Are these > standardised? I'm talking about draft-ietf-v6ops-cpe-slaac-renum-05 I think the preferred solution to complement this is have something that only changes the host. However, a solution that only involves hosts is complex, so your approach might be a good option if a host-only solution doesn't work out. From nobody Wed Oct 21 05:19: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 917D43A0A49; Wed, 21 Oct 2020 05:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, 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 09JfVwcXjq5Y; Wed, 21 Oct 2020 05:19:48 -0700 (PDT) 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 92CA13A0A3A; Wed, 21 Oct 2020 05:19:41 -0700 (PDT) Received: from [IPv6:2800:810:464:b9c:69b8:4602:916c:a007] (unknown [IPv6:2800:810:464:b9c:69b8:4602:916c:a007]) (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 BA2E0283CE0; Wed, 21 Oct 2020 12:19:35 +0000 (UTC) To: "Rob Wilton (rwilton)" , The IESG Cc: "draft-ietf-v6ops-cpe-slaac-renum@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops@ietf.org" , Owen DeLong References: <160313338012.7412.6288227175776828752@ietfa.amsl.com> <36e00b8f-1cde-5691-caea-1678fccba3b1@si6networks.com> From: Fernando Gont Message-ID: <83a09d58-a8b3-667f-33ae-557973c5d256@si6networks.com> Date: Wed, 21 Oct 2020 07:16:49 -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] Robert Wilton's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS and COMMENT) 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, 21 Oct 2020 12:19:51 -0000 On 21/10/20 06:14, Rob Wilton (rwilton) wrote: [....] >>> >>> Hopefully this isn't hard to resolve, but I don't understand the >>> meaning >> of the >>> text in section 2: >>> >>> 2. Requirements Language >>> >>> 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. [....] >> >> These words are used in exactly the same way as RFC7084, the RFC >> this document is meant to update. > [RW] > > Yes, I appreciate that. But I don't think that this text makes any > more sense to me in RFC7084 either! I'll let our AD (Warren) weigh in, since this would probably be a decision that would need his advice... > From my reading on this document, I would think that using the > standard RFC 2119 boilerplate is the best solution, and my reading of > RFC 2119 is that it is flexible enough to cover how the terms are > being used here. > > In particular, RFC 2119 states "Note that the force of these words is > modified by the requirement level of the document in which they are > used.", and the text in section 6 allows the terms to be used both > where it is "required for interoperation" and also "to limit > behaviour which has potential to cause harm". But in all cases the terminology seems to be directed at protocol specifications more than the kind of thing we are doing here. > Or, to put it another way, I don't really understand the difference > between how the terms are intended to be used here, and how they are > normally interpreted. Further to this thought, it also isn't clear > to me whether the terms are meant to be interpreted the same way both > in the first part of section 3 that is listing requirements, and also > sections 3.1, 3.2, and 3.3 the defines the details. That is indeed a valid point. Since there are places where we're quoting requirements from protocol specs (and hence the keywords should be interpreted as in RFC2119), while our own requirements should be interpreted as discussed in Section 2. SO I guess that at the very least this should be clarified. > So, I really think that using the standard boilerplate is the best > answer here, or if the terms are defined with different meanings that > the text needs to be more explicit about how exactly the terms differ > or are expected to be interpreted. I.e. rather that saying that they > are not interpreted the same as 2119, say that they are interpreted > the same as 2119, except for X & Y ... Or alternatively, list the > precise meanings that the terms take in this document if they don't > follow the definitions in 2119. Fair enough. The later would seem to me like the easier way forward. [....] >>> 7. Acknowledgments >>> [....] >>> >>> Is the third paragraph definitely needed in this document? >>> Perhaps ietf-6man-slaac-renum which is based on >>> gont-6man-slaac-renum could >> contain >>> this acknowledgement? Or perhaps you could merge the two >>> paragraphs >> into one, >>> if this is an earlier version of this document. This would also >>> allow >> you to >>> remove one of the references to similarly named documents in the >> references. >> [....] >> >> That's why the Acks are spelled out like that. > [RW] Okay, I agree that acknowledging people for the work and effort > that they have put in is right and important. > > Perhaps change: > > "providing valuable comments on [I-D.gont-6man-slaac-renum], on which > this document is based." > > to: > > "providing valuable comments on earlier work from which this document > is derived." > > That could then allow you to drop the reference to > gont-6man-slaac-renum? I don't mind doing that. Will do. [....] >> >> Refs #2 and #3 are needed, since those two are complementing >> documents to the present one. > [RW] Agreed. > >> >> Reference #1 is included because the Acks reference such >> individual version (as per explained above). >> >> Thoughts? > [RW] > > Please see my suggestion above on the acks section. If you were to > make that change then it would allow you to drop this reference. It > just feels odd for a document to have an informative reference to > what is logically an partial earlier version of the same work. Fair enough. Will apply the change. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Oct 21 07:22:48 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 C9C6B3A11CF; Wed, 21 Oct 2020 07:22:35 -0700 (PDT) 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=BcdkXAlo; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=JYhL2fC6 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgO-YqGnPWwP; Wed, 21 Oct 2020 07:22:33 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E51E3A0B76; Wed, 21 Oct 2020 07:22:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8502; q=dns/txt; s=iport; t=1603290153; x=1604499753; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zZdJfSsu59u7E1aQNs7ZArZWdPROyjCOpigciBcqtbQ=; b=BcdkXAlowpdDuFGVCWxkbgWQiI8z4e+jlY9LFWqXJ3YJx43xPo30dzso RZ/qMqxBXL2Ia5vjwqNTuJWyyL0NXjjgSQiCZ7tLQNYzOrXiFiIqB6VLg nwc5/H+MIajyAio9UhAAEV5Gg1bjG00EfcSS+3uoxX+nqRjh4P4neo1ew E=; IronPort-PHdr: =?us-ascii?q?9a23=3A7T/EaBURQhGovFEe52jq3kApXrjV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBN+FuelF1ezbr7/nQ28bp52GtSNKfJ9NUk?= =?us-ascii?q?oDjsMb10wlDdWeAEL2ZPjtc2QhHctEWVMkmhPzMUVcFMvkIVGHpHq04G0JG0?= =?us-ascii?q?v5OBZqIf72AcjZiMHkn+y38ofYNgNPgjf1aLhuLRKw+APWsMRegYZrJqsrjB?= =?us-ascii?q?XTpX4dcOVNzmQuLlWWzBs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtCQA4Q5Bf/4YNJK1gHgEBCxIMQIM?= =?us-ascii?q?hUQeBSS8sCoQyg0kDjVGYeoJTA1ULAQEBDQEBLQIEAQGESgIXgXECJTgTAgM?= =?us-ascii?q?BAQsBAQUBAQECAQYEbYVhDIVyAQEBAQIBEhERDAEBNwELBAIBCA4DBAEBAQI?= =?us-ascii?q?CJgICAjAVCAgCBAENBQgTB4VQAw4gAQOkKwKBOYhodoEygwQBAQWFLxiCEAm?= =?us-ascii?q?BDiqCcoNwgkSEExuBQT+BEUOCTT6EFSoVgwAzgiyQHoM2kxeRGQqCapsWgxa?= =?us-ascii?q?KDZQ3jlSEZYF8njgCBAIEBQIOAQEFgWsjgVdwFTuCaVAXAg2OHzeDOopWdDg?= =?us-ascii?q?CBgoBAQMJfIsHgTQBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.77,401,1596499200"; d="scan'208";a="568368803" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Oct 2020 14:22:31 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 09LEMVCB002761 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Oct 2020 14:22:31 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 21 Oct 2020 09:22:31 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 21 Oct 2020 10:22:30 -0400 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 21 Oct 2020 09:22:30 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DjvfmLrZiEyF42rkY3mshGVfmbMy5SpRtKeIO0+AQs6As5BjmrLVm+SpnCKRm60m5J1QqUmkiyzFAN9DAPfBWlKUKrWWlnu47XK88o4fHUNDzczvEWxFFK9L2wGTIuprk5rSi0Opfu93Tz9D5tbS0Ppt4cogJ7P7emGiUTS92hK9gYAcl9jFvgm/8Fa0qqI9HjIZBVaFKLqegLQrzXwaju/VdygeEO+bIivDMOSfuIGdOfaz8WE+7FBj/FZT9eGKdvKyyyzEdRqPMKc+mSubFQIDFU7YGPGRYe1YA2Su1Z7h5L4q4o5J9zdywV8l6VQ7qudDDyFRl2rzRZMXFKQhcg== 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=zZdJfSsu59u7E1aQNs7ZArZWdPROyjCOpigciBcqtbQ=; b=e4L51cDBjf0Qh93CjStN3/y/6MPBlPb8KGXEucLxKLZqVwvEcfTbL0i4dCoMEuYzol9bPmvjY3R2GHrxRc0hLZlEa/dwyvK7w/64f+UPZJCtpuImWzIXLyUcOqnp0wnHF+glM1WGYsELNxs9npmOTsn8fY7FN7xf81wHZUTClDu6j04akZDNdVp2cgJ+cu0L8mTZzjcS/2w/VrulSd/K4imIRKVZjBpZ5eOidWXddYotCt4tG/gcGaHcpo6PzoWRG1rUkTCYQRfmGBPVgXhFQtEYHcAwmV41ocZpRB6VpvhevAXdH8VFyUwI1XJveMIKNR7izSxV6TNnMXElH3zTvw== 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=zZdJfSsu59u7E1aQNs7ZArZWdPROyjCOpigciBcqtbQ=; b=JYhL2fC6kSaXkMnrH6BHybj4Q1hPims/MRsZngrx56cnO44XYx58w7lTbMKRPUU4fYhWLKUWg7YESLSlD/6JX7A2xPa30CBgDx9rRMbwhQCkVpElafoSvgW9rUQo+bOm4w3nrve/mnvdu//em9DHDOYNE2LoHZZRjgeZE16I0Gw= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by BL0PR11MB3108.namprd11.prod.outlook.com (2603:10b6:208:7e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21; Wed, 21 Oct 2020 14:22:29 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241%4]) with mapi id 15.20.3477.028; Wed, 21 Oct 2020 14:22:29 +0000 From: "Rob Wilton (rwilton)" To: Fernando Gont , The IESG , "Warren Kumari" CC: "draft-ietf-v6ops-cpe-slaac-renum@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops@ietf.org" , Owen DeLong Thread-Topic: Robert Wilton's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS and COMMENT) Thread-Index: AQHWpkimbtOSrm9F/0yD/Q4zVGHMSqmg44QAgADVaPCAACEVgIAAPv2Q Date: Wed, 21 Oct 2020 14:22:29 +0000 Message-ID: References: <160313338012.7412.6288227175776828752@ietfa.amsl.com> <36e00b8f-1cde-5691-caea-1678fccba3b1@si6networks.com> <83a09d58-a8b3-667f-33ae-557973c5d256@si6networks.com> In-Reply-To: <83a09d58-a8b3-667f-33ae-557973c5d256@si6networks.com> Accept-Language: en-US Content-Language: en-US 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=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cb166fb5-770d-43b3-189b-08d875ccbe09 x-ms-traffictypediagnostic: BL0PR11MB3108: 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: AWaJOsh41CuFVUIxFLGvKW4Kim58tD0etVzZs71yY27d6XUU9kOaz6cgaBhNqACMh6dKVCZLVDJhClnRzibt4mvd3lgk7Q6r8VxmqgZr1kriebxviuoIIdFPHCF7UgExSaye9Ogj1w2lGupLnv5VqGhRL8LXo5rCNK0bIXuBsKJzjdu39eJsBDNvBZaRACVh1CkRl0fs4MotRu6n1oRaJlxSd77uv/3xJOeeqZCz3beIGlZcjXDZBe7H6GKmkqxmVkw+4x60sMhmsQALFfdih8lPQtKoSTx6qg0GpdRzLOdEPEI0Tbrwkxgn0gzoQLbO6cXFlmTExZi1GG4WFcb6vg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(376002)(366004)(39860400002)(136003)(346002)(83380400001)(5660300002)(55016002)(4326008)(6506007)(53546011)(478600001)(26005)(71200400001)(33656002)(186003)(9686003)(7696005)(66446008)(64756008)(316002)(110136005)(66476007)(2906002)(86362001)(66556008)(66946007)(76116006)(8936002)(8676002)(52536014)(54906003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: SV8m7w8gzjo0r/VRMry6SFRvqcdVkhAZ/Xm4nZDf2HMQcUFjXRPYxKZrYVf48on4x1aRH6Awj3mQVowD8knNXWrFkadQSTWdXbcRAuKD8MT0Tukw2nPEksnotK8YE3O1rFgzzwa+9DvBa7W6q1M5+Pdj7aTmjV8PdCvCarz0pZ4DUCnXr1/txV2LCqJvcESc/OEDK/YMGFoJtnHQnDEZcZtrjLWy41Pbu6kzhohfJSTLyFpvCy2hQb4CIvfODVEkqDma4XEKnAMcNpiOBojoXs2ZpyEuDTM5RyKRNN3EJ4yHdq+V9eHeZLpkeEfDXXDkiV3hWKRzx/EVGacOpoFNaslz+opKUrQrXlRVlpRZIzADCg/aO+FtQP5MMvbcKxhVafpznN8N7SDAW/8UQ4LXloQSW4urEIi4fTaENqKFTtKBe5T4Y/II9L4tPIgDVve6XiPXhdx+1k6WO6z6+IEx7i26duCWnanzzt8JvxEhqI08rleoLWRUQjSGkUx3DUTU8E0N1kGbYz+p4M7QEjl9ltYq3nQ+VlMB4OT4c4LvtfiVBJeiC5bbt6hk/wySJRs38hHRXcFHTkm3hclWZeKJPEklgPBmljfHLA1I48fwNGVlUP7IyQ/RmXTMqNdGPweNZGLFnoWyDNU8us/VmZmp+A== 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: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cb166fb5-770d-43b3-189b-08d875ccbe09 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2020 14:22:29.3631 (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: cq5WXFflq3L9g4lrA/6XubJ4XCgmA/mhRDTve2Jg7FvzX3Rk+rICnXT2J0vwvTgX9rTT7yRcFFH7dEG4gDEtcA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3108 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [v6ops] Robert Wilton's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS and COMMENT) 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, 21 Oct 2020 14:22:42 -0000 SGkgRmVybmFuZG8sDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRmVy bmFuZG8gR29udCA8ZmdvbnRAc2k2bmV0d29ya3MuY29tPg0KPiBTZW50OiAyMSBPY3RvYmVyIDIw MjAgMTE6MTcNCj4gVG86IFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNpc2NvLmNvbT47 IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiBDYzogZHJhZnQtaWV0Zi12Nm9wcy1jcGUtc2xh YWMtcmVudW1AaWV0Zi5vcmc7IHY2b3BzLWNoYWlyc0BpZXRmLm9yZzsNCj4gdjZvcHNAaWV0Zi5v cmc7IE93ZW4gRGVMb25nIDxvd2VuQGRlbG9uZy5jb20+DQo+IFN1YmplY3Q6IFJlOiBSb2JlcnQg V2lsdG9uJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXY2b3BzLWNwZS1zbGFhYy1yZW51bS0NCj4g MDU6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQo+IA0KPiBPbiAyMS8xMC8yMCAwNjoxNCwg Um9iIFdpbHRvbiAocndpbHRvbikgd3JvdGU6DQo+IFsuLi4uXQ0KPiA+Pj4NCj4gPj4+IEhvcGVm dWxseSB0aGlzIGlzbid0IGhhcmQgdG8gcmVzb2x2ZSwgYnV0IEkgZG9uJ3QgdW5kZXJzdGFuZCB0 aGUNCj4gPj4+IG1lYW5pbmcNCj4gPj4gb2YgdGhlDQo+ID4+PiB0ZXh0IGluIHNlY3Rpb24gMjoN Cj4gPj4+DQo+ID4+PiAyLiAgUmVxdWlyZW1lbnRzIExhbmd1YWdlDQo+ID4+Pg0KPiA+Pj4gVGFr ZSBjYXJlZnVsIG5vdGU6IFVubGlrZSBvdGhlciBJRVRGIGRvY3VtZW50cywgdGhlIGtleSB3b3Jk cw0KPiA+PiAiTVVTVCIsDQo+ID4+PiAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAi U0hBTEwgTk9UIiwgIlNIT1VMRCIsICJTSE9VTEQNCj4gPj4gTk9UIiwNCj4gPj4+ICJSRUNPTU1F TkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiB0aGlzIGRvY3VtZW50IGFyZSBub3QNCj4g Pj4gdXNlZCBhcw0KPiA+Pj4gZGVzY3JpYmVkIGluIFtSRkMyMTE5XS4gIFRoaXMgZG9jdW1lbnQg dXNlcyB0aGVzZSBrZXl3b3JkcyBub3QNCj4gPj4+IHN0cmljdGx5IGZvciB0aGUgcHVycG9zZSBv ZiBpbnRlcm9wZXJhYmlsaXR5LCBidXQgcmF0aGVyIGZvciB0aGUNCj4gPj4+IHB1cnBvc2Ugb2Yg ZXN0YWJsaXNoaW5nIGluZHVzdHJ5LWNvbW1vbiBiYXNlbGluZSBmdW5jdGlvbmFsaXR5Lg0KPiBb Li4uLl0NCj4gPj4NCj4gPj4gVGhlc2Ugd29yZHMgYXJlIHVzZWQgaW4gZXhhY3RseSB0aGUgc2Ft ZSB3YXkgYXMgUkZDNzA4NCwgdGhlIFJGQw0KPiA+PiB0aGlzIGRvY3VtZW50IGlzIG1lYW50IHRv IHVwZGF0ZS4NCj4gPiBbUlddDQo+ID4NCj4gPiBZZXMsIEkgYXBwcmVjaWF0ZSB0aGF0LiAgQnV0 IEkgZG9uJ3QgdGhpbmsgdGhhdCB0aGlzIHRleHQgbWFrZXMgYW55DQo+ID4gbW9yZSBzZW5zZSB0 byBtZSBpbiBSRkM3MDg0IGVpdGhlciENCj4gDQo+IEknbGwgbGV0IG91ciBBRCAoV2FycmVuKSB3 ZWlnaCBpbiwgc2luY2UgdGhpcyB3b3VsZCBwcm9iYWJseSBiZSBhDQo+IGRlY2lzaW9uIHRoYXQg d291bGQgbmVlZCBoaXMgYWR2aWNlLi4uDQo+IA0KW1JXXSANCg0KTm90ZSwgSSdtIG5vdCBzdWdn ZXN0aW5nIHRoYXQgd2UgY2hhbmdlIHRoZSB0ZXh0IGluIFJGQyA3MDg0ICh3YXRlciB1bmRlciB0 aGUgYnJpZGdlKSwgYnV0IEkgZG8gdGhpbmsgdGhhdCB0aGUgdGV4dCBpbiB0aGlzIGRvY3VtZW50 IHNob3VsZCBiZSBjbGVhci4NCg0KUHJvYmFibHkgdGhpcyB3aWxsIGdldCBkaXNjdXNzZWQgaW4g dGhlIHRlbGVjaGF0IHRvbW9ycm93Lg0KDQo+IA0KPiANCj4gPiBGcm9tIG15IHJlYWRpbmcgb24g dGhpcyBkb2N1bWVudCwgSSB3b3VsZCB0aGluayB0aGF0IHVzaW5nIHRoZQ0KPiA+IHN0YW5kYXJk IFJGQyAyMTE5IGJvaWxlcnBsYXRlIGlzIHRoZSBiZXN0IHNvbHV0aW9uLCBhbmQgbXkgcmVhZGlu ZyBvZg0KPiA+IFJGQyAyMTE5IGlzIHRoYXQgaXQgaXMgZmxleGlibGUgZW5vdWdoIHRvIGNvdmVy IGhvdyB0aGUgdGVybXMgYXJlDQo+ID4gYmVpbmcgdXNlZCBoZXJlLg0KPiA+DQo+ID4gSW4gcGFy dGljdWxhciwgUkZDIDIxMTkgc3RhdGVzICJOb3RlIHRoYXQgdGhlIGZvcmNlIG9mIHRoZXNlIHdv cmRzIGlzDQo+ID4gbW9kaWZpZWQgYnkgdGhlIHJlcXVpcmVtZW50IGxldmVsIG9mIHRoZSBkb2N1 bWVudCBpbiB3aGljaCB0aGV5IGFyZQ0KPiA+IHVzZWQuIiwgYW5kIHRoZSB0ZXh0IGluIHNlY3Rp b24gNiBhbGxvd3MgdGhlIHRlcm1zIHRvIGJlIHVzZWQgYm90aA0KPiA+IHdoZXJlIGl0IGlzICJy ZXF1aXJlZCBmb3IgaW50ZXJvcGVyYXRpb24iIGFuZCBhbHNvICJ0byBsaW1pdA0KPiA+IGJlaGF2 aW91ciB3aGljaCBoYXMgcG90ZW50aWFsIHRvIGNhdXNlIGhhcm0iLg0KPiANCj4gQnV0IGluIGFs bCBjYXNlcyB0aGUgdGVybWlub2xvZ3kgc2VlbXMgdG8gYmUgZGlyZWN0ZWQgYXQgcHJvdG9jb2wN Cj4gc3BlY2lmaWNhdGlvbnMgbW9yZSB0aGFuIHRoZSBraW5kIG9mIHRoaW5nIHdlIGFyZSBkb2lu ZyBoZXJlLg0KW1JXXSANCg0KWWVzLCBJIGFncmVlIHRoYXQgYXBwbHlpbmcgUkZDIDIxMTkgbGFu Z3VhZ2UgdG8gYSBsaXN0IG9mIHJlcXVpcmVtZW50cyBjYW4gc2VlbSBhIGJpdCBzdHJhbmdlLg0K DQo+IA0KPiANCj4gDQo+ID4gT3IsIHRvIHB1dCBpdCBhbm90aGVyIHdheSwgSSBkb24ndCByZWFs bHkgdW5kZXJzdGFuZCB0aGUgZGlmZmVyZW5jZQ0KPiA+IGJldHdlZW4gaG93IHRoZSB0ZXJtcyBh cmUgaW50ZW5kZWQgdG8gYmUgdXNlZCBoZXJlLCBhbmQgaG93IHRoZXkgYXJlDQo+ID4gbm9ybWFs bHkgaW50ZXJwcmV0ZWQuICBGdXJ0aGVyIHRvIHRoaXMgdGhvdWdodCwgaXQgYWxzbyBpc24ndCBj bGVhcg0KPiA+IHRvIG1lIHdoZXRoZXIgdGhlIHRlcm1zIGFyZSBtZWFudCB0byBiZSBpbnRlcnBy ZXRlZCB0aGUgc2FtZSB3YXkgYm90aA0KPiA+IGluIHRoZSBmaXJzdCBwYXJ0IG9mIHNlY3Rpb24g MyB0aGF0IGlzIGxpc3RpbmcgcmVxdWlyZW1lbnRzLCBhbmQgYWxzbw0KPiA+IHNlY3Rpb25zIDMu MSwgMy4yLCBhbmQgMy4zIHRoZSBkZWZpbmVzIHRoZSBkZXRhaWxzLg0KPiANCj4gVGhhdCBpcyBp bmRlZWQgYSB2YWxpZCBwb2ludC4gU2luY2UgdGhlcmUgYXJlIHBsYWNlcyB3aGVyZSB3ZSdyZSBx dW90aW5nDQo+IHJlcXVpcmVtZW50cyBmcm9tIHByb3RvY29sIHNwZWNzIChhbmQgaGVuY2UgdGhl IGtleXdvcmRzIHNob3VsZCBiZQ0KPiBpbnRlcnByZXRlZCBhcyBpbiBSRkMyMTE5KSwgd2hpbGUg b3VyIG93biByZXF1aXJlbWVudHMgc2hvdWxkIGJlDQo+IGludGVycHJldGVkIGFzIGRpc2N1c3Nl ZCBpbiBTZWN0aW9uIDIuIFNPIEkgZ3Vlc3MgdGhhdCBhdCB0aGUgdmVyeSBsZWFzdA0KPiB0aGlz IHNob3VsZCBiZSBjbGFyaWZpZWQuDQpbUlddIA0KDQpBbm90aGVyIGNob2ljZSB3b3VsZCBiZSB0 byBqdXN0IHVzZSAibXVzdCBub3QiLyJzaG91bGQiLyJtdXN0Ii8ic2hvdWxkIG5vdCIgZm9yIHRo ZSByZXF1aXJlbWVudHMgTC0xNSB0byBMLTE4IGluIHNlY3Rpb24gMywgYW5kIHRoZW4geW91IGNv dWxkIHVzZSB0aGUgc3RhbmRhcmQgUkZDIDIxMTkgYm9pbGVyIHBsYXRlIGZvciB0aGUgdXNhZ2Ug b2YgdGhlc2UgdGVybXMgaW4gdGhlIHJlc3Qgb2YgdGhlIGRvY3VtZW50Lg0KDQoNCg0KPiANCj4g DQo+IA0KPiA+IFNvLCBJIHJlYWxseSB0aGluayB0aGF0IHVzaW5nIHRoZSBzdGFuZGFyZCBib2ls ZXJwbGF0ZSBpcyB0aGUgYmVzdA0KPiA+IGFuc3dlciBoZXJlLCBvciBpZiB0aGUgdGVybXMgYXJl IGRlZmluZWQgd2l0aCBkaWZmZXJlbnQgbWVhbmluZ3MgdGhhdA0KPiA+IHRoZSB0ZXh0IG5lZWRz IHRvIGJlIG1vcmUgZXhwbGljaXQgYWJvdXQgaG93IGV4YWN0bHkgdGhlIHRlcm1zIGRpZmZlcg0K PiA+IG9yIGFyZSBleHBlY3RlZCB0byBiZSBpbnRlcnByZXRlZC4gIEkuZS4gcmF0aGVyIHRoYXQg c2F5aW5nIHRoYXQgdGhleQ0KPiA+IGFyZSBub3QgaW50ZXJwcmV0ZWQgdGhlIHNhbWUgYXMgMjEx OSwgc2F5IHRoYXQgdGhleSBhcmUgaW50ZXJwcmV0ZWQNCj4gPiB0aGUgc2FtZSBhcyAyMTE5LCBl eGNlcHQgZm9yIFggJiBZIC4uLiAgT3IgYWx0ZXJuYXRpdmVseSwgbGlzdCB0aGUNCj4gPiBwcmVj aXNlIG1lYW5pbmdzIHRoYXQgdGhlIHRlcm1zIHRha2UgaW4gdGhpcyBkb2N1bWVudCBpZiB0aGV5 IGRvbid0DQo+ID4gZm9sbG93IHRoZSBkZWZpbml0aW9ucyBpbiAyMTE5Lg0KPiANCj4gRmFpciBl bm91Z2guIFRoZSBsYXRlciB3b3VsZCBzZWVtIHRvIG1lIGxpa2UgdGhlIGVhc2llciB3YXkgZm9y d2FyZC4NCj4gDQo+IA0KPiANCj4gWy4uLi5dDQo+ID4+PiA3LiAgQWNrbm93bGVkZ21lbnRzDQo+ ID4+Pg0KPiBbLi4uLl0NCj4gPj4+DQo+ID4+PiBJcyB0aGUgdGhpcmQgcGFyYWdyYXBoIGRlZmlu aXRlbHkgbmVlZGVkIGluIHRoaXMgZG9jdW1lbnQ/DQo+ID4+PiBQZXJoYXBzIGlldGYtNm1hbi1z bGFhYy1yZW51bSB3aGljaCBpcyBiYXNlZCBvbg0KPiA+Pj4gZ29udC02bWFuLXNsYWFjLXJlbnVt IGNvdWxkDQo+ID4+IGNvbnRhaW4NCj4gPj4+IHRoaXMgYWNrbm93bGVkZ2VtZW50PyAgT3IgcGVy aGFwcyB5b3UgY291bGQgbWVyZ2UgdGhlIHR3bw0KPiA+Pj4gcGFyYWdyYXBocw0KPiA+PiBpbnRv IG9uZSwNCj4gPj4+IGlmIHRoaXMgaXMgYW4gZWFybGllciB2ZXJzaW9uIG9mIHRoaXMgZG9jdW1l bnQuICBUaGlzIHdvdWxkIGFsc28NCj4gPj4+IGFsbG93DQo+ID4+IHlvdSB0bw0KPiA+Pj4gcmVt b3ZlIG9uZSBvZiB0aGUgcmVmZXJlbmNlcyB0byBzaW1pbGFybHkgbmFtZWQgZG9jdW1lbnRzIGlu IHRoZQ0KPiA+PiByZWZlcmVuY2VzLg0KPiA+Pg0KPiBbLi4uLl0NCj4gPj4NCj4gPj4gVGhhdCdz IHdoeSB0aGUgQWNrcyBhcmUgc3BlbGxlZCBvdXQgbGlrZSB0aGF0Lg0KPiA+IFtSV10gT2theSwg SSBhZ3JlZSB0aGF0IGFja25vd2xlZGdpbmcgcGVvcGxlIGZvciB0aGUgd29yayBhbmQgZWZmb3J0 DQo+ID4gdGhhdCB0aGV5IGhhdmUgcHV0IGluIGlzIHJpZ2h0IGFuZCBpbXBvcnRhbnQuDQo+ID4N Cj4gPiBQZXJoYXBzIGNoYW5nZToNCj4gPg0KPiA+ICJwcm92aWRpbmcgdmFsdWFibGUgY29tbWVu dHMgb24gW0ktRC5nb250LTZtYW4tc2xhYWMtcmVudW1dLCBvbiB3aGljaA0KPiA+IHRoaXMgZG9j dW1lbnQgaXMgYmFzZWQuIg0KPiA+DQo+ID4gdG86DQo+ID4NCj4gPiAicHJvdmlkaW5nIHZhbHVh YmxlIGNvbW1lbnRzIG9uIGVhcmxpZXIgd29yayBmcm9tIHdoaWNoIHRoaXMgZG9jdW1lbnQNCj4g PiBpcyBkZXJpdmVkLiINCj4gPg0KPiA+IFRoYXQgY291bGQgdGhlbiBhbGxvdyB5b3UgdG8gZHJv cCB0aGUgcmVmZXJlbmNlIHRvDQo+ID4gZ29udC02bWFuLXNsYWFjLXJlbnVtPw0KPiANCj4gSSBk b24ndCBtaW5kIGRvaW5nIHRoYXQuIFdpbGwgZG8uDQo+IA0KPiANCj4gWy4uLi5dDQo+ID4+DQo+ ID4+IFJlZnMgIzIgYW5kICMzIGFyZSBuZWVkZWQsIHNpbmNlIHRob3NlIHR3byBhcmUgY29tcGxl bWVudGluZw0KPiA+PiBkb2N1bWVudHMgdG8gdGhlIHByZXNlbnQgb25lLg0KPiA+IFtSV10gQWdy ZWVkLg0KPiA+DQo+ID4+DQo+ID4+IFJlZmVyZW5jZSAjMSBpcyBpbmNsdWRlZCBiZWNhdXNlIHRo ZSBBY2tzIHJlZmVyZW5jZSBzdWNoDQo+ID4+IGluZGl2aWR1YWwgdmVyc2lvbiAoYXMgcGVyIGV4 cGxhaW5lZCBhYm92ZSkuDQo+ID4+DQo+ID4+IFRob3VnaHRzPw0KPiA+IFtSV10NCj4gPg0KPiA+ IFBsZWFzZSBzZWUgbXkgc3VnZ2VzdGlvbiBhYm92ZSBvbiB0aGUgYWNrcyBzZWN0aW9uLiAgSWYg eW91IHdlcmUgdG8NCj4gPiBtYWtlIHRoYXQgY2hhbmdlIHRoZW4gaXQgd291bGQgYWxsb3cgeW91 IHRvIGRyb3AgdGhpcyByZWZlcmVuY2UuICBJdA0KPiA+IGp1c3QgZmVlbHMgb2RkIGZvciBhIGRv Y3VtZW50IHRvIGhhdmUgYW4gaW5mb3JtYXRpdmUgcmVmZXJlbmNlIHRvDQo+ID4gd2hhdCBpcyBs b2dpY2FsbHkgYW4gcGFydGlhbCBlYXJsaWVyIHZlcnNpb24gb2YgdGhlIHNhbWUgd29yay4NCj4g DQo+IEZhaXIgZW5vdWdoLg0KPiANCj4gV2lsbCBhcHBseSB0aGUgY2hhbmdlLg0KDQpUaGFua3Mg Zm9yIGFjY29tbW9kYXRpbmcuDQoNClJlZ2FyZHMsDQpSb2INCg0KDQo+IA0KPiBUaGFua3MhDQo+ IA0KPiBDaGVlcnMsDQo+IC0tDQo+IEZlcm5hbmRvIEdvbnQNCj4gU0k2IE5ldHdvcmtzDQo+IGUt bWFpbDogZmdvbnRAc2k2bmV0d29ya3MuY29tDQo+IFBHUCBGaW5nZXJwcmludDogNjY2NiAzMUM2 IEQ0ODQgNjNCMiA4RkIxIEUzQzQgQUUyNSAwRDU1IDFENEUgNzQ5Mg0KPiANCj4gDQo+IA0KDQo= From nobody Wed Oct 21 07:45: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 125D13A10DE; Wed, 21 Oct 2020 07:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, 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 xUQxvuPigwt7; Wed, 21 Oct 2020 07:45:02 -0700 (PDT) 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 D90073A0CD4; Wed, 21 Oct 2020 07:44:59 -0700 (PDT) Received: from [IPv6:2800:810:464:b9c:69b8:4602:916c:a007] (unknown [IPv6:2800:810:464:b9c:69b8:4602:916c:a007]) (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 76CBA283D38; Wed, 21 Oct 2020 14:44:55 +0000 (UTC) To: "Rob Wilton (rwilton)" , The IESG , Warren Kumari Cc: "draft-ietf-v6ops-cpe-slaac-renum@ietf.org" , "v6ops-chairs@ietf.org" , "v6ops@ietf.org" , Owen DeLong References: <160313338012.7412.6288227175776828752@ietfa.amsl.com> <36e00b8f-1cde-5691-caea-1678fccba3b1@si6networks.com> <83a09d58-a8b3-667f-33ae-557973c5d256@si6networks.com> From: Fernando Gont Message-ID: Date: Wed, 21 Oct 2020 11:44:48 -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] Robert Wilton's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS and COMMENT) 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, 21 Oct 2020 14:45:05 -0000 Hi, Rob, On 21/10/20 11:22, Rob Wilton (rwilton) wrote: [....] >>>>> Hopefully this isn't hard to resolve, but I don't understand >>>>> the meaning >>>> of the >>>>> text in section 2: >>>>> >>>>> 2. Requirements Language >>>>> >>>>> 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. >> [....] >>>> >>>> These words are used in exactly the same way as RFC7084, the >>>> RFC this document is meant to update. >>> [RW] >>> >>> Yes, I appreciate that. But I don't think that this text makes >>> any more sense to me in RFC7084 either! >> >> I'll let our AD (Warren) weigh in, since this would probably be a >> decision that would need his advice... >> > [RW] > > Note, I'm not suggesting that we change the text in RFC 7084 (water > under the bridge), but I do think that the text in this document > should be clear. > > Probably this will get discussed in the telechat tomorrow. I see your point. I just meant that I'd like the input from our AD, such that I don't screw things up myself. :-) >>> Or, to put it another way, I don't really understand the >>> difference between how the terms are intended to be used here, >>> and how they are normally interpreted. Further to this thought, >>> it also isn't clear to me whether the terms are meant to be >>> interpreted the same way both in the first part of section 3 that >>> is listing requirements, and also sections 3.1, 3.2, and 3.3 the >>> defines the details. >> >> That is indeed a valid point. Since there are places where we're >> quoting requirements from protocol specs (and hence the keywords >> should be interpreted as in RFC2119), while our own requirements >> should be interpreted as discussed in Section 2. SO I guess that at >> the very least this should be clarified. > [RW] > > Another choice would be to just use "must > not"/"should"/"must"/"should not" for the requirements L-15 to L-18 > in section 3, and then you could use the standard RFC 2119 boiler > plate for the usage of these terms in the rest of the document. I'm all for making things more clear. I've sent a heads-up to Warren and see if he weighs in, so that we can all converge on what might be the best way forward. Does that sound reasonable? 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 Wed Oct 21 09:53:45 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 00E6B3A0843; Wed, 21 Oct 2020 09:53:40 -0700 (PDT) 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=virginmedia.co.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fl9dKpN68loB; Wed, 21 Oct 2020 09:53:37 -0700 (PDT) Received: from mailrelay04.virginmedia.co.uk (mailrelay04.telewest.co.uk [193.38.82.68]) (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 446DB3A083F; Wed, 21 Oct 2020 09:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=virginmedia.co.uk; i=@virginmedia.co.uk; q=dns/txt; s=mailrelays; t=1603299216; x=1634835216; h=from:to:subject:date:message-id:references:in-reply-to: mime-version:content-transfer-encoding; bh=geoqbGgr8Oxvd97Do0ebC38n9QOYEk2YWcX6TXEtK70=; b=e8F1+Quy/llefiee0q72pWI+BTaa82rRRtnNA8TtPISJEvQ+4DGeEADu d/QcxxZskMXl7BSElde4hHTt5klOALY+MJi/7XnEFQaFjP98hF0oWyIAI LO6Ep4iRCi6nPStxnreHK3JiBbR96QtDU1CQYjB4FNMeqBroQjZdKt81H I=; IronPort-SDR: P4tfva2Y2mkOeI5tEW95c8LWfdzxDqWK8Dfw3XL/x3lDlOz4FCjh3aF7L4gdc3F7o0Bq2Uimm0 O6PWlXd9wzLA== X-AddDisclaimer: Media X-SMTP-INT: T X-NonCorpAttach-CLI: false From: "Olopade, Olorunloba" To: Vasilenko Eduard , 6man , "v6ops@ietf.org" Thread-Topic: New Version Notification for draft-olopade-6man-slaac-signaling-00.txt Thread-Index: AQHWpke+JPdFg9XuL0GCVbkMZbBb/qmfRCqggADXTgCAAOWTUIAAoH1AgACkhkA= Date: Wed, 21 Oct 2020 16:53:32 +0000 Message-ID: References: <160313300387.7363.3016109002772518574@ietfa.amsl.com> <4c01bfac27744f4ba408fac1158fe7e3@UKKNOPEXCH008.systems.private> <02114d0323604e848d5107db00d976a1@huawei.com> <161b04264ec24ba9862dcb72392b466e@UKKNOPEXCH008.systems.private> <4faaca17276d4cf6a4306421935fb7f1@huawei.com> In-Reply-To: <4faaca17276d4cf6a4306421935fb7f1@huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="koi8-r" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [v6ops] New Version Notification for draft-olopade-6man-slaac-signaling-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: Wed, 21 Oct 2020 16:53:40 -0000 V291bGQgY29uZmVzcyB0aGF0IEkgaGFkbid0IGNvbnNpZGVyIERIQ1AuIEJ1dCB0aGUgbG9naWMg Y2FuIHN0aWxsIHdvcmsgaS5lLiBESENQIFNvbGljaXQgdG8gdmFsaWRhdGUgYWRkcmVzcyB0aGF0 IHdhcyBhc3NpZ25lZCB2aWEgREhDUHY2LgoKU28gc2NlbmFyaW8gb25lLCBob3N0IHdpdGggYWRk cmVzcyBhc3NpZ25lZCB2aWEgREhDUHY2IHN0YXJ0cyB0byByZWNlaXZlIFJBIHdpdGggUElPIGhh dmluZyBBIGZsYWcgc2V0LiBOZXcgU0xBQUMgYWRkcmVzcyBpcyBmb3JtZWQsIGFuZCBob3N0IHNo b3VsZCB2YWxpZGF0ZSBwcmV2aW91cyBhZGRyZXNzIGJ5IHNlbmRpbmcgREhDUCBzb2xpY2l0IG1l c3NhZ2UuIElmIHJlc3BvbnNlIGlzIHJlY2VpdmVkLCBhZGRyZXNzIGlzIHN0aWxsIHZhbGlkLiBP dGhlcndpc2UsIGFkZHJlc3Mgc2hvdWxkIG5vIGxvbmdlciBiZSBwcmVmZXJyZWQKClNjZW5hcmlv IDIsIGhvc3Qgd2l0aCBhZGRyZXNzIGFzc2lnbmVkIHZpYSBTTEFBQywgc3RhcnQgdG8gcmVjZWl2 ZSBSQXMgd2l0aCBBIGZsYWcgY2xlYXJlZC4gSG9zdCBzaG91bGQgc2VuZCBESENQIFNvbGljaXQg bWVzc2FnZSB0byBnZXQgbmV0IGFkZHJlc3MuIEFuZCB0aGVuIFJTIG1lc3NhZ2UgdG8gcm91dGVy cywgd2hvIGNhbiB0aGVuIGRlcHJlY2F0ZSB0aGUgcHJlZml4IGlmIHJlcXVpcmVkLiAgCgotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQpGcm9tOiBWYXNpbGVua28gRWR1YXJkIFttYWlsdG86dmFz aWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tXSAKU2VudDogMjEgT2N0b2JlciAyMDIwIDA4OjM5ClRv OiBPbG9wYWRlLCBPbG9ydW5sb2JhIDxMb2JhLk9sb3BhZGVAdmlyZ2lubWVkaWEuY28udWs+OyA2 bWFuIDxpcHY2QGlldGYub3JnPjsgdjZvcHNAaWV0Zi5vcmcKU3ViamVjdDogUkU6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtb2xvcGFkZS02bWFuLXNsYWFjLXNpZ25hbGluZy0w MC50eHQKCj4gYSBjb21tb24gZmFjdG9yIHdvdWxkIGJlIHRoZSBmb3JtaW5nIG9mIGEgbmV3IGFk ZHJlc3MuCltFZDogXSBOb3BlLiBQcmVmaXggY291bGQgYmUgZm9yIERIQ1AgKEEgZmxhZyBjbGVh cmVkKS4gTmV3IGFkZHJlc3Mgd291bGQgYmUgZ2l2ZW4gbm90IGluc2lkZSBORCBlbmdpbmUgKERI Q1AgZGVtb24gaXMgZGlmZmVyZW50IGluIFVuaXgpLgpCeSB0aGUgd2F5LCBvbiB0aGUgcHJvYmxl bSBzdGF0ZW1lbnQ6IHNpbWlsYXIgcHJvYmxlbSBjb3VsZCBoYXBwZW4gZm9yIERIQ1AgdG9vLiBU aW1lcnMgd291bGQgYmUgYmV0dGVyIChob3VycyBhZ2FpbnN0IGRheXMpLCBidXQgaXQgaXMgbm90 IGFjY2VwdGFibGUgZm9yIHVzZXIgYW55d2F5IChmYXIgZnJvbSA1MG1zIHN0YW5kYXJkcyBvZiB0 aGUgcHJldmlvdXMgYWdlKS4gREhDUCBjb3JuZXIgY2FzZSBpcyBqdXN0IGhhdmUgbm90IGJlZW4g Zm91bmQgaW4gbGl2ZSwgbm90IHlldC4gSW4gcmVhbGl0eSB3ZSBoYXZlIGhlcmUgZ2VuZXJhbCBw cmVmaXggcm9idXN0bmVzcyBwcm9ibGVtIG9mIE5EIC0gaXQgaXMgbm90IHJlbGF0ZWQgb25seSB0 byBTTEFBQy4KTXkgIkNvbXBsZXRlIiBmbGFnIHdvdWxkIHJlc29sdmUgdGhpcyBwcm9ibGVtIHRv byAtIGVub3VnaCBpbmZvcm1hdGlvbiB0byBkZXByZWNhdGUgREhDUCBhZnRlciAxc3QgUkEuCkhv dyBob3N0IHNob3VsZCBkbyBESENQIGFkZHJlc3MgZGVwcmVjYXRpb24gaW4geW91ciBzb2x1dGlv bj8gRmVlZGJhY2sgZnJvbSBESENQIGRlbW9uIHRvIE5EPwoKPiAgU28sIEkgYmVsaWV2ZSBhbGwg dGhlIHVzZSBjYXNlcyBzaG91bGQgYmUgY292ZXJlZC4KW0VkOiBdIE5vcGUuIFlvdSBzZWUgYWJv dmUuCgo+IEkgYWdyZWUgdGhhdCB0aGlzIGFyZSBsb25nIHRlcm0gc29sdXRpb25zLiBGb3IgdGhl IHNob3J0IHRlcm0sIEkgdGhpbmsgd2UgYXJlIHN0dWNrIHdpdGgganVzdCBsb3dlcmluZyB0aGUg dGltZXJzLgpbRWQ6IF0gTm9wZS4gSSB3b3VsZCBzaG93LgoKPiBXZSBhbHNvIG5lZWQgdG8gY29u c2lkZXIgaG93IHRvIGRvIGdhcmJhZ2UgY29sbGVjdGlvbiBmb3IgUklPIGFuZCAKPiBSRE5TUwpb RWQ6IF0gUklPIGlzIGJldHRlciB0byBkZXByZWNhdGUgZm9yICJ0ZWxjbyBicm9hZGJhbmQgc2Vy dmljZXMiIGJlY2F1c2Ugb2YgbXVsdGktcHJlZml4IChtYW55IFBBIHByZWZpeGVzKSBlbnZpcm9u bWVudC4gSSB3b3VsZCBzaG93IHdoeSAtIE1ITVAgaXMgYSBsaXR0bGUgY29tcGxleCBzdG9yeS4K UklPIG1ha2Ugc2Vuc2Ugb25seSBmb3IgRW50ZXJwcmlzZSBlbnZpcm9ubWVudCAod2l0aCBzaW5n bGUgYWRkcmVzcyBzcGFjZSwgcHJvYmFibHkgUEkpIC0gSSBoYXZlIHB1dCB0aGlzIHN0YXRlbWVu dCBpbiB0aGUgZHJhZnQuCgpFZC8KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+IEZyb206 IE9sb3BhZGUsIE9sb3J1bmxvYmEgW21haWx0bzpMb2JhLk9sb3BhZGVAdmlyZ2lubWVkaWEuY28u dWtdCj4gU2VudDogMjEgz8vU0cLS0SAyMDIwIMcuIDI6MTQKPiBUbzogVmFzaWxlbmtvIEVkdWFy ZCA8dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tPjsgNm1hbiAKPiA8aXB2NkBpZXRmLm9yZz47 IHY2b3BzQGlldGYub3JnCj4gU3ViamVjdDogUkU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgCj4gZHJhZnQtb2xvcGFkZS02bWFuLXNsYWFjLXNpZ25hbGluZy0KPiAwMC50eHQKPiAKPiBI ZWxsbyBFZHVhcmQsCj4gCj4gWWVzLCBJIGRvIG1lYW4gTXVsdGljYXN0IFJTLgo+IAo+IFllcywg d2UgZG8gbmVlZCBzeW5jaHJvbmlzYXRpb24uIEkgYmVsaWV2ZSBzb21lIGZvcm0gb2YgImZlZWRi YWNrIiBpcyAKPiBuZWVkZWQgdG8gYWNoaWV2ZSBhICJzdGFibGUgc3lzdGVtIi4gVGhpcyBpcyB0 aGUgcHJlbWlzZSBJJ20gd29ya2luZyAKPiBvbi4gV2l0aCBTTEFBQyBhcyBpdCBjdXJyZW50bHkg aXMsIHdlIGRvbid0IGhhdmUgYSBtZWFucyBvZiBmZWVkaW5nIAo+IGJhY2sgaW5mb3JtYXRpb24g ZnJvbSBob3N0cyB0byByb3V0ZXJzLiBUaGF0IGFyZWEgaXMgd2hhdCBJJ20gdHJ5aW5nIAo+IHRv IGFkZHJlc3MgaW4gdGhpcyBkcmFmdC4gQnkgaW5jbHVkaW5nIGluZm9ybWF0aW9uIGluIFJTIG1l c3NhZ2VzLCByb3V0ZXJzIGNhbiBsZWFybiBhYm91dCB0aGUgc3RhdGUgb2YgdGhlIGhvc3QuCj4g Cj4gVGhpcyBpcyBhbiBpbml0aWFsIGRyYWZ0LiBTbyBJIHdhc24ndCBhdHRlbXB0aW5nIHRvIGRv Y3VtZW50IHRoZSAKPiBjb21wbGV0ZSBzb2x1dGlvbiBhdCB0aGlzIHRpbWUuIEJ1dCB3YW50ZWQg dG8gc2VlIGlmIG90aGVycyB3b3VsZCBzZWUgCj4gdGhlIGJlbmVmaXQgb2YgbW92aW5nIGluIHRo aXMgZGlyZWN0aW9uLiBJbiBteSBvcGluaW9uLCBJIHdpbGwgbGlrZSB0byAKPiBzZWUgMiBjaGFu Z2VzIHRvIGluY3JlYXNlIFNMQUFDIHJvYnVzdG5lc3MuIFRoaXMgYW5kIGEgbWVhbnMgZm9yIHRo ZSAKPiByb3V0ZXIgdG8gaW5kaWNhdGUgdGhhdCBpdCBpcyBzZW5kaW5nICJjb21wbGV0ZSIgIGlu Zm9ybWF0aW9uIChsaWtlIHlvdSBhcmUgaW5kaWNhdGluZyB3aXRoIHRoZSBmbGFnKS4KPiAKPiBC dXQgaWYgd2UgYXJlIHRvIGxvb2sgaW50byB0aGUgdmFyaW91cyB1c2UgY2FzZXMsIGEgY29tbW9u IGZhY3RvciAKPiB3b3VsZCBiZSB0aGUgZm9ybWluZyBvZiBhIG5ldyBhZGRyZXNzLiBIZW5jZSwg bXkgcHJvcG9zYWwgbGV2ZXJhZ2VzIG9uIAo+IHRoaXMsIGJ5IHNlbmRpbmcgdGhlIFJTLCBhcyB0 aGUgYWRkcmVzcyB0cmFuc2l0aW9ucyBmcm9tIHRlbnRhdGl2ZSB0byAKPiBwcmVmZXJyZWQuIFNv LCBJIGJlbGlldmUgYWxsIHRoZSB1c2UgY2FzZXMgc2hvdWxkIGJlIGNvdmVyZWQuCj4gCj4gQWx0 aG91Z2gsIEknbSBoYXZpbmcgYSBjaGFuZ2Ugb2YgaGVhcnQgb24gaG93IHRvIGFjaGlldmUgdGhp cy4gSSBub3cgCj4gdGhpbmsgdGhhdCB1c2luZyBvcHRpb25zIGluIFJTIGlzIGJldHRlciB0aGFu IHJlbHlpbmcgb24gdGhlIHNvdXJjZSAKPiBhZGRyZXNzLiBUaGUga2V5IGRpZmZlcmVuY2UgaXMg dGhhdCB0aGUgY3VycmVudCBwcm9wb3NhbCBpcyBsaW1pdGVkIHRvIAo+IFBJTyBpbmZvcm1hdGlv bi4gV2UgYWxzbyBuZWVkIHRvIGNvbnNpZGVyIGhvdyB0byBkbyBnYXJiYWdlIGNvbGxlY3Rpb24g Cj4gZm9yIFJJTyBhbmQgUkROU1MKW0VkOiBdIFJJTyBpcyBiZXR0ZXIgdG8gZGVwcmVjYXRlLiBJ IHdvdWxkIHNob3cgd2h5Lgo+IAo+IEkgYWdyZWUgdGhhdCB0aGlzIGFyZSBsb25nIHRlcm0gc29s dXRpb25zLiBGb3IgdGhlIHNob3J0IHRlcm0sIEkgdGhpbmsgCj4gd2UgYXJlIHN0dWNrIHdpdGgg anVzdCBsb3dlcmluZyB0aGUgdGltZXJzLgo+IAo+IAo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tCj4gRnJvbTogdjZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgVmFzaWxlbmtvIAo+IEVkdWFyZAo+IFNlbnQ6IDIwIE9jdG9iZXIgMjAyMCAwOTowNAo+ IFRvOiBPbG9wYWRlLCBPbG9ydW5sb2JhCj4gPExvYmEuT2xvcGFkZT00MHZpcmdpbm1lZGlhLmNv LnVrQGRtYXJjLmlldGYub3JnPjsgNm1hbiAKPiA8aXB2NkBpZXRmLm9yZz47IHY2b3BzQGlldGYu b3JnCj4gU3ViamVjdDogUmU6IFt2Nm9wc10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciAK PiBkcmFmdC1vbG9wYWRlLTZtYW4tc2xhYWMtIHNpZ25hbGluZy0wMC50eHQKPiAKPiBIaSBMb2Jh LAo+IEkgd2FzIHRoZSBsb3VkZXN0IHNob3V0aW5nIHRoYXQgInR3ZWFraW5nIHRpbWVycyIgaXMg YSB2ZXJ5IGJhZCBzb2x1dGlvbi4KPiBIZW5jZSwgaXQgd2FzIGxvZ2ljYWwgY29uc2VxdWVuY2Vz IHRoYXQgT2xlIGRpZCBwdXNoIG1lIHRvIGRldmVsb3AgbXkgZHJhZnQuCj4gSSBhbSB2ZXJ5IGNs b3NlIHRvIHB1Ymxpc2ggaXQuIEkgYW0gaW4gdGhlIGNvbnRleHQgb2YgdGhpcyBkaXNjdXNzaW9u LiAKPiBJIGhhdmUgc3BlbnQgY291cGxlIG9mIHdlZWtzIGV4Y2x1c2l2ZWx5IG9uIHRoaXMgcHJv YmxlbS4KPiAKPiBZb3UgcHJvYmFibHkgbWVhbjogIm11bHRpY2FzdCBSUyAiIG9yICJtdWx0aWNh c3QgTlMgdG8gYWxsIHJvdXRlcnMiLgo+IEl0IGlzIG5vdCBwb3NzaWJsZSB0byBmaW5kICJtdWx0 aWNhc3QiIGluIHlvdXIgZHJhZnQuCj4gCj4gWW91ciBwcm9wb3NhbCBieSBpdHNlbGYgaXMgbm90 IGJhZC4gU3luY2hyb25pemF0aW9uIGlzIG5lZWRlZCwgaW5kZWVkLgo+IEkgaGF2ZSBwcm9wb3Nl ZCBoZXJlIChhbmQgaXQgd291bGQgYmUgZGlzY3Vzc2VkIGluIG15IGRyYWZ0KSAxIAo+IGFkZGl0 aW9uYWwgZmxhZyBpbiBSQSBtZXNzYWdlIHRoYXQgaW5mb3JtYXRpb24gaXMgImNvbXBsZXRlIi4K PiBJTUhPOiBJdCBpcyBhIGxpdHRsZSBiZXR0ZXIgd2F5IGZvciBzeW5jaHJvbml6YXRpb24sIGJl Y2F1c2UgaXQgZG9lcyAKPiBub3QgbmVlZCBhZGRpdGlvbmFsIG1lc3NhZ2VzIHRvIHN5bmNocm9u aXplIHN0YXRlcy4KPiAKPiBCdXQgc3VjaCB0eXBlIG9mIHNvbHV0aW9ucyBhcmUgY29uc2lkZXJl ZCBieSBtZSBhcyAibG9uZy10ZXJtIi4gSXQgCj4gbmVlZHMgaG9zdCBzdXBwb3J0LiBJdCBjb3Vs ZCBub3QgaGFwcGVuIHZlcnkgc29vbi4KPiBTb21ldGhpbmcgZm9yIHNob3J0LXRlcm0gaXMgbmVl ZGVkIHRvby4KPiAKPiBBZGRpdGlvbmFsbHksIHlvdSBoYXZlIG5vdCBkaXNjdXNzZWQgc29sdXRp b25zIGZvciBhbGwgdXNlIGNhc2VzIAo+IHByZXNlbnRlZCBieSBGZXJuYW5kbyBpbiBkcmFmdC1p ZXRmLXY2b3BzLXNsYWFjLXJlbnVtLgo+IEZvciBleGFtcGxlOiBhYnJ1cHQgcHJlZml4IGNoYW5n ZSBvbiB0aGUgcm91dGVyICh3aXRob3V0IGRlcHJlY2F0aW9uKSAKPiBPciBhYnJ1cHQgVkxBTiBj aGFuZ2Ugb24gTDIgKDgwMi4xWCkgT3IgcHJlZml4IGlzIGp1c3QgZGlzY29ubmVjdGVkIAo+IGZy b20gQ2FycmllciwgYmVjYXVzZSB1cGxpbmsgaXMgZG93biAocmVwbGFjZW1lbnQgaXMgbm90IHBy b3Bvc2VkIHlldCkgCj4gT3Igc2l0dWF0aW9uIGluIG11bHRpLWhvbWluZyB3aGVuIG1hbnkgUEEg cHJlZml4ZXMgZnJvbSBkaWZmZXJlbnQgCj4gQ2FycmllcnMgYXJlIGFubm91bmNlZCBhbmQgc29t ZSBjb3VsZCBiZSBkaXNjb25uZWN0ZWQgZnJvbSBjYXJyaWVyLgo+IEJ1dCBtYXliZSBpdCB3YXMg bm90IHlvdXIgZ29hbCB0byBkZXZlbG9wIGNvbXByZWhlbnNpdmUgc29sdXRpb24gZm9yIAo+ICJO RCBwcmVmaXggcm9idXN0bmVzcyIgKHRoZSBsYXN0IHRlcm0gaXMgdGhlIG5hbWUgb2YgbXkgZHJh ZnQpCj4gCj4gRWR1YXJkCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+ID4gRnJvbTog djZvcHMgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgT2xvcGFk ZSwgCj4gPiBPbG9ydW5sb2JhCj4gPiBTZW50OiAxOSDPy9TRwtLRIDIwMjAgxy4gMjE6NTQKPiA+ IFRvOiA2bWFuIDxpcHY2QGlldGYub3JnPjsgdjZvcHNAaWV0Zi5vcmcKPiA+IFN1YmplY3Q6IFJl OiBbdjZvcHNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IKPiA+IGRyYWZ0LW9sb3BhZGUt Nm1hbi1zbGFhYy0gc2lnbmFsaW5nLTAwLnR4dAo+ID4KPiA+IEhlbGxvIGFsbCwKPiA+Cj4gPiBJ J20gcHJvcG9zaW5nIGFuIGFsdGVybmF0ZSB3YXkgdG8gYWRkcmVzcyB0aGUgU0xBQUMgZmxhc2gg Cj4gPiByZW51bWJlcmluZyBpc3N1ZSwgYW5kIEkndmUgYmVlbiBhZHZpc2VkIHRvIHB1dCB0aGlz IGluIGEgZHJhZnQuIAo+ID4gVGhpcyBpcyB0aGUgaW5pdGlhbCBkcmFmdCwgYW5kIGRlZmluaXRl bHkgbmVlZCBtb3JlIHdvcmssIGJ1dCB3aWxsIAo+ID4gbGlrZSB0byBrbm93IGlmIHBlb3BsZSB0 aGluayB0aGlzIGFwcHJvYWNoIGlzIHdvcnRoIGNvbnNpZGVyaW5nLgo+ID4KPiA+IFJlZ2FyZHMu Cj4gPgo+ID4gTG9iYSBPbG9wYWRlCj4gPgo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0K PiA+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10KPiA+IFNlbnQ6IDE5IE9jdG9iZXIgMjAyMCAxOTo0Mwo+ID4gVG86IE9sb3Bh ZGUsIE9sb3J1bmxvYmEgPExvYmEuT2xvcGFkZUB2aXJnaW5tZWRpYS5jby51az4KPiA+IFN1Ympl Y3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgCj4gPiBkcmFmdC1vbG9wYWRlLTZtYW4t c2xhYWMtc2lnbmFsaW5nLTAwLnR4dAo+ID4KPiA+Cj4gPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwg ZHJhZnQtb2xvcGFkZS02bWFuLXNsYWFjLXNpZ25hbGluZy0wMC50eHQKPiA+IGhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTG9iYSBPbG9wYWRlIGFuZCBwb3N0ZWQgdG8gdGhlIAo+ ID4gSUVURiByZXBvc2l0b3J5Lgo+ID4KPiA+IE5hbWU6CQlkcmFmdC1vbG9wYWRlLTZtYW4tc2xh YWMtc2lnbmFsaW5nCj4gPiBSZXZpc2lvbjoJMDAKPiA+IFRpdGxlOgkJRXhwbGljaXQgc2lnbmFs aW5nIG9mIFN0YXRlbGVzcyBBZGRyZXNzIEF1dG9jb25maWd1cmF0aW9uIChTTEFBQykKPiA+IHRv IFJlbnVtYmVyaW5nIEV2ZW50cwo+ID4gRG9jdW1lbnQgZGF0ZToJMjAyMC0xMC0xOQo+ID4gR3Jv dXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24KPiA+IFBhZ2VzOgkJNwo+ID4gVVJMOiAgICAgICAg ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtb2xvcGFkZS02bWFuLXNs YWFjLQo+ID4gc2lnbmFsaW5nLTAwLnR4dAo+ID4gU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW9sb3BhZGUtNm1hbi1zbGFhYy0KPiA+IHNpZ25h bGluZy8KPiA+IEh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9odG1sL2RyYWZ0LW9sb3BhZGUtNm1hbi0KPiBzbGFhYy0KPiA+IHNpZ25hbGluZwo+ID4gSHRt bGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1vbG9wYWRlLTZt YW4tc2xhYWMtc2lnbmFsaW5nLQo+IDAwCj4gPgo+ID4KPiA+IEFic3RyYWN0Ogo+ID4gICAgQWZ0 ZXIgYSByZW51bWJlcmluZyBldmVudCBpbiBhbiBJUHY2IG5ldHdvcmsgdXRpbGl6aW5nIFNMQUFD LCBob3N0cwo+ID4gICAgbWlnaHQgY29udGludWUgdG8gdXNlIHN0YWxlIGFkZHJlc3NlcywgYXMg dGhleSBhcmUgdW5hd2FyZSBvZiB0aGUKPiA+ICAgIGNoYW5nZXMuIExpa2V3aXNlLCByb3V0ZXJz LCB3aG8gbWF5IGRlcHJlY2F0ZSB0aGUgdXNlIG9mIHRoZXNlCj4gPiAgICBwcmVmaXhlcywgYXJl IHVuYXdhcmUgb2YgdGhlaXIgdXNlIG9uIHRoZSBob3N0cy4gVGhpcyBzY2VuYXJpbyBjb3VsZAo+ ID4gICAgaGF2ZSBhbiBhZHZlcnNlIGVmZmVjdCBvbiBjb21tdW5pY2F0aW9uIHdpdGggdGhlIGhv c3QuIFRoaXMgZG9jdW1lbnQKPiA+ICAgIHByb3Bvc2VzIGNoYW5nZXMgdG8gdGhlIFNMQUFDIGFs Z29yaXRobSB0aGF0IHdpbGwgZXhwbGljaXRseSBhbGxvdwo+ID4gICAgcm91dGVycyB0byBsZWFy biBvZiB0aGVzZSBzdGFsZSBwcmVmaXhlcyB0aGF0IGFyZSBzdGlsbCBhc3NpZ25lZCBvbgo+ID4g ICAgdGhlIG5ldHdvcmsuCj4gPgo+ID4KPiA+Cj4gPgo+ID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBt YXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YgCj4gPiBzdWJtaXNz aW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQg dG9vbHMuaWV0Zi5vcmcuCj4gPgo+ID4gVGhlIElFVEYgU2VjcmV0YXJpYXQKPiA+Cj4gPgo+ID4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0KPiA+IFNhdmUgUGFwZXIgLSBEbyB5b3UgcmVhbGx5IG5lZWQgdG8gcHJpbnQg dGhpcyBlLW1haWw/Cj4gPgo+ID4gVmlzaXQgd3d3LnZpcmdpbm1lZGlhLmNvbSBmb3IgbW9yZSBp bmZvcm1hdGlvbiwgYW5kIG1vcmUgZnVuLgo+ID4KPiA+IFRoaXMgZW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBhcmUgb3IgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgCj4gPiBsZWdhbGx5IHByaXZp bGVnZWQgYW5kIGFyZSBzZW50IHNvbGVseSBmb3IgdGhlIGF0dGVudGlvbiBvZiB0aGUgYWRkcmVz c2VlKHMpLgo+ID4KPiA+IFZpcmdpbiBNZWRpYSB3aWxsIG5ldmVyIGFzayBmb3IgYWNjb3VudCBv ciBmaW5hbmNpYWwgaW5mb3JtYXRpb24gdmlhIAo+ID4gZW1haWwuIElmIHlvdSBhcmUgaW4gcmVj ZWlwdCBvZiBhIHN1c3BpY2lvdXMgZW1haWwsIHBsZWFzZSByZXBvcnQgdG8gCj4gPiB3d3cudmly Z2lubWVkaWEuY29tL25ldHJlcG9ydAo+ID4KPiA+IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyCj4gPiBzeXN0ZW06IGl0 cyB1c2UsIGRpc2Nsb3N1cmUgb3IgY29weWluZyBpcyB1bmF1dGhvcmlzZWQuIFN0YXRlbWVudHMg Cj4gPiBhbmQgb3BpbmlvbnMgZXhwcmVzc2VkIGluIHRoaXMgZW1haWwgbWF5IG5vdCByZXByZXNl bnQgdGhvc2Ugb2YgCj4gPiBWaXJnaW4gTWVkaWEuIEFueSByZXByZXNlbnRhdGlvbnMgb3IgY29t bWl0bWVudHMgaW4gdGhpcyBlbWFpbCBhcmUgCj4gPiBzdWJqZWN0IHRvCj4gY29udHJhY3QuCj4g Pgo+ID4gUmVnaXN0ZXJlZCBvZmZpY2U6IDUwMCBCcm9vayBEcml2ZSwgUmVhZGluZywgUkcyIDZV VQo+ID4KPiA+IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBhbmQgV2FsZXMgd2l0aCBudW1iZXIgMjU5 MTIzNyAKPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Cj4gPiB2Nm9wcyBtYWlsaW5nIGxpc3QKPiA+IHY2b3BzQGlldGYub3JnCj4gPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzCj4gCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiB2Nm9wcyBtYWlsaW5nIGxpc3QKPiB2Nm9w c0BpZXRmLm9yZwo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMK PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQo+IFNhdmUgUGFwZXIgLSBEbyB5b3UgcmVhbGx5IG5lZWQgdG8gcHJpbnQg dGhpcyBlLW1haWw/Cj4gCj4gVmlzaXQgd3d3LnZpcmdpbm1lZGlhLmNvbSBmb3IgbW9yZSBpbmZv cm1hdGlvbiwgYW5kIG1vcmUgZnVuLgo+IAo+IFRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50 cyBhcmUgb3IgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVnYWxseSAKPiBwcml2aWxlZ2VkIGFu ZCBhcmUgc2VudCBzb2xlbHkgZm9yIHRoZSBhdHRlbnRpb24gb2YgdGhlIGFkZHJlc3NlZShzKS4K PiAKPiBWaXJnaW4gTWVkaWEgd2lsbCBuZXZlciBhc2sgZm9yIGFjY291bnQgb3IgZmluYW5jaWFs IGluZm9ybWF0aW9uIHZpYSAKPiBlbWFpbC4gSWYgeW91IGFyZSBpbiByZWNlaXB0IG9mIGEgc3Vz cGljaW91cyBlbWFpbCwgcGxlYXNlIHJlcG9ydCB0byAKPiB3d3cudmlyZ2lubWVkaWEuY29tL25l dHJlcG9ydAo+IAo+IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBs ZWFzZSBkZWxldGUgaXQgZnJvbSB5b3VyIAo+IHN5c3RlbTogaXRzIHVzZSwgZGlzY2xvc3VyZSBv ciBjb3B5aW5nIGlzIHVuYXV0aG9yaXNlZC4gU3RhdGVtZW50cyBhbmQgCj4gb3BpbmlvbnMgZXhw cmVzc2VkIGluIHRoaXMgZW1haWwgbWF5IG5vdCByZXByZXNlbnQgdGhvc2Ugb2YgVmlyZ2luIAo+ IE1lZGlhLiBBbnkgcmVwcmVzZW50YXRpb25zIG9yIGNvbW1pdG1lbnRzIGluIHRoaXMgZW1haWwg YXJlIHN1YmplY3QgdG8gY29udHJhY3QuCj4gCj4gUmVnaXN0ZXJlZCBvZmZpY2U6IDUwMCBCcm9v ayBEcml2ZSwgUmVhZGluZywgUkcyIDZVVQo+IAo+IFJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBhbmQg V2FsZXMgd2l0aCBudW1iZXIgMjU5MTIzNwotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KU2F2ZSBQYXBlciAtIERvIHlv dSByZWFsbHkgbmVlZCB0byBwcmludCB0aGlzIGUtbWFpbD8NCg0KVmlzaXQgd3d3LnZpcmdpbm1l ZGlhLmNvbSBmb3IgbW9yZSBpbmZvcm1hdGlvbiwgYW5kIG1vcmUgZnVuLg0KDQpUaGlzIGVtYWls IGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIG9yIG1heSBiZSBjb25maWRlbnRpYWwgYW5kIGxlZ2Fs bHkgcHJpdmlsZWdlZA0KYW5kIGFyZSBzZW50IHNvbGVseSBmb3IgdGhlIGF0dGVudGlvbiBvZiB0 aGUgYWRkcmVzc2VlKHMpLg0KDQpWaXJnaW4gTWVkaWEgd2lsbCBuZXZlciBhc2sgZm9yIGFjY291 bnQgb3IgZmluYW5jaWFsIGluZm9ybWF0aW9uIHZpYSBlbWFpbC4gSWYgeW91IGFyZSBpbiByZWNl aXB0IG9mIGEgc3VzcGljaW91cyBlbWFpbCwgcGxlYXNlIHJlcG9ydCB0byB3d3cudmlyZ2lubWVk aWEuY29tL25ldHJlcG9ydA0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy cm9yLCBwbGVhc2UgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW06IGl0cyB1c2UsIGRpc2Nsb3N1 cmUgb3IgY29weWluZyBpcyB1bmF1dGhvcmlzZWQuIFN0YXRlbWVudHMgYW5kIG9waW5pb25zIGV4 cHJlc3NlZCBpbiB0aGlzIGVtYWlsIG1heSBub3QgcmVwcmVzZW50IHRob3NlIG9mIFZpcmdpbiBN ZWRpYS4gQW55IHJlcHJlc2VudGF0aW9ucyBvciBjb21taXRtZW50cyBpbiB0aGlzIGVtYWlsIGFy ZSBzdWJqZWN0IHRvIGNvbnRyYWN0Lg0KDQpSZWdpc3RlcmVkIG9mZmljZTogNTAwIEJyb29rIERy aXZlLCBSZWFkaW5nLCBSRzIgNlVVDQoNClJlZ2lzdGVyZWQgaW4gRW5nbGFuZCBhbmQgV2FsZXMg d2l0aCBudW1iZXIgMjU5MTIzNwo= From nobody Wed Oct 21 10:53: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 5F8FB3A13EB; Wed, 21 Oct 2020 10:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 baqhxcfBSB9K; Wed, 21 Oct 2020 10:52:56 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 72B533A13E4; Wed, 21 Oct 2020 10:52:56 -0700 (PDT) Received: from lhreml717-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id A7C863A6EDF6740A1FD9; Wed, 21 Oct 2020 18:52:53 +0100 (IST) Received: from msceml702-chm.china.huawei.com (10.219.141.160) by lhreml717-chm.china.huawei.com (10.201.108.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 21 Oct 2020 18:52:53 +0100 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml702-chm.china.huawei.com (10.219.141.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 21 Oct 2020 20:52:52 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Wed, 21 Oct 2020 20:52:52 +0300 From: Vasilenko Eduard To: "Olopade, Olorunloba" , 6man , "v6ops@ietf.org" Thread-Topic: New Version Notification for draft-olopade-6man-slaac-signaling-00.txt Thread-Index: AQHWpke+JPdFg9XuL0GCVbkMZbBb/qmfRCqggADXTgCAAOWTUIAAoH1AgACkhkCAAA7DkA== Date: Wed, 21 Oct 2020 17:52:52 +0000 Message-ID: References: <160313300387.7363.3016109002772518574@ietfa.amsl.com> <4c01bfac27744f4ba408fac1158fe7e3@UKKNOPEXCH008.systems.private> <02114d0323604e848d5107db00d976a1@huawei.com> <161b04264ec24ba9862dcb72392b466e@UKKNOPEXCH008.systems.private> <4faaca17276d4cf6a4306421935fb7f1@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.197.73] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] New Version Notification for draft-olopade-6man-slaac-signaling-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: Wed, 21 Oct 2020 17:52:59 -0000 I was not talking about extremely rear case when DHCP is replaced by SLAAC = or vice versa. I was talking about more probable case: CPE has given prefix and DHCP lease= to LAN host, then reloaded (in invisible way for host, probably bridge in = between), then announce different prefix for DHCP. How host should understand that old DHCP lease should be deprecated? It may be that host would not start DHCP demon again. DHCP demon is not aut= omatic - something should push it. If this something would not push - host would not receive new address, that= would not activate your solution.=20 You are dependent on: (1) ND (additional NS check) and (2) DHCP demon (to r= eceive new address)), and additionally (3) on something else (some monitori= ng) that should recognize availability of new DHCP prefix to activate DHCP. Coordination between DHCP, ND and monitoring is additional complexity in yo= ur solution. I propose flag "complete" that operates only on ND. DHCP demon or any monit= oring is not needed to deprecate old address. It would be less difficult for monitoring to understand that all addresses = are deprecated - DHCP needed again. Ed/ > -----Original Message----- > From: Olopade, Olorunloba [mailto:Loba.Olopade@virginmedia.co.uk] > Sent: 21 =CF=CB=D4=D1=C2=D2=D1 2020 =C7. 19:54 > To: Vasilenko Eduard ; 6man ; > v6ops@ietf.org > Subject: RE: New Version Notification for draft-olopade-6man-slaac-signal= ing- > 00.txt >=20 > Would confess that I hadn't consider DHCP. But the logic can still work i= .e. DHCP > Solicit to validate address that was assigned via DHCPv6. >=20 > So scenario one, host with address assigned via DHCPv6 starts to receive = RA > with PIO having A flag set. New SLAAC address is formed, and host should > validate previous address by sending DHCP solicit message. If response is > received, address is still valid. Otherwise, address should no longer be = preferred >=20 > Scenario 2, host with address assigned via SLAAC, start to receive RAs wi= th A flag > cleared. Host should send DHCP Solicit message to get net address. And th= en RS > message to routers, who can then deprecate the prefix if required. >=20 > -----Original Message----- > From: Vasilenko Eduard [mailto:vasilenko.eduard@huawei.com] > Sent: 21 October 2020 08:39 > To: Olopade, Olorunloba ; 6man > ; v6ops@ietf.org > Subject: RE: New Version Notification for draft-olopade-6man-slaac-signal= ing- > 00.txt >=20 > > a common factor would be the forming of a new address. > [Ed: ] Nope. Prefix could be for DHCP (A flag cleared). New address would= be > given not inside ND engine (DHCP demon is different in Unix). > By the way, on the problem statement: similar problem could happen for DH= CP > too. Timers would be better (hours against days), but it is not acceptabl= e for > user anyway (far from 50ms standards of the previous age). DHCP corner ca= se is > just have not been found in live, not yet. In reality we have here genera= l prefix > robustness problem of ND - it is not related only to SLAAC. > My "Complete" flag would resolve this problem too - enough information to > deprecate DHCP after 1st RA. > How host should do DHCP address deprecation in your solution? Feedback fr= om > DHCP demon to ND? >=20 > > So, I believe all the use cases should be covered. > [Ed: ] Nope. You see above. >=20 > > I agree that this are long term solutions. For the short term, I think = we are > stuck with just lowering the timers. > [Ed: ] Nope. I would show. >=20 > > We also need to consider how to do garbage collection for RIO and > > RDNSS > [Ed: ] RIO is better to deprecate for "telco broadband services" because = of > multi-prefix (many PA prefixes) environment. I would show why - MHMP is a > little complex story. > RIO make sense only for Enterprise environment (with single address space= , > probably PI) - I have put this statement in the draft. >=20 > Ed/ > > -----Original Message----- > > From: Olopade, Olorunloba [mailto:Loba.Olopade@virginmedia.co.uk] > > Sent: 21 =CF=CB=D4=D1=C2=D2=D1 2020 =C7. 2:14 > > To: Vasilenko Eduard ; 6man > > ; v6ops@ietf.org > > Subject: RE: New Version Notification for > > draft-olopade-6man-slaac-signaling- > > 00.txt > > > > Hello Eduard, > > > > Yes, I do mean Multicast RS. > > > > Yes, we do need synchronisation. I believe some form of "feedback" is > > needed to achieve a "stable system". This is the premise I'm working > > on. With SLAAC as it currently is, we don't have a means of feeding > > back information from hosts to routers. That area is what I'm trying > > to address in this draft. By including information in RS messages, rout= ers can > learn about the state of the host. > > > > This is an initial draft. So I wasn't attempting to document the > > complete solution at this time. But wanted to see if others would see > > the benefit of moving in this direction. In my opinion, I will like to > > see 2 changes to increase SLAAC robustness. This and a means for the > > router to indicate that it is sending "complete" information (like you= are > indicating with the flag). > > > > But if we are to look into the various use cases, a common factor > > would be the forming of a new address. Hence, my proposal leverages on > > this, by sending the RS, as the address transitions from tentative to > > preferred. So, I believe all the use cases should be covered. > > > > Although, I'm having a change of heart on how to achieve this. I now > > think that using options in RS is better than relying on the source > > address. The key difference is that the current proposal is limited to > > PIO information. We also need to consider how to do garbage collection > > for RIO and RDNSS > [Ed: ] RIO is better to deprecate. I would show why. > > > > I agree that this are long term solutions. For the short term, I think > > we are stuck with just lowering the timers. > > > > > > -----Original Message----- > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Vasilenko > > Eduard > > Sent: 20 October 2020 09:04 > > To: Olopade, Olorunloba > > ; 6man > > ; v6ops@ietf.org > > Subject: Re: [v6ops] New Version Notification for > > draft-olopade-6man-slaac- signaling-00.txt > > > > Hi Loba, > > I was the loudest shouting that "tweaking timers" is a very bad solutio= n. > > Hence, it was logical consequences that Ole did push me to develop my d= raft. > > I am very close to publish it. I am in the context of this discussion. > > I have spent couple of weeks exclusively on this problem. > > > > You probably mean: "multicast RS " or "multicast NS to all routers". > > It is not possible to find "multicast" in your draft. > > > > Your proposal by itself is not bad. Synchronization is needed, indeed. > > I have proposed here (and it would be discussed in my draft) 1 > > additional flag in RA message that information is "complete". > > IMHO: It is a little better way for synchronization, because it does > > not need additional messages to synchronize states. > > > > But such type of solutions are considered by me as "long-term". It > > needs host support. It could not happen very soon. > > Something for short-term is needed too. > > > > Additionally, you have not discussed solutions for all use cases > > presented by Fernando in draft-ietf-v6ops-slaac-renum. > > For example: abrupt prefix change on the router (without deprecation) > > Or abrupt VLAN change on L2 (802.1X) Or prefix is just disconnected > > from Carrier, because uplink is down (replacement is not proposed yet) > > Or situation in multi-homing when many PA prefixes from different > > Carriers are announced and some could be disconnected from carrier. > > But maybe it was not your goal to develop comprehensive solution for > > "ND prefix robustness" (the last term is the name of my draft) > > > > Eduard > > > -----Original Message----- > > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Olopade, > > > Olorunloba > > > Sent: 19 =CF=CB=D4=D1=C2=D2=D1 2020 =C7. 21:54 > > > To: 6man ; v6ops@ietf.org > > > Subject: Re: [v6ops] New Version Notification for > > > draft-olopade-6man-slaac- signaling-00.txt > > > > > > Hello all, > > > > > > I'm proposing an alternate way to address the SLAAC flash > > > renumbering issue, and I've been advised to put this in a draft. > > > This is the initial draft, and definitely need more work, but will > > > like to know if people think this approach is worth considering. > > > > > > Regards. > > > > > > Loba Olopade > > > > > > -----Original Message----- > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > Sent: 19 October 2020 19:43 > > > To: Olopade, Olorunloba > > > Subject: New Version Notification for > > > draft-olopade-6man-slaac-signaling-00.txt > > > > > > > > > A new version of I-D, draft-olopade-6man-slaac-signaling-00.txt > > > has been successfully submitted by Loba Olopade and posted to the > > > IETF repository. > > > > > > Name: draft-olopade-6man-slaac-signaling > > > Revision: 00 > > > Title: Explicit signaling of Stateless Address Autoconfiguration > (SLAAC) > > > to Renumbering Events > > > Document date: 2020-10-19 > > > Group: Individual Submission > > > Pages: 7 > > > URL: https://www.ietf.org/archive/id/draft-olopade-6man-sl= aac- > > > signaling-00.txt > > > Status: https://datatracker.ietf.org/doc/draft-olopade-6man-s= laac- > > > signaling/ > > > Htmlized: https://datatracker.ietf.org/doc/html/draft-olopade-6= man- > > slaac- > > > signaling > > > Htmlized: https://tools.ietf.org/html/draft-olopade-6man-slaac- > signaling- > > 00 > > > > > > > > > Abstract: > > > After a renumbering event in an IPv6 network utilizing SLAAC, host= s > > > might continue to use stale addresses, as they are unaware of the > > > changes. Likewise, routers, who may deprecate the use of these > > > prefixes, are unaware of their use on the hosts. This scenario cou= ld > > > have an adverse effect on communication with the host. This docume= nt > > > proposes changes to the SLAAC algorithm that will explicitly allow > > > routers to learn of these stale prefixes that are still assigned o= n > > > the network. > > > > > > > > > > > > > > > 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 > > > > > > > > > -------------------------------------------------------------------- > > > Save Paper - Do you really need to print this e-mail? > > > > > > Visit www.virginmedia.com for more information, and more fun. > > > > > > This email and any attachments are or may be confidential and > > > legally privileged and are sent solely for the attention of the addre= ssee(s). > > > > > > Virgin Media will never ask for account or financial information via > > > email. If you are in receipt of a suspicious email, please report to > > > www.virginmedia.com/netreport > > > > > > If you have received this email in error, please delete it from your > > > system: its use, disclosure or copying is unauthorised. Statements > > > and opinions expressed in this email may not represent those of > > > Virgin Media. Any representations or commitments in this email are > > > subject to > > contract. > > > > > > Registered office: 500 Brook Drive, Reading, RG2 6UU > > > > > > Registered in England and Wales with number 2591237 > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > -------------------------------------------------------------------- > > Save Paper - Do you really need to print this e-mail? > > > > Visit www.virginmedia.com for more information, and more fun. > > > > This email and any attachments are or may be confidential and legally > > privileged and are sent solely for the attention of the addressee(s). > > > > Virgin Media will never ask for account or financial information via > > email. If you are in receipt of a suspicious email, please report to > > www.virginmedia.com/netreport > > > > If you have received this email in error, please delete it from your > > system: its use, disclosure or copying is unauthorised. Statements and > > opinions expressed in this email may not represent those of Virgin > > Media. Any representations or commitments in this email are subject to > contract. > > > > Registered office: 500 Brook Drive, Reading, RG2 6UU > > > > Registered in England and Wales with number 2591237 > -------------------------------------------------------------------- > Save Paper - Do you really need to print this e-mail? >=20 > Visit www.virginmedia.com for more information, and more fun. >=20 > This email and any attachments are or may be confidential and legally pri= vileged > and are sent solely for the attention of the addressee(s). >=20 > Virgin Media will never ask for account or financial information via emai= l. If you > are in receipt of a suspicious email, please report to > www.virginmedia.com/netreport >=20 > If you have received this email in error, please delete it from your syst= em: its > use, disclosure or copying is unauthorised. Statements and opinions expre= ssed in > this email may not represent those of Virgin Media. Any representations o= r > commitments in this email are subject to contract. >=20 > Registered office: 500 Brook Drive, Reading, RG2 6UU >=20 > Registered in England and Wales with number 2591237 From nobody Wed Oct 21 12:33:47 2020 Return-Path: X-Original-To: expand-draft-ietf-v6ops-slaac-renum.all@virtual.ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 87ED73A1458; Wed, 21 Oct 2020 12:33:42 -0700 (PDT) X-Original-To: xfilter-draft-ietf-v6ops-slaac-renum.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-v6ops-slaac-renum.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8E33A133D for ; Wed, 21 Oct 2020 12:33:42 -0700 (PDT) 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, 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=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 sG87M3r2jho1 for ; Wed, 21 Oct 2020 12:33:40 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 6AF633A12AF for ; Wed, 21 Oct 2020 12:33:40 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id d24so4567726lfa.8 for ; Wed, 21 Oct 2020 12:33:40 -0700 (PDT) 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; bh=1zk/L7clvohVO9DZeaCL+EdTQHFs0LdyGk2lTut2f9w=; b=Xn5elHARWSFwq3B31yfHakgH6h8op0UV6Wi5RkenGqOKDGINToDzXepTsq/RCXfVJ8 eMktGp1qYb+sia5jsRGc7ZF27y7Oqx/yrIkvHSnpaitFWnXJMyY1TIYyYvhnFcRbqnDk wfIxWlPTee3mFCeP4c03sxZrEQSjdWdwK7fndGeYCENxDk0rdZjfSJhO5U/i7Xf7vSod hiXa6BQkdSHA7cCQu2gwpvhxSHryOYsuBCw9TAhcsKPitpMra9QATY9EMXS0Zt/KuSf6 7H1KnFda5aluJjylmSw5xJi3qwQGgpD8xHFaGRUrm+Fl/RlFjCaJCE9Mtd1h80M/tU33 nM0A== 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; bh=1zk/L7clvohVO9DZeaCL+EdTQHFs0LdyGk2lTut2f9w=; b=XYrOr59c2p4+D3qA/XWyc9ZYKM6MxeKwObihYM6LN/VOa04sziG711s/F7DU1vLBm4 fJxMQB/Av+s4FtAWn3gFR6kDmK3OQmDuheiZ4XzUtnWlDfuJbQwFAG8C+N5CJ66h+kgU cAVvWb9Z5uIx1ag+uvrPzwTsw705SGaeSkRZNyl5Lr0GbZBZch8sCSxDg9McXfOCnmgU EmzaZ03uZd9NBrWHhPYYvFq6SKAYajAztM4awpeUZUPkwPjBCP0eXINxZc5rYCGPArYI MIfIqwh/IVQ1zTdpu/b3+ZD3pII3hNJyOSvvhDEkZWF4csxZgvGqi9iDI/6eA0BkRr5N 3MdQ== X-Gm-Message-State: AOAM531kLs+ChDdEhHPgL8jpKNLMVQ5We+wLeLPcqSzkpR2oNv/hEXdA p8nZ8gcN2DXjBJG4Irtc6crHoCKKsQeJ9rCqRcyohg== X-Google-Smtp-Source: ABdhPJyRAktPV7i0imXJGQozpwkbXVbdfl8OIxAwYLbCQniTQ62xixpJ2olAhEkH/bxf9f5Jj1VHhF9GUh/9XbLPtl4= X-Received: by 2002:a19:87c5:: with SMTP id j188mr1937016lfd.386.1603308817093; Wed, 21 Oct 2020 12:33:37 -0700 (PDT) MIME-Version: 1.0 References: <159968910157.15345.3077847299653382902@ietfa.amsl.com> <03acb49d-9c05-521a-9bf8-40da16c5f7a7@si6networks.com> <20200910101320.izuzgihtdkaxyov3@anna.jacobs.jacobs-university.de> <5bf5b0c9-0e12-0034-d3b4-1b9e895c93f1@si6networks.com> <20200910111004.yy7bimcq4fxheud3@anna.jacobs.jacobs-university.de> In-Reply-To: <20200910111004.yy7bimcq4fxheud3@anna.jacobs.jacobs-university.de> From: Warren Kumari Date: Wed, 21 Oct 2020 15:33:00 -0400 Message-ID: To: Juergen Schoenwaelder , ops-dir , draft-ietf-v6ops-slaac-renum.all@ietf.org Content-Type: multipart/alternative; boundary="00000000000082326d05b2336cca" Resent-From: Resent-To: fgont@si6networks.com, jan@connect.com, richard.patterson@sky.uk, rbonica@juniper.net, fredbaker.ietf@gmail.com, rwilton@cisco.com, warren@kumari.net, Owen DeLong , v6ops@ietf.org, owen@delong.com Resent-Message-Id: <20201021193342.87ED73A1458@ietfa.amsl.com> Resent-Date: Wed, 21 Oct 2020 12:33:42 -0700 (PDT) Archived-At: Subject: Re: [v6ops] [OPS-DIR] Opsdir last call review of draft-ietf-v6ops-slaac-renum-03 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, 21 Oct 2020 19:33:43 -0000 --00000000000082326d05b2336cca Content-Type: text/plain; charset="UTF-8" [ - many groups, for clutter ] While balloting I realized that I'd forgotten to thank Juergen this OpsDir review. Thank you, Juergen (and authors) for the back and forth, and addressing the comments - it's improved the quality of the document... W On Thu, Sep 10, 2020 at 7:10 AM Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Sep 10, 2020 at 07:33:09AM -0300, Fernando Gont wrote: > > [...] > > > > I would probably simply remove text that talks about the general use > > > of timers. It is not needed to understand the problem, I think it > > > actually confuses the problem. For me, the prefix is soft-state that a > > > box learned (like it learns a lot of other soft-state) and so you > > > either go for 'reasonably short' lifetimes or you design mechanisms to > > > detect and handle stale information gracefully. > > > > Fair enough. So, removing beginning of the section up to, and including > the > > sentence that says "For obvious reasons, the whole ...", then? > > Yes. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > -- 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 --00000000000082326d05b2336cca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[ - many groups, for clutter ]

While balloting I realized = that I'd forgotten to thank Juergen this OpsDir review.=C2=A0

Than= k you, Juergen (and authors) for the back and forth, and addressing the com= ments - it's improved the quality of the document...

W
=
On Thu= , Sep 10, 2020 at 7:10 AM Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de&g= t; wrote:
On Thu= , Sep 10, 2020 at 07:33:09AM -0300, Fernando Gont wrote:

[...]

> > I would probably simply remove text that talks about the general = use
> > of timers. It is not needed to understand the problem, I think it=
> > actually confuses the problem. For me, the prefix is soft-state t= hat a
> > box learned (like it learns a lot of other soft-state) and so you=
> > either go for 'reasonably short' lifetimes or you design = mechanisms to
> > detect and handle stale information gracefully.
>
> Fair enough. So, removing beginning of the section up to, and includin= g the
> sentence that says "For obvious reasons, the whole ...", the= n?

Yes.

/js

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>


--
I don't think the execution is relevant when= it was obviously a bad idea in the first place.
This is like putting ra= bid weasels in your pants, and later expressing regret at having chosen tho= se particular rabid weasels and that pair of pants.
=C2=A0 =C2=A0---maf<= /div> --00000000000082326d05b2336cca-- From nobody Wed Oct 21 13:34:47 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 716EE3A03F8; Wed, 21 Oct 2020 13:34:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Suresh Krishnan via Datatracker To: Cc: draft-ietf-v6ops-cpe-slaac-renum.all@ietf.org, last-call@ietf.org, v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160331248040.20197.17042000687787703033@ietfa.amsl.com> Reply-To: Suresh Krishnan Date: Wed, 21 Oct 2020 13:34:40 -0700 Archived-At: Subject: [v6ops] Iotdir telechat review of draft-ietf-v6ops-cpe-slaac-renum-05 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, 21 Oct 2020 20:34:41 -0000 Reviewer: Suresh Krishnan Review result: Ready with Issues Minor ------- * Section 3.1 Second Paragraph Looks like there is a minor error in the DHCPv6 option handling. Suggest fixing this OLD: This means that the advertised "Preferred Lifetime" and "Valid Lifetime" MUST be dynamically adjusted NEW: This means that the advertised "preferred-lifetime" and "valid-lifetime" MUST be dynamically adjusted * Section 3.3 Are there any recommendations for the T1 and T2 times for the DHCPv6 IA options? Or is the expectation that they will be set to 0.5 and 0.8 of the shortest preferred-lifetime inside the IAs? From nobody Wed Oct 21 13:49:43 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 AEFB13A07F5; Wed, 21 Oct 2020 13:49:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Erik Kline via Datatracker To: "The IESG" Cc: draft-ietf-v6ops-slaac-renum@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, Owen DeLong , v6ops@ietf.org, owen@delong.com X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <160331338169.29285.8506664356153222594@ietfa.amsl.com> Date: Wed, 21 Oct 2020 13:49:41 -0700 Archived-At: Subject: [v6ops] Erik Kline's No Objection on draft-ietf-v6ops-slaac-renum-04: (with COMMENT) 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, 21 Oct 2020 20:49:42 -0000 Erik Kline has entered the following ballot position for draft-ietf-v6ops-slaac-renum-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-slaac-renum/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [[ comments ]] [ section 2.1 ] * There should be some clarification that use of dynamic prefixes does not automatically imply flash renumbering, but rather that it increases the likelihood of a flash renumbering event occurring (basically make it clear that flash renumbering is the issue, not dynamically changing prefixes). * There's also more than one layer of PD stability to be considered: the stability of the block delegated from the ISP to the modem/ISP-provided CPE (discussed here), and (for example) the stability of the prefix that's subdelegated to another router in the home (in cases where the user has purchased an additional router to place between nodes in the home and the ISP CPE). In this way, even with stable ISP->CPE prefix delegation, it might be possible for the home router to get a different subprefix on reboot. [ section 2.2 ] * This section should make it clear that magnitude of the impact is a function of these timers and that these defaults are not necessarily in common use. The text strongly implies that all flash renumbering events impact hosts for 7 days, and I don't think that's true. (I don't think I've been on any dynamic prefix network that used these defaults for a long time.) [ section 2.3 ] * I support Ben's observation about authenticated RAs. [[ nits ]] [ abstract ] * "will continue using stale prefixes" -> "may continue using stale prefixes" or "could" or "might" or "are likely to" I think "will" is only correct under very certain circumstances. Same text change in the first paragraph of the introduction as well. [ section 1 ] * "and and" -> "and" * "configure for": perhaps "configured from" the previously-advertised prefix From nobody Wed Oct 21 16:41:04 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 A88DF3A0BAA; Wed, 21 Oct 2020 16:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, 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 iACGtnl0Yrhh; Wed, 21 Oct 2020 16:40:53 -0700 (PDT) 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 97C2E3A0B58; Wed, 21 Oct 2020 16:40:41 -0700 (PDT) Received: from [IPv6:2800:810:464:b9c:452e:36a3:27fd:8f9b] (unknown [IPv6:2800:810:464:b9c:452e:36a3:27fd:8f9b]) (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 724FD283AFC; Wed, 21 Oct 2020 23:40:36 +0000 (UTC) To: Erik Kline , The IESG Cc: draft-ietf-v6ops-slaac-renum@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, Owen DeLong References: <160331338169.29285.8506664356153222594@ietfa.amsl.com> From: Fernando Gont Message-ID: Date: Wed, 21 Oct 2020 19:45: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: <160331338169.29285.8506664356153222594@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Erik Kline's No Objection on draft-ietf-v6ops-slaac-renum-04: (with COMMENT) 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, 21 Oct 2020 23:40:56 -0000 Hi, Erik, Thanks so much for your comments! In-line.... On 21/10/20 17:49, Erik Kline via Datatracker wrote: [....] > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > [[ comments ]] > > [ section 2.1 ] > > * There should be some clarification that use of dynamic prefixes does > not automatically imply flash renumbering, but rather that it increases > the likelihood of a flash renumbering event occurring (basically make it > clear that flash renumbering is the issue, not dynamically changing > prefixes). > * There's also more than one layer of PD stability to be considered: the > stability of the block delegated from the ISP to the modem/ISP-provided > CPE (discussed here), and (for example) the stability of the prefix that's > subdelegated to another router in the home (in cases where the user has > purchased an additional router to place between nodes in the home and the > ISP CPE). In this way, even with stable ISP->CPE prefix delegation, it > might be possible for the home router to get a different subprefix on > reboot. How about adding this to the front of Section 2.1: "In network scenarios where dynamic prefixes are employed, changes in the employed prefixes are propagated through the network, such that the renumbering event is handled in gracefully handled. However, if the renumbering event happens along with e.g. loss of configuration state by some of the devices involved in the renumbering procedure (e.g., a router crashes, reboots, and gets leased a new prefix), this may result in a flash-renumbering event, where new prefixes are introduced without properly phasing out the old ones". ? Then tweak: " In simple residential or small office scenarios, the problem discussed in this document would be avoided if DHCPv6-PD would lease "stable" prefixes." (I've added "simple"). And then added a bullet in between the first and second that says: "While an ISP might lease a stable prefixes to the home or small office, the Customer Edge router might in turn leases sub-prefixes of this prefixes to other internal network devices. Unless this late lease database is stored on non-volatile storage, these internal systems might be leased dynamic sub-prefixes from the otherwise stable prefix leased by the ISP. In other words, every time a prefix is leased there is the potential that the resulting prefixes are dynamic, even if the devices has been leased a stable prefix by its upstream router." ? > [ section 2.2 ] > > * This section should make it clear that magnitude of the impact is a > function of these timers and that these defaults are not necessarily in > common use. The text strongly implies that all flash renumbering events > impact hosts for 7 days, and I don't think that's true. (I don't think > I've been on any dynamic prefix network that used these defaults for a > long time.) How about tweaking this section as: ---- cut here ---- The impact of the issue discussed in this document is a function of the lifetime values employed for the PIO lifetimes, since these values determine for how long the corresponding addresses will be preferred and considered valid. Thus, when the problem discussed in this document is experienced, the longer the PIO lifetimes, the higher the impact. [RFC4861] specifies the following default PIO lifetime values: o Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days) o Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days) Under problematic circumstances, such as where the corresponding network information has become stale without any explicit signal from the network (as described in Section 1), it would take a host 7 days (one week) to deprecate the corresponding addresses, and 30 days (one month) to eventually invalidate and remove any addresses configured for the stale prefix. This means that it will typically take hosts an unacceptably long period of time (on the order of several days) to recover from these scenarios. ---- cut here ---- Please do let me know if there's more to add/change. Note: I have dynamic prefixes at home, and my Mikrotik router employs the RFC4861-specified default values. :-( > [ section 2.3 ] > > * I support Ben's observation about authenticated RAs. I'll s/RAs/unauthenticated RAs/. That say, are there any real deployments where RAs are authenticated? > > > [[ nits ]] > > [ abstract ] > > * "will continue using stale prefixes" -> "may continue using stale prefixes" > or "could" or "might" or "are likely to" > > I think "will" is only correct under very certain circumstances. > > Same text change in the first paragraph of the introduction as well. > Will do. > [ section 1 ] > > * "and and" -> "and" > > * "configure for": perhaps "configured from" the previously-advertised prefix Will do. 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 Wed Oct 21 17:59: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 726723A0EC0; Wed, 21 Oct 2020 17:59:46 -0700 (PDT) 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=cooperw.in header.b=s18pp0Jo; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mv7En4Ff Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjZnliy-cM_I; Wed, 21 Oct 2020 17:59:45 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 218683A0B73; Wed, 21 Oct 2020 17:59:45 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id DA1FE132E; Wed, 21 Oct 2020 20:59:42 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 21 Oct 2020 20:59:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=w pxRLhW6ftUi1BDSKu54+HXIITTqdRCSlyAcpdZRPvk=; b=s18pp0JowBKEHKhdr bHJFQtcUTtQNeZmB9X06h1QeCwYPunzgzqQlIw3SfC8jw02F8+g1IgMzexSNohnV mlDxXC5R1azWRpj3VWL85CYOXM/WBhx5CTBqSGUhLn7mGUJGE7ifYoOVe5iGdAsg VzE/96pCENRIEdpsp5Ju4v8ziWP94WseHYGPZk1ObjR8zKMIU1yEZrf4i2KkAZdr dfMQKcFfqVnSXzA8ffhWORO7oSiiP++7kHasCcf8lAmkTbIjAEv2vYyMJ2qwXMGK FpSHOIfVCCrbTh9F4dOmhm00w+KJee3tRwovQI6Oq2Fd9j/mfsAUZhlAB8n+K1/H k+QnA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=wpxRLhW6ftUi1BDSKu54+HXIITTqdRCSlyAcpdZRP vk=; b=mv7En4FfiI6kgsDhISGBJigoJqzOIr1CPaews2+BTUGpEU5OuNcNfUhAi 3dhSZn19cxwReqkdjISAFbZadnCSaYwcE/5jN8yqod0zYMt5CtRN5alH9E4kwTh7 r+FOU8VdpZrvcpPjOin2xAH3fZImh0q3aQMAR5lRXV3Lg+OOUbEpOAOTUpFHu9pN 3VZFm6sYGvqxFc/Ah8R5HaDc4Dza/iFOwazOw04U/FpCSgawEnxZ70S8nJ2tpfjm 2uffwlw+z/BBIEXPl7PPGcskDJqvuynsk7tKhoT46BvZD8e81UYL+WiIO+ydBT9W Ht8fiIrxtn2KTSouPJDHw/zkCp8TQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrjeeigdefkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuggftrfgrth htvghrnhepgfeutdektefhkeelheehteehvdekkeettddvvdejgffhieekffeggeevfeeu gedtnecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrd eiheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegr lhhishhsrgestghoohhpvghrfidrihhn X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.65]) by mail.messagingengine.com (Postfix) with ESMTPA id AD64D3280064; Wed, 21 Oct 2020 20:59:41 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Alissa Cooper In-Reply-To: <922CA45E-598A-464E-B5FE-00535E00F6A6@delong.com> Date: Wed, 21 Oct 2020 20:59:40 -0400 Cc: Last Call , IETF Gen-ART , draft-ietf-v6ops-slaac-renum.all@ietf.org, v6ops list , Owen DeLong Content-Transfer-Encoding: quoted-printable Message-Id: <6735628F-92B4-4AD1-BD62-A66837C8EAF8@cooperw.in> References: <87a6y6clid.fsf@hobgoblin.ariadne.com> <922CA45E-598A-464E-B5FE-00535E00F6A6@delong.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [v6ops] [Gen-art] Genart last call review of draft-ietf-v6ops-slaac-renum-03 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, 22 Oct 2020 00:59:47 -0000 Dale, thanks for your review. All, thanks for your responses. I entered = a No Objection ballot. Alissa > On Sep 30, 2020, at 11:23 PM, Owen DeLong wrote: >=20 >>> In this case, timely is most about user perception. If the now = dysfunctional >>> address remains in use long enough for the user to become annoyed = (or arguably >>> even notice), then recovery is not timely. Since the definition of = timely in >>> this case is actually subjective, I=E2=80=99m not sure that such = clarification is >>> practical or useful. >>=20 >> I agree. But if timliness has no really solid definition, why does = the >> text firmly assert that certain particular values, without = qualificaton, >> are not timely? >=20 > One can be quite certain that a user will not wait for 3 days for a = web page to load without being certain whether the user will wait 30 = seconds, 1 minute, 3 minutes, or even 1 hour. >=20 > It=E2=80=99s very easy to call 3 days untimely in such a case. It is = very hard to draw a clear line among the lower values. >=20 > Owen >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Oct 21 17:59:58 2020 Return-Path: X-Original-To: expand-draft-ietf-v6ops-slaac-renum.all@virtual.ietf.org Delivered-To: v6ops@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id D0CD63A0EC4; Wed, 21 Oct 2020 17:59:46 -0700 (PDT) X-Original-To: xfilter-draft-ietf-v6ops-slaac-renum.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-v6ops-slaac-renum.all@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726723A0EC0; Wed, 21 Oct 2020 17:59:46 -0700 (PDT) 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=cooperw.in header.b=s18pp0Jo; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mv7En4Ff Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjZnliy-cM_I; Wed, 21 Oct 2020 17:59:45 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 218683A0B73; Wed, 21 Oct 2020 17:59:45 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id DA1FE132E; Wed, 21 Oct 2020 20:59:42 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 21 Oct 2020 20:59:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=w pxRLhW6ftUi1BDSKu54+HXIITTqdRCSlyAcpdZRPvk=; b=s18pp0JowBKEHKhdr bHJFQtcUTtQNeZmB9X06h1QeCwYPunzgzqQlIw3SfC8jw02F8+g1IgMzexSNohnV mlDxXC5R1azWRpj3VWL85CYOXM/WBhx5CTBqSGUhLn7mGUJGE7ifYoOVe5iGdAsg VzE/96pCENRIEdpsp5Ju4v8ziWP94WseHYGPZk1ObjR8zKMIU1yEZrf4i2KkAZdr dfMQKcFfqVnSXzA8ffhWORO7oSiiP++7kHasCcf8lAmkTbIjAEv2vYyMJ2qwXMGK FpSHOIfVCCrbTh9F4dOmhm00w+KJee3tRwovQI6Oq2Fd9j/mfsAUZhlAB8n+K1/H k+QnA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=wpxRLhW6ftUi1BDSKu54+HXIITTqdRCSlyAcpdZRP vk=; b=mv7En4FfiI6kgsDhISGBJigoJqzOIr1CPaews2+BTUGpEU5OuNcNfUhAi 3dhSZn19cxwReqkdjISAFbZadnCSaYwcE/5jN8yqod0zYMt5CtRN5alH9E4kwTh7 r+FOU8VdpZrvcpPjOin2xAH3fZImh0q3aQMAR5lRXV3Lg+OOUbEpOAOTUpFHu9pN 3VZFm6sYGvqxFc/Ah8R5HaDc4Dza/iFOwazOw04U/FpCSgawEnxZ70S8nJ2tpfjm 2uffwlw+z/BBIEXPl7PPGcskDJqvuynsk7tKhoT46BvZD8e81UYL+WiIO+ydBT9W Ht8fiIrxtn2KTSouPJDHw/zkCp8TQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrjeeigdefkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuggftrfgrth htvghrnhepgfeutdektefhkeelheehteehvdekkeettddvvdejgffhieekffeggeevfeeu gedtnecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepudejfedrfeekrdduudejrd eiheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegr lhhishhsrgestghoohhpvghrfidrihhn X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.65]) by mail.messagingengine.com (Postfix) with ESMTPA id AD64D3280064; Wed, 21 Oct 2020 20:59:41 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Alissa Cooper In-Reply-To: <922CA45E-598A-464E-B5FE-00535E00F6A6@delong.com> Date: Wed, 21 Oct 2020 20:59:40 -0400 Cc: Last Call , IETF Gen-ART , draft-ietf-v6ops-slaac-renum.all@ietf.org, v6ops list , Owen DeLong Content-Transfer-Encoding: quoted-printable Message-Id: <6735628F-92B4-4AD1-BD62-A66837C8EAF8@cooperw.in> References: <87a6y6clid.fsf@hobgoblin.ariadne.com> <922CA45E-598A-464E-B5FE-00535E00F6A6@delong.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.3608.120.23.2.4) Resent-From: Resent-To: fgont@si6networks.com, jan@connect.com, richard.patterson@sky.uk, rbonica@juniper.net, fredbaker.ietf@gmail.com, warren@kumari.net, rwilton@cisco.com, Owen DeLong , v6ops@ietf.org, owen@delong.com Resent-Message-Id: <20201022005946.D0CD63A0EC4@ietfa.amsl.com> Resent-Date: Wed, 21 Oct 2020 17:59:46 -0700 (PDT) Archived-At: Subject: Re: [v6ops] [Gen-art] Genart last call review of draft-ietf-v6ops-slaac-renum-03 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, 22 Oct 2020 00:59:47 -0000 Dale, thanks for your review. All, thanks for your responses. I entered = a No Objection ballot. Alissa > On Sep 30, 2020, at 11:23 PM, Owen DeLong wrote: >=20 >>> In this case, timely is most about user perception. If the now = dysfunctional >>> address remains in use long enough for the user to become annoyed = (or arguably >>> even notice), then recovery is not timely. Since the definition of = timely in >>> this case is actually subjective, I=E2=80=99m not sure that such = clarification is >>> practical or useful. >>=20 >> I agree. But if timliness has no really solid definition, why does = the >> text firmly assert that certain particular values, without = qualificaton, >> are not timely? >=20 > One can be quite certain that a user will not wait for 3 days for a = web page to load without being certain whether the user will wait 30 = seconds, 1 minute, 3 minutes, or even 1 hour. >=20 > It=E2=80=99s very easy to call 3 days untimely in such a case. It is = very hard to draw a clear line among the lower values. >=20 > Owen >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Wed Oct 21 19:37:59 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 B8C783A09DF; Wed, 21 Oct 2020 19:37:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Barry Leiba via Datatracker To: "The IESG" Cc: draft-ietf-v6ops-cpe-slaac-renum@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, Owen DeLong , v6ops-chairs@ietf.org, owen@delong.com X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Barry Leiba Message-ID: <160333427125.13008.17525178699509411272@ietfa.amsl.com> Date: Wed, 21 Oct 2020 19:37:51 -0700 Archived-At: Subject: [v6ops] Barry Leiba's No Objection on draft-ietf-v6ops-cpe-slaac-renum-05: (with COMMENT) 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, 22 Oct 2020 02:37:52 -0000 Barry Leiba has entered the following ballot position for draft-ietf-v6ops-cpe-slaac-renum-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Rob's DISCUSS and agree that it would be better just to use the terms in lower case, rather than making them appear as special key words but disclaim the definition. I'll note that RFC 7084 predates RFC 8174, and that the latter clarifies that using the terms in lower case has exactly the meaning that the disclaimer in Section 2 is trying (unsuccessfully) to make. I also agree with Ben's comment that keeping the grammatical error "preferable" is unnecessary. But if we end up getting rid of the whole thing, that becomes moot anyway. From nobody Wed Oct 21 22:37:44 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 661F73A0A8E; Wed, 21 Oct 2020 22:37:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Erik Kline via Datatracker To: "The IESG" Cc: draft-ietf-v6ops-cpe-slaac-renum@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, Owen DeLong , v6ops-chairs@ietf.org, owen@delong.com X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Erik Kline Message-ID: <160334506239.20395.15102292380884503313@ietfa.amsl.com> Date: Wed, 21 Oct 2020 22:37:42 -0700 Archived-At: Subject: [v6ops] Erik Kline's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS and COMMENT) 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, 22 Oct 2020 05:37:42 -0000 Erik Kline has entered the following ballot position for draft-ietf-v6ops-cpe-slaac-renum-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- [ section 3.2 ] * I absolutely agree in principle at these other lifetimes should be updated to the shorter of the two applicable lifetimes, but I'm worried that this text is not sufficiently precise. Specifically, this recommendation only applies to options that depend in any way on the change in the delegated prefix, yes? Perhaps just this qualifier is sufficient? For example, none of these comparative lifetime recommendations apply to a stable ULA for a router that meets requirements ULA-[1..5] and chooses to advertise a ULA /48 RIO and maybe even a ULA DNS server, I think. That being said, should this document also be saying that the ULA-derived options SHOULD prefer the ND_{P,V}_LIMIT lifetime values, in case a reboot causes a new ULA to be generated (i.e. the one supposedly in stable storage is lost or otherwise unrecoverable)? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [[ comments ]] [ section 3.1 ] * With respect to the second bullet: the lifetimes need to be dynamically *updateable*, not necessarily updated if, for example, the ND_{P,V}_LIMIT values are always lower than the remaining PD lifetimes. In this situation, the requirement is still that the lifetimes can be updated, but to the casual observer of the steady state the RA contents might appear static (e.g., while the PD'd prefix is continuously renewed). Maybe there's no text required here, but I didn't want a reader to be left with the impression that no two RAs could be identical [[ nits ]] [ section 3.3 ] * In the 2nd bullet's 2nd bullet (this might be easier if these lists were numbered), it might be good to clarify that "the *deprecated* prefix can simply be advertised..." From nobody Wed Oct 21 22:53: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 896373A0B40; Wed, 21 Oct 2020 22:53:20 -0700 (PDT) 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, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-sZAdkcBsKi; Wed, 21 Oct 2020 22:53:18 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 710333A0B10; Wed, 21 Oct 2020 22:53:17 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09M5r2EV030797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Oct 2020 01:53:06 -0400 Date: Wed, 21 Oct 2020 22:53:02 -0700 From: Benjamin Kaduk To: Fernando Gont Cc: The IESG , draft-ietf-v6ops-slaac-renum@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, Owen DeLong Message-ID: <20201022055302.GZ39170@kduck.mit.edu> References: <160323723374.19211.14841316122738197736@ietfa.amsl.com> <89bee4d0-1a69-f165-3486-f9e2275be7a7@si6networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <89bee4d0-1a69-f165-3486-f9e2275be7a7@si6networks.com> Archived-At: Subject: Re: [v6ops] Benjamin Kaduk's Discuss on draft-ietf-v6ops-slaac-renum-04: (with DISCUSS and COMMENT) 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, 22 Oct 2020 05:53:21 -0000 Hi Fernando, Also inline... On Tue, Oct 20, 2020 at 09:47:06PM -0300, Fernando Gont wrote: > Hello, Ben, > > Thanks so much for your detailed review! In-line..... > > > On 20/10/20 20:40, Benjamin Kaduk via Datatracker wrote: > [....] > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > In Section 2.3 we make a claim about item 'e)' of section 5.5.3 of RFC > > 4862, in particular that it says that 'an RA may never reduce the > > RemainingLifetime" to less than two hours', but the relevant text from RFC > > 4862 seems to be: > > > > 2. If RemainingLifetime is less than or equal to 2 hours, ignore > > the Prefix Information option with regards to the valid > > lifetime, unless the Router Advertisement from which this > > option was obtained has been authenticated (e.g., via Secure > > Neighbor Discovery [RFC3971]). If the Router Advertisement > > was authenticated, the valid lifetime of the corresponding > > address should be set to the Valid Lifetime in the received > > option. > > > > which clearly allows an *authenticated* RA to reduce the > > "RemainingLifetime" to smaller values. (Text with a similar > > not-quite-accurate statement appears in Section 2.4 of this document as > > well.) > > I know of no-real world deployment where RAs are authenticated. > > That said, would noting "unauthenticated RA" in our draft address your > comment? Yes, that is the resolution I was expecting. > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I look forward to seeing the more comprehensive solution/advice in > > draft-ietf-6man-slaac-renum and draft-ietf-6man-cpe-slaac-renum > > progress. > > > > I note that https://www.rfc-editor.org/materials/abbrev.expansion.txt > > does not mark "CPE" as "well-known", implying that we should probably > > expand it on first use. > > Our bad. We should use "CE Router" rather than "CPE", which is the term > employed in RFC7084. Will fix this. > > > > > Section 1 > > > > Scenarios where this problem may arise include, but are not limited > > to, the following: > > > > o The most common IPv6 deployment scenario for residential or small > > office networks is that in which a CPE router employs DHCPv6 > > Prefix Delegation (DHCPv6-PD) [RFC8415] to request a prefix from > > an Internet Service Provider (ISP), and a sub-prefix of the leased > > > > (nit/editorial) this construction looks like "scenarios where Q might > > happen include: A common scenario for X is Y. Sometimes, Y can be a > > scenario where Q happens." Pedantically, the list contents don't match > > the list introduction, since the extra introductory material doesn't > > match the classifier attempting to describe it. > > You're right. How about fixing this as: > "The most common IPv6 deployment scenario for residential or small > office networks, where a CE router..." That looks like it should do the trick. And nicely done, too -- I don't think I would have found that elegant of a tweak! > > > > o A router (e.g. Customer Edge router) may advertise > > autoconfiguration prefixes corresponding to prefixes learned via > > DHCPv6-PD with constant PIO lifetimes that are not synchronized > > with the DHCPv6-PD lease time (as required in Section 6.3 of > > [RFC8415]). [...] > > > > nit: I suggest the parenthetical be "even though Section 6.3 of > > [RFC8415] requires such synchronization", since the present formulation > > is potentially unclear about which behavior is the required one. > > Will apply this suggested edit. Thanks! > > > > > This means that in the aforementioned scenarios, the stale addresses > > would be retained and also actively employed for new communications > > instances for an unacceptably long period of time (one month, and one > > week, respectively), leading to interoperability problems, instead of > > hosts transitioning to the newly-advertised prefix(es) in a timelier > > manner. > > > > I am not 100% sure that "would" is always applicable, as I could imagine > > situations that conform to the above-listed scenarios yet have > > qualifying factors that result in non-use of the stale addresses. > > Could you please elaborate? I think I'm complaining more about "would be actively employed" than "would be retained" -- the "would be retained" part is pretty clearly true...which is what you go on to say below :) But they would not be employed if the node didn't generate any traffic at all, for example, or had a fresher prefix arrive and policy chose to use the newer one. > > > Perhaps "could" is more appropriate? > > Addresses will certainly be retained. I guess one might say "would be > retained and could also be...actively employed...."? That would address my concern here, yes. I would also understand if you decide that this new text is ugly and prefer to keep the old text even if it is pedantically not-quite-correct. > > > Section 2.2 > > > > IPv6 SLAAC employs the following default PIO lifetime values: > > > > o Preferred Lifetime (AdvPreferredLifetime): 604800 seconds (7 days) > > > > o Valid Lifetime (AdvValidLifetime): 2592000 seconds (30 days) > > > > We noted these values previously, in the Introduction. Is it useful to > > repeat them in both locations? > > If anything, I'd remove them from the Introduction, and point to Section > 2.2 from there... No complaint from me; I could also understand if the answer to my literal question was "yes", but wasn't sure just on my own first reading. > > > > > Under problematic circumstances, such as where the corresponding > > network information has become stale without any explicit signal from > > the network (as described in Section 1), it will take a host 7 days > > (one week) to deprecate the corresponding addresses, and 30 days (one > > > > I suggest "up to" [7 days ...]. > > Saying "up to" would suggest that that's the worst case scenario as > opposed to the regular case. Put another way: what'd be the scenario > where it would take less than that? I guess it depends on the frequency of RAs (which I do not have fresh in memory). In principle if you advertise something with a lifetime of 7 days and the recipient sets a timer, then if you crash and lose state, there could be anywhere from 0 to 7 days left on that timer. But if you are re-sending the "7 days" announcement every hour, then yes, it's pretty much always going to be 7 days. So, sorry for not having thought this through more thoroughly at first. > > > > Section 2.5 > > > > At times, the prefix lease time is fed as a constant value to the > > SLAAC router implementation, meaning that, eventually, the prefix > > lifetime advertised on the LAN side will span *past* the DHCPv6-PD > > lease time. This is clearly incorrect, since the SLAAC router > > implementation would be allowing the use of such prefixes for a > > longer time than it has been granted usage of those prefixes via > > DHCPv6-PD. > > > > I recognize that this is an informational document and we're not > > obligated to give advice, but we've given advice elsewhere in the > > document and it feels weird to end the section on such a grim note. > > Should we say something about such implementations ideally getting > > updated to reflect the specification? > > This document is meant to describe the problem, and provide operational > advice. As such, there's not really anything one can operationally do > with this implementation issue -- unless you're thinking of "replace the > device with one that has a different implementation". > > draft-ietf-v6ops-cpe-slaac-renum provides advice in this respect (i.e., > implementation). > > Thoughts? I was imagining "such broken implementations should be updated to honor the spec" (but worded a little more nicely). In practice that would probably be "replace the device" (as you note) for many affected devices, and thus is not particularly useful advice. So I would certainly understand if it's easier to just leave this text alone. > > > > > Section 3.2 > > > > NOTES: > > A CPE router advertising a sub-prefix of a prefixed leased via > > DHCPv6-PD will periodically refresh the Preferred Lifetime and the > > > > nit: s/prefixed leased/prefix leased/ > > Thanks! Will fix. > > > > > > > Section 6 > > > > This document does not introduce any > > new security issues. > > > > (side note) we sort-of recommend using different values for > > AdvPreferredLifetime/AdvValidLifetime, which would presumably affect the > > tradeoffs for robustness vs. susceptibility to attack. But the values > > from RFC 4861 are just "defaults", so there's a reasonable claim to be > > made that the relevant security considerations should have been covered > > in 4861 itself and we don't need to say more here. > > Roman made a similar comment, and my suggestion was to tweak the text to: > > This document discusses a problem that may arise in scenarios where > flash-renumbering events occur, and proposes workarounds to mitigate > the aforementioned problems. This document does not introduce any > new security issues, and thus the same security considerations as > for [RFC4861] apply. > > > Thoughts? Indeed, I only noticed Roman's comment after I filed my ballot. The text you agreed with him addresses my concerns, too. > > > > > Section 8.1 > > > > It's not clear to me that the one place we cite RFC 4941 qualifies as a > > normative reference. > > Agreed. I will move it to the Informative references. > > > > > > Section 8.2 > > > > The use of "[Linux]" as a slug for referencing a post to netdev is > > perhaps debatable. > > It's a link to a patch that has been committed to the tree (in the same > URL, you'll find the note that the patch has been accepted). I could > provide a link to the corresponding commit on the git repo? > > (fwiw, we didn't mean "[Linux]" to convey anything special... it was > just the obvious choice for the reference). To me (and no guarantees about anyone else), "[Linux]" sounds good for a link to the commit in the official git repo, and "[Linux-update]" sounds good for a link to the netdev post. Either seems like it would perform the role of reference adequately for the statement in question. > > > > The way in which we cite RFC 6724 seems similar to the way in which we > > cite, e.g., RFC 8028 (which is listed as normative). > > Agreed. We'll make RFC6724 normative. > > Thanks! Thanks! -Ben From nobody Wed Oct 21 23:56:05 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 337E33A0BC2; Wed, 21 Oct 2020 23:56:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-v6ops-cpe-slaac-renum@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, Owen DeLong , v6ops-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <160334976319.30197.9207349191059290751@ietfa.amsl.com> Date: Wed, 21 Oct 2020 23:56:03 -0700 Archived-At: Subject: [v6ops] Murray Kucherawy's No Objection on draft-ietf-v6ops-cpe-slaac-renum-05: (with COMMENT) 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, 22 Oct 2020 06:56:03 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-v6ops-cpe-slaac-renum-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Rob's DISCUSS, for the reasons Barry gave. In addition, I believe IETF consensus is to use BCP 14 in its entirety, not just the first half of it. Also, this sentence gave me pause: "This document uses these keywords not strictly for the purpose of interoperability, but rather for the purpose of establishing industry-common baseline functionality." Maybe this should be an applicability statement, and thus Standards Track? From nobody Thu Oct 22 00:06:00 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 C50673A0C70; Thu, 22 Oct 2020 00:05:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Murray Kucherawy via Datatracker To: "The IESG" Cc: draft-ietf-v6ops-slaac-renum@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, Owen DeLong , v6ops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Murray Kucherawy Message-ID: <160335035934.27332.14039596343041838249@ietfa.amsl.com> Date: Thu, 22 Oct 2020 00:05:59 -0700 Archived-At: Subject: [v6ops] Murray Kucherawy's No Objection on draft-ietf-v6ops-slaac-renum-04: (with COMMENT) 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, 22 Oct 2020 07:06:00 -0000 Murray Kucherawy has entered the following ballot position for draft-ietf-v6ops-slaac-renum-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-slaac-renum/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I concur with Martin Duke's suggestion. Otherwise, I've just a couple of nits here: Abstract: * "This document documents this issue ..." -- how about "describes"? Section 1: * s/timelier/more timely/ From nobody Thu Oct 22 03:11:56 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 A9E9F3A08AD; Thu, 22 Oct 2020 03:11:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-v6ops-slaac-renum@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, Owen DeLong , v6ops@ietf.org, owen@delong.com, jiangsheng@huawei.com, mellon@fugue.com X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <160336150623.22400.9696222623015648417@ietfa.amsl.com> Date: Thu, 22 Oct 2020 03:11:46 -0700 Archived-At: Subject: [v6ops] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-v6ops-slaac-renum-04=3A_=28with_COMMENT=29?= 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, 22 Oct 2020 10:11:47 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-v6ops-slaac-renum-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-slaac-renum/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. It is easy to read but errs sometimes on the anecdotes side rather than on the facts side (except for Jordi's survey). As discussed before, I personaly wonder whether it is a real problem for the IETF: it is largely about CPE/node implementation issues and not a protocol one (even if I agree that the RFC 4861 default timers were badly chosen 20 years ago). Please find below a couple of non-blocking COMMENT points and one nit but please also check: - Ted Lemon's IoT directorate review with his note about sleeping devices and time-outs: https://datatracker.ietf.org/doc/review-ietf-v6ops-slaac-renum-04-iotdir-telechat-lemon-2020-10-19/ - Sheng Jiang's Internet directorate review: https://datatracker.ietf.org/doc/review-ietf-v6ops-slaac-renum-04-intdir-telechat-jiang-2020-10-19/ I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Section 1 -- "for an unacceptably long period of time, thus resulting in connectivity problems." while the 'long period of time" is explained in the end of this section, giving a hint would help the reader to appreciate the problem. I found this introduction rather qualitative than quantitative. "it is not an unusual behavior" may be... but, documenting (OS versions, specific use cases) would make this argument stronger. "there has been evidence that some 802.1x supplicants do not reset network settings after successful 802.1x authentication." this is a very outdated behavior of Windows if not mistaken and fixed years ago. In all cases, documenting (OS version, specific case) would make this argument stronger. "Lacking any explicit signaling to deprecate the previously-advertised prefixes", as the explicit mechanism exists, I suggest to s/explicit/reliable/ "because of egress-filtering by the CPE or ISP" or is it ingress-filtering when packets are sourced by an 'internal' host ? "or routed elsewhere" I wonder how a packet could be routed elsewhere if the source address is wrong. Policy-based routing ? Suggest to remove those words. -- Section 2.1 -- Jordi's survey (a good one) does not say how often and how planned are those prefix changes? My own /48 is not 'stable per contract' but has been stable for 7 years (as long as the BNG does not change it will stay the same as AAA & DHCP are linked together at my ISP). So, the 37% is probably not meaning that 37% of the CPE are changing of prefix everyday. Did the authors check with the German ISP? AFAIK, the default policy has changed. Suggest to change the reference from RFC 4941 to the -bis document that is in the same IESG telechat (so will not cause delay in the publication of this document). -- Section 2.3 -- No reply required but I find the last part of this section quite smart. I would not have thought about this corner case ;-) -- Section 2.5 -- "Not unusually, the two protocols are implemented in two different", I am afraid that this is again 'anecdote' and not 'facts'. Citing implementations details would make this statement stronger. -- Section 3 -- To be honest, I was about to ballot a DISCUSS on this section as I think that there could be other mitigation techniques. E.g., the ISP could advertise 2 prefixes by DHCP-PD for a while (would need to re-read DHCPv6 to be sure) allowing an easier roll-over of the prefixes (esp. when planned prefix change). Or possibly remove completely this section as 3.1 obvious and it is not exhaustive. -- Section 3.2 -- While I agree that the default timers are wrong and that the suggested values are way better, this is a change in the CPE doing SLAAC and not in operator settings (or did I badly understood 'operator' as 'network operator' in the sense of ISP as opposed as residential user?). Is the same technique also described in the SLAAC CPE document ? == NITS == -- Section 3.2 -- The use of () in the first paragraph renders it difficult to parse. Consider rewriting it. From nobody Thu Oct 22 04:17:27 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 645293A09D3; Thu, 22 Oct 2020 04:17:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-v6ops-cpe-slaac-renum@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, Owen DeLong , v6ops-chairs@ietf.org, owen@delong.com, suresh@kaloom.com, jiangsheng@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <160336543195.21161.17851078775777074492@ietfa.amsl.com> Date: Thu, 22 Oct 2020 04:17:12 -0700 Archived-At: Subject: [v6ops] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-v6o?= =?utf-8?q?ps-cpe-slaac-renum-05=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 22 Oct 2020 11:17:13 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-v6ops-cpe-slaac-renum-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you for the work put into this easy-to-read document. I support Erik Kline's DISCUSS points. Please find below a couple of non-blocking COMMENT points and one nit but please also check: - Suresh Krishnan's IoT directorate review: https://datatracker.ietf.org/doc/review-ietf-v6ops-cpe-slaac-renum-05-iotdir-telechat-krishnan-2020-10-21/ - Sheng Jiang's Internet directorate review: https://datatracker.ietf.org/doc/review-ietf-v6ops-cpe-slaac-renum-05-intdir-telechat-jiang-2020-10-19/ I hope that this helps to improve the document, Regards, -éric == DISCUSS == As observed by Sheng in his review and by Rob Wilton, the use of normative-looking "MUST" is unusual in an informational document even with the section 2 about requirement languages as the use of uppercase could confuse the reader; or at least limit their use in the L-* text in section 3. Also, note that RFC 2119 has been updated by RFC 8174. The precedent set by RFC 7084 seems a bad one. I will trust the responsible AD decision on this topic. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The shepherd write-up includes twice "a particular corner case where DHCPv6 is being used to distribute effectively static addresses". Perhaps is it due for not being a native English speaker, but, the use of "corner case" in a shepherd write-up appears to me as weird and unexpected: is it the shepherd's opinion or the WG consensus of being a 'corner case'. I read this as 'very rare case' whereas I sincerely think, and Jordi's review indicates so, that this is not a rare case. -- Abstract -- I wonder why the word "IPv6" is never mentioned in the abstract while the whole document is about IPv6. OTOH, perhaps the default IP version in 2020 is indeed IPv6 ;-) -- Section 3 -- Should the L-13 of RFC 7084 be also updated ? Briefly discussed in section 3.3 I wonder what is the actual structure of this section? There are 4 L-XX requirements followed by 3 subsections and mapping between L-15 with section 3.1 and the same for L-16, L-17 but not for L-18 ? As noted in section 3.1, L-13 is actually Section 6.3 of [RFC8415] that is standard track -- Section 3.2 -- There is a reference to section 2.1 of this document but the authors probably meant section 3.1 of this document or Section 6.3 of [RFC8415]. Should the list of ND options include by default all options ? or at least indicate that this is not an exhaustive list to allow for future ND options ? -- Section 3.3 -- I agree with "IPv6 network renumbering is expected to take place in a planned manner," but this sentence seems to contradict the premisses of draft-ietf-v6ops-slaac-renum. Unsure how to reconciliate the two I-D (sharing some authors ;-) ). " since we acknowledge " suggest to slightly rewrite this sentence to make it less personal. Suggestion to mention whether RA are sent only on received RS, multicasted immediately (the document mention periodically), or unicasted when possible (some CPE keeps the mapping of all its unicast client notably on the Wi-Fi side). From nobody Thu Oct 22 06:04:09 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 6D4ED3A0EED; Thu, 22 Oct 2020 06:03:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-v6ops-slaac-renum@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, Owen DeLong , v6ops@ietf.org, owen@delong.com X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <160337183742.12987.1922843840262538450@ietfa.amsl.com> Date: Thu, 22 Oct 2020 06:03:57 -0700 Archived-At: Subject: [v6ops] Alissa Cooper's No Objection on draft-ietf-v6ops-slaac-renum-04: (with COMMENT) 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, 22 Oct 2020 13:04:04 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-v6ops-slaac-renum-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-slaac-renum/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- It seems like the first paragraph of Section 4 should be removed since it isn't future work at this point. From nobody Thu Oct 22 06:17:01 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 401883A0B9D; Thu, 22 Oct 2020 06:17:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-v6ops-cpe-slaac-renum@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, Owen DeLong , v6ops-chairs@ietf.org, owen@delong.com X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <160337261986.9706.15256831018374618832@ietfa.amsl.com> Date: Thu, 22 Oct 2020 06:17:00 -0700 Archived-At: Subject: [v6ops] Alissa Cooper's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS) 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, 22 Oct 2020 13:17:00 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-v6ops-cpe-slaac-renum-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Let's resolve the document status issue -- it was last-called as Proposed Standard, it's listed as Informational, but it seems like it should be a BCP. I support Rob's DISCUSS and I believe the RFC 8174 boilerplate should be used. From nobody Thu Oct 22 06:18: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 B25333A0983; Thu, 22 Oct 2020 06:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=cjYdDWCG; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=LmG4aSi7 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jvw7J5qQRty; Thu, 22 Oct 2020 06:18:45 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A67713A08B2; Thu, 22 Oct 2020 06:18:45 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 5FAA6A22; Thu, 22 Oct 2020 09:18:44 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 22 Oct 2020 09:18:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=f nldevfYuDNVLkRumYOUTxBd6t8JT+h+su9dDSQblQ8=; b=cjYdDWCGT+c1HFP6p IytIlzvlC5YxFSwsl1ro8jiAXTjTCSH4KvXq7ttUt+ygztqqR5Qhb6MvErfqmC6O dJSveGyXnLKeb71a/DO58Dbs/seR3iE28YqTsGVwnKSO7AwHWH3ckcHUhlDDYA+K ny6d40jbTDlgR5G1k+iEKga50QSD3StYCs5mxpGSoCpGtsgNoXdilJcVWxlwV9/o r9v24PdF/yUGcnx+Imyl5Nk8Ra8P6FqUYqjmmMPh6YhPh8p98DuABzLwQvC1t2yI 5UXF4ku6SrmWsxlZN4jlRg92MlF0TfuXSNHPfK71D9FR1r7HIB4w2fjPdV1SOaDn Mb28Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=fnldevfYuDNVLkRumYOUTxBd6t8JT+h+su9dDSQbl Q8=; b=LmG4aSi7ygJJpJU5yBU7d0o6yOdw2+57VKdPk1s6biSdWaadhZATIxoOk 5xRfmmoL2vRlvsX6b46KAKFBpw9PFYaCY0XCRu8Rq94utfsu3YAh3t9B1UNjBRBY MIVqe6lOz1dHEfElflGwV3UE8wDrnpqsGNLsGpwmOziH75N5723UooTR56d8Hk4z 4hxDq/VVBtUZEqdb1jPd47KIVJ3ez74KReUFEKFdBoaVBHT0CHIy9Ul/ZNoQHlpR nhGNGtiEmTdN3GZ4/D3syWvOrwptPhSe+WIng2l0a1i11Hx5FpXMBG5TCsOZoRMd 5j+2h/WUj6JEnjxWYfHZRcRVPQgTA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrjeejgdeiudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuggftrfgrth htvghrnhepiedtuefgteehieejudeiheeuffeutedufffggeelgfetjedvleefteehvdej kedtnecuffhomhgrihhnpegvphhishhtvghmvgdrnhgvthdpihgvthhfrdhorhhgnecukf hppedujeefrdefkedruddujedrkedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr rghmpehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinh X-ME-Proxy: Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.80]) by mail.messagingengine.com (Postfix) with ESMTPA id C084B3064682; Thu, 22 Oct 2020 09:18:42 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Alissa Cooper In-Reply-To: Date: Thu, 22 Oct 2020 09:18:41 -0400 Cc: Bernie Volz , IETF Gen-ART , draft-ietf-v6ops-cpe-slaac-renum.all@ietf.org, v6ops list , last-call@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <80F195D7-9D53-443C-AA43-7CE129CC49D7@cooperw.in> References: <159968036707.9786.16859070438001357349@ietfa.amsl.com> <8d777075-25b5-1817-5c2a-18162bfb9e71@si6networks.com> <2C9BF3C2-A611-4F18-8F03-104405DD9799@cisco.com> To: Pete Resnick X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [v6ops] [Gen-art] [Last-Call] Genart last call review of draft-ietf-v6ops-cpe-slaac-renum-04 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, 22 Oct 2020 13:18:48 -0000 Thanks for your review, Pete. Fernando, thanks for making updates. I = entered a DISCUSS ballot to get the document status straightened out. Alissa > On Sep 11, 2020, at 7:51 PM, Pete Resnick = wrote: >=20 > I missed that. And indeed the Last Call went out for Proposed = Standard. Warren should probably look into this before it goes to the = IESG. >=20 > pr >=20 > On 9 Sep 2020, at 19:50, Bernie Volz (volz) wrote: >=20 >> Interesting that the datatracker says the document is "Proposed = Standard", but the document has "Intend status: Informational". The two = should be made to agree. >>=20 >> - Bernie >>=20 >>> On Sep 9, 2020, at 8:45 PM, Fernando Gont = wrote: >>>=20 >>> =EF=BB=BFHello, Pete, >>>=20 >>> Thanks a lot for your feedback! In-line.... >>>=20 >>> On 9/9/20 16:39, Pete Resnick via Datatracker wrote: >>> [....] >>>> Major issues: None >>>> draft-ietf-v6ops-cpe-slaac-renum >>>> Minor issues: >>>> The shepherd writeup says: >>>> The document so far has been approved by the V6OPS working group >>>> (successful working group last call). The document does not = specify >>>> new protocol, but rather changes to the default parameters in >>>> existing protocols. >>>> However, the document is Informational, as confirmed by the = shepherd writeup. >>>> If this is actually updating default parameters in protocols, that = sounds like >>>> it should either be a Standards Track document or more likely a = BCP. As 2026 >>>> says: >>>> The BCP subseries of the RFC series is designed to be a way to >>>> standardize practices and the results of community deliberations. = [...] >>>> ...[G]ood user >>>> service requires that the operators and administrators of the >>>> Internet follow some common guidelines for policies and = operations. >>>> While these guidelines are generally different in scope and style >>>> from protocol standards, their establishment needs a similar = process >>>> for consensus building. >>>> That sounds like what this is doing, especially with all of the = 2119 language >>>> in here. Maybe this is Informational because 7084 (and 6204 before = it) were >>>> Informational, but perhaps 7084 (and other such document) should be = BCP as >>>> well. Indeed, it sounds like all of these SLAAC operational = documents could be >>>> in one BCP together. >>>=20 >>> FWIW, the reason for which this document is informational is because = the document it's formally updating (RFC7084) is also informational. -- = Me, I'd probably agree with you that both RFC7084 and this document = should be BCPs, rather than Informational. I'd like to hear from our AD = regarding how to proceed here. >>>=20 >>> FWIW, I'm fine with changing the track to BCP, although I'd also = note that there's plenty of existing practice of documents of this type = published as Informational. >>>=20 >>>=20 >>>=20 >>> Either way, Informational seems wrong. >>>> Nits/editorial comments: >>>> Throughout the document, it says, "This document RECOMMENDS..." or = "This >>>> document also RECOMMENDS" or "Additionally, this document = RECOMMENDS". RFC 2119 >>>> does not use "RECOMMENDS". You can say "CE Routers SHOULD..." or "A = Router >>>> Lifetime of ND_PREFERRED_LIMIT is RECOMMENDED" or if you must "It = is >>>> RECOMMENDED that..." (blech, I hate the passive form), since SHOULD = and >>>> RECOMMENDED are equivalent in 2119, but using the "This document = RECOMMENDS..." >>>> form is weird and isn't in 2119. >>>=20 >>> Fair enough. I'll apply the suggested edit unless I hear otherwise = from others. >>>=20 >>>=20 >>>=20 >>>=20 >>>> In 3.3, it says: >>>> o Upon changes to the advertised prefixes, and after = bootstrapping, >>>> the CE router advertising prefix information via SLAAC SHOULD >>>> proceed as follows: >>>> But then each of the things under there has a SHOULD or a MUST. The = SHOULD here >>>> is confusing. Instead, the sentence could simply be: >>>> o Upon changes to the advertised prefixes, and after = bootstrapping, >>>> the CE router advertising prefix information via SLAAC proceeds = as >>>> follows: >>>> Similarly: >>>> This document RECOMMENDS that if a CE Router provides LAN-side = DHCPv6 >>>> (address assignment or prefix delegation), the following behavior = be >>>> implemented: >>>> Just make the sentence: >>>> If a CE Router that provides LAN-side DHCPv6 (address assignment = or >>>> prefix delegation), then: >>>=20 >>> FWIW, the motivation for the "SHOULD" in Section 3.3 is that it = generally implies that the device records prefixes on non-volatile = storage. But there are valid reasons for which a device might be unable = to (e.g., economical, if you wish). >>>=20 >>> Then, the "MUSTs" elsewhere essentially try to signal how crucial = implementation of each specific behavior is. >>>=20 >>> Thoughts? >>>=20 >>> Thanks! >>>=20 >>> Regards, >>> --=20 >>> Fernando Gont >>> SI6 Networks >>> e-mail: fgont@si6networks.com >>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >>>=20 >>>=20 >>>=20 >>>=20 >=20 >=20 > --=20 > Pete Resnick https://www.episteme.net/ > All connections to the world are tenuous at best >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art From nobody Thu Oct 22 06:46: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 A48033A0C10 for ; Thu, 22 Oct 2020 06:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1UJ-yhpU8tp for ; Thu, 22 Oct 2020 06:46:15 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 6A3AF3A00D9 for ; Thu, 22 Oct 2020 06:46:15 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id b15so1652783iod.13 for ; Thu, 22 Oct 2020 06:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RQgAkJS7AADMssSbCogj0LDkKkXsMq1mI5ZMS7RSgtk=; b=CLPq/wopMm/ME++1AeP4qR5tuHnGackXngL6ZI5Bter6zX1ZUWPDvgdtXa7xmuzCd8 qzE+Ka43oWovmk/q1hT8/mmcu9NGdO/LqlGXcJgsMfGogJWZxVQjke5sMvuEQl8ZIPYD XEaHWsNvxs1UQkFP+F1o/aUBRzTS5PFKJbPweBCW85YVNd94vA/vWaxOpCLjXye443s4 /hySVIG8v0VsO9YX6VW0Dxda/snhNpK49uUp7ZYBY0FVjA5ZltHwCSny5IjSq99ePqIF bIhfbcCcqXyjnM4SkaQruoRLcq9/LjrI4OxiHAQeuRVqOXZNlVsLxVjh6y3ImVLWTmlO D91g== 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=RQgAkJS7AADMssSbCogj0LDkKkXsMq1mI5ZMS7RSgtk=; b=lWJJUrcb9mluSTploBwhdF0WJLz/LeL97ye/VTkM8+hcozFFqXoWxUZltQhvt0UvQG rT/bAyA/GH+rJLBVXoFoHj6XaPmcpekjyT26iUYiXKYFDeAt88IjlsZ7nMY/08/feSkD p/q9y72RQTpCYpNwZqjT8bA67kOOCnVo/9ZievTXL72bFpKzdE0MllmSYS6P3xBLPk+L CjbdfhZa5ZSzfYSTHERpqwbOiO5G59XKSJZHcsuBr1b0VV/oiPQiOxmrDwcN8i+g9uug dQapAU5mwLahL74tuvymwl4rt7avTBTrsGA7Egy1cjIV/cBXZ8PBctoyEq8JKWcJLfJR akkA== X-Gm-Message-State: AOAM531EHLr8hA1aWGtCVD3ctPY6gTE+X4TyQstizhv2yjXM5IsD1Y1N P79sNh3/F5Q2eqdZyr/2Sj33YaObOqhLuUl4TRZB0g== X-Google-Smtp-Source: ABdhPJydl9V6MbSMVEbeodmXgFNFzRQoQVOAeE+D7wkvzIvShYrW/dlo/2PKYSkdBPVLzYo3NF8p1rLdqddndw/x0ss= X-Received: by 2002:a5e:dc0b:: with SMTP id b11mr1257509iok.179.1603374374340; Thu, 22 Oct 2020 06:46:14 -0700 (PDT) MIME-Version: 1.0 References: <160337261986.9706.15256831018374618832@ietfa.amsl.com> In-Reply-To: <160337261986.9706.15256831018374618832@ietfa.amsl.com> From: Lorenzo Colitti Date: Thu, 22 Oct 2020 22:46:03 +0900 Message-ID: To: Alissa Cooper Cc: The IESG , V6Ops Chairs , "v6ops@ietf.org WG" , draft-ietf-v6ops-cpe-slaac-renum@ietf.org, v6ops-ads@ietf.org Content-Type: multipart/alternative; boundary="00000000000006bffa05b242b0df" Archived-At: Subject: Re: [v6ops] Alissa Cooper's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS) 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, 22 Oct 2020 13:46:21 -0000 --00000000000006bffa05b242b0df Content-Type: text/plain; charset="UTF-8" On Thu, Oct 22, 2020 at 10:17 PM Alissa Cooper via Datatracker < noreply@ietf.org> wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-v6ops-cpe-slaac-renum-05: Discuss > [...] > DISCUSS: > ---------------------------------------------------------------------- > > Let's resolve the document status issue -- it was last-called as Proposed > Standard, it's listed as Informational, but it seems like it should be a > BCP. > > I support Rob's DISCUSS and I believe the RFC 8174 boilerplate should be > used. > I don't think this should be classified as BCP without sending it to the WG for another look. WG consensus was reached on the assumption that the intended status was informational. I suspect many WG participants would have looked at the text with different eyes, and held it to a different/higher standard, if the intended status had been BCP. I know for sure that I would have. --00000000000006bffa05b242b0df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Oct 22, 2020 at 10:17 PM Alissa C= ooper via Datatracker <noreply@ietf.= org> wrote:
Alissa Cooper has entered the following ballo= t position for
draft-ietf-v6ops-cpe-slaac-renum-05: Discuss
[...]
DISCUSS:
----------------------------------------------------------------------

Let's resolve the document status issue -- it was last-called as Propos= ed
Standard, it's listed as Informational, but it seems like it should be = a BCP.

I support Rob's DISCUSS and I believe the RFC 8174 boilerplate should b= e used.

I don't think this should b= e classified as BCP without sending it to the WG for another look. WG conse= nsus was reached on the=C2=A0assumption that the intended status was inform= ational. I suspect many WG participants would have looked at the text with = different eyes, and held it to a different/higher standard, if the intended= status had been BCP. I know for sure that I would have.
--00000000000006bffa05b242b0df-- From nobody Thu Oct 22 07:06: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 C917A3A0CA0; Thu, 22 Oct 2020 07:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=L5CJHQl5; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=sPpwv2xG Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKCayi9f3Mwo; Thu, 22 Oct 2020 07:06:02 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BA2F3A0C9E; Thu, 22 Oct 2020 07:05:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10796; q=dns/txt; s=iport; t=1603375562; x=1604585162; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=l8Q5KL93UxHNuQCqoYHh3tiBK24wGjv/8vW3VVWSi3E=; b=L5CJHQl5ikbZmLrA/fqRAI8w1uFVHmuaG5z0Je6i6HUFxOHy5O3UqsJe 9+20aUIAbToFATHLGPq9ZdBgoMtxe6tMHPEP8ILIDW1m1QaxMynfswvvp dvYQvnY3MrwZSd683bxzvTqCUuAEz97qYh9t7pHZp633FoQVZ0n7SGdTo c=; IronPort-PHdr: =?us-ascii?q?9a23=3AHb5slx1LxMh2mLzJsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGu6dii1jGWYid4PVB2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YkdSH8n6ahvZpXjhpTIXEw?= =?us-ascii?q?/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpBQBXkJFf/49dJa1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQGCD4EjL1EHcFkvLAqEMoNJA41PlAuEb4JTA1ULAQEBDQEBLQI?= =?us-ascii?q?EAQGESgIXgXICJTgTAgMBAQsBAQUBAQECAQYEbYVhDIVyAQEBBBIRChMBATc?= =?us-ascii?q?BDwIBCBEEAQEoAwICAjAUCQgCBAENBQgagwWBfk0DLgGnZwKBOYhodoEygwQ?= =?us-ascii?q?BAQWFAxiCEAmBOIJyg3CCRIQTG4IAgRFDgk0+hD80gmEzgiyQMYJnPYcUnSA?= =?us-ascii?q?KgmqVcIUroV6OV4RloDcCBAIEBQIOAQEFgWsjN4EgcBWDJFAXAg2OHzeDOop?= =?us-ascii?q?WdDgCBgoBAQMJfIw7AYEQAQE?= X-IronPort-AV: E=Sophos;i="5.77,404,1596499200"; d="scan'208,217";a="569623469" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Oct 2020 14:05:56 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 09ME5uiG029632 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 22 Oct 2020 14:05:56 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 22 Oct 2020 09:05:55 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 22 Oct 2020 09:05:55 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 22 Oct 2020 09:05:55 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D2hIHG0PH7cerRwIQ/KeKMzqpyC7ZwqIPTrEueyxjIYvyNAkoxWhaL2V2bnAJkTNjOBk8G0htZUkLUtviQA+eWyLd3mG+3kSi+A687yYrcY01p4kwti5oCO4ej+sZ3iCq9fI8nsVR2I+eCZROPmWSy6P6+MsAADhqkTJzMVEKBKsoPkJkXb8CFTipiLP9NpRuMov1BvOHlWX+9+qudvmV0nXV/e8EhA8EyW0dy/b1XjxdsfJ770EGy3Wfz3Ldin/FufngoY1oO7nmiKyx64DpGZP60pZhnvHQM9Iu4ILD5gzJwlbOBDMChZjc9CBqjWxy4OxCo/8aoxnoZ05YxQTWA== 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=l8Q5KL93UxHNuQCqoYHh3tiBK24wGjv/8vW3VVWSi3E=; b=jzp8TjRQsMsk/wKHXG4xnUnzXsyPhu6D16bq9JAMtgefFrAlgra4aLY63gb685938/RGdYKixFcxaGQxiUGASr7kyzArw8CSeaXgSbHd31N6Trfbn2mcHtrlowQYaIefiy9TA6r8QMkin61L8h7qOYT1XD3tlHbKjLZxRmQuC23woIzJha9xlAkrf24jeAyCIwn24riGKgpeTYwb1G30ClqjrifkhgfTV2DQY4F7k2/rIPI+UbE/HnIuuc904b9A7fCAvMEwUZIgYEdlybAfxwTmSooZPmW8T33CMngIuBii7WMchRDyhNj4Bs3igIolVYhpWH11REXIEa9sHmEjww== 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=l8Q5KL93UxHNuQCqoYHh3tiBK24wGjv/8vW3VVWSi3E=; b=sPpwv2xG4MPG2FHCE4Ohq1JfBKtpmfKh5JCf40wsL2Yq7hHlZuZx9UkYsyitruWyhXH36HiJ51PguTucmIJUePDZ9P2+HP9JJoFCZdsOT7V82KVoLh9M0nRcjliDevp9FZn8G+HzA0IEa9NkaP/xfGYUyyTOtZIRbP3QIlDbmLs= Received: from BN7SPR01MB0024.namprd11.prod.outlook.com (2603:10b6:408:38::13) by BN7PR11MB2563.namprd11.prod.outlook.com (2603:10b6:406:b0::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Thu, 22 Oct 2020 14:05:54 +0000 Received: from BN7SPR01MB0024.namprd11.prod.outlook.com ([fe80::cc63:cc73:9544:bc0f]) by BN7SPR01MB0024.namprd11.prod.outlook.com ([fe80::cc63:cc73:9544:bc0f%6]) with mapi id 15.20.3477.020; Thu, 22 Oct 2020 14:05:54 +0000 From: "Bernie Volz (volz)" To: Lorenzo Colitti , Alissa Cooper CC: The IESG , V6Ops Chairs , "v6ops@ietf.org WG" , "draft-ietf-v6ops-cpe-slaac-renum@ietf.org" , "v6ops-ads@ietf.org" Thread-Topic: [v6ops] Alissa Cooper's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS) Thread-Index: AQHWqHWmmo3SZxwvS06ShjNztyMHsamjonKAgAAE/4A= Date: Thu, 22 Oct 2020 14:05:54 +0000 Message-ID: References: <160337261986.9706.15256831018374618832@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.86] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 01286e17-2d7b-4535-362c-08d876939741 x-ms-traffictypediagnostic: BN7PR11MB2563: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: LQFj17BxDWBQWS2a/ZqzCvmrCRinJQC+yQuCn6tz9x+4NxBdnUafEudzhp3YMfdO/UbdL+eJHfVYnv2/+NHdw+7ezGD+KVjTrAgbO5rpUVXPfyRPWlfJ4D85K/kAK9KG6pFBe0luNa9pZGMsAIZ7TIy3zkpLLTvoS5dzQqN4m2Ami12xPNnBDfRSlVbbLvVw0J6G62vK6TM1NLqtsictlpG/YjSK8XXGOG9vkTYUre9CBCczSQIlXbKMs7zmqpx7YyWkd5R8l04kPH0EUh7dDEo0I2RXUd9UPymsaQayHHeG14ulmGkGp1C5zoU/fmBp+DnndIn5n4hDK2dhuQYGEw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7SPR01MB0024.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(366004)(396003)(136003)(376002)(39860400002)(53546011)(6506007)(316002)(4326008)(55016002)(71200400001)(2906002)(86362001)(66946007)(186003)(66476007)(76116006)(64756008)(66556008)(66446008)(110136005)(8676002)(54906003)(33656002)(478600001)(9686003)(52536014)(8936002)(5660300002)(26005)(7696005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: r6ZQbflM+wP7GNU06FsrPgHtc5SsKq3N5tu/kWkbAFOjC3aJz2wAQTI6KjshuhuyCE5SxcPfohDbc+rq2WlBg2HcNqNgAqVAfzmbxgT7QEFvSmrInFoBjmWescoyaK2OGLsNP+2nrsvJkPnj+hinL8cepVm+hTT54gKRoawp1rtNNOgHkoECJlmrMrIjbsJ8MT80eVAzoF9CtfEP1TTc6K9ngyrEKL6WvZfRTXZmvWP+d4QFDNrRdefOULA7jDaawTADeib2VSyqf0fpDEeqeEQ9E1u12wJOX7Van1i0AazguMwKUUyJfAotcB4Z1Po8v0l9LU46FcbHfUuFu1Sua2SPdDJ7PW6ESjP5aC+3vvpvf1I/WcIViZh75muqUIB/iXKee7RtyPs1mxJQFJo0qqBGc2mc5AxcXcZwCOioo9LecFnJeyuZOcM6zQPWTJ4Y5ltwEASHRZBiKPWqeNjGTunILe5p7jRaU4eJvUmtDEtCQwuq954EouwlQaOk1kqvjs7uaZORdj6NB6sNVFd7sNW19zX1u4LHKsBd1BcrPOJh6D45eoMIGkfdL53Hw7CTJxCi2Ou3u0Y4bDGU835YxyK7wg4E7MJPFvkFXjnnxy/u3ADVAri+rt6E+2FJMBQn44S60KdgGmbc88o094Sk9Q== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN7SPR01MB0024A74D648916CE1F2E9F24CF1D0BN7SPR01MB0024na_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN7SPR01MB0024.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 01286e17-2d7b-4535-362c-08d876939741 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2020 14:05:54.1689 (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: v0WNkUA2CYOp1SsPmhFi8u9bIkPQ1FADqDGzRnOzhpsm2s0FSUWasnPoMSDv0W+6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2563 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [v6ops] Alissa Cooper's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS) 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, 22 Oct 2020 14:06:07 -0000 --_000_BN7SPR01MB0024A74D648916CE1F2E9F24CF1D0BN7SPR01MB0024na_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxzbywgZ2l2ZW4gdGhhdCB0aGUgZG9jdW1lbnQgaXQgaXMgdXBkYXRpbmcgaXMgUkZDNzA4NCB3 aGljaCBpdHNlbGYgaXMgSU5GT1JNQVRJT05BTCwgaGFyZCB0byBzZWUgd2h5IHRoaXMgd291bGQg bm90IGJlIHRoZSBzYW1lPw0KDQoNCiAgKiAgIEJlcm5pZQ0KDQpGcm9tOiBMb3JlbnpvIENvbGl0 dGkgPGxvcmVuem9AZ29vZ2xlLmNvbT4NClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDIyLCAyMDIw IDk6NDYgQU0NClRvOiBBbGlzc2EgQ29vcGVyIDxhbGlzc2FAY29vcGVydy5pbj4NCkNjOiBUaGUg SUVTRyA8aWVzZ0BpZXRmLm9yZz47IFY2T3BzIENoYWlycyA8djZvcHMtY2hhaXJzQGlldGYub3Jn PjsgdjZvcHNAaWV0Zi5vcmcgV0cgPHY2b3BzQGlldGYub3JnPjsgZHJhZnQtaWV0Zi12Nm9wcy1j cGUtc2xhYWMtcmVudW1AaWV0Zi5vcmc7IHY2b3BzLWFkc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFt2Nm9wc10gQWxpc3NhIENvb3BlcidzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi12Nm9wcy1jcGUt c2xhYWMtcmVudW0tMDU6ICh3aXRoIERJU0NVU1MpDQoNCk9uIFRodSwgT2N0IDIyLCAyMDIwIGF0 IDEwOjE3IFBNIEFsaXNzYSBDb29wZXIgdmlhIERhdGF0cmFja2VyIDxub3JlcGx5QGlldGYub3Jn PG1haWx0bzpub3JlcGx5QGlldGYub3JnPj4gd3JvdGU6DQpBbGlzc2EgQ29vcGVyIGhhcyBlbnRl cmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi12Nm9wcy1j cGUtc2xhYWMtcmVudW0tMDU6IERpc2N1c3MNClsuLi5dDQpESVNDVVNTOg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQpMZXQncyByZXNvbHZlIHRoZSBkb2N1bWVudCBzdGF0dXMgaXNzdWUgLS0gaXQgd2FzIGxh c3QtY2FsbGVkIGFzIFByb3Bvc2VkDQpTdGFuZGFyZCwgaXQncyBsaXN0ZWQgYXMgSW5mb3JtYXRp b25hbCwgYnV0IGl0IHNlZW1zIGxpa2UgaXQgc2hvdWxkIGJlIGEgQkNQLg0KDQpJIHN1cHBvcnQg Um9iJ3MgRElTQ1VTUyBhbmQgSSBiZWxpZXZlIHRoZSBSRkMgODE3NCBib2lsZXJwbGF0ZSBzaG91 bGQgYmUgdXNlZC4NCg0KSSBkb24ndCB0aGluayB0aGlzIHNob3VsZCBiZSBjbGFzc2lmaWVkIGFz IEJDUCB3aXRob3V0IHNlbmRpbmcgaXQgdG8gdGhlIFdHIGZvciBhbm90aGVyIGxvb2suIFdHIGNv bnNlbnN1cyB3YXMgcmVhY2hlZCBvbiB0aGUgYXNzdW1wdGlvbiB0aGF0IHRoZSBpbnRlbmRlZCBz dGF0dXMgd2FzIGluZm9ybWF0aW9uYWwuIEkgc3VzcGVjdCBtYW55IFdHIHBhcnRpY2lwYW50cyB3 b3VsZCBoYXZlIGxvb2tlZCBhdCB0aGUgdGV4dCB3aXRoIGRpZmZlcmVudCBleWVzLCBhbmQgaGVs ZCBpdCB0byBhIGRpZmZlcmVudC9oaWdoZXIgc3RhbmRhcmQsIGlmIHRoZSBpbnRlbmRlZCBzdGF0 dXMgaGFkIGJlZW4gQkNQLiBJIGtub3cgZm9yIHN1cmUgdGhhdCBJIHdvdWxkIGhhdmUuDQo= --_000_BN7SPR01MB0024A74D648916CE1F2E9F24CF1D0BN7SPR01MB0024na_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0 Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTow aW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExp c3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE1MTM0OTI2MTU7DQoJ bXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi04NDI5MDc3ODAg MTE5Mjg5NjM2IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3 Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwt c3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3Qg bDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVs Ng0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsc28sIGdpdmVuIHRoYXQgdGhlIGRvY3VtZW50IGl0 IGlzIHVwZGF0aW5nIGlzIFJGQzcwODQgd2hpY2ggaXRzZWxmIGlzIElORk9STUFUSU9OQUwsIGhh cmQgdG8gc2VlIHdoeSB0aGlzIHdvdWxkIG5vdCBiZSB0aGUgc2FtZT88bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJt YXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPkJlcm5pZTxv OnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj5Gcm9tOjwvYj4gTG9yZW56byBDb2xpdHRpICZsdDtsb3JlbnpvQGdvb2dsZS5jb20mZ3Q7IDxi cj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgT2N0b2JlciAyMiwgMjAyMCA5OjQ2IEFNPGJyPg0K PGI+VG86PC9iPiBBbGlzc2EgQ29vcGVyICZsdDthbGlzc2FAY29vcGVydy5pbiZndDs8YnI+DQo8 Yj5DYzo8L2I+IFRoZSBJRVNHICZsdDtpZXNnQGlldGYub3JnJmd0OzsgVjZPcHMgQ2hhaXJzICZs dDt2Nm9wcy1jaGFpcnNAaWV0Zi5vcmcmZ3Q7OyB2Nm9wc0BpZXRmLm9yZyBXRyAmbHQ7djZvcHNA aWV0Zi5vcmcmZ3Q7OyBkcmFmdC1pZXRmLXY2b3BzLWNwZS1zbGFhYy1yZW51bUBpZXRmLm9yZzsg djZvcHMtYWRzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIEFsaXNz YSBDb29wZXIncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtdjZvcHMtY3BlLXNsYWFjLXJlbnVtLTA1 OiAod2l0aCBESVNDVVNTKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gVGh1LCBPY3QgMjIsIDIwMjAgYXQgMTA6MTcgUE0gQWxpc3NhIENvb3BlciB2aWEg RGF0YXRyYWNrZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpub3JlcGx5QGlldGYub3JnIj5ub3JlcGx5 QGlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxpc3NhIENvb3BlciBoYXMgZW50ZXJl ZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3I8YnI+DQpkcmFmdC1pZXRmLXY2b3Bz LWNwZS1zbGFhYy1yZW51bS0wNTogRGlzY3Vzczxicj4NClsuLi5dPGJyPg0KRElTQ1VTUzo8YnI+ DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KTGV0J3MgcmVzb2x2ZSB0aGUgZG9jdW1lbnQgc3Rh dHVzIGlzc3VlIC0tIGl0IHdhcyBsYXN0LWNhbGxlZCBhcyBQcm9wb3NlZDxicj4NClN0YW5kYXJk LCBpdCdzIGxpc3RlZCBhcyBJbmZvcm1hdGlvbmFsLCBidXQgaXQgc2VlbXMgbGlrZSBpdCBzaG91 bGQgYmUgYSBCQ1AuPGJyPg0KPGJyPg0KSSBzdXBwb3J0IFJvYidzIERJU0NVU1MgYW5kIEkgYmVs aWV2ZSB0aGUgUkZDIDgxNzQgYm9pbGVycGxhdGUgc2hvdWxkIGJlIHVzZWQuPG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbid0 IHRoaW5rIHRoaXMgc2hvdWxkIGJlIGNsYXNzaWZpZWQgYXMgQkNQIHdpdGhvdXQgc2VuZGluZyBp dCB0byB0aGUgV0cgZm9yIGFub3RoZXIgbG9vay4gV0cgY29uc2Vuc3VzIHdhcyByZWFjaGVkIG9u IHRoZSZuYnNwO2Fzc3VtcHRpb24gdGhhdCB0aGUgaW50ZW5kZWQgc3RhdHVzIHdhcyBpbmZvcm1h dGlvbmFsLiBJIHN1c3BlY3QgbWFueSBXRyBwYXJ0aWNpcGFudHMgd291bGQgaGF2ZSBsb29rZWQg YXQgdGhlDQogdGV4dCB3aXRoIGRpZmZlcmVudCBleWVzLCBhbmQgaGVsZCBpdCB0byBhIGRpZmZl cmVudC9oaWdoZXIgc3RhbmRhcmQsIGlmIHRoZSBpbnRlbmRlZCBzdGF0dXMgaGFkIGJlZW4gQkNQ LiBJIGtub3cgZm9yIHN1cmUgdGhhdCBJIHdvdWxkIGhhdmUuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN7SPR01MB0024A74D648916CE1F2E9F24CF1D0BN7SPR01MB0024na_-- From nobody Thu Oct 22 07:06: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 14ECD3A110F; Thu, 22 Oct 2020 07:06:24 -0700 (PDT) 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 SJXvk-gI-MQd; Thu, 22 Oct 2020 07:06:21 -0700 (PDT) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 900383A0E66; Thu, 22 Oct 2020 07:06:18 -0700 (PDT) Received: by mail-oi1-x22f.google.com with SMTP id k27so1806495oij.11; Thu, 22 Oct 2020 07:06:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=A7EBN+IezsluJnX8u0026btj+V8GRyLR/gD6BRu2kls=; b=XvRMDUZcoDrxSn/+WZDyawOOXTVfdV7/YmPxTywVlFq3Y9bWpecPeBrMDrqWAgBHLc D/6S98WioyVZdm3r4xSZGeom91IeQaFlOrmXBXOIiHzo7zmKX5XASMquePnw6/ux2vKE 5f5RDL0otoHgUAfRtOel8tj/PChzICvPwC/yWTDQPGLF+rRdLpLRIgQp9ghNVp5ACby3 K9hJokzbNBBrxbCEB8PCUuLuDD7YyGNh27LEULPnMiNxD/Rcgys2SBCPYr4dXmzl/SsT qRagd/bCAOMnyb3+5z6Lxz8XEx2buksnl/QTGYzo0WlwiDSKsVnkor1v7noGnqF3nq+7 SuDw== 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=A7EBN+IezsluJnX8u0026btj+V8GRyLR/gD6BRu2kls=; b=OBo5TCeOwVP2zbg8jSzC0GIaaGJJzVDF+dp9cvk2x8Fm5Kplr4q/tM8kggXD39Dxkq wGTiXc/ik6KaEypSrwT0cLybbaKZkAWzLks2b+YqTnmngRyBQu5wKKZVjwEWPrJR5LiE 19CRvv7RIgFQKhD1aj9fWRwLNg34EeyGLAu3w3QKfUacBTMbY1QQ2naD4Vihea+m5h2W 8QiWQiPBI0sXEumg4aw0Kl+L6RWJn4cdeHbs9XLSzhA3xRDJxNHAB5JOWRHbKfO5ZMUg Xt5dRv1EvUf2DaMNx94AtHil+N52GVCNuv3eVXR06wHd1p25zvvZ1xAAbnMeO+Kp6s2m 6jiQ== X-Gm-Message-State: AOAM531j7YDeDI6J9et9rlyTMkRYj+cL+myXI0c110qvSqwfWaGkdSbN dyYd80z62da3H+8rnPypaHCcmtqLnmok8r95xFuRR02b X-Google-Smtp-Source: ABdhPJzlrhAWdkhT3YUQBJeqFc02Thx0jiKc/qxl3hltztYvwtTJ5m8U8Ba6J2FMi2UMkNNQCWoWpYZ6jyA1Ze5UN2g= X-Received: by 2002:a05:6808:9b8:: with SMTP id e24mr1700972oig.97.1603375577753; Thu, 22 Oct 2020 07:06:17 -0700 (PDT) MIME-Version: 1.0 References: <160337261986.9706.15256831018374618832@ietfa.amsl.com> In-Reply-To: From: Erik Kline Date: Thu, 22 Oct 2020 07:06:07 -0700 Message-ID: To: Lorenzo Colitti Cc: Alissa Cooper , draft-ietf-v6ops-cpe-slaac-renum@ietf.org, "v6ops@ietf.org WG" , V6Ops Chairs , The IESG , v6ops-ads@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Alissa Cooper's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS) 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, 22 Oct 2020 14:06:29 -0000 On Thu, Oct 22, 2020 at 6:46 AM Lorenzo Colitti wrote: > > On Thu, Oct 22, 2020 at 10:17 PM Alissa Cooper via Datatracker wrote: >> >> Alissa Cooper has entered the following ballot position for >> draft-ietf-v6ops-cpe-slaac-renum-05: Discuss >> [...] >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Let's resolve the document status issue -- it was last-called as Propose= d >> Standard, it's listed as Informational, but it seems like it should be a= BCP. >> >> I support Rob's DISCUSS and I believe the RFC 8174 boilerplate should be= used. > > > I don't think this should be classified as BCP without sending it to the = WG for another look. WG consensus was reached on the assumption that the in= tended status was informational. I suspect many WG participants would have = looked at the text with different eyes, and held it to a different/higher s= tandard, if the intended status had been BCP. I know for sure that I would = have. This (running by the wg again) seems entirely reasonable to me. From nobody Thu Oct 22 07:11:32 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 A73713A0D31 for ; Thu, 22 Oct 2020 07:11:31 -0700 (PDT) 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 lP7OSYLryPQL for ; Thu, 22 Oct 2020 07:11:29 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 C325C3A0D33 for ; Thu, 22 Oct 2020 07:11:29 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id 140so1549018qko.2 for ; Thu, 22 Oct 2020 07:11:29 -0700 (PDT) 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=cpOdbE+/o6Nf4MV+fel+6LgyKb8tQ+YaBQ/zpV2Frjw=; b=pCm3RPrOYafzAQ6w9RBz1AHuQ/beRMdm5rJ8Jo2nlFbhovzTCR5uJk7ChsuoFCuVIR uUGiveS8Xzqb+rpCWs9itrNy4V0R2ywzsPWl7/tFifJIi+PNKNEvTy0BhxDmjSvEtJZR hnQqkkkju2UUE4KgCC/EvXCJ2Rn9S2DKYhhvw2iabD0h1QarPpe0wJQZJqg/0owTORCP k7wtJOYBGb5zDarOIwkDKZaI6s4hNs+8x+NJed2lIklFB4ll89ikO+ZpGqXr2f/OUzTu P5Vzg9GYuXd37PLPX+WiChkTyJlNi9N04MslX0XuBFM7/x5OxjuZwdUVlI1o6w+Gsf/B 9v3w== 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=cpOdbE+/o6Nf4MV+fel+6LgyKb8tQ+YaBQ/zpV2Frjw=; b=i05XaJvraa2RTU1vBnxmdVz4wKFNz467xVoMxQNvO4R87PIbv5QJCBTIf3SyepSOR/ wEBJmET8PP9g0OWQPioqhuC6UnoZu0EX2zFNUdTTF6GUJzwECosjRlfIX0mPvfv7xLCZ 7d4a0FlPOXBo5tzjRBZVNGCVwD94HpoxZTOPn1TUggz9SSfDilgoWi0gXj+Teei+f4Cu nc4MZ+NxPT5RiK0ptAWfc9ilsvkcZyq/yvCFg/XPuOkq1FmAhM/QqhIBofaptMMnrWCu ElCm0FWi9DIalXicpf2m/H5a2aZBrl/2cNbx2IZo60NEqLSxdR9yCj6p4DFgxzMzR2RB HTAg== X-Gm-Message-State: AOAM531jy7tu1hTZ7+zBoQYkRip+4gMrtFWR8ADOh5Ol+GAWYh54NVuT YQlobxmzS1zODCjmKKDEmNBrOA== X-Google-Smtp-Source: ABdhPJwF2eHtcqF4Kcc10Wc9bPsv4aMp3SV1SaB/cvai1lBqWMeJ04jfAQikR2nCj2eVZlijgEXJmA== X-Received: by 2002:a37:86c4:: with SMTP id i187mr1033765qkd.371.1603375886784; Thu, 22 Oct 2020 07:11:26 -0700 (PDT) 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 p38sm1109859qtb.20.2020.10.22.07.11.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 22 Oct 2020 07:11:26 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Thu, 22 Oct 2020 10:11:24 -0400 Message-Id: <34783E29-F267-4A58-9C3E-5CC2C0D93B49@fugue.com> References: <160334506239.20395.15102292380884503313@ietfa.amsl.com> Cc: The IESG , v6ops-chairs@ietf.org, v6ops@ietf.org, draft-ietf-v6ops-cpe-slaac-renum@ietf.org In-Reply-To: <160334506239.20395.15102292380884503313@ietfa.amsl.com> To: Erik Kline X-Mailer: iPhone Mail (18B79) Archived-At: Subject: Re: [v6ops] Erik Kline's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS and COMMENT) 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, 22 Oct 2020 14:11:32 -0000 I think it=E2=80=99s reasonable to assume that in some situations a ULA will= be generated and not remembered, or that the /48 will be remembered but the= subnetting will not be. E.g. this could happen in an HNCP-delegated network= pretty easily. The set of behaviors we are seeing in existing border router= s fairly constrained with respect to what is theoretically possible and even= reasonable. So I don=E2=80=99t think there=E2=80=99s a good reason to sugg= est different treatment for ULAs.=20 > On Oct 22, 2020, at 01:37, Erik Kline via Datatracker w= rote: >=20 > =EF=BB=BFErik Kline has entered the following ballot position for > draft-ietf-v6ops-cpe-slaac-renum-05: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > [ section 3.2 ] >=20 > * I absolutely agree in principle at these other lifetimes should be updat= ed > to the shorter of the two applicable lifetimes, but I'm worried that this= > text is not sufficiently precise. Specifically, this recommendation only= > applies to options that depend in any way on the change in the delegated > prefix, yes? Perhaps just this qualifier is sufficient? >=20 > For example, none of these comparative lifetime recommendations apply to > a stable ULA for a router that meets requirements ULA-[1..5] and chooses > to advertise a ULA /48 RIO and maybe even a ULA DNS server, I think. >=20 > That being said, should this document also be saying that the ULA-derived= > options SHOULD prefer the ND_{P,V}_LIMIT lifetime values, in case a reboo= t > causes a new ULA to be generated (i.e. the one supposedly in stable stora= ge > is lost or otherwise unrecoverable)? >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > [[ comments ]] >=20 > [ section 3.1 ] >=20 > * With respect to the second bullet: the lifetimes need to be dynamically > *updateable*, not necessarily updated if, for example, the ND_{P,V}_LIMIT= > values are always lower than the remaining PD lifetimes. In this situati= on, > the requirement is still that the lifetimes can be updated, but to the > casual observer of the steady state the RA contents might appear static > (e.g., while the PD'd prefix is continuously renewed). >=20 > Maybe there's no text required here, but I didn't want a reader to be lef= t > with the impression that no two RAs could be identical >=20 >=20 > [[ nits ]] >=20 > [ section 3.3 ] >=20 > * In the 2nd bullet's 2nd bullet (this might be easier if these lists were= > numbered), it might be good to clarify that "the *deprecated* prefix can > simply be advertised..." >=20 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Oct 22 07:28:26 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 E2A973A0A10; Thu, 22 Oct 2020 07:28:24 -0700 (PDT) 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 tjo6SLFujYX7; Thu, 22 Oct 2020 07:28:23 -0700 (PDT) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 622083A09E3; Thu, 22 Oct 2020 07:28:23 -0700 (PDT) Received: by mail-oi1-x22e.google.com with SMTP id w141so1919095oia.2; Thu, 22 Oct 2020 07:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=lMjECnk78jVepyfZjPNeyjoslg1YWp4I+90WokcicHc=; b=SLOaXWBIUZVm5yg1l2JoYPqwFsLBzQrIiikhWA4/0EYQz1gb1w7rqSQU4hz+d94CVd paeKK4DH+P/xA4ih7ivPDUByG0u++gqVhQhupEFylN4HNuI4/UTdvZTjA2EbtA6F67IQ HVhJaZMxPw1XNAf7s2Eha8/DD1GPnD31aF72xrK8ZtS6Uq5VmoBIdMRzAYdUQekexnUt N0qSgCOdjMBrdcW8Lq/tGjCQqpGHgYbQg//gd7FcTogbF03aIsaeFGUtGuiH3hD0S2Ht KE+3rl+f0QtaHUjvVFujkTcX5THzl0jzkqKCjsoGPRX8OVZe2R+1gOx9tw7POkoHj+H7 kFDQ== 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=lMjECnk78jVepyfZjPNeyjoslg1YWp4I+90WokcicHc=; b=LQYkwnpfg5acLVMcml18GxxZU9P3dXh4oEl5PRAmtm1PGbV1B7Y2/gwNrslRoOYKwn wcgTHCDEQs5KUA/6DcN/3G+VUNnVjxsQCh0llf7PPTbsMpmoHiz4YchV3uISaaClMmtQ WXovipdhm5V/24rDfzWpKiFu3E8o9NOtiQDvoEOQ3H4/t4JNAEmAqUKDBd8x6zJr9m4c 2A/KmVYMQl1ki+GfFtvpOKlSQnXI2OWohPCqX97PaaQtkfjrnxiAFFughBV8u8Qb0FMg jOmV7jyekLKXb07zfG67QGa/rrOnZQaSE3qsZZSOc2m2unOjfw1YzPtJgn9VrPV2FtwC yjfA== X-Gm-Message-State: AOAM530fhSMBbxbA4R01bk32UvnON/bxT0q8b0F2nOB9OaGZIEQF1h/L nNaSnJMgJdJ80go272AW0AwLP5pxwRm7CeA3QwY= X-Google-Smtp-Source: ABdhPJzKAkChcKpqmWM9aofRGwiDUmQOrRzZfoLO+7Wu/UWskyA3lK/LBz0hkpAuoqr99ldzsnSvBSjCcd4ygJuR5HA= X-Received: by 2002:a05:6808:9b8:: with SMTP id e24mr1776459oig.97.1603376902616; Thu, 22 Oct 2020 07:28:22 -0700 (PDT) MIME-Version: 1.0 References: <160334506239.20395.15102292380884503313@ietfa.amsl.com> <34783E29-F267-4A58-9C3E-5CC2C0D93B49@fugue.com> In-Reply-To: <34783E29-F267-4A58-9C3E-5CC2C0D93B49@fugue.com> From: Erik Kline Date: Thu, 22 Oct 2020 07:28:12 -0700 Message-ID: To: Ted Lemon Cc: The IESG , V6Ops Chairs , v6ops list , draft-ietf-v6ops-cpe-slaac-renum@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [v6ops] Erik Kline's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS and COMMENT) 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, 22 Oct 2020 14:28:25 -0000 I agree. I just think then the text about "the lesser of two lifetime values" doesn't quite read correctly nor give the impression that this applies to things like ULA prefixes. I think it's probably pretty easy to fix with minimal text. On Thu, Oct 22, 2020 at 7:11 AM Ted Lemon wrote: > > I think it=E2=80=99s reasonable to assume that in some situations a ULA w= ill be generated and not remembered, or that the /48 will be remembered but= the subnetting will not be. E.g. this could happen in an HNCP-delegated ne= twork pretty easily. The set of behaviors we are seeing in existing border = routers fairly constrained with respect to what is theoretically possible a= nd even reasonable. So I don=E2=80=99t think there=E2=80=99s a good reason= to suggest different treatment for ULAs. > > > On Oct 22, 2020, at 01:37, Erik Kline via Datatracker wrote: > > > > =EF=BB=BFErik Kline has entered the following ballot position for > > draft-ietf-v6ops-cpe-slaac-renum-05: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > [ section 3.2 ] > > > > * I absolutely agree in principle at these other lifetimes should be up= dated > > to the shorter of the two applicable lifetimes, but I'm worried that t= his > > text is not sufficiently precise. Specifically, this recommendation o= nly > > applies to options that depend in any way on the change in the delegat= ed > > prefix, yes? Perhaps just this qualifier is sufficient? > > > > For example, none of these comparative lifetime recommendations apply = to > > a stable ULA for a router that meets requirements ULA-[1..5] and choos= es > > to advertise a ULA /48 RIO and maybe even a ULA DNS server, I think. > > > > That being said, should this document also be saying that the ULA-deri= ved > > options SHOULD prefer the ND_{P,V}_LIMIT lifetime values, in case a re= boot > > causes a new ULA to be generated (i.e. the one supposedly in stable st= orage > > is lost or otherwise unrecoverable)? > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > [[ comments ]] > > > > [ section 3.1 ] > > > > * With respect to the second bullet: the lifetimes need to be dynamical= ly > > *updateable*, not necessarily updated if, for example, the ND_{P,V}_LI= MIT > > values are always lower than the remaining PD lifetimes. In this situ= ation, > > the requirement is still that the lifetimes can be updated, but to the > > casual observer of the steady state the RA contents might appear stati= c > > (e.g., while the PD'd prefix is continuously renewed). > > > > Maybe there's no text required here, but I didn't want a reader to be = left > > with the impression that no two RAs could be identical > > > > > > [[ nits ]] > > > > [ section 3.3 ] > > > > * In the 2nd bullet's 2nd bullet (this might be easier if these lists w= ere > > numbered), it might be good to clarify that "the *deprecated* prefix c= an > > simply be advertised..." > > > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Oct 22 07:29:06 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 9C3863A0FC7; Thu, 22 Oct 2020 07:28:58 -0700 (PDT) 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.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160337693862.13087.13080264764759369992@ietfa.amsl.com> Date: Thu, 22 Oct 2020 07:28:58 -0700 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: Thu, 22 Oct 2020 14:29:05 -0000 IESG state changed: New State: IESG Evaluation::Revised I-D Needed (The previous state was IESG Evaluation) Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-v6ops-slaac-renum/ From nobody Thu Oct 22 07:35: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 6285D3A0EDF; Thu, 22 Oct 2020 07:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, 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 h804es5jv11c; Thu, 22 Oct 2020 07:35:52 -0700 (PDT) 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 30F3E3A0ED5; Thu, 22 Oct 2020 07:35:50 -0700 (PDT) Received: from [IPv6:2800:810:464:b9c:452e:36a3:27fd:8f9b] (unknown [IPv6:2800:810:464:b9c:452e:36a3:27fd:8f9b]) (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 8814D28151F; Thu, 22 Oct 2020 14:35:46 +0000 (UTC) To: Erik Kline , The IESG Cc: draft-ietf-v6ops-cpe-slaac-renum@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, Owen DeLong References: <160334506239.20395.15102292380884503313@ietfa.amsl.com> From: Fernando Gont Message-ID: <47621153-e87f-4d98-946c-45208580c24b@si6networks.com> Date: Thu, 22 Oct 2020 11:34:59 -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: <160334506239.20395.15102292380884503313@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [v6ops] Erik Kline's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS and COMMENT) 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, 22 Oct 2020 14:35:55 -0000 Hello, Erik, Thanks a lot for your comments! In-line.... On 22/10/20 02:37, Erik Kline via Datatracker wrote: [....]> ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > [ section 3.2 ] > > * I absolutely agree in principle at these other lifetimes should be updated > to the shorter of the two applicable lifetimes, but I'm worried that this > text is not sufficiently precise. Specifically, this recommendation only > applies to options that depend in any way on the change in the delegated > prefix, yes? I'd say it applies to options that depend on the delegated prefix or the existence of the router that advertised them (which in a way are intimately related). Local example at home: I recently installed a backup connection. Both of my ISPs do IPv6. Say I'm testing whether the setup works. I connect CPE1, connected to ISP1. Then Connect CPE2, connected to ISP2. Then unplug CPE1. What's the usefulness of the options advertised by CPE1 if the only thing I have is CPE2? (e.g., ISP1 might have ACLs that only allows subscribers of ISP1 to use its recursive servers). > Perhaps just this qualifier is sufficient? You mean the qualifier instead of spelling out the option names? Or are you suggesting to add this clarification in addition to spelling out the option names. (Adding the clarification, either in the second paragraph of Section 3.2, or as one of the bullets in the "RATIONALE" below would be useful. OTOH, replacing the list of options with this note probably wouldn't (since then we're throwing the problem at implementers, who now need to know the analysis themselves). > For example, none of these comparative lifetime recommendations apply to > a stable ULA for a router that meets requirements ULA-[1..5] and chooses > to advertise a ULA /48 RIO and maybe even a ULA DNS server, I think. I see your point. However, my next question would be: do ULA implementations behave in that way? (most (if not all) of the CPEs I've run into don't treat ULAs in any special way). And, what if (as you correctly noted in your review for the other companion document) you have two cascading routers, that do ULA+GUA, where the first router generates the /48 ULA, and the cascading one gets a leased ULA prefix from the former? And, besides, if the options are not refreshed, that's because the corresponding router is gone. So, in that case, you wouldn't have a router that forwards your packets. And, if nodes are on-link, why not use link-locals instead. > That being said, should this document also be saying that the ULA-derived > options SHOULD prefer the ND_{P,V}_LIMIT lifetime values, in case a reboot > causes a new ULA to be generated (i.e. the one supposedly in stable storage > is lost or otherwise unrecoverable)? At least in my mental model, that was implied (i.e., I don't think that ULAs are special in this respect, because of the reasons noted above). That said, are you suggesting that explicitly note this for ULA PIOs, or something else? (me thinking out loud: I realize that for the CE Router connecting to the ISP, ULAs are special case in the sense that they are being locally generated... and hence it would make sense to be explicit about that). Thoughts? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > [[ comments ]] > > [ section 3.1 ] > > * With respect to the second bullet: the lifetimes need to be dynamically > *updateable*, not necessarily updated if, for example, the ND_{P,V}_LIMIT > values are always lower than the remaining PD lifetimes. In this situation, > the requirement is still that the lifetimes can be updated, but to the > casual observer of the steady state the RA contents might appear static > (e.g., while the PD'd prefix is continuously renewed). > > Maybe there's no text required here, but I didn't want a reader to be left > with the impression that no two RAs could be identical Agreed. How about if we tweak the bullet as: * The lifetime values of prefixes advertised on the LAN-side via SLAAC must be dynamically updated (rather than static values), otherwise the advertised lifetimes would eventually span past the DHCPv6-PD lifetimes. In scenarios where the LAN-side configured option lifetimes (see Section 3.2 and Section 4) are always smaller than (or equal to) the remaining DHCPv6-PD lifetimes, the LAN-side option lifetimes will exhibit constant values. > > > [[ nits ]] > > [ section 3.3 ] > > * In the 2nd bullet's 2nd bullet (this might be easier if these lists were > numbered), Will do the symbols-> numbers . > it might be good to clarify that "the *deprecated* prefix can > simply be advertised..." Will do. 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 Oct 22 08:04:09 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 0E0873A10D2; Thu, 22 Oct 2020 08:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=UyzhMWgw; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=tmxdh0sQ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wr1hR65_v8XU; Thu, 22 Oct 2020 08:04:04 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 452483A10D9; Thu, 22 Oct 2020 08:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2722; q=dns/txt; s=iport; t=1603379044; x=1604588644; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NPj+l48bjcKN14ZilPWIE2M+aN9lxT6VKUijEhUxuW0=; b=UyzhMWgw8mhmIKP00uhcDnX2dlGtcHhIMHAEBWygpAVohzVchTDjlzfc lDeM/uNG6NscVNhqo6dxLDOKuD9YG9w5c7pCXSeQcF7lft8wjMxUDwL7/ z/FfhcuQRmo1Hnz+Rl77drtWeigIi0gcRUY6xFkSFpAtmnSL7FWuesY0I s=; X-IPAS-Result: =?us-ascii?q?A0AZCQBEnpFf/5ldJa1gHQEBAQEJARIBBQUBQIFPgVJRB?= =?us-ascii?q?4FJLyyEPINJA40pJooQjmqCUwNVCwEBAQ0BAS0CBAEBhEoCF4FyAiU4EwIDA?= =?us-ascii?q?QEBAwIDAQEBAQUBAQECAQYEbYVhDIVyAQEBBBIREQwBATcBCwQCAQgOAwMBA?= =?us-ascii?q?gECAiYCAgIfERUICAIEAQ0FIoMEgkwDLgGnbwKBOYhodoEygwQBAQWFAg0Lg?= =?us-ascii?q?hAJgQ4qgnKDcIZXG4FBP4ERJwwQgk0+ghpCBIFdgxczgiyQMYJnPaNgVAqCa?= =?us-ascii?q?pVsBIUJAx+hXo5XhGWNY5JUAgQCBAUCDgEBBYFrI4FXcBVlAYI+UBcCDY4fN?= =?us-ascii?q?4M6ilZ0AjYCBgEJAQEDCXyNTAEB?= IronPort-PHdr: =?us-ascii?q?9a23=3A6mbKwBfnJ0mnJkKjDH7upofplGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQAdfU7vtFj6zdtKWzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutaFjbo3n05jkXSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,404,1596499200"; d="scan'208";a="561491132" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Oct 2020 15:03:53 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 09MF3rfE030653 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 22 Oct 2020 15:03:53 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 22 Oct 2020 10:03:52 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 22 Oct 2020 10:03:52 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 22 Oct 2020 11:03:52 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WtcoHL8S4/MLqlrHtn81xIymLYgFxeqUP9Q0PWzobVBK1bl/e5hK3C9D0ZMi45m+ZbK56ArWuWKAm50L8yQRHRNiH/27lMdPJnmHL0NIwo1jz/Gp3IgpUaljR4PUUa5Q/IIm3PxC0T5OfNyFjxdeeo6hWYX5miizxzjX/J//JsddzF7S22is8ecSbyFvgAUyhsI+Zm5gkrXBSHhq1DlbXtknqRERDNfIvOtLEY/vR+893JZfw6Vk+TQxkG32bJskTKEdaajSu/F9W8jRblQlAZNFnookNwtLjQEN2zdWv8q7jvDJmlbZ7i90LTYWCJXy+Kayhx7t6VXPgCxktxIIww== 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=NPj+l48bjcKN14ZilPWIE2M+aN9lxT6VKUijEhUxuW0=; b=BpfoClzf6uhSPdPWdAGMEGrxA4vDAzJLMRdwQBPCrull4uvsnAK3QLlH/KVYQZ+KfuBdpdqlzhb7Uj47IHm2N71e2eBsVKsjFfvjYFCFekju/3SPiyjNLJjusLRk8AEPGVCsAp4tE3zrkrGgiWER9ntw1AtBw0GVpOhIq+l7Jwp7KuUA3Ny61la/HUwEaYu/PSHSmGbOhV2dZIVDBh/0tEADLQp+dL5234EoS0naRbPAneRvTo/6xIX7QTGojpfiRcSnzpZERMb5/y9pvQW+tOoBQ8lS2B+EhhQ4/w2247zjBr/dA/adn+gtCP/j/FuBw+gKMAOmelGxHqOvQVoOIw== 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=NPj+l48bjcKN14ZilPWIE2M+aN9lxT6VKUijEhUxuW0=; b=tmxdh0sQwJ/5yxqw5cuzIyGaZ4ig5sS61K0mDY7ZqEgZSeO73Va5EEUAYZNZ6eIcfZhtUegAqQ4QdDr9d8tiip/Wu7Z3Nq8Vc2m70ANHVty5wVQwDAog8pMOpbuaMnDGV9LsbHhY2QqSZpyTSqae5E36qgO+h+NFFpya3PhM4ow= Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB4776.namprd11.prod.outlook.com (2603:10b6:510:30::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.20; Thu, 22 Oct 2020 15:03:51 +0000 Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::453b:b2f5:ec29:410d]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::453b:b2f5:ec29:410d%7]) with mapi id 15.20.3499.018; Thu, 22 Oct 2020 15:03:51 +0000 From: "Eric Vyncke (evyncke)" To: Erik Kline , Lorenzo Colitti CC: Alissa Cooper , "v6ops@ietf.org WG" , "v6ops-ads@ietf.org" , V6Ops Chairs , "draft-ietf-v6ops-cpe-slaac-renum@ietf.org" , The IESG Thread-Topic: [v6ops] Alissa Cooper's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS) Thread-Index: AQHWqHWxsXy3v5ILPkGL2cjRYWIj26mjonKAgAAFm4CAADGnAA== Date: Thu, 22 Oct 2020 15:03:51 +0000 Message-ID: <9F483E75-4C33-4886-AE9F-D2DECDA529C0@cisco.com> References: <160337261986.9706.15256831018374618832@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.42.20101102 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:7548:2923:aba0:edcf] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fca1b0c0-5428-479a-52d7-08d8769bafb4 x-ms-traffictypediagnostic: PH0PR11MB4776: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: o7m0mdQfjNdwD541hXMnp/9y5RfMC3tBWGTk69Ol7/OCTKzByKFb7LbNis8GEuEgdYCb6V0e+6KAEoRfuz0aH7QJ2YKa7FnETmkZ36U0yKUG+Kc+cE056CxoS2iWpsJFXIMYNND1vNfPUvwTW2fhSsLUYFEml1+ZQQqTW5FUm+kIOhQl8ReRZZtGw361P9C4Kov5gS1OUHcBBOSZYSZW7vy/CcLUKmb2CGPh/vtZxm7Wb4fM3B03HQb4ExUZ9Nu/K6PwmRa8dY8A7MYTB7V9jWqcU4h16/0+3W1jKkIG2Osf16OIKrO05A7unVSXTIt9z0A+OsX3E6MM6w81mH9T7w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(396003)(346002)(136003)(376002)(366004)(2616005)(8936002)(6506007)(8676002)(110136005)(54906003)(53546011)(71200400001)(316002)(83380400001)(64756008)(66556008)(5660300002)(66946007)(66446008)(91956017)(478600001)(76116006)(33656002)(86362001)(6512007)(2906002)(186003)(66476007)(6486002)(36756003)(4326008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: bgfj2hJ3XQvBK1G39xqahAkuV8vz5psUKwJ7L8QXNbr3ZihLzkIMssLZgTkEr4tVAdOFveOH8Qm9ZdwkMmf68TS4573Xu6WbBGljJRXt65C8z1NUnEt86n3ld9BTRiam+3MchLwZahn4Ug7zzPBi1cmndsjaASm97a2q9NLC5LEYdOY5jOIqv1IckqGxPAFzIPycAv/VOKnyhjC1KizqGVus5dRvRjduueD+WdRD1m9gTl7Kk/nW0YnODpazVKv7sBFSPMKOkYm10C2Zu1ydZpYujjs1o4a1BPxnPhZYdJKeGp8Fb23f/4Nmf2eeYa8W3CD+jsQNNYfz27GzJ0Q/2Z9HoIQKwVLEkUUQ9Q3owOwKoCB9fsevtnz4BMatppKyPMN9QKTwOqcBVT+/t/W20rG2JFeA58AXxmnaGppL1jEjokOXjNTPCTeSyObPRQpyrxBdw1bHa0bOVln3XWAmIE44dAUMi3lE0p1GKGu+1epZcLE6Hh0tCTmdgMVKVgkvItbn1TaIHON7Y4kOf8/Zuw6mj2VUT7hJ+mSVT1oysNNGrNlgE20ace3tjsD4HwOxL9LwQchMwVJl+BYnCMvD16aJu0kM8tSbIEw1LQSsDC82PQK2dnnRz3aHej7UG4Wh89aCYF0j+zrWCsPtkJETI1pN0yEgtPLCGnvGDKofhzLjGW+CxToy6AAfeWRdNa/DlzhGwaNh5i64FMBvESm9Rg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <508B330A9A42CB49BF928E5B34281956@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fca1b0c0-5428-479a-52d7-08d8769bafb4 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2020 15:03:51.1848 (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: rqQlxAPjc7npifBtgr0hz+2yCx7aFn5q6V26jKLyqcxrhtWoWK7RXCM7E4QjJPjtsI55H2VFoXKMD55bdSEX3Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4776 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [v6ops] Alissa Cooper's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS) 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, 22 Oct 2020 15:04:08 -0000 U2FtZSBoZXJlOiBnb2luZyBCQ1Agc2hvdWxkIHNlbmQgdGhlIGRvY3VtZW50IGJhY2sgdG8gVjZP UFMsIHRoZSB0ZXh0IHF1YWxpdHkgY291bGQgYmUgaW1wcm92ZWQgYSBsb3QgYnkgcmVtb3Zpbmcg J2hhbmQgd2F2aW5nJyB0ZXh0cyB0aGF0IGFyZSBraW5kIG9mIE9LIGZvciBpbmZvcm1hdGlvbmFs IGJ1dCBub3QgZm9yIEJDUCBJTUhPLg0KDQotw6lyaWMgDQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBpZXNnIDxpZXNnLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBv ZiBFcmlrIEtsaW5lIDxlay5pZXRmQGdtYWlsLmNvbT4NCkRhdGU6IFRodXJzZGF5LCAyMiBPY3Rv YmVyIDIwMjAgYXQgMTY6MDcNClRvOiBMb3JlbnpvIENvbGl0dGkgPGxvcmVuem89NDBnb29nbGUu Y29tQGRtYXJjLmlldGYub3JnPg0KQ2M6IEFsaXNzYSBDb29wZXIgPGFsaXNzYUBjb29wZXJ3Lmlu PiwgInY2b3BzQGlldGYub3JnIFdHIiA8djZvcHNAaWV0Zi5vcmc+LCAidjZvcHMtYWRzQGlldGYu b3JnIiA8djZvcHMtYWRzQGlldGYub3JnPiwgVjZPcHMgQ2hhaXJzIDx2Nm9wcy1jaGFpcnNAaWV0 Zi5vcmc+LCAiZHJhZnQtaWV0Zi12Nm9wcy1jcGUtc2xhYWMtcmVudW1AaWV0Zi5vcmciIDxkcmFm dC1pZXRmLXY2b3BzLWNwZS1zbGFhYy1yZW51bUBpZXRmLm9yZz4sIFRoZSBJRVNHIDxpZXNnQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFt2Nm9wc10gQWxpc3NhIENvb3BlcidzIERpc2N1c3Mgb24g ZHJhZnQtaWV0Zi12Nm9wcy1jcGUtc2xhYWMtcmVudW0tMDU6ICh3aXRoIERJU0NVU1MpDQoNCiAg ICBPbiBUaHUsIE9jdCAyMiwgMjAyMCBhdCA2OjQ2IEFNIExvcmVuem8gQ29saXR0aQ0KICAgIDxs b3JlbnpvPTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQogICAgPg0KICAgID4g T24gVGh1LCBPY3QgMjIsIDIwMjAgYXQgMTA6MTcgUE0gQWxpc3NhIENvb3BlciB2aWEgRGF0YXRy YWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc+IHdyb3RlOg0KICAgID4+DQogICAgPj4gQWxpc3NhIENv b3BlciBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3INCiAgICA+ PiBkcmFmdC1pZXRmLXY2b3BzLWNwZS1zbGFhYy1yZW51bS0wNTogRGlzY3Vzcw0KICAgID4+IFsu Li5dDQogICAgPj4gRElTQ1VTUzoNCiAgICA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPj4NCiAgICA+ PiBMZXQncyByZXNvbHZlIHRoZSBkb2N1bWVudCBzdGF0dXMgaXNzdWUgLS0gaXQgd2FzIGxhc3Qt Y2FsbGVkIGFzIFByb3Bvc2VkDQogICAgPj4gU3RhbmRhcmQsIGl0J3MgbGlzdGVkIGFzIEluZm9y bWF0aW9uYWwsIGJ1dCBpdCBzZWVtcyBsaWtlIGl0IHNob3VsZCBiZSBhIEJDUC4NCiAgICA+Pg0K ICAgID4+IEkgc3VwcG9ydCBSb2IncyBESVNDVVNTIGFuZCBJIGJlbGlldmUgdGhlIFJGQyA4MTc0 IGJvaWxlcnBsYXRlIHNob3VsZCBiZSB1c2VkLg0KICAgID4NCiAgICA+DQogICAgPiBJIGRvbid0 IHRoaW5rIHRoaXMgc2hvdWxkIGJlIGNsYXNzaWZpZWQgYXMgQkNQIHdpdGhvdXQgc2VuZGluZyBp dCB0byB0aGUgV0cgZm9yIGFub3RoZXIgbG9vay4gV0cgY29uc2Vuc3VzIHdhcyByZWFjaGVkIG9u IHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlIGludGVuZGVkIHN0YXR1cyB3YXMgaW5mb3JtYXRpb25h bC4gSSBzdXNwZWN0IG1hbnkgV0cgcGFydGljaXBhbnRzIHdvdWxkIGhhdmUgbG9va2VkIGF0IHRo ZSB0ZXh0IHdpdGggZGlmZmVyZW50IGV5ZXMsIGFuZCBoZWxkIGl0IHRvIGEgZGlmZmVyZW50L2hp Z2hlciBzdGFuZGFyZCwgaWYgdGhlIGludGVuZGVkIHN0YXR1cyBoYWQgYmVlbiBCQ1AuIEkga25v dyBmb3Igc3VyZSB0aGF0IEkgd291bGQgaGF2ZS4NCg0KICAgIFRoaXMgKHJ1bm5pbmcgYnkgdGhl IHdnIGFnYWluKSBzZWVtcyBlbnRpcmVseSByZWFzb25hYmxlIHRvIG1lLg0KDQoNCg== From nobody Thu Oct 22 08:20: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 9F8EB3A1047; Thu, 22 Oct 2020 08:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, 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 UbIonHICZhdz; Thu, 22 Oct 2020 08:20:48 -0700 (PDT) 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 C39A93A0957; Thu, 22 Oct 2020 08:20:43 -0700 (PDT) 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 1C9ED280D45; Thu, 22 Oct 2020 15:20:38 +0000 (UTC) To: Erik Kline , Ted Lemon Cc: The IESG , V6Ops Chairs , v6ops list , draft-ietf-v6ops-cpe-slaac-renum@ietf.org References: <160334506239.20395.15102292380884503313@ietfa.amsl.com> <34783E29-F267-4A58-9C3E-5CC2C0D93B49@fugue.com> From: Fernando Gont Message-ID: <4d07f3a5-192b-fcd9-a8b6-28e2d2b4d8fd@si6networks.com> Date: Thu, 22 Oct 2020 12:19:10 -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] Erik Kline's Discuss on draft-ietf-v6ops-cpe-slaac-renum-05: (with DISCUSS and COMMENT) 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, 22 Oct 2020 15:20:51 -0000 On 22/10/20 11:28, Erik Kline wrote: > I agree. I just think then the text about "the lesser of two lifetime > values" doesn't quite read correctly nor give the impression that this > applies to things like ULA prefixes. I think it's probably pretty > easy to fix with minimal text. My shot at it: At the end of this: CE routers SHOULD set the Router Lifetime to ND_PREFERRED_LIMIT. CE routers SHOULD also set the PIO Preferred Lifetime to the lesser of the remaining preferred lifetime (see Section 3.1) and ND_PREFERRED_LIMIT, and the PIO Valid Lifetime to the lesser of the remaining valid lifetime and ND_VALID_LIMIT. Add: "If a ULA prefix is locally generated as specified in [RFC4193] and advertised on the LAN-side via PIO options, the corresponding PIO Preferred Lifetime and Valid Lifetime SHOULD be set to ND_PREFERRED_LIMIT and ND_VALID_LIMIT, respectively." At the end of: CE Routers providing stateful address configuration via DHCPv6 SHOULD set the DHCPv6 IA Address Option preferred-lifetime to the lesser of the remaining preferred lifetime and ND_PREFERRED_LIMIT, and the valid-lifetime of the same option to the lesser of the remaining valid lifetime and ND_VALID_LIMIT. Add: "If a ULA prefix is locally generated as specified in [RFC4193] and employed for stateful address configuration via DHCPv6, the corresponding DHCPv6 IA Address Option preferred-lifetime and valid-lifetime SHOULD be set to ND_PREFERRED_LIMIT and ND_VALID_LIMIT, respectively. Finally, for the DHCPv6-PD case, at the end of: CE Routers providing DHCPv6-PD on the LAN-side SHOULD set the DHCPv6 IA Prefix Option preferred-lifetime to the lesser of the remaining preferred lifetime and ND_PREFERRED_LIMIT, and the valid-lifetime of the same option to the lesser of the remaining valid lifetime and ND_VALID_LIMIT. Add: "If a ULA prefix is locally generated as specified in [RFC4193] and the CE Router provides DHCPv6-PD on the LAN-side, it SHOULD set the DHCPv6 IA Prefix Option preferred-lifetime to ND_PREFERRED_LIMIT, and the valid-lifetime of the same option to ND_VALID_LIMIT." Thoughts? P.S.: Bottom-line is that this is only special for ULA prefixes that are *locally* generated, since in that case there's only one lifetime involved (no "lifetimes" from the upstream). Thanks, Fernando > > On Thu, Oct 22, 2020 at 7:11 AM Ted Lemon wrote: >> >> I think it’s reasonable to assume that in some situations a ULA will be generated and not remembered, or that the /48 will be remembered but the subnetting will not be. E.g. this could happen in an HNCP-delegated network pretty easily. The set of behaviors we are seeing in existing border routers fairly constrained with respect to what is theoretically possible and even reasonable. So I don’t think there’s a good reason to suggest different treatment for ULAs. >> >>> On Oct 22, 2020, at 01:37, Erik Kline via Datatracker wrote: >>> >>> Erik Kline has entered the following ballot position for >>> draft-ietf-v6ops-cpe-slaac-renum-05: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> [ section 3.2 ] >>> >>> * I absolutely agree in principle at these other lifetimes should be updated >>> to the shorter of the two applicable lifetimes, but I'm worried that this >>> text is not sufficiently precise. Specifically, this recommendation only >>> applies to options that depend in any way on the change in the delegated >>> prefix, yes? Perhaps just this qualifier is sufficient? >>> >>> For example, none of these comparative lifetime recommendations apply to >>> a stable ULA for a router that meets requirements ULA-[1..5] and chooses >>> to advertise a ULA /48 RIO and maybe even a ULA DNS server, I think. >>> >>> That being said, should this document also be saying that the ULA-derived >>> options SHOULD prefer the ND_{P,V}_LIMIT lifetime values, in case a reboot >>> causes a new ULA to be generated (i.e. the one supposedly in stable storage >>> is lost or otherwise unrecoverable)? >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> [[ comments ]] >>> >>> [ section 3.1 ] >>> >>> * With respect to the second bullet: the lifetimes need to be dynamically >>> *updateable*, not necessarily updated if, for example, the ND_{P,V}_LIMIT >>> values are always lower than the remaining PD lifetimes. In this situation, >>> the requirement is still that the lifetimes can be updated, but to the >>> casual observer of the steady state the RA contents might appear static >>> (e.g., while the PD'd prefix is continuously renewed). >>> >>> Maybe there's no text required here, but I didn't want a reader to be left >>> with the impression that no two RAs could be identical >>> >>> >>> [[ nits ]] >>> >>> [ section 3.3 ] >>> >>> * In the 2nd bullet's 2nd bullet (this might be easier if these lists were >>> numbered), it might be good to clarify that "the *deprecated* prefix can >>> simply be advertised..." >>> >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Oct 22 08:54: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 0C2E83A00D9 for ; Thu, 22 Oct 2020 08:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_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=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 qN9dMM5nB_j9 for ; Thu, 22 Oct 2020 08:54:39 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AF5E3A00D2 for ; Thu, 22 Oct 2020 08:54:39 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id h6so2891949lfj.3 for ; Thu, 22 Oct 2020 08:54:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=lq4ZaH3UuTFieq1FCRHGcFznOXuCSr+2EiB/02SoTy0=; b=p6507q3qwfIMLHTcUj+p6tr88fOvVU0z0F8hZo/LO57FN7X7p5D9iZoMgjiJBcuNeC /LeazhIVGQAWkit/IOZwJ18qdiZeKjWZYlC1rLswW0q8VQNjiV3VscyaOSBZZP9wrQvw 5LscMZm/U+Ysm+ztWG5OPNOYCA34YMZ8MC7aAxrjSkWap6+W2BsXS0L5i5qMNJCKs9c1 Zn5KtzbrRwGJZcGeqXT0VLx2n9zT2SZSycY7JQeO34lXtcnyQccgPQLWuS7Symq9TB1c Lea3bmiYA5ArghU9xlmw+QLUSUgyTN1UuAkAQy77RcvtJjxrhKaIljP3n070hH5KzamG Apsg== 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=lq4ZaH3UuTFieq1FCRHGcFznOXuCSr+2EiB/02SoTy0=; b=g0VpHY8NZLv9XC/gACM9z/eCHxk4o+nd0lQfffPcR2II39SsgNWC3xa0FvNawkmS6z 6yYsn1x5JA0u5uuGLTJBUFnwH2LVR5I/DPwkOHjiU0t9bFA2omxAleRoA6gE3oMmLFuW 7kdGsFvv0F7OpiohBxSknSDuecVhTWyXTCgbjqNW6imZdWdm6+F63v3W9TTL0xnXXgyf ungDxl3Ae/cYkuZhtm7oeWdfTDzisSBZPRgCzyov72BH7f1dh02CtWQyJCxxR8nYR0kx t511NHSU6Ik85bN8W5EswWGcKfQaPyypMUTfEFWIFXBzuLydX946BAAOeIajVWb4A11E StNQ== X-Gm-Message-State: AOAM5326sT7mWtQXK/cMp/zeGqMdD/tgo0Tt1TdqEI86JQbtRTeexaMD SRRkNKem8vSmg2/MToFRRC+ZTA8J8rHGSDGGPfXrZmeYgcQ89gHj X-Google-Smtp-Source: ABdhPJzZ9iBhQQjZOozfyih9NzKhEvmmq2SbtfcPSMjfMKw5OoXSl3kAGjqJjOJevHa/wtA+TCCQRHnwxynZOSoha+8= X-Received: by 2002:ac2:5dd5:: with SMTP id x21mr1023617lfq.41.1603382075674; Thu, 22 Oct 2020 08:54:35 -0700 (PDT) MIME-Version: 1.0 From: Warren Kumari Date: Thu, 22 Oct 2020 11:53:59 -0400 Message-ID: To: IPv6 Operations , Fernando Gont , "Rob Wilton (rwilton)" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [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: Thu, 22 Oct 2020 15:54:41 -0000 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 Thu Oct 22 09:19: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 38DB13A07DB; Thu, 22 Oct 2020 09:19:01 -0700 (PDT) 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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 imfuvC5BO6qZ; Thu, 22 Oct 2020 09:18:59 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 7E5FF3A03EC; Thu, 22 Oct 2020 09:18:59 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09MGIgA7011161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 22 Oct 2020 12:18:51 -0400 Date: Thu, 22 Oct 2020 09:18:42 -0700 From: Benjamin Kaduk To: Fernando Gont Cc: The IESG , draft-ietf-v6ops-cpe-slaac-renum@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, Owen DeLong Message-ID: <20201022161842.GF39170@kduck.mit.edu> References: <160325603610.17357.6914550111489766157@ietfa.amsl.com> <58f8bb8c-55b8-f0dd-2b6e-4d15f37b144e@si6networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58f8bb8c-55b8-f0dd-2b6e-4d15f37b144e@si6networks.com> Archived-At: Subject: Re: [v6ops] Benjamin Kaduk's No Objection on draft-ietf-v6ops-cpe-slaac-renum-05: (with COMMENT) 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, 22 Oct 2020 16:19:01 -0000 On Wed, Oct 21, 2020 at 03:59:28AM -0300, Fernando Gont wrote: > Hello, Ben, > > On 21/10/20 01:53, Benjamin Kaduk via Datatracker wrote: > [....] > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I am not sure that we should avoid having the conversation about > > intended status; consider, for example, "CE Routers SHOULD override the > > default [...] values from [RFC4861]" (RFC 4861 is a Draft Standard). (The > > question was raised in the genart review thread by virtue of skew between > > the datatracker state and the document header, but it looks like the WG chair > > changed the status in the datatracker and there was no further discussion of > > the topic on the list.) > > FWIW, the "Intended status" in the datatracker was simply an error. -- > the document has always targeted "Informational", since the document it > is updating is also Informational. Fair enough. That document looks like it might be better as a BCP, though :) Anyway, I chose to not ballot Discuss on this topic (but Alissa did), so probably the discussion on this topic should not happen in this thread. > My understanding is that [RFC4861] specifies a default value for some > parameters, which are not necessarily the "recommended" values. > > For the most part, this document follows the style and track of RFC7084. > > > > > The diff between Abstract and Introduction is interesting: there is a > > parenthetical "(such as when a Customer Edge Router crashes and reboots > > without knowledge of the previously-employed configuration information)" > > only in the abstract that might also be useful in the introduction, and > > the abstract uses 'hosts' where the introduction uses 'nodes'. (There > > are a couple other incidental wording differences that the authors might > > wish to consider normalizing on one wording for, as well as the expected > > additional text in the introduction that is not appropriate for an > > abstract.) > > Will do. > > > > > > Section 2 > > > > purpose of establishing industry-common baseline functionality. As > > such, the document points to several other specifications (preferable > > in RFC or stable form) to provide additional guidance to implementers > > > > I'm not sure that there's value in saying "preferable" [sic] in the > > final RFC; it's not like there would be a further chance to change the > > reference to have such a property anymore. > > I think we should s/preferable/preferably/. That said, what the document > means is that in these cases, other documents such as e.g. RIPE BCOPs > might be referenced. > > > > > > > Section 3.1 > > > > This means that > > the advertised "Preferred Lifetime" and "Valid Lifetime" MUST be > > dynamically adjusted such that they never span past the remaining > > preferred and valid lifetimes of the corresponding prefixes delegated > > via DHCPv6-PD on the WAN-side. > > > > (nitty/editorial) Perhaps it is obvious to most readers, but perhaps it > > is not universally clear that the "advertised" part refers to > > "advertised by the CPE in SLAAC PIOs"; if I wanted to reword to remove > > ambiguity, I might go with something like 'This means that the > > "Preferred Lifetime" and "Valid Lifetime" advertised in PIOs by the CE > > router MUST be dynamically adjusted [...]'. > > The next paragraph (for the DHCPv6 case) uses a similar wording, but the > > first paragraph of that sentence is a bit more clear about "employed > > with DHCPv6 on the LAN-side" that also serves to reduce the potential > > ambiguity. I'm happy to see or propose a similar rewording for the > > DHCPv6 case if that would be useful, but don't mind if we leave both > > paragraphs unchnaged, either. > > If you think such changes would improve the document, please feel free > to propose tweaks/text. (Thanks!) My recommendation is for the first paragraph to change to have 'This meanas that the "Preferred Lifetime" and "Valid Lifetime" advertised on the LAN-side MUST be dynamically adjusted [...]', to give the two paragraphs a (relatively) parallel structure. > > > > CE Routers providing stateful address configuration via DHCPv6 SHOULD > > set the DHCPv6 IA Address Option preferred-lifetime to the lesser of > > the remaining preferred lifetime and ND_PREFERRED_LIMIT, and the > > valid-lifetime of the same option to the lesser of the remaining > > valid lifetime and ND_VALID_LIMIT. > > > > Is it worth mentioning that ND_PREFERRED_LIMIT and ND_VALID_LIMIT are > > defined in Section 4? > > I wouldn't mind noting that if you think that would improve the > document. In such case, how about adding > > NOTE: > ND_PREFERRED_LIMIT and ND_VALID_LIMIT are defined in Sectonn 4 > of this document. > > > ? Sounds good; thanks. > > > > > > Section 3.2 > > > > * CE Routers need not employ the (possibly long) DHCPv6-PD > > lifetimes for the Valid Lifetime and Preferred Lifetime of PIOs > > > > (nit) do we want "received" in there anywhere (e.g., "received DHCPv6-PD > > lifetimes")? > > Will do. > > > > > * Similarly, CE Routers need not employ the (possibly long) > > DHCPv6-PD lifetimes for the valid-lifetime and preferred- > > > > (Likewise, we could use "received" or "WAN-side" here.) > > Will do. > > > > > Section 3.3 > > > > In order to phase-out stale SLAAC configuration information: > > [...] > > If a CE Router provides LAN-side DHCPv6 (address assignment or prefix > > delegation), then: > > [...] > > > > (editorial) Can/should these sentences use a parallel structure (e.g., > > "If a CE Router provides SLAAC configuration information, then [...]")? > > It is assumed that all CE Routers provide SLAAC configuration > information, since it's the only mandatory mechanism for doing so > (DHCPv6 is optional). Okay; thanks for the reminder about SLAAC being mandatory. > > * In Replies to DHCPv6 Request, Renew, Rebind messages, send 0 > > lifetimes for any address assignments or prefix delegations for > > the deprecated prefixes for at least the valid-lifetime > > previously employed for them, or for a period of ND_VALID_LIMIT > > if the recommended lifetimes from Section 3.2 are employed. > > > > Is it deliberate to say nothing at all about Advertise messages (which > > are sent in response to Solicit messages, not any of the listed ones)? > > Unless I'm missing something: yes, that's deliberate. Essentially, what > we are saying is that messages that can convey lease information should > advertise the stale prefix as stale. (Advertise messages do not convey > that kind of information). Okay. I tried to look through RFC 8415 to see whether they did, and didn't find a clear answer in the time alloted, so I asked. > > > > * The requirement in this section is conveyed as a "SHOULD" (as > > opposed to a "MUST"), since we acknowledge that the requirement > > to store information on stable storage may represent a > > challenge for some implementations. > > > > (editorial/style) It's not entirely clear that we gain much from the use > > of the first person, here. E.g., we could say 'conveyed as a "SHOULD" > > (as opposed to a "MUST"), since the requirement to store information on > > stable storage may represent a challenge for some implementations'. > > Will apply the suggested edit. (Thanks!). > > > > > Section 6 > > > > I suggest noting that the security considerations from RFC 7084 continue > > to apply. (Also, basically the same comment I had for > > draft-ietf-v6ops-slaac-renum applies, which still does not imply any > > changes to the text.) > > Would tweaking the last sentence of the Security Considerations as: > "It does not introduce new security issues, and therefore the security > considerations for [RFC7084] also apply to this document." > > address this? Yes; thanks. > > > Section 8.1 > > > > Since we say that we are *not* using the BCP 14 keywords in the sense of > > RFC 2119, it does not seem that RFC 2119 needs to be a normative > > reference. > > Fair enough. Will move RFC2119 to the Informational references. (I guess this may become irrelevant in light of the other ballot threads.) > > Section 8.2 > > > > It would feel more natural, at least to me, if RFC 7084 was listed as a > > normative reference. (In the sense that we are Updating it to make > > incremental additions, but you need the whole combined assembly of both > > documents in order to have a functional setup.) > > Agreed. Will do. Thanks! -Ben From nobody Thu Oct 22 09:47: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 AABBB3A0898; Thu, 22 Oct 2020 09:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.146 X-Spam-Level: X-Spam-Status: No, score=-2.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, 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 N6n3mxPa-XPt; Thu, 22 Oct 2020 09:47:06 -0700 (PDT) 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 F01673A0874; Thu, 22 Oct 2020 09:47:05 -0700 (PDT) Received: from [IPv6:2800:810:464:b9c:452e:36a3:27fd:8f9b] (unknown [IPv6:2800:810:464:b9c:452e:36a3:27fd:8f9b]) (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 4EF43283A26; Thu, 22 Oct 2020 16:47:01 +0000 (UTC) To: =?UTF-8?Q?=c3=89ric_Vyncke?= , The IESG Cc: draft-ietf-v6ops-slaac-renum@ietf.org, v6ops-chairs@ietf.org, v6ops@ietf.org, Owen DeLong , jiangsheng@huawei.com, mellon@fugue.com References: <160336150623.22400.9696222623015648417@ietfa.amsl.com> From: Fernando Gont Message-ID: <86223251-2455-b57a-3ea7-cd1d4e27fee4@si6networks.com> Date: Thu, 22 Oct 2020 13:43:09 -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: <160336150623.22400.9696222623015648417@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [v6ops] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-v6ops-slaac-renum-04=3A_=28with_COMMENT=29?= 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, 22 Oct 2020 16:47:10 -0000 Hello, Eric, Thanks so much for your comments! In-line.... On 22/10/20 07:11, Éric Vyncke via Datatracker wrote: [....] > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the work put into this document. It is easy to read but errs > sometimes on the anecdotes side rather than on the facts side (except for > Jordi's survey). As discussed before, I personaly wonder whether it is a real > problem for the IETF: it is largely about CPE/node implementation issues and > not a protocol one (even if I agree that the RFC 4861 default timers were badly > chosen 20 years ago). As noted in the introduction, I believe this both an operational and a protocol related problem. One of the many reasons for which you may experience this is related to CPEs -- but that's not the only one. There are also operational scenarios that lead to the same problem. There's also a protocol robustness problem: the default timers in RFC4861 means that as soon as something happens out of plans, you have a long outage. The protocol itself should be more robust in that respect. > > Please find below a couple of non-blocking COMMENT points and one nit but > please also check: - Ted Lemon's IoT directorate review with his note about > sleeping devices and time-outs: > https://datatracker.ietf.org/doc/review-ietf-v6ops-slaac-renum-04-iotdir-telechat-lemon-2020-10-19/ > - Sheng Jiang's Internet directorate review: > https://datatracker.ietf.org/doc/review-ietf-v6ops-slaac-renum-04-intdir-telechat-jiang-2020-10-19/ FWIW, we're working on these. > == COMMENTS == > > -- Section 1 -- > "for an unacceptably long period of time, thus resulting in connectivity > problems." while the 'long period of time" is explained in the end of this > section, giving a hint would help the reader to appreciate the problem. I found > this introduction rather qualitative than quantitative. How about adding "(more than one week)"? > "it is not an unusual behavior" may be... but, documenting (OS versions, > specific use cases) would make this argument stronger. OpenBSD's implementation seems one case. See e.g.: https://marc.info/?l=openbsd-misc&m=160243530006001&w=2 [...] > "there has been evidence that some 802.1x supplicants do not reset network > settings after successful 802.1x authentication." this is a very outdated > behavior of Windows if not mistaken and fixed years ago. In all cases, > documenting (OS version, specific case) would make this argument stronger. Will try to find out. This had been reported by Jen. > "Lacking any explicit signaling to deprecate the previously-advertised > prefixes", as the explicit mechanism exists, I suggest to s/explicit/reliable/ What we meant here is that the signaling doesn't take place. So yes, we'd hope for reliable signaling of this condition. BUt there's no signaling at all. > "because of egress-filtering by the CPE or ISP" or is it ingress-filtering when > packets are sourced by an 'internal' host ? I guess it's in the eyes of the observer? :-) e.g., my CPE might filter on egress, and my ISP could filter on ingress from me. > "or routed elsewhere" I wonder how a packet could be routed elsewhere if the > source address is wrong. Policy-based routing ? Suggest to remove those words. What we meant was "... or the return traffic being discarded or routed elsewhere". > -- Section 2.1 -- > Jordi's survey (a good one) does not say how often and how planned are those > prefix changes? My own /48 is not 'stable per contract' but has been stable for > 7 years (as long as the BNG does not change it will stay the same as AAA & DHCP > are linked together at my ISP). So, the 37% is probably not meaning that 37% of > the CPE are changing of prefix everyday. No. But when the change happens, you may experience the problem. At least for me, whether that's once a day, once a week, or once a month, still means there's a problem. > Did the authors check with the German ISP? AFAIK, the default policy has > changed. FWIW, BFDI seems to me a government organization, rather than an ISP. > Suggest to change the reference from RFC 4941 to the -bis document that is in > the same IESG telechat (so will not cause delay in the publication of this > document). Wouldn't this actually be the other way around? If we reference a draft, some might want to the draft to be published as RFC before progressing this one.... > -- Section 2.3 -- > No reply required but I find the last part of this section quite smart. I would > not have thought about this corner case ;-) :-) > -- Section 2.5 -- > "Not unusually, the two protocols are implemented in two different", I am > afraid that this is again 'anecdote' and not 'facts'. Citing implementations > details would make this statement stronger. Example: Linux radvd(8) does not do DHCPv6-PD. OpenBSD rad() does not do DHCPv6-PD, either. In fact, the only one that I can think of that does both is dhcpcd. > -- Section 3 -- > To be honest, I was about to ballot a DISCUSS on this section as I think that > there could be other mitigation techniques. E.g., the ISP could advertise 2 > prefixes by DHCP-PD for a while (would need to re-read DHCPv6 to be sure) > allowing an easier roll-over of the prefixes (esp. when planned prefix change). > Or possibly remove completely this section as 3.1 obvious and it is not > exhaustive. IIRC, the procedure to do graceful renumbering in dhcpv6 is largely unspecified. That said, if RECONFIGURE is nto supported, then you need to wait for the clients to contact the server -- which is not a lot different than simply waiting for the prefixes to expire. Note: I'm not a fan myself of Section 3.1 as a mitigation. But rather this was a result of what some part of the wg sees as a way to avoid the problem. > > -- Section 3.2 -- > While I agree that the default timers are wrong and that the suggested values > are way better, this is a change in the CPE doing SLAAC and not in operator > settings (or did I badly understood 'operator' as 'network operator' in the > sense of ISP as opposed as residential user?). Here we're talking about any routers, and not necessarily just the CPE. > Is the same technique also > described in the SLAAC CPE document ? Yes. > > == NITS == > > -- Section 3.2 -- > The use of () in the first paragraph renders it difficult to parse. Consider > rewriting it. How about: An operator may wish to override some SLAAC default lifetimes such that, under normal circumstances, the associated timers will be refreshed/reset by local routers but, in the presence of network faults, the corresponding information will be phased out in a timelier manner. ? 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 Oct 22 12:25: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 9B3073A0B58 for ; Thu, 22 Oct 2020 12:25:06 -0700 (PDT) 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 shoqXmxl7yyp for ; Thu, 22 Oct 2020 12:25:05 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5510B3A0B08 for ; Thu, 22 Oct 2020 12:25:05 -0700 (PDT) Received: from astfgl.hanazo.no (unknown [IPv6:2a01:79c:cebd:9724:2d6b:2bad:a6eb:d06b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 75B504E128C5; Thu, 22 Oct 2020 19:25:04 +0000 (UTC) Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id B0BE442190D0; Thu, 22 Oct 2020 21:24:57 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: otroan@employees.org In-Reply-To: Date: Thu, 22 Oct 2020 21:24:57 +0200 Cc: IPv6 Operations , Fernando Gont , "Rob Wilton (rwilton)" Content-Transfer-Encoding: quoted-printable Message-Id: <46512217-610D-4CD4-A3F4-D7589D537A54@employees.org> References: To: Warren Kumari X-Mailer: Apple Mail (2.3608.120.23.2.4) 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: Thu, 22 Oct 2020 19:25:07 -0000 I object. Both to s/Informational/BCP and to the change of 2119 language. This document is part of a series, 6204, 7084, which are more like = procurement documents than protocol specifications. There are quite a lot of disagreement with regards to this practice, = while you could perhaps claim this was a CPE BCP in reaction to an SP = WCP. If the IESG doesn't want this published in it's current form I would = prefer it was sent back to the wg for a respin. Ole > On 22 Oct 2020, at 17:53, Warren Kumari wrote: >=20 > Hi all, >=20 > draft-ietf-v6ops-cpe-slaac-renum-05 was on today's telechat, and ran > into issues. >=20 > 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. >=20 > I proposed that we change the status to BCP, and that the terms be > used in the normal manner. >=20 > I'd like to give the WG 2 weeks to object to this proposal, and, if > none received, start another IETF LC as BCP. >=20 > 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**. >=20 >=20 > W >=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 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Oct 22 13:28: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 B0CDD3A0ECB for ; Thu, 22 Oct 2020 13:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.342 X-Spam-Level: X-Spam-Status: No, score=-1.342 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.247, RDNS_NONE=0.793, 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 B3sGDj3UooqZ for ; Thu, 22 Oct 2020 13:28:35 -0700 (PDT) Received: from fgont.go6lab.si (unknown [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 D67B03A0ECA for ; Thu, 22 Oct 2020 13:28:28 -0700 (PDT) Received: from [IPv6:2800:810:464:b9c:3814:f192:8491:1ea] (unknown [IPv6:2800:810:464:b9c:3814:f192:8491:1ea]) (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 1696B280285; Thu, 22 Oct 2020 20:28:21 +0000 (UTC) To: otroan@employees.org, Warren Kumari Cc: IPv6 Operations , "Rob Wilton (rwilton)" References: <46512217-610D-4CD4-A3F4-D7589D537A54@employees.org> From: Fernando Gont Message-ID: Date: Thu, 22 Oct 2020 17:28:10 -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: <46512217-610D-4CD4-A3F4-D7589D537A54@employees.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Thu, 22 Oct 2020 20:28:38 -0000 Hi, Ole, On 22/10/20 16:24, otroan@employees.org wrote: > I object. Both to s/Informational/BCP and to the change of 2119 > language. > > This document is part of a series, 6204, 7084, which are more like > procurement documents than protocol specifications. I don't see how this document (or 6204 or 7084) can be seen as procurement documents. Actually, they pretty much look like protocol specifications, and in many cases could even be protocol specs. For example, I just opened one random document from the list you provided, and looked at some random text. Found this: WPD-7: If the IPv6 CE router requests both an IA_NA and an IA_PD option in DHCPv6, it MUST accept an IA_PD option in DHCPv6 Advertise/Reply messages, even if the message does not contain any addresses. This kind of thing could easily be part of the DHCPv6 spec. So I fail to see why you argue that these look like procurement documents. That said, this present document is not part of any series (or well, only part of the *slaac-renum* series). So I'm not sure why a decision on this document should consider whatever discussion was had, at a different point in time, on other documents. [...] > If the IESG doesn't want this published in it's current form I would > prefer it was sent back to the wg for a respin. A respin for what? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Oct 23 14:16:21 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 C08D83A0B21; Fri, 23 Oct 2020 14:15:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: v6ops@ietf.org, warren@kumari.net X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160348774476.5087.14120480502097534270@ietfa.amsl.com> Date: Fri, 23 Oct 2020 14:15:44 -0700 Archived-At: Subject: [v6ops] v6ops - Requested session has been scheduled for IETF 109 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, 23 Oct 2020 21:15:47 -0000 Dear Fred Baker, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. v6ops Session 1 (2:00 requested) Thursday, 19 November 2020, Session III 1600-1800 Room Name: Room 4 size: 504 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/109/sessions/v6ops.ics Request Information: --------------------------------------------------------- Working Group Name: IPv6 Operations Area Name: Operations and Management Area Session Requester: Fred Baker Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: Chair Conflict: spring lsr 6man intarea idr Key Participant Conflict: rtgwg tsvarea panrg grow tsvwg People who must be present: Fred Baker Ron Bonica Warren "Ace" Kumari Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Oct 26 03:03:37 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 E919E3A1A56 for ; Mon, 26 Oct 2020 03:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 Xj88hBbbVvPi for ; Mon, 26 Oct 2020 03:03:30 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 917A93A1A58 for ; Mon, 26 Oct 2020 03:03:30 -0700 (PDT) Received: from lhreml736-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 8FEDBD5F909FB0AEF4B4 for ; Mon, 26 Oct 2020 10:03:27 +0000 (GMT) Received: from msceml702-chm.china.huawei.com (10.219.141.160) by lhreml736-chm.china.huawei.com (10.201.108.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 26 Oct 2020 10:03:27 +0000 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml702-chm.china.huawei.com (10.219.141.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 26 Oct 2020 13:03:26 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Mon, 26 Oct 2020 13:03:26 +0300 From: Vasilenko Eduard To: IPv6 Operations Thread-Topic: draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance Thread-Index: AdarfiOiihVVds8iT0KdHPG3+auXlw== Date: Mon, 26 Oct 2020 10:03:26 +0000 Message-ID: <54abce3e4abc449fa896a6ae318a6128@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.192.169] Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance 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, 26 Oct 2020 10:03:35 -0000 Hi Fernando, Sorry. I have spotted it just now. It does not make sense to mention 802.1x as the reason for renumbering prob= lem. 802.1x operates strictly on L2. Switch port is blocked for any other traffi= c at that time. If authentication would fail then port could be put into "guest" VLAN. But important point to mention that 802.1x supplicant has finished its job = - it could not activate authentication again. It needs same event like link= up/down or admin push. Enterprises do not manage clients in such a dynamic= way. The decision to move host from "guest" to some other VLAN is not related to= 802.1x, not at all. It could be probably configuration push to switch (Net= Conf?). If such bad practice would happen then it would break connectivity for IPv4= too - DHCP would not have any information that VLAN has been changes. Hence, it does not matter what mechanism has been used initially to put hos= t into "guest" VLAN. It could be something other than 802.1x. It is important that some automation tool could break IP connectivity shift= ing hosts between VLANs. It is not possible to develop the resolution on IPv4, but it is possible to= invent additional protection on IPv6. The reason is still valid - precautions make sense to have. But it has noth= ing to do with 802.1x. It is general VLAN shuffling. Eduard > -----Original Message----- > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of IETF Secretariat > Sent: 22 =CF=CB=D4=D1=C2=D2=D1 2020 =C7. 17:29 > To: owen@delong.com; draft-ietf-v6ops-slaac-renum@ietf.org; > v6ops@ietf.org; warren@kumari.net; v6ops-chairs@ietf.org; Owen DeLong > > Subject: [v6ops] Datatracker State Update Notice: renum-04.txt> >=20 > IESG state changed: >=20 > New State: IESG Evaluation::Revised I-D Needed >=20 > (The previous state was IESG Evaluation) >=20 >=20 > Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-v6ops-slaac- > renum/ >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Mon Oct 26 18:22: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 ACBC93A1170 for ; Mon, 26 Oct 2020 18:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYmVK1m5BjdQ for ; Mon, 26 Oct 2020 18:22:07 -0700 (PDT) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 951363A116F for ; Mon, 26 Oct 2020 18:22:07 -0700 (PDT) Received: by mail-oi1-x22a.google.com with SMTP id j7so12499905oie.12 for ; Mon, 26 Oct 2020 18:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hKm+UhAYDJMRM5A5MmpzuKYWbS2k4Pez9BE1rbBKTGM=; b=HVGOLQuBwbuR1ImXjUot68y0YWhJNUNKrlj3u03P6ORd0e9tg0Qy5JDL4b9KTrX3ba 20lh8tJ8nZISRbapSh2iI3/ebvos/cunf3FKDP26S2S48yuEuktooiolMOBDAohWzjZn GpUzDVaiBimpJEMur+2dv3TCdiKeG/MVDky2MVQWnnCsD9gV2x9Kyr5+p4bd1pF0NNxF dZGibaes0q26FBKLnPjupjdA3XaNq+Pz/BDMwWwt3tuvAUyxUy+/Y8alVvYbnTQbkATF 7tRN+KZ8ct1k+xLiihpJh37KtpFSLM0Ehn5kXTVoW5z0Tx2gyf+ieyZiQtj0+lYtGItc hAsQ== 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=hKm+UhAYDJMRM5A5MmpzuKYWbS2k4Pez9BE1rbBKTGM=; b=M5AxL0vc8NvSoedu3fS/AxxLSpjADwGEcQf5fGj+HtVO2MR6qafL3mIF8eol8bLbP1 R1fOpZrl7nUpMo+KKBwYhAEg1DRCQ2+UWRuuH88R6KNdoIsViHk7RV2hNyz9V4PviUJm /tuePQgUGwu5G/s2pjqtuv4uDXeoqeZEfApKfA+bwslEZngacft/v6/HoZR4sBHZh63R uyq0PgwqM9OL5Izt0dDYRS7VcBH68TpzbjjBoAowYVdE8GdSoCq2qA+SD97Yi7VIBPiW Q3x010JwnSoFUpr8gOtxWBTT4XmbO+ztNOcGf52NVLx2BO9uESazmbnlfq0gVDArH1sm iYgg== X-Gm-Message-State: AOAM533bmqNIRdYFwdVHZYEI4PNlRNZc9S+7dpHj9h9wACOlUVAP9GDl Fk4Ej3S53L+FlVQqwJBoQmJO4AMrOIwAv8cU2XQ= X-Google-Smtp-Source: ABdhPJykv97/JHcgCey8oAuBpTPo1V8eJ92hdPHAMzg8bXJzROjjq4KBFRSi0ZcMQNJQ36jxhYexorRlVq/wcG4zPHo= X-Received: by 2002:aca:1e09:: with SMTP id m9mr37252oic.60.1603761726947; Mon, 26 Oct 2020 18:22:06 -0700 (PDT) MIME-Version: 1.0 References: <19EE82F7-8D52-4519-8087-0DF17435A3B8@gmail.com> In-Reply-To: <19EE82F7-8D52-4519-8087-0DF17435A3B8@gmail.com> From: Mark Smith Date: Tue, 27 Oct 2020 12:21:40 +1100 Message-ID: To: Gyan Mishra Cc: v6ops list , Greg Mirsky , Jeff Tantsura Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [v6ops] draft-smith-v6ops-larger-ipv6-loopback-prefix-04 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, 27 Oct 2020 01:22:09 -0000 Hi Gyan, Sorry not to get back to you sooner. On Tue, 20 Oct 2020 at 00:26, Gyan Mishra wrote: > > > Hi Mark > > What ended up happening with this draft I let it expire, as I didn't think it would be adopted by the WG. There seemed to be a bit of resistance to it as people said that ULAs could be used instead. The link local prefix is also required on any IPv6 interface, per RFC4291, so there is supposed to be a link-local /64 on the loopback interface(s) providing many addresses to which a process could be separately bound, although a drawback of using the link-local prefix is having to deal with scope/zone IDs (although Linux doesn't comply with that requirement, it doesn't have a link-local address on the loopback interface by default). > and was the work picked up in any other draft. Not as far as I'm aware. What is your use case? Regards, Mark. > > Thanks > > Gyan > > Sent from my iPhone From nobody Mon Oct 26 20:39: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 4570D3A1468 for ; Mon, 26 Oct 2020 20:38:58 -0700 (PDT) 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 sHYLcaTlndVZ for ; Mon, 26 Oct 2020 20:38:56 -0700 (PDT) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (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 918DB3A1466 for ; Mon, 26 Oct 2020 20:38:56 -0700 (PDT) Received: by mail-ua1-x92b.google.com with SMTP id b34so76319uab.8 for ; Mon, 26 Oct 2020 20:38:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KqINlbcRe5Gm9SDW4LlpoHKBkZqS1DXWgKERF3CEdgQ=; b=dp02dXoa9vDUAnOBGJ2IX8aB+YF7HuULm1DNyWnYIW3XKoggWS4DEnGTkru/Fe8sW3 Fze9TfFyujriLyAGvglbNLS+jlJyvoxrytCf84WvtmfgGT2BsbwM/nTRqsz3QwwZu+7s UL828U1a06/8l2LPB8iGEnbioTXNSui0qnH3UvlHm9nWnAeNDisGleyH2CT/0PU4lTET VEuYhVCJT8I4LMdsvjkb4MOqrGfoiIT7/kefTYit4cu6TR8jxF3XKQM71osL3fepC8Lf 4WLo+ebVYNrWAS88GL/jIe8i9NuiP0KIZR2+n8uIQoShw6JF6X4Kfe5heQ8i2Xu55jbd 6ayw== 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=KqINlbcRe5Gm9SDW4LlpoHKBkZqS1DXWgKERF3CEdgQ=; b=ERi9b2HVwnBNof/Uz6/gTGCxPiFEuXrGZyL7c6rFJ922E9qeWHyGsr2Fg1vv4NHOH1 rBnvo5YhvoFHXAw8LUERrniT3lfzmSKnsfXVsu+cmdBFj52C2hMkWBwEKyHIkSedGrtI 2RCARqtDOfeQY6Ac5HW+03s3nB0+BEpfwb5a3a5CQGsPazPv2chSWbOQfed7dKbcWiP0 D/NN0DYWWm7sgnVHApbgMqHXDxTAQglDZ4e+I2sBfH3wbFAhS0NRet2zqXcJ1lLEkEEJ F5z1CnpH2tbfAaRtu76PIhStV4R3//i4mf474PxrIOQqYUod2Fnxsv0fuj0Y/d8iE7mn jJCg== X-Gm-Message-State: AOAM531wvQBMp7rWylsKDPUBBx1r8xpOFr6QxJMEOnVMUCeqEi/EULU5 B1DcaygSAKAz/LgEGH0PlCTghuUSa8WG6N4yFtI= X-Google-Smtp-Source: ABdhPJzX5cSoakv8/RRRKK/sCNVmrjG4+1+pR+0GiNcjlak4Lo/Kkv9vowSmCkytsw2BKQseyXmoZl4CA7Cg/Ut7xOY= X-Received: by 2002:ab0:1016:: with SMTP id f22mr115653uab.141.1603769935414; Mon, 26 Oct 2020 20:38:55 -0700 (PDT) MIME-Version: 1.0 References: <19EE82F7-8D52-4519-8087-0DF17435A3B8@gmail.com> In-Reply-To: From: Gyan Mishra Date: Mon, 26 Oct 2020 23:38:44 -0400 Message-ID: To: Mark Smith Cc: Greg Mirsky , Jeff Tantsura , v6ops list Content-Type: multipart/alternative; boundary="0000000000004d48f305b29ec9ea" Archived-At: Subject: Re: [v6ops] draft-smith-v6ops-larger-ipv6-loopback-prefix-04 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, 27 Oct 2020 03:38:58 -0000 --0000000000004d48f305b29ec9ea Content-Type: text/plain; charset="UTF-8" Hi Mark Thanks for responding. The use case was for BFD continuity test for special use cases or MPLS lsp ping and now draft for vxlan BFD, where for IPv4 for continuity test you have 127/8 loopback but for IPv6 there is only one loopback address ::/128. For IPv6 we ended up using IPv4 mapped IPv6 addresses for MPLS LSP ping used to bootstrap to FEC LSP ping to BFD. So now for new vxlan BFD the topic came up and again for another draft which now as a standard we are now planning to use IPv4 mapped IPv6 for BFD continuity test. That BFD thread brought back the IPv6 RFC 4291 standard that IPv6 only has one loopback where IPv4 has a /8 worth. As you stated per RFC 4291, there is supposedly a link local /64 fe80::/64 loopback on the loopback interface which has plenty of space. I have to check on a router but I am guessing If that is implemented by all router vendors following RFC 4291, then that would be an alternative option to IPv4 mapped IPv6 for BFD continuity tests. Thanks Gyan On Mon, Oct 26, 2020 at 9:22 PM Mark Smith wrote: > Hi Gyan, > > Sorry not to get back to you sooner. > > On Tue, 20 Oct 2020 at 00:26, Gyan Mishra wrote: > > > > > > Hi Mark > > > > What ended up happening with this draft > > I let it expire, as I didn't think it would be adopted by the WG. > > There seemed to be a bit of resistance to it as people said that ULAs > could be used instead. > > The link local prefix is also required on any IPv6 interface, per > RFC4291, so there is supposed to be a link-local /64 on the loopback > interface(s) providing many addresses to which a process could be > separately bound, although a drawback of using the link-local prefix > is having to deal with scope/zone IDs (although Linux doesn't comply > with that requirement, it doesn't have a link-local address on the > loopback interface by default). > > > and was the work picked up in any other draft. > > Not as far as I'm aware. > > What is your use case? > > Regards, > Mark. > > > > > > Thanks > > > > Gyan > > > > Sent from my iPhone > -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --0000000000004d48f305b29ec9ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Mark

<= div dir=3D"auto">Thanks for responding.

The use case was for BFD continuity test for special use ca= ses or MPLS lsp ping and now draft for =C2=A0vxlan BFD, where for IPv4 for = continuity test you have 127/8 loopback but for IPv6 there is only one loop= back address ::/128. =C2=A0

For IPv6 we ended up using IPv4 mapped IPv6 addresses for MPLS LSP ping= used to bootstrap to FEC LSP ping to BFD.=C2=A0 So now for new vxlan BFD t= he topic came up and again for another draft which now as a standard we are= now planning to use IPv4 mapped IPv6 for BFD continuity test.

That BFD thread brought back the IPv= 6 RFC 4291 standard that IPv6 only has one loopback where IPv4 has a /8 wor= th. =C2=A0

As you stated= per RFC 4291, there is supposedly a link local /64 fe80::/64 loopback on t= he loopback interface which has plenty of space.=C2=A0 I have to check on a= router but I am guessing If that is implemented by all router vendors foll= owing RFC 4291, then that would be an alternative option to IPv4 mapped IPv= 6 for BFD continuity tests.=C2=A0

Thanks=C2=A0

G= yan

On Mon, Oct 26, 2020 at 9:22 PM Mark Smith <markzzzsmith@gmail.com> wrote:
Hi Gyan,

Sorry not to get back to you sooner.

On Tue, 20 Oct 2020 at 00:26, Gyan Mishra <hayabusagsm@gmail.com> wrote:
>
>
> Hi Mark
>
> What ended up happening with this draft

I let it expire, as I didn't think it would be adopted by the WG.

There seemed to be a bit of resistance to it as people said that ULAs
could be used instead.

The link local prefix is also required on any IPv6 interface, per
RFC4291, so there is supposed to be a link-local /64 on the loopback
interface(s) providing many addresses to which a process could be
separately bound, although a drawback of using the link-local prefix
is having to deal with scope/zone IDs (although Linux doesn't comply with that requirement, it doesn't have a link-local address on the
loopback interface by default).

> and was the work picked up in any other draft.

Not as far as I'm aware.

What is your use case?

Regards,
Mark.


>
> Thanks
>
> Gyan
>
> Sent from my iPhone
--
--0000000000004d48f305b29ec9ea-- From nobody Tue Oct 27 01:03: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 2A5683A12DE; Tue, 27 Oct 2020 01:03:07 -0700 (PDT) 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 TEETEEcngLpG; Tue, 27 Oct 2020 01:03:05 -0700 (PDT) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F02813A12D6; Tue, 27 Oct 2020 01:03:04 -0700 (PDT) Received: by mail-il1-x132.google.com with SMTP id q1so670627ilt.6; Tue, 27 Oct 2020 01:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e7L5njDw9bHL34WY32/WhQRZ+neauDVWAq7FZeiI7Qo=; b=VDZi62Z4zvhpXMuee7O6zbr/ZeRNXQa6zZY52XajuzTbGNmjRhe57M5jioPO5zLJp0 uulwquIQFjMdF0NjCNRZNp8O5zsTim0We1HEmMCo0ryFOOiVdAOV4XF9vUrqMWOsTMvX PkkC0uhjFhOizyF5mOr/lU8JbO7qydc06BAdH+m1KKd/fuCnwoVPhvnxlam938rcBJDC 7of2ckx/WPa5yFbow1FrS/B7wXqHvjWgWPwypKXBoIbjWA+u1Is3XgkkVffvaXMEI44B 2Fi6GuW68bWpZlZA2IMGuBSIUPyq7wO4amXyYf1uUd9DXb0ozjEs48DrAJVcDzgLqFzJ YyGA== 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=e7L5njDw9bHL34WY32/WhQRZ+neauDVWAq7FZeiI7Qo=; b=FiVevXCSbk8XFocxLl4MpG4hOWNxvxYagcadpLATUtcVzG64Khg37xFHq4xLv2IYhm eGafv16uxE6siiZWE9rTecEDd8TdAikwax0f1CwTm0AnPbjoJuvuZQLNixG7S4gBJ/px yUubo4yLMdEeFr03xKvLAAV/6gPwFrYKXOXVlOdAC0n+MLEYGXtzeI/UzlHQ6Dja+1bZ UzPekCS95qgqmHfwTUkHpsmwiIL0X5xzkKzoKY1BQFpbYw3n/CCzh3PBoZDyuc+PnSex EKNf38VOuBMuvQzy5qj9Yme7CQGoK7ZGp5ogYZrip9eagyfXvVO7rPI5SpxqXOEq9hOY heTg== X-Gm-Message-State: AOAM531tgUXj+LGjcMeQPmopt9vzhHx8BZ+h9K69szE9lOUyg7BIdHwA V6wxSRXYDd75LEHvXmVZ9mrLdrNAyiu9TWM5mkk= X-Google-Smtp-Source: ABdhPJzlyO0b5PfRDX31MEBqu+zOAoPUpQgGo6v1VLesS4dqAK7LTzbvfues5RP1iSbdLlhz76dj/ps4dxdkEAtaK6w= X-Received: by 2002:a92:5e14:: with SMTP id s20mr758634ilb.16.1603785784232; Tue, 27 Oct 2020 01:03:04 -0700 (PDT) MIME-Version: 1.0 References: <65f390e222244427bd3cbc1f58a3ec95@boeing.com> <533e7f91ae814feeb594bc42b7cd70c9@huawei.com> <618b9ee8ddec4957906bf715b04190a0@boeing.com> In-Reply-To: <618b9ee8ddec4957906bf715b04190a0@boeing.com> From: "Ms. Li HUANG" Date: Tue, 27 Oct 2020 16:02:52 +0800 Message-ID: To: "Templin (US), Fred L" Cc: otroan@employees.org, Vasilenko Eduard , v6ops list , 6man WG , dhcwg Content-Type: multipart/alternative; boundary="000000000000f710fe05b2a279a6" Archived-At: Subject: Re: [v6ops] [dhcwg] [EXTERNAL] Re: Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Tue, 27 Oct 2020 08:03:07 -0000 --000000000000f710fe05b2a279a6 Content-Type: text/plain; charset="UTF-8" 15:46.hk S8 Oct. 27 2020 Good Day group, The own sg, vlan routing to ISP dhcpv6 ? - its ipv6 route told unable routed? - stub insight sg or modem.isp? The own rv ipv6 temp at ipconfig /all is AT wan, none PD possible to be set up... - wan v6 would be able to package exchanging to isp dhcpv6? - stub on this rv? The modem.isp only network to endpoint pc, - stub on modem possible ? - stub on vrrp v6 of isp ? - stub at ISP behind of the client 's rv, or sg or modem ? none of is then, no stub package would once tried , no longer possible to resent it as probably immediately dropped at the 1st transformation failed right afterward ? Sincerely Li HUANG On Sat, Oct 17, 2020, 04:49 Templin (US), Fred L wrote: > Ole, > > > The CPE requirements document could have had a requirement that it > should never forward a packet received on the WAN interface > > back out the WAN interface. > > That is what I said before, but I qualified it by saying "should never > forward a packet > received on the WAN interface back out the WAN interface *via a default > route*." > It could be that there are more-specific routes that would cause a packet > coming > into the WAN interface to go back out the WAN interface and that is OK; > but, not > via a default route. > > However, the further discussion seems to suggest that the delegating > router needs > to be mindful of clients that maliciously or otherwise send ping-ponged > self-directed > packets. I was worried that the delegating router would not be able to > distinguish > CPE router A from CPE routers B, C, D in some cases. But, I am not worried > about > that anymore. > > Thanks - Fred > > > -----Original Message----- > > From: otroan@employees.org [mailto:otroan@employees.org] > > Sent: Friday, October 16, 2020 11:31 AM > > To: Templin (US), Fred L > > Cc: Vasilenko Eduard ; Michael Richardson < > mcr+ietf@sandelman.ca>; v6ops list ; > > 6man WG ; dhcwg > > Subject: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay > Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay- > > requirements > > > > This message was sent from outside of Boeing. Please do not click links > or open attachments unless you recognize the sender and > > know that the content is safe. > > > > > > > > > > We are talking past each other, and one of us does not have a clear > understanding > > > of the issue at the heart of the discussion which I see as a > forwarding plane issue > > > having nothing to do with the control plane. > > > > Well, the forwarding plane just does what it's told. > > When you set up DHCP with static routes at both ends, which are > maintained by snooping on a protocol. It's not inconceivable that > > there are cases where you'd get a routing loop. Good thing we have the > HLIM field. ;-) > > > > Markus' draft is still the most authorative document discussion the > solution space: > > https://tools.ietf.org/html/draft-stenberg-v6ops-pd-route-maintenance-00 > > > > The CPE requirements document could have had a requirement that it > should never forward a packet received on the WAN interface > > back out the WAN interface. > > > > Cheers, > > Ole= > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --000000000000f710fe05b2a279a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Using link-locals would be the bette= r option.
15:46.hk S8 Oct. 27 2020


Good Day group,

=


<= br>
The own sg,=C2=A0 vlan routing to ISP dhcpv6 ?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -=C2=A0 its ipv6 route to= ld unable routed?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -=C2= =A0 stub insight sg or modem.isp?


The own rv ipv6 temp at ipconfig /all= is AT wan, none PD possible to be set up...
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 - wan v6 would be able to package exchanging to isp dh= cpv6?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - stub on this rv?=



The modem.isp only network to endpoint pc,= =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -=C2=A0 stub on m= odem possible ?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 -=C2=A0 = =C2=A0stub on vrrp v6 of isp ?
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 -=C2=A0 =C2=A0 stub at ISP behind of the client 's rv, or sg or = modem ?


=C2=A0 =C2=A0 =C2=A0 =C2=A0none of is then, no stub package wou= ld once tried , no longer possible to resent it as probably immediately dro= pped at the 1st transformation failed right afterward ?



Sincerely
Li HUANG
On Sat, O= ct 17, 2020, 04:49 Templin (US), Fred L <Fred.L.Templin@boeing.co= m> wrote:
Ole,

> The CPE requirements document could have had a requirement that it sho= uld never forward a packet received on the WAN interface
> back out the WAN interface.

That is what I said before, but I qualified it by saying "should never= forward a packet
received on the WAN interface back out the WAN interface *via a default rou= te*."
It could be that there are more-specific routes that would cause a packet c= oming
into the WAN interface to go back out the WAN interface and that is OK; but= , not
via a default route.

However, the further discussion seems to suggest that the delegating router= needs
to be mindful of clients that maliciously or otherwise send ping-ponged sel= f-directed
packets. I was worried that the delegating router would not be able to dist= inguish
CPE router A from CPE routers B, C, D in some cases. But, I am not worried = about
that anymore.

Thanks - Fred

> -----Original Message-----
> From: otroan@employees.org [mailto:otroa= n@employees.org]
> Sent: Friday, October 16, 2020 11:31 AM
> To: Templin (US), Fred L <Fred.L.Templin@boeing.c= om>
> Cc: Vasilenko Eduard <vasilenko.eduard@huawei.c= om>; Michael Richardson <mcr+ietf@sandelman.ca>; v6ops list <v6ops@ietf.org>;
> 6man WG <ipv6@ietf.org>; dhcwg <dhcwg@ietf.o= rg>
> Subject: [EXTERNAL] Re: [dhcwg] [v6ops] Re: Question to DHCPv6 Relay I= mplementors regarding draft-ietf-dhc-dhcpv6-pd-relay-
> requirements
>
> This message was sent from outside of Boeing. Please do not click link= s or open attachments unless you recognize the sender and
> know that the content is safe.
>
>
> >
> > We are talking past each other, and one of us does not have a cle= ar understanding
> > of the issue at the heart of the discussion which I see as a forw= arding plane issue
> > having nothing to do with the control plane.
>
> Well, the forwarding plane just does what it's told.
> When you set up DHCP with static routes at both ends, which are mainta= ined by snooping on a protocol. It's not inconceivable that
> there are cases where you'd get a routing loop. Good thing we have= the HLIM field. ;-)
>
> Markus' draft is still the most authorative document discussion th= e solution space:
> h= ttps://tools.ietf.org/html/draft-stenberg-v6ops-pd-route-maintenance-00=
>
> The CPE requirements document could have had a requirement that it sho= uld never forward a packet received on the WAN interface
> back out the WAN interface.
>
> Cheers,
> Ole=3D

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listin= fo/dhcwg
--000000000000f710fe05b2a279a6-- From nobody Tue Oct 27 05:48:45 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 148C03A00E5 for ; Tue, 27 Oct 2020 05:48:44 -0700 (PDT) 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, 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=helix-net-nz.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LLHo9O0KOEth for ; Tue, 27 Oct 2020 05:48:41 -0700 (PDT) Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) (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 7444B3A00E3 for ; Tue, 27 Oct 2020 05:48:40 -0700 (PDT) Received: by mail-io1-xd43.google.com with SMTP id z5so1375553iob.1 for ; Tue, 27 Oct 2020 05:48:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vUQdGzyb2NpeDluUBFnU+EHhaax1kopmA4pkolLxbuE=; b=Imgiured5ZM1NdGYIklE7INzIcAvJzHZHK6mKrmERPerIguPmBRIrc7sfCL3fBlmEi YpCgrDflUFwH0UuHctOym7VnIQA5t3d4COKwZEhmGF8GB6PAulS5jL0QpBSnvqJf3HJq 51rEG2Y93qBdgs/7i5eUR9RHbSyeEVtqrMK9jf2+CxDBSUJqGvH+HpiLiIq+p7wVv9z8 xi22Jqx5J3w7HcE8m5kXDHb1fFWztjObLt8x3dohLeq8at468Apf0keIz+DU/UQ7HsEZ PSBkFtS2JKvuo+iZ2DsvvK+El83qpsp4NsuihEo95e5rUsE/i+72vwt1bc5kaqmrT+Uh wTgA== 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=vUQdGzyb2NpeDluUBFnU+EHhaax1kopmA4pkolLxbuE=; b=Bt6zG3/c6vqSEHVHuvnYDe47ygvjWrYHpW5jHi6JYSZ20zYx16lPH7F6t26tUXP1QX MJF0rBt9KUm9bkRPEQtAXox6WY/VKRYZdQqUp9fJgekDt7Q2CS4IV69zLmuk9+XhSk8y GUFkrmMZZhHl9n9Ja2dOXeZtDeMz+XaMACJJotvXub+zq4nhsSqywjyq+NqyJ7wvzNxN dGy8v4Yo/rtmrXIHwGfZfOlC0oazr7/knw5YUYgnoYZ6nQYtx5vKz3w9Rlr8lxX5k/s+ vwluAqF92zkKl+o0M4NfBP98GRfAKhErfYvSpCxDB7yD0UmsIKUvw2DSyxqG1bLx19IR Knyg== X-Gm-Message-State: AOAM531IMH7jJYCZqiachw3y0QzyEATXtJDyDL2DhNbi5hX2HZ1duYUV +H1jcT7F5MdR0iaUHB+5o1sxr7vDgnXaiQ== X-Google-Smtp-Source: ABdhPJz0lRY6jFsiLWohMMGnGIrPLV03iuEFUpZSHczRq8hVtb9xGST7EC5ShSMDPngl7ZUC1HlL7w== X-Received: by 2002:a02:1349:: with SMTP id 70mr2261138jaz.130.1603802919715; Tue, 27 Oct 2020 05:48:39 -0700 (PDT) Received: from mail-io1-f42.google.com (mail-io1-f42.google.com. [209.85.166.42]) by smtp.gmail.com with ESMTPSA id z15sm900034ilb.73.2020.10.27.05.48.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2020 05:48:38 -0700 (PDT) Received: by mail-io1-f42.google.com with SMTP id z17so1340032iog.11 for ; Tue, 27 Oct 2020 05:48:38 -0700 (PDT) X-Received: by 2002:a05:6638:f81:: with SMTP id h1mr2177282jal.115.1603802918398; Tue, 27 Oct 2020 05:48:38 -0700 (PDT) MIME-Version: 1.0 References: <54abce3e4abc449fa896a6ae318a6128@huawei.com> In-Reply-To: <54abce3e4abc449fa896a6ae318a6128@huawei.com> From: Richard Patterson Date: Tue, 27 Oct 2020 12:48:27 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Vasilenko Eduard Cc: IPv6 Operations Content-Type: multipart/alternative; boundary="0000000000003dafc005b2a67766" Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance 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, 27 Oct 2020 12:48:44 -0000 --0000000000003dafc005b2a67766 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Eduard, We're not pointing out any interoperation with 802.1x specifically, we were just using it as an example that may trigger a renumbering event without the physical port flapping, which I believe is valid. A switch-port the host is connected to may be moved to another subnet (VLAN) as a result of manual switch-port reconfiguration or 802.1x re-authentication. I think the statement above is clear that 802.1x is simply an example of when a host may be shifted between VLANs and a renumbering event may occur, if you believe the wording isn't clear enough, would you be able to suggest how we may improve it please? -Rich On Mon, 26 Oct 2020 at 10:04, Vasilenko Eduard wrote: > Hi Fernando, > Sorry. I have spotted it just now. > It does not make sense to mention 802.1x as the reason for renumbering > problem. > 802.1x operates strictly on L2. Switch port is blocked for any other > traffic at that time. > If authentication would fail then port could be put into "guest" VLAN. > But important point to mention that 802.1x supplicant has finished its jo= b > - it could not activate authentication again. It needs same event like li= nk > up/down or admin push. Enterprises do not manage clients in such a dynami= c > way. > The decision to move host from "guest" to some other VLAN is not related > to 802.1x, not at all. It could be probably configuration push to switch > (NetConf?). > If such bad practice would happen then it would break connectivity for > IPv4 too - DHCP would not have any information that VLAN has been changes= . > Hence, it does not matter what mechanism has been used initially to put > host into "guest" VLAN. It could be something other than 802.1x. > It is important that some automation tool could break IP connectivity > shifting hosts between VLANs. > It is not possible to develop the resolution on IPv4, but it is possible > to invent additional protection on IPv6. > The reason is still valid - precautions make sense to have. But it has > nothing to do with 802.1x. It is general VLAN shuffling. > Eduard > > -----Original Message----- > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of IETF > Secretariat > > Sent: 22 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2020 =D0=B3. 17:29 > > To: owen@delong.com; draft-ietf-v6ops-slaac-renum@ietf.org; > > v6ops@ietf.org; warren@kumari.net; v6ops-chairs@ietf.org; Owen DeLong > > > > Subject: [v6ops] Datatracker State Update Notice: > > renum-04.txt> > > > > IESG state changed: > > > > New State: IESG Evaluation::Revised I-D Needed > > > > (The previous state was IESG Evaluation) > > > > > > Datatracker URL: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-slaac- > > renum/ > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --0000000000003dafc005b2a67766 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Eduard,

We're not pointing out a= ny interoperation with 802.1x specifically, we were just using it as an exa= mple that may trigger a renumbering event without the physical port flappin= g, which I believe is valid.

A switch-port the host is connected to may =
be moved to another
      subnet (VLAN) as a result of manual switch-port reconfiguration or
      802.1x re-authentication.

I think the= statement above is clear that 802.1x is simply an example of when a host m= ay be shifted between VLANs and a renumbering event may occur, if you belie= ve the wording isn't clear enough, would you be able to suggest how we = may improve it please?

-Rich

On Mon, 26 Oct 2= 020 at 10:04, Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote:
Hi Fernando,
Sorry. I have spotted it just now.
It does not make sense to mention 802.1x as the reason for renumbering prob= lem.
802.1x operates strictly on L2. Switch port is blocked for any other traffi= c at that time.
If authentication would fail then port could be put into "guest" = VLAN.
But important point to mention that 802.1x supplicant has finished its job = - it could not activate authentication again. It needs same event like link= up/down or admin push. Enterprises do not manage clients in such a dynamic= way.
The decision to move host from "guest" to some other VLAN is not = related to 802.1x, not at all. It could be probably configuration push to s= witch (NetConf?).
If such bad practice would happen then it would break connectivity for IPv4= too - DHCP would not have any information that VLAN has been changes.
Hence, it does not matter what mechanism has been used initially to put hos= t into "guest" VLAN. It could be something other than 802.1x.
It is important that some automation tool could break IP connectivity shift= ing hosts between VLANs.
It is not possible to develop the resolution on IPv4, but it is possible to= invent additional protection on IPv6.
The reason is still valid - precautions make sense to have. But it has noth= ing to do with 802.1x. It is general VLAN shuffling.
Eduard
> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of IETF Secretariat
> Sent: 22 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2020 =D0=B3. 17:29=
> To: owen@delong.c= om; draft-ietf-v6ops-slaac-renum@ietf.org;
> v6ops@ietf.org= ; warren@kumari.net<= /a>; v6ops-chair= s@ietf.org; Owen DeLong
> <owen@delong.c= om>
> Subject: [v6ops] Datatracker State Update Notice: <draft-ietf-v6ops= -slaac-
> renum-04.txt>
>
> IESG state changed:
>
> New State: IESG Evaluation::Revised I-D Needed
>
> (The previous state was IESG Evaluation)
>
>
> Datatracker URL: https://datatracker.ie= tf.org/doc/draft-ietf-v6ops-slaac-
> renum/
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops
--0000000000003dafc005b2a67766-- From nobody Tue Oct 27 06:05:48 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 5C0593A09F9 for ; Tue, 27 Oct 2020 06:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 hwNIXEZgqI9B for ; Tue, 27 Oct 2020 06:05:36 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 BE5383A09C9 for ; Tue, 27 Oct 2020 06:05:35 -0700 (PDT) Received: from lhreml730-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id EE132DFDF4297563B1B5; Tue, 27 Oct 2020 13:05:33 +0000 (GMT) Received: from msceml704-chm.china.huawei.com (10.219.141.143) by lhreml730-chm.china.huawei.com (10.201.108.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 27 Oct 2020 13:05:33 +0000 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml704-chm.china.huawei.com (10.219.141.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 27 Oct 2020 16:05:32 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Tue, 27 Oct 2020 16:05:32 +0300 From: Vasilenko Eduard To: Richard Patterson CC: IPv6 Operations Thread-Topic: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance Thread-Index: AdarfiOiihVVds8iT0KdHPG3+auXlwAyC3uAAAafLvA= Date: Tue, 27 Oct 2020 13:05:32 +0000 Message-ID: <12e219a6add2417685d386c026dce8e4@huawei.com> References: <54abce3e4abc449fa896a6ae318a6128@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.197.128] Content-Type: multipart/alternative; boundary="_000_12e219a6add2417685d386c026dce8e4huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance 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, 27 Oct 2020 13:05:47 -0000 --_000_12e219a6add2417685d386c026dce8e4huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmljaGFyZCwNCkkgYmVsaWV2ZSB0aGF0IGl0IGlzIG1pc2xlYWRpbmcuDQpCZWNhdXNlIDgw Mi4xeCBpdHNlbGYgaXMgbm90IGNhcGFibGUgdG8gbW92ZSBiZXR3ZWVuIFZMQU5zIGFmdGVyIGFk ZHJlc3MgYWNjZXB0ZWQuIDgwMi4xeCBjb3VsZCBtb3ZlIGJldHdlZW4gVkxBTnMgYmVmb3JlIGFk ZHJlc3MgYWNjZXB0ZWQg4oCTIGl0IGlzIG5vdCByZWxldmFudCBoZXJlLg0KU29tZXRoaW5nIGVs c2Ugc2hvdWxkIHB1c2ggYmV0d2VlbiBWTEFOcyB0byBicmVhayBJUCBjb25uZWN0aXZpdHkuIEl0 IGNvdWxkIG5vdCBiZSA4MDIuMXguIEl0IGlzIGJldHRlciBub3QgdG8gbWVudGlvbiA4MDIuMXgu IEl0IGlzIG5vdCBpbXBvcnRhbnQgd2hhdCB3YXMgdGhlIG1lY2hhbmlzbSB0aGF0IGluaXRpYWxs eSBjb25uZWN0ZWQgaG9zdCB0byAxc3QgVkxBTi4NCkl0IGNvdWxkIGJlIG5vIGFueSBzcGVjaWFs IG1lY2hhbmlzbSBhdCBhbGwuIE9yIGl0IGNvdWxkIGJlIOKAnE1BQy1hdXRoZW50aWNhdGlvbuKA nS4gSXQgZG9lcyBub3QgbWF0dGVyLg0KDQpJdCBpcyBpbXBvcnRhbnQgd2hhdCBjb3VsZCBiZSB0 aGUgbWVjaGFuaXNtIHRoYXQgbW92ZWQgYmV0d2VlbiBWTEFOcy4gSSBkbyBhc3N1bWUgc29tZSBz b3J0IG9mIGNvbmZpZ3VyYXRpb24gY2hhbmdlIGJ5IENMSSBvZiBOZXRjb25mLg0KQnV0IGl0IGlz IG5vdCA4MDIuMXggYW55d2F5Lg0KRWR1YXJkDQpGcm9tOiBSaWNoYXJkIFBhdHRlcnNvbiBbbWFp bHRvOnJpY2hhcmRAaGVsaXgubmV0Lm56XQ0KU2VudDogMjcg0L7QutGC0Y/QsdGA0Y8gMjAyMCDQ sy4gMTU6NDgNClRvOiBWYXNpbGVua28gRWR1YXJkIDx2YXNpbGVua28uZWR1YXJkQGh1YXdlaS5j b20+DQpDYzogSVB2NiBPcGVyYXRpb25zIDx2Nm9wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb djZvcHNdIGRyYWZ0LWlldGYtdjZvcHMtc2xhYWMtcmVudW0tMDQgLSA4MDIuMXggcmVsZXZhbmNl DQoNCkhpIEVkdWFyZCwNCg0KV2UncmUgbm90IHBvaW50aW5nIG91dCBhbnkgaW50ZXJvcGVyYXRp b24gd2l0aCA4MDIuMXggc3BlY2lmaWNhbGx5LCB3ZSB3ZXJlIGp1c3QgdXNpbmcgaXQgYXMgYW4g ZXhhbXBsZSB0aGF0IG1heSB0cmlnZ2VyIGEgcmVudW1iZXJpbmcgZXZlbnQgd2l0aG91dCB0aGUg cGh5c2ljYWwgcG9ydCBmbGFwcGluZywgd2hpY2ggSSBiZWxpZXZlIGlzIHZhbGlkLg0KDQoNCkEg c3dpdGNoLXBvcnQgdGhlIGhvc3QgaXMgY29ubmVjdGVkIHRvIG1heSBiZSBtb3ZlZCB0byBhbm90 aGVyDQoNCiAgICAgIHN1Ym5ldCAoVkxBTikgYXMgYSByZXN1bHQgb2YgbWFudWFsIHN3aXRjaC1w b3J0IHJlY29uZmlndXJhdGlvbiBvcg0KDQogICAgICA4MDIuMXggcmUtYXV0aGVudGljYXRpb24u DQoNCkkgdGhpbmsgdGhlIHN0YXRlbWVudCBhYm92ZSBpcyBjbGVhciB0aGF0IDgwMi4xeCBpcyBz aW1wbHkgYW4gZXhhbXBsZSBvZiB3aGVuIGEgaG9zdCBtYXkgYmUgc2hpZnRlZCBiZXR3ZWVuIFZM QU5zIGFuZCBhIHJlbnVtYmVyaW5nIGV2ZW50IG1heSBvY2N1ciwgaWYgeW91IGJlbGlldmUgdGhl IHdvcmRpbmcgaXNuJ3QgY2xlYXIgZW5vdWdoLCB3b3VsZCB5b3UgYmUgYWJsZSB0byBzdWdnZXN0 IGhvdyB3ZSBtYXkgaW1wcm92ZSBpdCBwbGVhc2U/DQoNCi1SaWNoDQoNCk9uIE1vbiwgMjYgT2N0 IDIwMjAgYXQgMTA6MDQsIFZhc2lsZW5rbyBFZHVhcmQgPHZhc2lsZW5rby5lZHVhcmRAaHVhd2Vp LmNvbTxtYWlsdG86dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tPj4gd3JvdGU6DQpIaSBGZXJu YW5kbywNClNvcnJ5LiBJIGhhdmUgc3BvdHRlZCBpdCBqdXN0IG5vdy4NCkl0IGRvZXMgbm90IG1h a2Ugc2Vuc2UgdG8gbWVudGlvbiA4MDIuMXggYXMgdGhlIHJlYXNvbiBmb3IgcmVudW1iZXJpbmcg cHJvYmxlbS4NCjgwMi4xeCBvcGVyYXRlcyBzdHJpY3RseSBvbiBMMi4gU3dpdGNoIHBvcnQgaXMg YmxvY2tlZCBmb3IgYW55IG90aGVyIHRyYWZmaWMgYXQgdGhhdCB0aW1lLg0KSWYgYXV0aGVudGlj YXRpb24gd291bGQgZmFpbCB0aGVuIHBvcnQgY291bGQgYmUgcHV0IGludG8gImd1ZXN0IiBWTEFO Lg0KQnV0IGltcG9ydGFudCBwb2ludCB0byBtZW50aW9uIHRoYXQgODAyLjF4IHN1cHBsaWNhbnQg aGFzIGZpbmlzaGVkIGl0cyBqb2IgLSBpdCBjb3VsZCBub3QgYWN0aXZhdGUgYXV0aGVudGljYXRp b24gYWdhaW4uIEl0IG5lZWRzIHNhbWUgZXZlbnQgbGlrZSBsaW5rIHVwL2Rvd24gb3IgYWRtaW4g cHVzaC4gRW50ZXJwcmlzZXMgZG8gbm90IG1hbmFnZSBjbGllbnRzIGluIHN1Y2ggYSBkeW5hbWlj IHdheS4NClRoZSBkZWNpc2lvbiB0byBtb3ZlIGhvc3QgZnJvbSAiZ3Vlc3QiIHRvIHNvbWUgb3Ro ZXIgVkxBTiBpcyBub3QgcmVsYXRlZCB0byA4MDIuMXgsIG5vdCBhdCBhbGwuIEl0IGNvdWxkIGJl IHByb2JhYmx5IGNvbmZpZ3VyYXRpb24gcHVzaCB0byBzd2l0Y2ggKE5ldENvbmY/KS4NCklmIHN1 Y2ggYmFkIHByYWN0aWNlIHdvdWxkIGhhcHBlbiB0aGVuIGl0IHdvdWxkIGJyZWFrIGNvbm5lY3Rp dml0eSBmb3IgSVB2NCB0b28gLSBESENQIHdvdWxkIG5vdCBoYXZlIGFueSBpbmZvcm1hdGlvbiB0 aGF0IFZMQU4gaGFzIGJlZW4gY2hhbmdlcy4NCkhlbmNlLCBpdCBkb2VzIG5vdCBtYXR0ZXIgd2hh dCBtZWNoYW5pc20gaGFzIGJlZW4gdXNlZCBpbml0aWFsbHkgdG8gcHV0IGhvc3QgaW50byAiZ3Vl c3QiIFZMQU4uIEl0IGNvdWxkIGJlIHNvbWV0aGluZyBvdGhlciB0aGFuIDgwMi4xeC4NCkl0IGlz IGltcG9ydGFudCB0aGF0IHNvbWUgYXV0b21hdGlvbiB0b29sIGNvdWxkIGJyZWFrIElQIGNvbm5l Y3Rpdml0eSBzaGlmdGluZyBob3N0cyBiZXR3ZWVuIFZMQU5zLg0KSXQgaXMgbm90IHBvc3NpYmxl IHRvIGRldmVsb3AgdGhlIHJlc29sdXRpb24gb24gSVB2NCwgYnV0IGl0IGlzIHBvc3NpYmxlIHRv IGludmVudCBhZGRpdGlvbmFsIHByb3RlY3Rpb24gb24gSVB2Ni4NClRoZSByZWFzb24gaXMgc3Rp bGwgdmFsaWQgLSBwcmVjYXV0aW9ucyBtYWtlIHNlbnNlIHRvIGhhdmUuIEJ1dCBpdCBoYXMgbm90 aGluZyB0byBkbyB3aXRoIDgwMi4xeC4gSXQgaXMgZ2VuZXJhbCBWTEFOIHNodWZmbGluZy4NCkVk dWFyZA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB2Nm9wcyBbbWFpbHRv OnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc+XSBP biBCZWhhbGYgT2YgSUVURiBTZWNyZXRhcmlhdA0KPiBTZW50OiAyMiDQvtC60YLRj9Cx0YDRjyAy MDIwINCzLiAxNzoyOQ0KPiBUbzogb3dlbkBkZWxvbmcuY29tPG1haWx0bzpvd2VuQGRlbG9uZy5j b20+OyBkcmFmdC1pZXRmLXY2b3BzLXNsYWFjLXJlbnVtQGlldGYub3JnPG1haWx0bzpkcmFmdC1p ZXRmLXY2b3BzLXNsYWFjLXJlbnVtQGlldGYub3JnPjsNCj4gdjZvcHNAaWV0Zi5vcmc8bWFpbHRv OnY2b3BzQGlldGYub3JnPjsgd2FycmVuQGt1bWFyaS5uZXQ8bWFpbHRvOndhcnJlbkBrdW1hcmku bmV0PjsgdjZvcHMtY2hhaXJzQGlldGYub3JnPG1haWx0bzp2Nm9wcy1jaGFpcnNAaWV0Zi5vcmc+ OyBPd2VuIERlTG9uZw0KPiA8b3dlbkBkZWxvbmcuY29tPG1haWx0bzpvd2VuQGRlbG9uZy5jb20+ Pg0KPiBTdWJqZWN0OiBbdjZvcHNdIERhdGF0cmFja2VyIFN0YXRlIFVwZGF0ZSBOb3RpY2U6IDxk cmFmdC1pZXRmLXY2b3BzLXNsYWFjLQ0KPiByZW51bS0wNC50eHQ+DQo+DQo+IElFU0cgc3RhdGUg Y2hhbmdlZDoNCj4NCj4gTmV3IFN0YXRlOiBJRVNHIEV2YWx1YXRpb246OlJldmlzZWQgSS1EIE5l ZWRlZA0KPg0KPiAoVGhlIHByZXZpb3VzIHN0YXRlIHdhcyBJRVNHIEV2YWx1YXRpb24pDQo+DQo+ DQo+IERhdGF0cmFja2VyIFVSTDogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi12Nm9wcy1zbGFhYy0NCj4gcmVudW0vDQo+DQo+DQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHY2b3BzIG1haWxpbmcgbGlzdA0KPiB2 Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCnY2b3BzIG1haWxpbmcgbGlzdA0KdjZvcHNAaWV0Zi5vcmc8 bWFpbHRvOnY2b3BzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby92Nm9wcw0K --_000_12e219a6add2417685d386c026dce8e4huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNv LXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5 OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkhpIFJpY2hhcmQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYmVsaWV2ZSB0aGF0 IGl0IGlzIG1pc2xlYWRpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJlY2F1c2UgODAyLjF4IGl0c2Vs ZiBpcyBub3QgY2FwYWJsZSB0byBtb3ZlIGJldHdlZW4gVkxBTnMgYWZ0ZXIgYWRkcmVzcyBhY2Nl cHRlZC4gODAyLjF4IGNvdWxkIG1vdmUgYmV0d2VlbiBWTEFOcyBiZWZvcmUgYWRkcmVzcyBhY2Nl cHRlZCDigJMgaXQgaXMgbm90IHJlbGV2YW50DQogaGVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U29t ZXRoaW5nIGVsc2Ugc2hvdWxkIHB1c2ggYmV0d2VlbiBWTEFOcyB0byBicmVhayBJUCBjb25uZWN0 aXZpdHkuIEl0IGNvdWxkIG5vdCBiZSA4MDIuMXguIEl0IGlzIGJldHRlciBub3QgdG8gbWVudGlv biA4MDIuMXguIEl0IGlzIG5vdCBpbXBvcnRhbnQgd2hhdCB3YXMgdGhlDQogbWVjaGFuaXNtIHRo YXQgaW5pdGlhbGx5IGNvbm5lY3RlZCBob3N0IHRvIDE8c3VwPnN0PC9zdXA+IFZMQU4uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkl0IGNvdWxkIGJlIG5vIGFueSBzcGVjaWFsIG1lY2hhbmlzbSBhdCBhbGwu IE9yIGl0IGNvdWxkIGJlIOKAnE1BQy1hdXRoZW50aWNhdGlvbuKAnS4gSXQgZG9lcyBub3QgbWF0 dGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SXQgaXMgaW1w b3J0YW50IHdoYXQgY291bGQgYmUgdGhlIG1lY2hhbmlzbSB0aGF0IG1vdmVkIGJldHdlZW4gVkxB TnMuIEkgZG8gYXNzdW1lIHNvbWUgc29ydCBvZiBjb25maWd1cmF0aW9uIGNoYW5nZSBieSBDTEkg b2YgTmV0Y29uZi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QnV0IGl0IGlzIG5vdCA4MDIuMXggYW55d2F5 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5FZHVhcmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+IFJpY2hhcmQgUGF0dGVyc29uIFttYWlsdG86cmljaGFyZEBoZWxpeC5uZXQu bnpdDQo8YnI+DQo8Yj5TZW50OjwvYj4gMjcg0L7QutGC0Y/QsdGA0Y8gMjAyMCDQsy4gMTU6NDg8 YnI+DQo8Yj5Ubzo8L2I+IFZhc2lsZW5rbyBFZHVhcmQgJmx0O3Zhc2lsZW5rby5lZHVhcmRAaHVh d2VpLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IElQdjYgT3BlcmF0aW9ucyAmbHQ7djZvcHNAaWV0 Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZv cHMtc2xhYWMtcmVudW0tMDQgLSA4MDIuMXggcmVsZXZhbmNlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEVkdWFyZCw8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlJ3JlIG5vdCBwb2ludGluZyBvdXQg YW55IGludGVyb3BlcmF0aW9uIHdpdGggODAyLjF4IHNwZWNpZmljYWxseSwgd2Ugd2VyZSBqdXN0 IHVzaW5nIGl0IGFzIGFuIGV4YW1wbGUgdGhhdCBtYXkgdHJpZ2dlciBhIHJlbnVtYmVyaW5nIGV2 ZW50IHdpdGhvdXQgdGhlIHBoeXNpY2FsIHBvcnQgZmxhcHBpbmcsIHdoaWNoIEkgYmVsaWV2ZSBp cyB2YWxpZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0id29y ZC1icmVhazpicmVhay1hbGw7Ym94LXNpemluZzpib3JkZXItYm94O2JvcmRlci1yYWRpdXM6NHB4 O292ZXJmbG93OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNr Ij5BIHN3aXRjaC1wb3J0IHRoZSBob3N0IGlzIGNvbm5lY3RlZCB0byBtYXkgYmUgbW92ZWQgdG8g YW5vdGhlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0id29yZC1icmVhazpi cmVhay1hbGwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3VibmV0IChWTEFOKSBhcyBhIHJlc3VsdCBvZiBt YW51YWwgc3dpdGNoLXBvcnQgcmVjb25maWd1cmF0aW9uIG9yPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlIHN0eWxlPSJ3b3JkLWJyZWFrOmJyZWFrLWFsbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA4 MDIuMXggcmUtYXV0aGVudGljYXRpb24uIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoZSBzdGF0ZW1lbnQgYWJv dmUgaXMgY2xlYXIgdGhhdCA4MDIuMXggaXMgc2ltcGx5IGFuIGV4YW1wbGUgb2Ygd2hlbiBhIGhv c3QgbWF5IGJlIHNoaWZ0ZWQgYmV0d2VlbiBWTEFOcyBhbmQgYSByZW51bWJlcmluZyBldmVudCBt YXkgb2NjdXIsIGlmIHlvdSBiZWxpZXZlIHRoZSB3b3JkaW5nIGlzbid0IGNsZWFyIGVub3VnaCwg d291bGQgeW91IGJlIGFibGUgdG8gc3VnZ2VzdCBob3cgd2UgbWF5DQogaW1wcm92ZSBpdCBwbGVh c2U/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi1SaWNoPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIE1vbiwgMjYgT2N0IDIwMjAgYXQgMTA6MDQsIFZhc2lsZW5rbyBFZHVhcmQgJmx0Ozxh IGhyZWY9Im1haWx0bzp2YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5r Ij52YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEZlcm5hbmRv LDxicj4NClNvcnJ5LiBJIGhhdmUgc3BvdHRlZCBpdCBqdXN0IG5vdy48YnI+DQpJdCBkb2VzIG5v dCBtYWtlIHNlbnNlIHRvIG1lbnRpb24gODAyLjF4IGFzIHRoZSByZWFzb24gZm9yIHJlbnVtYmVy aW5nIHByb2JsZW0uPGJyPg0KODAyLjF4IG9wZXJhdGVzIHN0cmljdGx5IG9uIEwyLiBTd2l0Y2gg cG9ydCBpcyBibG9ja2VkIGZvciBhbnkgb3RoZXIgdHJhZmZpYyBhdCB0aGF0IHRpbWUuPGJyPg0K SWYgYXV0aGVudGljYXRpb24gd291bGQgZmFpbCB0aGVuIHBvcnQgY291bGQgYmUgcHV0IGludG8g JnF1b3Q7Z3Vlc3QmcXVvdDsgVkxBTi48YnI+DQpCdXQgaW1wb3J0YW50IHBvaW50IHRvIG1lbnRp b24gdGhhdCA4MDIuMXggc3VwcGxpY2FudCBoYXMgZmluaXNoZWQgaXRzIGpvYiAtIGl0IGNvdWxk IG5vdCBhY3RpdmF0ZSBhdXRoZW50aWNhdGlvbiBhZ2Fpbi4gSXQgbmVlZHMgc2FtZSBldmVudCBs aWtlIGxpbmsgdXAvZG93biBvciBhZG1pbiBwdXNoLiBFbnRlcnByaXNlcyBkbyBub3QgbWFuYWdl IGNsaWVudHMgaW4gc3VjaCBhIGR5bmFtaWMgd2F5Ljxicj4NClRoZSBkZWNpc2lvbiB0byBtb3Zl IGhvc3QgZnJvbSAmcXVvdDtndWVzdCZxdW90OyB0byBzb21lIG90aGVyIFZMQU4gaXMgbm90IHJl bGF0ZWQgdG8gODAyLjF4LCBub3QgYXQgYWxsLiBJdCBjb3VsZCBiZSBwcm9iYWJseSBjb25maWd1 cmF0aW9uIHB1c2ggdG8gc3dpdGNoIChOZXRDb25mPykuPGJyPg0KSWYgc3VjaCBiYWQgcHJhY3Rp Y2Ugd291bGQgaGFwcGVuIHRoZW4gaXQgd291bGQgYnJlYWsgY29ubmVjdGl2aXR5IGZvciBJUHY0 IHRvbyAtIERIQ1Agd291bGQgbm90IGhhdmUgYW55IGluZm9ybWF0aW9uIHRoYXQgVkxBTiBoYXMg YmVlbiBjaGFuZ2VzLjxicj4NCkhlbmNlLCBpdCBkb2VzIG5vdCBtYXR0ZXIgd2hhdCBtZWNoYW5p c20gaGFzIGJlZW4gdXNlZCBpbml0aWFsbHkgdG8gcHV0IGhvc3QgaW50byAmcXVvdDtndWVzdCZx dW90OyBWTEFOLiBJdCBjb3VsZCBiZSBzb21ldGhpbmcgb3RoZXIgdGhhbiA4MDIuMXguPGJyPg0K SXQgaXMgaW1wb3J0YW50IHRoYXQgc29tZSBhdXRvbWF0aW9uIHRvb2wgY291bGQgYnJlYWsgSVAg Y29ubmVjdGl2aXR5IHNoaWZ0aW5nIGhvc3RzIGJldHdlZW4gVkxBTnMuPGJyPg0KSXQgaXMgbm90 IHBvc3NpYmxlIHRvIGRldmVsb3AgdGhlIHJlc29sdXRpb24gb24gSVB2NCwgYnV0IGl0IGlzIHBv c3NpYmxlIHRvIGludmVudCBhZGRpdGlvbmFsIHByb3RlY3Rpb24gb24gSVB2Ni48YnI+DQpUaGUg cmVhc29uIGlzIHN0aWxsIHZhbGlkIC0gcHJlY2F1dGlvbnMgbWFrZSBzZW5zZSB0byBoYXZlLiBC dXQgaXQgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCA4MDIuMXguIEl0IGlzIGdlbmVyYWwgVkxBTiBz aHVmZmxpbmcuPGJyPg0KRWR1YXJkPGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LTxicj4NCiZndDsgRnJvbTogdjZvcHMgW21haWx0bzo8YSBocmVmPSJtYWlsdG86djZvcHMtYm91 bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ XSBPbiBCZWhhbGYgT2YgSUVURiBTZWNyZXRhcmlhdDxicj4NCiZndDsgU2VudDogMjIg0L7QutGC 0Y/QsdGA0Y8gMjAyMCDQsy4gMTc6Mjk8YnI+DQomZ3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86b3dl bkBkZWxvbmcuY29tIiB0YXJnZXQ9Il9ibGFuayI+b3dlbkBkZWxvbmcuY29tPC9hPjsgPGEgaHJl Zj0ibWFpbHRvOmRyYWZ0LWlldGYtdjZvcHMtc2xhYWMtcmVudW1AaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj4NCmRyYWZ0LWlldGYtdjZvcHMtc2xhYWMtcmVudW1AaWV0Zi5vcmc8L2E+Ozxicj4N CiZndDsgPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+djZv cHNAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86d2FycmVuQGt1bWFyaS5uZXQiIHRhcmdl dD0iX2JsYW5rIj4NCndhcnJlbkBrdW1hcmkubmV0PC9hPjsgPGEgaHJlZj0ibWFpbHRvOnY2b3Bz LWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnY2b3BzLWNoYWlyc0BpZXRmLm9yZzwv YT47IE93ZW4gRGVMb25nPGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm93ZW5AZGVsb25n LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm93ZW5AZGVsb25nLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyBT dWJqZWN0OiBbdjZvcHNdIERhdGF0cmFja2VyIFN0YXRlIFVwZGF0ZSBOb3RpY2U6ICZsdDtkcmFm dC1pZXRmLXY2b3BzLXNsYWFjLTxicj4NCiZndDsgcmVudW0tMDQudHh0Jmd0Ozxicj4NCiZndDsg PGJyPg0KJmd0OyBJRVNHIHN0YXRlIGNoYW5nZWQ6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE5ldyBT dGF0ZTogSUVTRyBFdmFsdWF0aW9uOjpSZXZpc2VkIEktRCBOZWVkZWQ8YnI+DQomZ3Q7IDxicj4N CiZndDsgKFRoZSBwcmV2aW91cyBzdGF0ZSB3YXMgSUVTRyBFdmFsdWF0aW9uKTxicj4NCiZndDsg PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IERhdGF0cmFja2VyIFVSTDogPGEgaHJlZj0iaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy1zbGFhYy0iIHRhcmdldD0i X2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdjZv cHMtc2xhYWMtPC9hPjxicj4NCiZndDsgcmVudW0vPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4N CiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQomZ3Q7IHY2b3BzIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOnY2b3Bz QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wczwv YT48YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCnY2b3BzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzp2Nm9wc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnY2b3BzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_12e219a6add2417685d386c026dce8e4huaweicom_-- From nobody Tue Oct 27 07:08: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 828993A0CF8 for ; Tue, 27 Oct 2020 07:08:29 -0700 (PDT) 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, 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=helix-net-nz.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zL4H6ed4k1cx for ; Tue, 27 Oct 2020 07:08:26 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 BD9233A03FC for ; Tue, 27 Oct 2020 07:08:26 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id u19so1652950ion.3 for ; Tue, 27 Oct 2020 07:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iOQrKzFNCD2xni4HjOe8Y3BZJ3/u1ggq6QyC5q0nQ+4=; b=vtazVUKqsINcyLrhZ0VRvbLayyXSW02ytjkbWyVpikjB/1FkCqUTbx7xE+7hL6JVTu bkae7vjWrs/irvElBNBWrB/SX91E2EQUiaQaHUN+kfFTniTIWTIdlFePVghCfEVlud1p V5AGnuN01yU22jyXRtCzxnn/wgtZRPW6JrxpkIeBuWO7aWM8jwoLqQL//wjaov6NhOfV mUEQl/nQAAajQ+q6Uu1WxXH78RxcZoYTLYL//ui8bM6Pi2j1wHh59oT8b3ceLleY3D62 LWPK/ye7s38RJCya0Fa9bNtjMSp9lTnMgHBx0cqdtoSBrjMdhIhYW64Q7vRF/pqfUheR XY2w== 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=iOQrKzFNCD2xni4HjOe8Y3BZJ3/u1ggq6QyC5q0nQ+4=; b=TjScqIm+AT/m48JqqhD7OBKffu5Naj26TQF/6l1tPxTPF7PVrtoEg/Tm9xqhKXojg3 KvDZ8S03CIZ09Gq/qzxs5L+lX/uSEvIwQ4mBHjqxckBjDhFqBOxbV6+Z04ufSF9Xkjpy pic1nvGfIOrn7Q0EBkekjrUmjVpCVD6BDZO/Zu02UPFdck+nXmHhND+BSmClTkXQmQgy p8HFFTvfIkhNx+C53gwOCuXtFD9H1980ff0ecArr9fig67afy0q4qjh+2lMejW/KDRiv G+hcEDkae3iO/h03U5c6/mNetbnBdj/L5h/p00Kf9zOOPXEceAL4D7Jad0Jc9KOnY4m2 DjWg== X-Gm-Message-State: AOAM531DKbhVveR/ts4RLdjsiky+WXbfu6HcPAoBd6qB6cvMK3WBfQ9+ WieavcCFYWv+WuYIahMBiS9Y1hAcYbPJ4g== X-Google-Smtp-Source: ABdhPJw39zRVK3qFbJspi5yBMepvJPn8whO4bk9Sef6jXXrBrnX7lGq2qEwL3BU9aZNwDpTvh/t++g== X-Received: by 2002:a5d:8e0a:: with SMTP id e10mr2294653iod.169.1603807705329; Tue, 27 Oct 2020 07:08:25 -0700 (PDT) Received: from mail-il1-f179.google.com (mail-il1-f179.google.com. [209.85.166.179]) by smtp.gmail.com with ESMTPSA id c3sm1105037ila.47.2020.10.27.07.08.24 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2020 07:08:24 -0700 (PDT) Received: by mail-il1-f179.google.com with SMTP id a20so1588807ilk.13 for ; Tue, 27 Oct 2020 07:08:24 -0700 (PDT) X-Received: by 2002:a05:6e02:c:: with SMTP id h12mr2107701ilr.177.1603807703767; Tue, 27 Oct 2020 07:08:23 -0700 (PDT) MIME-Version: 1.0 References: <54abce3e4abc449fa896a6ae318a6128@huawei.com> <12e219a6add2417685d386c026dce8e4@huawei.com> In-Reply-To: <12e219a6add2417685d386c026dce8e4@huawei.com> From: Richard Patterson Date: Tue, 27 Oct 2020 14:08:12 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Vasilenko Eduard Cc: IPv6 Operations Content-Type: multipart/alternative; boundary="00000000000078a3f305b2a794a9" Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance 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, 27 Oct 2020 14:08:33 -0000 --00000000000078a3f305b2a794a9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable So do you believe the rest of the paragraph that provides the example, is wrong? In particular, there has been evidence that some 802.1x supplicants do not reset network settings after successful 802.1x authentication. So if a host had failed 802.1x authentication for some reason, was placed in a "quarantine" VLAN and then got successfully authenticated later on, it might end up having IPv6 addresses from both old ("quarantine") and new VLANs. On Tue, 27 Oct 2020 at 13:05, Vasilenko Eduard wrote: > Hi Richard, > > I believe that it is misleading. > > Because 802.1x itself is not capable to move between VLANs after address > accepted. 802.1x could move between VLANs before address accepted =E2=80= =93 it is > not relevant here. > > Something else should push between VLANs to break IP connectivity. It > could not be 802.1x. It is better not to mention 802.1x. It is not > important what was the mechanism that initially connected host to 1st > VLAN. > > It could be no any special mechanism at all. Or it could be > =E2=80=9CMAC-authentication=E2=80=9D. It does not matter. > > > > It is important what could be the mechanism that moved between VLANs. I d= o > assume some sort of configuration change by CLI of Netconf. > > But it is not 802.1x anyway. > > Eduard > > *From:* Richard Patterson [mailto:richard@helix.net.nz] > *Sent:* 27 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2020 =D0=B3. 15:48 > *To:* Vasilenko Eduard > *Cc:* IPv6 Operations > *Subject:* Re: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance > > > > Hi Eduard, > > > > We're not pointing out any interoperation with 802.1x specifically, we > were just using it as an example that may trigger a renumbering event > without the physical port flapping, which I believe is valid. > > > > A switch-port the host is connected to may be moved to another > > subnet (VLAN) as a result of manual switch-port reconfiguration or > > 802.1x re-authentication. > > > > I think the statement above is clear that 802.1x is simply an example of > when a host may be shifted between VLANs and a renumbering event may occu= r, > if you believe the wording isn't clear enough, would you be able to sugge= st > how we may improve it please? > > > > -Rich > > > > On Mon, 26 Oct 2020 at 10:04, Vasilenko Eduard < > vasilenko.eduard@huawei.com> wrote: > > Hi Fernando, > Sorry. I have spotted it just now. > It does not make sense to mention 802.1x as the reason for renumbering > problem. > 802.1x operates strictly on L2. Switch port is blocked for any other > traffic at that time. > If authentication would fail then port could be put into "guest" VLAN. > But important point to mention that 802.1x supplicant has finished its jo= b > - it could not activate authentication again. It needs same event like li= nk > up/down or admin push. Enterprises do not manage clients in such a dynami= c > way. > The decision to move host from "guest" to some other VLAN is not related > to 802.1x, not at all. It could be probably configuration push to switch > (NetConf?). > If such bad practice would happen then it would break connectivity for > IPv4 too - DHCP would not have any information that VLAN has been changes= . > Hence, it does not matter what mechanism has been used initially to put > host into "guest" VLAN. It could be something other than 802.1x. > It is important that some automation tool could break IP connectivity > shifting hosts between VLANs. > It is not possible to develop the resolution on IPv4, but it is possible > to invent additional protection on IPv6. > The reason is still valid - precautions make sense to have. But it has > nothing to do with 802.1x. It is general VLAN shuffling. > Eduard > > -----Original Message----- > > From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of IETF > Secretariat > > Sent: 22 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2020 =D0=B3. 17:29 > > To: owen@delong.com; draft-ietf-v6ops-slaac-renum@ietf.org; > > v6ops@ietf.org; warren@kumari.net; v6ops-chairs@ietf.org; Owen DeLong > > > > Subject: [v6ops] Datatracker State Update Notice: > > renum-04.txt> > > > > IESG state changed: > > > > New State: IESG Evaluation::Revised I-D Needed > > > > (The previous state was IESG Evaluation) > > > > > > Datatracker URL: > https://datatracker.ietf.org/doc/draft-ietf-v6ops-slaac- > > renum/ > > > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --00000000000078a3f305b2a794a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So do you believe the rest of the paragraph that provides = the example, is wrong?

In particular, there has been evidence
      that some 802.1x supplicants do not reset network settings after
      successful 802.1x authentication.  So if a host had failed 802.1x
      authentication for some reason, was placed in a "quarantine"=
; VLAN
      and then got successfully authenticated later on, it might end up
      having IPv6 addresses from both old ("quarantine") and new =
VLANs.

On Tue, 27 Oct 2020 at 13:05, Vasilenko Eduard <vasilenko.eduard@huawei.com>= ; wrote:

Hi Richard,

I believe that it is misleading.

Because 802.1x itself is not capable to move= between VLANs after address accepted. 802.1x could move between VLANs befo= re address accepted =E2=80=93 it is not relevant here.

Something else should push between VLANs to = break IP connectivity. It could not be 802.1x. It is better not to mention = 802.1x. It is not important what was the mechanism that initially connected host to 1st VLAN.<= /u>

It could be no any special mechanism at all.= Or it could be =E2=80=9CMAC-authentication=E2=80=9D. It does not matter.

=C2=A0

It is important what could be the mechanism = that moved between VLANs. I do assume some sort of configuration change by = CLI of Netconf.

But it is not 802.1x anyway.

Eduard

From: Richard Patterson [mailto:richard@helix.net.nz]
Sent: 27 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2020 =D0=B3. 15:= 48
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: IPv6 Operations <v6ops@ietf.org>
Subject: Re: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x releva= nce

=C2=A0

Hi Eduard,

=C2=A0

We're not pointing out any interoperation with 8= 02.1x specifically, we were just using it as an example that may trigger a = renumbering event without the physical port flapping, which I believe is va= lid.

=C2=A0

A switch-port t=
he host is connected to may be moved to another
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 subnet (VLAN) as a result of manual sw=
itch-port reconfiguration or
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 802.1x re-authentication.

=C2=A0

I think the statement above is clear that 802.1x is = simply an example of when a host may be shifted between VLANs and a renumbe= ring event may occur, if you believe the wording isn't clear enough, wo= uld you be able to suggest how we may improve it please?

=C2=A0

-Rich

=C2=A0

On Mon, 26 Oct 2020 at 10:04, Vasilenko Eduard <<= a href=3D"mailto:vasilenko.eduard@huawei.com" target=3D"_blank">vasilenko.e= duard@huawei.com> wrote:

Hi Fernando,
Sorry. I have spotted it just now.
It does not make sense to mention 802.1x as the reason for renumbering prob= lem.
802.1x operates strictly on L2. Switch port is blocked for any other traffi= c at that time.
If authentication would fail then port could be put into "guest" = VLAN.
But important point to mention that 802.1x supplicant has finished its job = - it could not activate authentication again. It needs same event like link= up/down or admin push. Enterprises do not manage clients in such a dynamic= way.
The decision to move host from "guest" to some other VLAN is not = related to 802.1x, not at all. It could be probably configuration push to s= witch (NetConf?).
If such bad practice would happen then it would break connectivity for IPv4= too - DHCP would not have any information that VLAN has been changes.
Hence, it does not matter what mechanism has been used initially to put hos= t into "guest" VLAN. It could be something other than 802.1x.
It is important that some automation tool could break IP connectivity shift= ing hosts between VLANs.
It is not possible to develop the resolution on IPv4, but it is possible to= invent additional protection on IPv6.
The reason is still valid - precautions make sense to have. But it has noth= ing to do with 802.1x. It is general VLAN shuffling.
Eduard
> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of IETF Secretariat
> Sent: 22 =D0=BE=D0=BA=D1=82=D1=8F=D0=B1=D1=80=D1=8F 2020 =D0=B3. 17:29=
> To: owen@delong.c= om; draft-ietf-v6ops-slaac-renum@ietf.org;
> v6ops@ietf.org= ; warren@kumari.net; v6ops-chairs@ietf.org; Owen DeLong
> <owen@delong.c= om>
> Subject: [v6ops] Datatracker State Update Notice: <draft-ietf-v6ops= -slaac-
> renum-04.txt>
>
> IESG state changed:
>
> New State: IESG Evaluation::Revised I-D Needed
>
> (The previous state was IESG Evaluation)
>
>
> Datatracker URL: https://datatracker.ietf.org/doc/draft-ietf-v6ops-slaac-
> renum/
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org=
> https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--00000000000078a3f305b2a794a9-- From nobody Tue Oct 27 07:28: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 08B913A0D3D for ; Tue, 27 Oct 2020 07:28:22 -0700 (PDT) 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 UpGigWDCzUyz for ; Tue, 27 Oct 2020 07:28:20 -0700 (PDT) Received: from mail-qv1-xf31.google.com (mail-qv1-xf31.google.com [IPv6:2607:f8b0:4864:20::f31]) (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 4F2C33A0D3B for ; Tue, 27 Oct 2020 07:28:11 -0700 (PDT) Received: by mail-qv1-xf31.google.com with SMTP id t20so717031qvv.8 for ; Tue, 27 Oct 2020 07:28:10 -0700 (PDT) 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=PS7+iwI9B+AcijtNyrlykaLT1UO7AlhueZ74m80qlL8=; b=fSMNAJP8tspUBQBI+ZL3kC2H8Tpck8S3UeqIvy0kVPhbRJAJUX5D5Ga6K4eH41yWLK tYUEN9mhQXDj/NcorsjgCh8goKGs7FDxNe5R0kD4wD39aKyXH/1Hx3RgVzb20nOZp020 TzaDh6ZMxYsiFMZjWTC+/fpU84LWnv8Qou/PY/BxF4uUEu+rqRC/SWxgLOELja1dnj5t Qf0WtMgsuC0PsVu+LvtL859hcbVett/VK7LPLbDN+Ju+8r4ggdz1NpuETlLcfKtfxmCN Cn7blGVlQwYIlPnLnyqtYy3Lvu9YLNs30VDIkYN1PogtvBYRbqttfHK7iweCWRcJvQpE 5cTg== 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=PS7+iwI9B+AcijtNyrlykaLT1UO7AlhueZ74m80qlL8=; b=uN0yizyDdBZIOlhTT4VaTcoEE4cp8yegsGPuZFEKel0LaddJpEghJEu333DHeVr2EK dP7o1JVFoXslXe1XcXx9SDyzebkrBtZgnbXHRdf1a8+0NUVxDZSUo4MX5D8YHDuROGOo bE8eJOqKQ+MeCDIHsRuMiRgdK1b5YYzz3UzGjYv0f/BW15KiafkKYGMkGnYmYfud8CDX WY2UJtISBiD929ANHKEvl3HOO25UfzApG34SXR4wEyDJZ1JWZzf/OaDU/fFa8SBvwaWA +gyjn9Bf0xF5pvbk1JfiKjjBYe2MHdCxNyGPO2SFCF2OWoTPjGwc2eUgwHZ132GZm1Lq o/GQ== X-Gm-Message-State: AOAM533Voui+dsdiGUR8ZpT4QrrrjAsvy7tNpR9ObyfGSntI3PiT04uN OXR6q7yNagV3zrWcu1QpRfKCDQ== X-Google-Smtp-Source: ABdhPJy1PSg7rbO6KRBYGgV0hbjmb8qQkA5vFCwJMqoW8dF22H6kk4U3jQLxXP5cW4IUxtSZVbp0sQ== X-Received: by 2002:a05:6214:b84:: with SMTP id fe4mr2745589qvb.3.1603808889903; Tue, 27 Oct 2020 07:28:09 -0700 (PDT) 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 a21sm725601qkk.98.2020.10.27.07.28.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Oct 2020 07:28:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Tue, 27 Oct 2020 10:28:07 -0400 Message-Id: References: <12e219a6add2417685d386c026dce8e4@huawei.com> Cc: Richard Patterson , IPv6 Operations In-Reply-To: <12e219a6add2417685d386c026dce8e4@huawei.com> To: Vasilenko Eduard X-Mailer: iPhone Mail (18B79) Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance 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, 27 Oct 2020 14:28:22 -0000 On Oct 27, 2020, at 09:06, Vasilenko Eduard wr= ote: > Because 802.1x itself is not capable to move between VLANs after address a= ccepted. 802.1x is individually implemented on a variety of different operating syste= ms. A categorical statement like this doesn=E2=80=99t make sense. On which o= perating systems do you know your statement to be true? You haven=E2=80=99t s= aid.=20 Also, 802.1x is a layer 2 protocol and knows nothing of layer three unless t= he attack on a particular device OSS programmed with a heuristic for how to b= ehave once layer 3 is up.=20 Can you explain why you are so certain you are right about this rather than r= estating it as fact with no justification?= From nobody Tue Oct 27 10:14: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 BBA863A1256 for ; Tue, 27 Oct 2020 10:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-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 XwuDlm4j7bk4 for ; Tue, 27 Oct 2020 10:14:19 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 895063A1255 for ; Tue, 27 Oct 2020 10:14:19 -0700 (PDT) Received: from lhreml706-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 14AE8B7B8B1A7D0F363E; Tue, 27 Oct 2020 17:14:18 +0000 (GMT) Received: from msceml703-chm.china.huawei.com (10.219.141.161) by lhreml706-chm.china.huawei.com (10.201.108.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Tue, 27 Oct 2020 17:14:17 +0000 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml703-chm.china.huawei.com (10.219.141.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 27 Oct 2020 20:14:17 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Tue, 27 Oct 2020 20:14:17 +0300 From: Vasilenko Eduard To: Ted Lemon CC: Richard Patterson , IPv6 Operations Thread-Topic: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance Thread-Index: AdarfiOiihVVds8iT0KdHPG3+auXlwAyC3uAAAafLvD//+bfgP//oBeg Date: Tue, 27 Oct 2020 17:14:16 +0000 Message-ID: References: <12e219a6add2417685d386c026dce8e4@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.197.128] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance 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, 27 Oct 2020 17:14:21 -0000 SGkgVGVkLA0KSSBoYXZlIGludmVzdGlnYXRlZCAzIHZlbmRvcnMuIDgwMi4xeCBpcyB0byBmaW5p c2ggdGhlIHBhdGNoY29yZCBjb25uZWN0aW9uIG9uIEwyLiBMMyBjb3VsZCBoYXBwZW4gb25seSBh ZnRlciB0aGlzLiBJZiBhbnkgdmVuZG9yIHdvdWxkIGltcGxlbWVudCBpdCBkaWZmZXJlbnRseSAt IGl0IHdvdWxkIGJlIGludGVyZXN0aW5nIHRvIGhlYXIuDQpCdXQgd2h5IHdlIGhhdmUgcmV2ZXJ0 ZWQgdGhpcyBxdWVzdGlvbj8gSSBiZWxpZXZlIHRoYXQgcHJvdmVzIHNob3VsZCBiZSBmcm9tIHRo ZSBvbmUgd2hvIGhhcyBwdXQgODAyLjF4IGFzIHRoZSByZWFzb24gaW50byB0aGUgZG9jdW1lbnQu DQpJdCB3YXMgbm90IG1lLg0KRWR1YXJkDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IFRlZCBMZW1vbiBbbWFpbHRvOm1lbGxvbkBmdWd1ZS5jb21dDQo+IFNlbnQ6IDI3INC+ 0LrRgtGP0LHRgNGPIDIwMjAg0LMuIDE3OjI4DQo+IFRvOiBWYXNpbGVua28gRWR1YXJkIDx2YXNp bGVua28uZWR1YXJkQGh1YXdlaS5jb20+DQo+IENjOiBSaWNoYXJkIFBhdHRlcnNvbiA8cmljaGFy ZEBoZWxpeC5uZXQubno+OyBJUHY2IE9wZXJhdGlvbnMNCj4gPHY2b3BzQGlldGYub3JnPg0KPiBT dWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLXNsYWFjLXJlbnVtLTA0IC0gODAy LjF4IHJlbGV2YW5jZQ0KPiANCj4gT24gT2N0IDI3LCAyMDIwLCBhdCAwOTowNiwgVmFzaWxlbmtv IEVkdWFyZCA8dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tPg0KPiB3cm90ZToNCj4gPiBCZWNh dXNlIDgwMi4xeCBpdHNlbGYgaXMgbm90IGNhcGFibGUgdG8gbW92ZSBiZXR3ZWVuIFZMQU5zIGFm dGVyIGFkZHJlc3MNCj4gYWNjZXB0ZWQuDQo+IA0KPiA4MDIuMXggaXMgaW5kaXZpZHVhbGx5IGlt cGxlbWVudGVkIG9uIGEgdmFyaWV0eSBvZiBkaWZmZXJlbnQgb3BlcmF0aW5nIHN5c3RlbXMuIEEN Cj4gY2F0ZWdvcmljYWwgc3RhdGVtZW50IGxpa2UgdGhpcyBkb2VzbuKAmXQgbWFrZSBzZW5zZS4g T24gd2hpY2ggb3BlcmF0aW5nIHN5c3RlbXMNCj4gZG8geW91IGtub3cgeW91ciBzdGF0ZW1lbnQg dG8gYmUgdHJ1ZT8gWW91IGhhdmVu4oCZdCBzYWlkLg0KPiANCj4gQWxzbywgODAyLjF4IGlzIGEg bGF5ZXIgMiBwcm90b2NvbCBhbmQga25vd3Mgbm90aGluZyBvZiBsYXllciB0aHJlZSB1bmxlc3Mg dGhlDQo+IGF0dGFjayBvbiBhIHBhcnRpY3VsYXIgZGV2aWNlIE9TUyBwcm9ncmFtbWVkIHdpdGgg YSBoZXVyaXN0aWMgZm9yIGhvdyB0bw0KPiBiZWhhdmUgb25jZSBsYXllciAzIGlzIHVwLg0KPiAN Cj4gQ2FuIHlvdSBleHBsYWluIHdoeSB5b3UgYXJlIHNvIGNlcnRhaW4geW91IGFyZSByaWdodCBh Ym91dCB0aGlzIHJhdGhlciB0aGFuDQo+IHJlc3RhdGluZyAgaXQgYXMgZmFjdCB3aXRoIG5vIGp1 c3RpZmljYXRpb24/DQo= From nobody Tue Oct 27 10:23: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 B0A7E3A0D58 for ; Tue, 27 Oct 2020 10:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 e6m0SMf8OUdX for ; Tue, 27 Oct 2020 10:23:10 -0700 (PDT) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 55BCE3A0D52 for ; Tue, 27 Oct 2020 10:23:09 -0700 (PDT) Received: by mail-qv1-xf29.google.com with SMTP id bl9so1027162qvb.10 for ; Tue, 27 Oct 2020 10:23:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=DEgzu53cwhLyV4jDrvHEML6xqHTkU4ufTv0SNxnPiJ0=; b=D/k1knzTTlBcYGXRNJvnelG1t+/dCftMLfSr2fV9rHcZmeW5IXizapgoeYIastp9pF bzqPvPj0rhaCnxaCgwDqVV6CXaQrlIVVN25CPE0F29zyO+q3gE2lS8R6tGSueYSdLbiB ECGdLlzHCi4h1vKGidtv+85odzyk6F8Qlk5/+hy0oIHwXoU0zU3J5YpixT96W5CrLRkT qt2VJFo6BH4bxpDZL25Sov6AzrbTmPB6ApqWW6KJ1gpfOjSvzCNk7Vzvj9ysMaCpvbCK R3D3VCIRzCtgtFeWp0WvG1Gn9H+Xs6yB77Rpgd2zK2DCiEorSHxNn04v6w/pAeIN/SVt EESg== 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=DEgzu53cwhLyV4jDrvHEML6xqHTkU4ufTv0SNxnPiJ0=; b=cIAoZBwy2hCEpr+MDsvhtp9nEwbyBprCkEfEMtVbNwQHGf6VNdYks/YTtMwarRYT5v h5CXFgjEaK6w0bktsDp9//mPi7C58WnpyR/B2nxpZPTllGDxdZWpyyRX00X6qlBq37ps cO6kuEAUzM6Z7P9UtDew2WfYCwPyeUe20EOh9z2rgZoOh9WMbnEyfRINmySwSuO/YPvP pMC8MJvwTn3kCU0tOsiNXMGIcFLdkGsGo9PzfXz6kWiemp5MAp1ReZ8w7cJdqRTsuVHd J/WmqtcP6IkXwEdtgg8TE3W7bN9mWHavD43ziqy04V1ah9lwnfhfDdOU1f7BguKR+WBs Bgfw== X-Gm-Message-State: AOAM532qVtussg0M8ArDsRC2H0a3JOgjPdIz15tUtRcuQjEk/wMc3Tl0 d81XenbApEzcYtMci3BnHVAZUw== X-Google-Smtp-Source: ABdhPJx7y1ZlA+aDy1i8kHTZJSVvwTvGSRcFVHBE3na8XYHt8f95Ozl74MJQTrxz5TjLhFB9OvZoaw== X-Received: by 2002:ad4:5387:: with SMTP id i7mr3160344qvv.43.1603819388922; Tue, 27 Oct 2020 10:23:08 -0700 (PDT) Received: from [192.168.4.70] (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id n3sm1176409qta.10.2020.10.27.10.23.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Oct 2020 10:23:07 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_5791BBC8-07FC-4854-887E-33F2AC4AC481" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Tue, 27 Oct 2020 13:23:05 -0400 In-Reply-To: Cc: Richard Patterson , IPv6 Operations To: Vasilenko Eduard References: <12e219a6add2417685d386c026dce8e4@huawei.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance 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, 27 Oct 2020 17:23:12 -0000 --Apple-Mail=_5791BBC8-07FC-4854-887E-33F2AC4AC481 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Oct 27, 2020, at 1:14 PM, Vasilenko Eduard = wrote: > I have investigated 3 vendors. 802.1x is to finish the patchcord = connection on L2. L3 could happen only after this. If any vendor would = implement it differently - it would be interesting to hear. > But why we have reverted this question? I believe that proves should = be from the one who has put 802.1x as the reason into the document. The problem with your theory is that you haven=E2=80=99t actually = understood the point you are contradicting. The situation that was = described is as follows: 1. host attempts to connect to 802.1x, is unable to authenticate, is = connected to quarantine vlan 2. host acquires l3 info for quarantine vlan 3. user acquires authentication information for 802.1x through the = quarantine process 4. user authenticates to 802.1x 5. host is now connected to internal vlan, and is no longer connected to = quarantine vlan 6. host layer 3 does not see a link state transition, and does not = invalidate state acquired on quarantine vlan 7. communication is unreliable because quarantine vlan addresses are not = valid, but are considered valid candidates for use. Does this make the situation clearer? --Apple-Mail=_5791BBC8-07FC-4854-887E-33F2AC4AC481 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Oct 27, 2020, at 1:14 PM, Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote:
I have investigated 3 vendors. 802.1x is to finish the = patchcord connection on L2. L3 could happen only after this. If any = vendor would implement it differently - it would be interesting to = hear.
But why we = have reverted this question? I believe that proves should be from the = one who has put 802.1x as the reason into the = document.

The problem with your theory is that you haven=E2=80=99t = actually understood the point you are contradicting.  The situation = that was described is as follows:

1. host attempts to connect to 802.1x, = is unable to authenticate, is connected to quarantine vlan
2. host acquires l3 info for quarantine vlan
3. user acquires authentication information for 802.1x = through the quarantine process
4. user = authenticates to 802.1x
5. host is now connected to = internal vlan, and is no longer connected to quarantine vlan
6. host layer 3 does not see a link state transition, and = does not invalidate state acquired on quarantine vlan
7. communication is unreliable because quarantine vlan = addresses are not valid, but are considered valid candidates for = use.

Does this = make the situation clearer?

= --Apple-Mail=_5791BBC8-07FC-4854-887E-33F2AC4AC481-- From nobody Tue Oct 27 10:30:12 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 64DC63A1265 for ; Tue, 27 Oct 2020 10:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 HgmJBOY72DcK for ; Tue, 27 Oct 2020 10:30:08 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 6ED633A1506 for ; Tue, 27 Oct 2020 10:29:45 -0700 (PDT) Received: from lhreml708-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 6CCA2AE535DFF074D3FE; Tue, 27 Oct 2020 17:29:42 +0000 (GMT) Received: from msceml701-chm.china.huawei.com (10.219.141.159) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Tue, 27 Oct 2020 17:29:41 +0000 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml701-chm.china.huawei.com (10.219.141.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 27 Oct 2020 20:29:41 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Tue, 27 Oct 2020 20:29:41 +0300 From: Vasilenko Eduard To: Richard Patterson CC: IPv6 Operations Thread-Topic: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance Thread-Index: AdarfiOiihVVds8iT0KdHPG3+auXlwAyC3uAAAafLvD//+FOAP//mTIg Date: Tue, 27 Oct 2020 17:29:40 +0000 Message-ID: <889d7d6719ee44cea52020bb37383571@huawei.com> References: <54abce3e4abc449fa896a6ae318a6128@huawei.com> <12e219a6add2417685d386c026dce8e4@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.197.128] Content-Type: multipart/alternative; boundary="_000_889d7d6719ee44cea52020bb37383571huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance 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, 27 Oct 2020 17:30:10 -0000 --_000_889d7d6719ee44cea52020bb37383571huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLg0KVGhpcyDigJxhbmQgdGhlbiBnb3Qgc3VjY2Vzc2Z1bGx5IGF1dGhlbnRpY2F0ZWQgbGF0 ZXIgb27igJ0gbWlzbGVhZCB0aGF0IGl0IGlzIHNvbWVob3cgcmVsYXRlZCB0byB0aGUgcHJldmlv dXMgc2VudGVuY2UgYWJvdXQgODAyLjF4Lg0KSXQgaXMgbm90Lg0KSXQgY291bGQgaGFwcGVuIGJ5 IG90aGVyIG1lY2hhbmlzbSwgbm90IGJ5IDgwMi4xeC4NCg0KSW4gZ2VuZXJhbCwgaXQgZG9lcyBu b3QgbWFrZSBzZW5zZSB0byBtZW50aW9uIDgwMi4xeCBpbiB0aGlzIGRvY3VtZW50LCBiZWNhdXNl IGl0IGlzIG5vdCByZWxhdGVkLg0KSXQgaXMgYmV0dGVyIHRvIHJlcGxhY2UgaXQgYnk6DQoNCuKA nFRoZSBob3N0IGNvdWxkIGJlIGNvbm5lY3RlZCBpbml0aWFsbHkgdG8gVkxBTiB3aXRoIElQdjYg cHJlZml4LCB0aGVuIGxhdGVyIGhvc3QgbWF5IGJlIG1vdmVkIHRvIGFub3RoZXIgVkxBTiB3aXRo IGRpZmZlcmVudCBJUHY2IHByZWZpeCAoaHVtYW4gbWlzdGFrZSwgYmFkIHN5c3RlbSBkZXNpZ24s IEwyIHRvcG9sb2d5IGNoYW5nZSkuIEl0IG1pZ2h0IGVuZCB1cCBoYXZpbmcgSVB2NiBhZGRyZXNz ZXMgZnJvbSBib3RoIG9sZCBhbmQgbmV3IFZMQU5zLiBTb3VyY2luZyB0cmFmZmljIGZyb20gdGhl IG9sZCBwcmVmaXggY291bGQgbGVhZCB0byB0aGUgdHJhZmZpYyBkcm9wIGJ5IFJQRiBpbiB1cHN0 cmVhbSBkaXJlY3Rpb24sIGRvd25zdHJlYW0gdHJhZmZpYyBtYXkgYmUgbm90IGZvcndhcmRlZCB0 byBwcm9wZXIgbGluay4g4oCdDQoNCkVkdWFyZA0KRnJvbTogUmljaGFyZCBQYXR0ZXJzb24gW21h aWx0bzpyaWNoYXJkQGhlbGl4Lm5ldC5uel0NClNlbnQ6IDI3INC+0LrRgtGP0LHRgNGPIDIwMjAg 0LMuIDE3OjA4DQpUbzogVmFzaWxlbmtvIEVkdWFyZCA8dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWku Y29tPg0KQ2M6IElQdjYgT3BlcmF0aW9ucyA8djZvcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog W3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLXNsYWFjLXJlbnVtLTA0IC0gODAyLjF4IHJlbGV2YW5j ZQ0KDQpTbyBkbyB5b3UgYmVsaWV2ZSB0aGUgcmVzdCBvZiB0aGUgcGFyYWdyYXBoIHRoYXQgcHJv dmlkZXMgdGhlIGV4YW1wbGUsIGlzIHdyb25nPw0KDQoNCkluIHBhcnRpY3VsYXIsIHRoZXJlIGhh cyBiZWVuIGV2aWRlbmNlDQoNCiAgICAgIHRoYXQgc29tZSA4MDIuMXggc3VwcGxpY2FudHMgZG8g bm90IHJlc2V0IG5ldHdvcmsgc2V0dGluZ3MgYWZ0ZXINCg0KICAgICAgc3VjY2Vzc2Z1bCA4MDIu MXggYXV0aGVudGljYXRpb24uICBTbyBpZiBhIGhvc3QgaGFkIGZhaWxlZCA4MDIuMXgNCg0KICAg ICAgYXV0aGVudGljYXRpb24gZm9yIHNvbWUgcmVhc29uLCB3YXMgcGxhY2VkIGluIGEgInF1YXJh bnRpbmUiIFZMQU4NCg0KICAgICAgYW5kIHRoZW4gZ290IHN1Y2Nlc3NmdWxseSBhdXRoZW50aWNh dGVkIGxhdGVyIG9uLCBpdCBtaWdodCBlbmQgdXANCg0KICAgICAgaGF2aW5nIElQdjYgYWRkcmVz c2VzIGZyb20gYm90aCBvbGQgKCJxdWFyYW50aW5lIikgYW5kIG5ldyBWTEFOcy4NCg0KT24gVHVl LCAyNyBPY3QgMjAyMCBhdCAxMzowNSwgVmFzaWxlbmtvIEVkdWFyZCA8dmFzaWxlbmtvLmVkdWFy ZEBodWF3ZWkuY29tPG1haWx0bzp2YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb20+PiB3cm90ZToN CkhpIFJpY2hhcmQsDQpJIGJlbGlldmUgdGhhdCBpdCBpcyBtaXNsZWFkaW5nLg0KQmVjYXVzZSA4 MDIuMXggaXRzZWxmIGlzIG5vdCBjYXBhYmxlIHRvIG1vdmUgYmV0d2VlbiBWTEFOcyBhZnRlciBh ZGRyZXNzIGFjY2VwdGVkLiA4MDIuMXggY291bGQgbW92ZSBiZXR3ZWVuIFZMQU5zIGJlZm9yZSBh ZGRyZXNzIGFjY2VwdGVkIOKAkyBpdCBpcyBub3QgcmVsZXZhbnQgaGVyZS4NClNvbWV0aGluZyBl bHNlIHNob3VsZCBwdXNoIGJldHdlZW4gVkxBTnMgdG8gYnJlYWsgSVAgY29ubmVjdGl2aXR5LiBJ dCBjb3VsZCBub3QgYmUgODAyLjF4LiBJdCBpcyBiZXR0ZXIgbm90IHRvIG1lbnRpb24gODAyLjF4 LiBJdCBpcyBub3QgaW1wb3J0YW50IHdoYXQgd2FzIHRoZSBtZWNoYW5pc20gdGhhdCBpbml0aWFs bHkgY29ubmVjdGVkIGhvc3QgdG8gMXN0IFZMQU4uDQpJdCBjb3VsZCBiZSBubyBhbnkgc3BlY2lh bCBtZWNoYW5pc20gYXQgYWxsLiBPciBpdCBjb3VsZCBiZSDigJxNQUMtYXV0aGVudGljYXRpb27i gJ0uIEl0IGRvZXMgbm90IG1hdHRlci4NCg0KSXQgaXMgaW1wb3J0YW50IHdoYXQgY291bGQgYmUg dGhlIG1lY2hhbmlzbSB0aGF0IG1vdmVkIGJldHdlZW4gVkxBTnMuIEkgZG8gYXNzdW1lIHNvbWUg c29ydCBvZiBjb25maWd1cmF0aW9uIGNoYW5nZSBieSBDTEkgb2YgTmV0Y29uZi4NCkJ1dCBpdCBp cyBub3QgODAyLjF4IGFueXdheS4NCkVkdWFyZA0KRnJvbTogUmljaGFyZCBQYXR0ZXJzb24gW21h aWx0bzpyaWNoYXJkQGhlbGl4Lm5ldC5uejxtYWlsdG86cmljaGFyZEBoZWxpeC5uZXQubno+XQ0K U2VudDogMjcg0L7QutGC0Y/QsdGA0Y8gMjAyMCDQsy4gMTU6NDgNClRvOiBWYXNpbGVua28gRWR1 YXJkIDx2YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb208bWFpbHRvOnZhc2lsZW5rby5lZHVhcmRA aHVhd2VpLmNvbT4+DQpDYzogSVB2NiBPcGVyYXRpb25zIDx2Nm9wc0BpZXRmLm9yZzxtYWlsdG86 djZvcHNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1z bGFhYy1yZW51bS0wNCAtIDgwMi4xeCByZWxldmFuY2UNCg0KSGkgRWR1YXJkLA0KDQpXZSdyZSBu b3QgcG9pbnRpbmcgb3V0IGFueSBpbnRlcm9wZXJhdGlvbiB3aXRoIDgwMi4xeCBzcGVjaWZpY2Fs bHksIHdlIHdlcmUganVzdCB1c2luZyBpdCBhcyBhbiBleGFtcGxlIHRoYXQgbWF5IHRyaWdnZXIg YSByZW51bWJlcmluZyBldmVudCB3aXRob3V0IHRoZSBwaHlzaWNhbCBwb3J0IGZsYXBwaW5nLCB3 aGljaCBJIGJlbGlldmUgaXMgdmFsaWQuDQoNCg0KQSBzd2l0Y2gtcG9ydCB0aGUgaG9zdCBpcyBj b25uZWN0ZWQgdG8gbWF5IGJlIG1vdmVkIHRvIGFub3RoZXINCg0KICAgICAgc3VibmV0IChWTEFO KSBhcyBhIHJlc3VsdCBvZiBtYW51YWwgc3dpdGNoLXBvcnQgcmVjb25maWd1cmF0aW9uIG9yDQoN CiAgICAgIDgwMi4xeCByZS1hdXRoZW50aWNhdGlvbi4NCg0KSSB0aGluayB0aGUgc3RhdGVtZW50 IGFib3ZlIGlzIGNsZWFyIHRoYXQgODAyLjF4IGlzIHNpbXBseSBhbiBleGFtcGxlIG9mIHdoZW4g YSBob3N0IG1heSBiZSBzaGlmdGVkIGJldHdlZW4gVkxBTnMgYW5kIGEgcmVudW1iZXJpbmcgZXZl bnQgbWF5IG9jY3VyLCBpZiB5b3UgYmVsaWV2ZSB0aGUgd29yZGluZyBpc24ndCBjbGVhciBlbm91 Z2gsIHdvdWxkIHlvdSBiZSBhYmxlIHRvIHN1Z2dlc3QgaG93IHdlIG1heSBpbXByb3ZlIGl0IHBs ZWFzZT8NCg0KLVJpY2gNCg0KT24gTW9uLCAyNiBPY3QgMjAyMCBhdCAxMDowNCwgVmFzaWxlbmtv IEVkdWFyZCA8dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tPG1haWx0bzp2YXNpbGVua28uZWR1 YXJkQGh1YXdlaS5jb20+PiB3cm90ZToNCkhpIEZlcm5hbmRvLA0KU29ycnkuIEkgaGF2ZSBzcG90 dGVkIGl0IGp1c3Qgbm93Lg0KSXQgZG9lcyBub3QgbWFrZSBzZW5zZSB0byBtZW50aW9uIDgwMi4x eCBhcyB0aGUgcmVhc29uIGZvciByZW51bWJlcmluZyBwcm9ibGVtLg0KODAyLjF4IG9wZXJhdGVz IHN0cmljdGx5IG9uIEwyLiBTd2l0Y2ggcG9ydCBpcyBibG9ja2VkIGZvciBhbnkgb3RoZXIgdHJh ZmZpYyBhdCB0aGF0IHRpbWUuDQpJZiBhdXRoZW50aWNhdGlvbiB3b3VsZCBmYWlsIHRoZW4gcG9y dCBjb3VsZCBiZSBwdXQgaW50byAiZ3Vlc3QiIFZMQU4uDQpCdXQgaW1wb3J0YW50IHBvaW50IHRv IG1lbnRpb24gdGhhdCA4MDIuMXggc3VwcGxpY2FudCBoYXMgZmluaXNoZWQgaXRzIGpvYiAtIGl0 IGNvdWxkIG5vdCBhY3RpdmF0ZSBhdXRoZW50aWNhdGlvbiBhZ2Fpbi4gSXQgbmVlZHMgc2FtZSBl dmVudCBsaWtlIGxpbmsgdXAvZG93biBvciBhZG1pbiBwdXNoLiBFbnRlcnByaXNlcyBkbyBub3Qg bWFuYWdlIGNsaWVudHMgaW4gc3VjaCBhIGR5bmFtaWMgd2F5Lg0KVGhlIGRlY2lzaW9uIHRvIG1v dmUgaG9zdCBmcm9tICJndWVzdCIgdG8gc29tZSBvdGhlciBWTEFOIGlzIG5vdCByZWxhdGVkIHRv IDgwMi4xeCwgbm90IGF0IGFsbC4gSXQgY291bGQgYmUgcHJvYmFibHkgY29uZmlndXJhdGlvbiBw dXNoIHRvIHN3aXRjaCAoTmV0Q29uZj8pLg0KSWYgc3VjaCBiYWQgcHJhY3RpY2Ugd291bGQgaGFw cGVuIHRoZW4gaXQgd291bGQgYnJlYWsgY29ubmVjdGl2aXR5IGZvciBJUHY0IHRvbyAtIERIQ1Ag d291bGQgbm90IGhhdmUgYW55IGluZm9ybWF0aW9uIHRoYXQgVkxBTiBoYXMgYmVlbiBjaGFuZ2Vz Lg0KSGVuY2UsIGl0IGRvZXMgbm90IG1hdHRlciB3aGF0IG1lY2hhbmlzbSBoYXMgYmVlbiB1c2Vk IGluaXRpYWxseSB0byBwdXQgaG9zdCBpbnRvICJndWVzdCIgVkxBTi4gSXQgY291bGQgYmUgc29t ZXRoaW5nIG90aGVyIHRoYW4gODAyLjF4Lg0KSXQgaXMgaW1wb3J0YW50IHRoYXQgc29tZSBhdXRv bWF0aW9uIHRvb2wgY291bGQgYnJlYWsgSVAgY29ubmVjdGl2aXR5IHNoaWZ0aW5nIGhvc3RzIGJl dHdlZW4gVkxBTnMuDQpJdCBpcyBub3QgcG9zc2libGUgdG8gZGV2ZWxvcCB0aGUgcmVzb2x1dGlv biBvbiBJUHY0LCBidXQgaXQgaXMgcG9zc2libGUgdG8gaW52ZW50IGFkZGl0aW9uYWwgcHJvdGVj dGlvbiBvbiBJUHY2Lg0KVGhlIHJlYXNvbiBpcyBzdGlsbCB2YWxpZCAtIHByZWNhdXRpb25zIG1h a2Ugc2Vuc2UgdG8gaGF2ZS4gQnV0IGl0IGhhcyBub3RoaW5nIHRvIGRvIHdpdGggODAyLjF4LiBJ dCBpcyBnZW5lcmFsIFZMQU4gc2h1ZmZsaW5nLg0KRWR1YXJkDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IHY2b3BzIFttYWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZzxt YWlsdG86djZvcHMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBJRVRGIFNlY3JldGFy aWF0DQo+IFNlbnQ6IDIyINC+0LrRgtGP0LHRgNGPIDIwMjAg0LMuIDE3OjI5DQo+IFRvOiBvd2Vu QGRlbG9uZy5jb208bWFpbHRvOm93ZW5AZGVsb25nLmNvbT47IGRyYWZ0LWlldGYtdjZvcHMtc2xh YWMtcmVudW1AaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtdjZvcHMtc2xhYWMtcmVudW1AaWV0 Zi5vcmc+Ow0KPiB2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+OyB3YXJyZW5A a3VtYXJpLm5ldDxtYWlsdG86d2FycmVuQGt1bWFyaS5uZXQ+OyB2Nm9wcy1jaGFpcnNAaWV0Zi5v cmc8bWFpbHRvOnY2b3BzLWNoYWlyc0BpZXRmLm9yZz47IE93ZW4gRGVMb25nDQo+IDxvd2VuQGRl bG9uZy5jb208bWFpbHRvOm93ZW5AZGVsb25nLmNvbT4+DQo+IFN1YmplY3Q6IFt2Nm9wc10gRGF0 YXRyYWNrZXIgU3RhdGUgVXBkYXRlIE5vdGljZTogPGRyYWZ0LWlldGYtdjZvcHMtc2xhYWMtDQo+ IHJlbnVtLTA0LnR4dD4NCj4NCj4gSUVTRyBzdGF0ZSBjaGFuZ2VkOg0KPg0KPiBOZXcgU3RhdGU6 IElFU0cgRXZhbHVhdGlvbjo6UmV2aXNlZCBJLUQgTmVlZGVkDQo+DQo+IChUaGUgcHJldmlvdXMg c3RhdGUgd2FzIElFU0cgRXZhbHVhdGlvbikNCj4NCj4NCj4gRGF0YXRyYWNrZXIgVVJMOiBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLXNsYWFjLQ0KPiBy ZW51bS8NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gdjZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGlldGYub3JnPG1haWx0bzp2Nm9w c0BpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9w cw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KdjZv cHMgbWFpbGluZyBsaXN0DQp2Nm9wc0BpZXRmLm9yZzxtYWlsdG86djZvcHNAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo= --_000_889d7d6719ee44cea52020bb37383571huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcy LjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5ZZXMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRo aXMg4oCcPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5h bmQgdGhlbiBnb3Qgc3VjY2Vzc2Z1bGx5IGF1dGhlbnRpY2F0ZWQgbGF0ZXIgb248L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPuKAnQ0KIG1pc2xlYWQgdGhhdCBpdCBpcyBzb21l aG93IHJlbGF0ZWQgdG8gdGhlIHByZXZpb3VzIHNlbnRlbmNlIGFib3V0IDgwMi4xeC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+SXQgaXMgbm90LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JdCBjb3VsZCBoYXBwZW4g Ynkgb3RoZXIgbWVjaGFuaXNtLCBub3QgYnkgODAyLjF4Lg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JbiBnZW5lcmFsLCBpdCBkb2VzIG5vdCBtYWtlIHNlbnNl IHRvIG1lbnRpb24gODAyLjF4IGluIHRoaXMgZG9jdW1lbnQsIGJlY2F1c2UgaXQgaXMgbm90IHJl bGF0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkl0IGlzIGJldHRlciB0byByZXBsYWNlIGl0IGJ5Ojxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmUgc3R5bGU9IndvcmQtYnJlYWs6YnJlYWstYWxsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+4oCcVGhlIGhvc3QgY291bGQgYmUgY29ubmVj dGVkIGluaXRpYWxseSB0byBWTEFOIHdpdGggSVB2NiBwcmVmaXgsIHRoZW4gbGF0ZXIgaG9zdCBt YXkgYmUgbW92ZWQgdG8gYW5vdGhlciBWTEFOIHdpdGggZGlmZmVyZW50IElQdjYgcHJlZml4ICho dW1hbiBtaXN0YWtlLCBiYWQgc3lzdGVtIGRlc2lnbiwgTDIgdG9wb2xvZ3kgY2hhbmdlKS4gPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5JdCBtaWdodCBl bmQgdXAgaGF2aW5nIElQdjYgYWRkcmVzc2VzIGZyb20gYm90aCBvbGQgYW5kIG5ldyBWTEFOcy4g PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Tb3VyY2luZyB0cmFmZmljIGZy b20gdGhlIG9sZCBwcmVmaXggY291bGQgbGVhZCB0byB0aGUgdHJhZmZpYyBkcm9wIGJ5IFJQRiBp biB1cHN0cmVhbSBkaXJlY3Rpb24sIGRvd25zdHJlYW0gdHJhZmZpYyBtYXkgYmUgbm90IGZvcndh cmRlZCB0byBwcm9wZXIgbGluay4g4oCdIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPkVkdWFyZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBw dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4g UmljaGFyZCBQYXR0ZXJzb24gW21haWx0bzpyaWNoYXJkQGhlbGl4Lm5ldC5uel0NCjxicj4NCjxi PlNlbnQ6PC9iPiAyNyDQvtC60YLRj9Cx0YDRjyAyMDIwINCzLiAxNzowODxicj4NCjxiPlRvOjwv Yj4gVmFzaWxlbmtvIEVkdWFyZCAmbHQ7dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tJmd0Ozxi cj4NCjxiPkNjOjwvYj4gSVB2NiBPcGVyYXRpb25zICZsdDt2Nm9wc0BpZXRmLm9yZyZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1zbGFhYy1yZW51 bS0wNCAtIDgwMi4xeCByZWxldmFuY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gZG8geW91IGJlbGlldmUgdGhlIHJlc3Qgb2YgdGhlIHBh cmFncmFwaCB0aGF0IHByb3ZpZGVzIHRoZSBleGFtcGxlLCBpcyB3cm9uZz88bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9IndvcmQtYnJlYWs6YnJlYWstYWxsO2JveC1zaXppbmc6 Ym9yZGVyLWJveDtib3JkZXItcmFkaXVzOjRweDtvdmVyZmxvdzphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+SW4gcGFydGljdWxhciwgdGhlcmUgaGFzIGJl ZW4gZXZpZGVuY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9IndvcmQtYnJl YWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoYXQgc29tZSA4MDIuMXggc3VwcGxpY2Fu dHMgZG8gbm90IHJlc2V0IG5ldHdvcmsgc2V0dGluZ3MgYWZ0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmUgc3R5bGU9IndvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHN1Y2Nlc3NmdWwgODAyLjF4IGF1dGhlbnRpY2F0aW9uLiZuYnNwOyBTbyBpZiBhIGhvc3QgaGFk IGZhaWxlZCA4MDIuMXg8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9IndvcmQt YnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGF1dGhlbnRpY2F0aW9uIGZvciBzb21l IHJlYXNvbiwgd2FzIHBsYWNlZCBpbiBhICZxdW90O3F1YXJhbnRpbmUmcXVvdDsgVkxBTjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0id29yZC1icmVhazpicmVhay1hbGwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgYW5kIHRoZW4gZ290IHN1Y2Nlc3NmdWxseSBhdXRoZW50aWNhdGVkIGxh dGVyIG9uLCBpdCBtaWdodCBlbmQgdXA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5 bGU9IndvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGhhdmluZyBJUHY2IGFk ZHJlc3NlcyBmcm9tIGJvdGggb2xkICgmcXVvdDtxdWFyYW50aW5lJnF1b3Q7KSBhbmQgbmV3IFZM QU5zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBUdWUsIDI3IE9jdCAyMDIwIGF0IDEzOjA1LCBWYXNpbGVua28gRWR1YXJk ICZsdDs8YSBocmVmPSJtYWlsdG86dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tIj52YXNpbGVu a28uZWR1YXJkQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgUmljaGFyZCw8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5JIGJlbGlldmUgdGhhdCBpdCBpcyBtaXNsZWFkaW5nLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJl Y2F1c2UgODAyLjF4IGl0c2VsZiBpcyBub3QgY2FwYWJsZSB0byBtb3ZlIGJldHdlZW4gVkxBTnMg YWZ0ZXIgYWRkcmVzcyBhY2NlcHRlZC4gODAyLjF4IGNvdWxkIG1vdmUNCiBiZXR3ZWVuIFZMQU5z IGJlZm9yZSBhZGRyZXNzIGFjY2VwdGVkIOKAkyBpdCBpcyBub3QgcmVsZXZhbnQgaGVyZS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5Tb21ldGhpbmcgZWxzZSBzaG91bGQgcHVzaCBiZXR3ZWVuIFZMQU5z IHRvIGJyZWFrIElQIGNvbm5lY3Rpdml0eS4gSXQgY291bGQgbm90IGJlIDgwMi4xeC4gSXQgaXMg YmV0dGVyDQogbm90IHRvIG1lbnRpb24gODAyLjF4LiBJdCBpcyBub3QgaW1wb3J0YW50IHdoYXQg d2FzIHRoZSBtZWNoYW5pc20gdGhhdCBpbml0aWFsbHkgY29ubmVjdGVkIGhvc3QgdG8gMTxzdXA+ c3Q8L3N1cD4gVkxBTi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JdCBjb3VsZCBiZSBubyBhbnkgc3Bl Y2lhbCBtZWNoYW5pc20gYXQgYWxsLiBPciBpdCBjb3VsZCBiZSDigJxNQUMtYXV0aGVudGljYXRp b27igJ0uIEl0IGRvZXMgbm90IG1hdHRlci48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5JdCBpcyBpbXBvcnRhbnQgd2hhdCBjb3VsZCBiZSB0aGUgbWVjaGFu aXNtIHRoYXQgbW92ZWQgYmV0d2VlbiBWTEFOcy4gSSBkbyBhc3N1bWUgc29tZSBzb3J0IG9mIGNv bmZpZ3VyYXRpb24NCiBjaGFuZ2UgYnkgQ0xJIG9mIE5ldGNvbmYuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+QnV0IGl0IGlzIG5vdCA4MDIuMXggYW55d2F5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkVkdWFy ZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBSaWNoYXJkIFBh dHRlcnNvbiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpyaWNoYXJkQGhlbGl4Lm5ldC5ueiIgdGFy Z2V0PSJfYmxhbmsiPnJpY2hhcmRAaGVsaXgubmV0Lm56PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9i PiAyNyDQvtC60YLRj9Cx0YDRjyAyMDIwINCzLiAxNTo0ODxicj4NCjxiPlRvOjwvYj4gVmFzaWxl bmtvIEVkdWFyZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbTwvYT4mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiBJUHY2IE9wZXJhdGlvbnMgJmx0OzxhIGhyZWY9Im1haWx0bzp2Nm9wc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnY2b3BzQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1zbGFhYy1yZW51bS0wNCAt IDgwMi4xeCByZWxldmFuY2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkhpIEVkdWFyZCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5XZSdyZSBub3QgcG9pbnRpbmcgb3V0IGFueSBpbnRlcm9w ZXJhdGlvbiB3aXRoIDgwMi4xeCBzcGVjaWZpY2FsbHksIHdlIHdlcmUganVzdCB1c2luZyBpdCBh cyBhbiBleGFtcGxlIHRoYXQgbWF5IHRyaWdnZXIgYSByZW51bWJlcmluZyBldmVudCB3aXRob3V0 IHRoZSBwaHlzaWNhbCBwb3J0IGZsYXBwaW5nLA0KIHdoaWNoIEkgYmVsaWV2ZSBpcyB2YWxpZC48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJ3b3JkLWJyZWFr OmJyZWFrLWFsbDtib3gtc2l6aW5nOmJvcmRlci1ib3g7Ym9yZGVyLXJhZGl1czo0cHg7b3ZlcmZs b3c6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPkEgc3dp dGNoLXBvcnQgdGhlIGhvc3QgaXMgY29ubmVjdGVkIHRvIG1heSBiZSBtb3ZlZCB0byBhbm90aGVy PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJ3b3JkLWJyZWFrOmJyZWFrLWFs bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBzdWJuZXQgKFZMQU4pIGFzIGEgcmVzdWx0IG9mIG1hbnVhbCBz d2l0Y2gtcG9ydCByZWNvbmZpZ3VyYXRpb24gb3I8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9IndvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDgwMi4xeCBy ZS1hdXRoZW50aWNhdGlvbi4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHRoaW5rIHRoZSBzdGF0ZW1lbnQgYWJvdmUg aXMgY2xlYXIgdGhhdCA4MDIuMXggaXMgc2ltcGx5IGFuIGV4YW1wbGUgb2Ygd2hlbiBhIGhvc3Qg bWF5IGJlIHNoaWZ0ZWQgYmV0d2VlbiBWTEFOcyBhbmQgYSByZW51bWJlcmluZyBldmVudCBtYXkg b2NjdXIsIGlmIHlvdSBiZWxpZXZlIHRoZSB3b3JkaW5nIGlzbid0DQogY2xlYXIgZW5vdWdoLCB3 b3VsZCB5b3UgYmUgYWJsZSB0byBzdWdnZXN0IGhvdyB3ZSBtYXkgaW1wcm92ZSBpdCBwbGVhc2U/ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4tUmljaDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+T24gTW9uLCAyNiBPY3QgMjAyMCBhdCAxMDowNCwgVmFzaWxlbmtvIEVkdWFyZCAm bHQ7PGEgaHJlZj0ibWFpbHRvOnZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPnZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGkgRmVybmFuZG8sPGJyPg0KU29ycnku IEkgaGF2ZSBzcG90dGVkIGl0IGp1c3Qgbm93Ljxicj4NCkl0IGRvZXMgbm90IG1ha2Ugc2Vuc2Ug dG8gbWVudGlvbiA4MDIuMXggYXMgdGhlIHJlYXNvbiBmb3IgcmVudW1iZXJpbmcgcHJvYmxlbS48 YnI+DQo4MDIuMXggb3BlcmF0ZXMgc3RyaWN0bHkgb24gTDIuIFN3aXRjaCBwb3J0IGlzIGJsb2Nr ZWQgZm9yIGFueSBvdGhlciB0cmFmZmljIGF0IHRoYXQgdGltZS48YnI+DQpJZiBhdXRoZW50aWNh dGlvbiB3b3VsZCBmYWlsIHRoZW4gcG9ydCBjb3VsZCBiZSBwdXQgaW50byAmcXVvdDtndWVzdCZx dW90OyBWTEFOLjxicj4NCkJ1dCBpbXBvcnRhbnQgcG9pbnQgdG8gbWVudGlvbiB0aGF0IDgwMi4x eCBzdXBwbGljYW50IGhhcyBmaW5pc2hlZCBpdHMgam9iIC0gaXQgY291bGQgbm90IGFjdGl2YXRl IGF1dGhlbnRpY2F0aW9uIGFnYWluLiBJdCBuZWVkcyBzYW1lIGV2ZW50IGxpa2UgbGluayB1cC9k b3duIG9yIGFkbWluIHB1c2guIEVudGVycHJpc2VzIGRvIG5vdCBtYW5hZ2UgY2xpZW50cyBpbiBz dWNoIGEgZHluYW1pYyB3YXkuPGJyPg0KVGhlIGRlY2lzaW9uIHRvIG1vdmUgaG9zdCBmcm9tICZx dW90O2d1ZXN0JnF1b3Q7IHRvIHNvbWUgb3RoZXIgVkxBTiBpcyBub3QgcmVsYXRlZCB0byA4MDIu MXgsIG5vdCBhdCBhbGwuIEl0IGNvdWxkIGJlIHByb2JhYmx5IGNvbmZpZ3VyYXRpb24gcHVzaCB0 byBzd2l0Y2ggKE5ldENvbmY/KS48YnI+DQpJZiBzdWNoIGJhZCBwcmFjdGljZSB3b3VsZCBoYXBw ZW4gdGhlbiBpdCB3b3VsZCBicmVhayBjb25uZWN0aXZpdHkgZm9yIElQdjQgdG9vIC0gREhDUCB3 b3VsZCBub3QgaGF2ZSBhbnkgaW5mb3JtYXRpb24gdGhhdCBWTEFOIGhhcyBiZWVuIGNoYW5nZXMu PGJyPg0KSGVuY2UsIGl0IGRvZXMgbm90IG1hdHRlciB3aGF0IG1lY2hhbmlzbSBoYXMgYmVlbiB1 c2VkIGluaXRpYWxseSB0byBwdXQgaG9zdCBpbnRvICZxdW90O2d1ZXN0JnF1b3Q7IFZMQU4uIEl0 IGNvdWxkIGJlIHNvbWV0aGluZyBvdGhlciB0aGFuIDgwMi4xeC48YnI+DQpJdCBpcyBpbXBvcnRh bnQgdGhhdCBzb21lIGF1dG9tYXRpb24gdG9vbCBjb3VsZCBicmVhayBJUCBjb25uZWN0aXZpdHkg c2hpZnRpbmcgaG9zdHMgYmV0d2VlbiBWTEFOcy48YnI+DQpJdCBpcyBub3QgcG9zc2libGUgdG8g ZGV2ZWxvcCB0aGUgcmVzb2x1dGlvbiBvbiBJUHY0LCBidXQgaXQgaXMgcG9zc2libGUgdG8gaW52 ZW50IGFkZGl0aW9uYWwgcHJvdGVjdGlvbiBvbiBJUHY2Ljxicj4NClRoZSByZWFzb24gaXMgc3Rp bGwgdmFsaWQgLSBwcmVjYXV0aW9ucyBtYWtlIHNlbnNlIHRvIGhhdmUuIEJ1dCBpdCBoYXMgbm90 aGluZyB0byBkbyB3aXRoIDgwMi4xeC4gSXQgaXMgZ2VuZXJhbCBWTEFOIHNodWZmbGluZy48YnI+ DQpFZHVhcmQ8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBG cm9tOiB2Nm9wcyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+djZvcHMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBP ZiBJRVRGIFNlY3JldGFyaWF0PGJyPg0KJmd0OyBTZW50OiAyMiDQvtC60YLRj9Cx0YDRjyAyMDIw INCzLiAxNzoyOTxicj4NCiZndDsgVG86IDxhIGhyZWY9Im1haWx0bzpvd2VuQGRlbG9uZy5jb20i IHRhcmdldD0iX2JsYW5rIj5vd2VuQGRlbG9uZy5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86ZHJh ZnQtaWV0Zi12Nm9wcy1zbGFhYy1yZW51bUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KZHJh ZnQtaWV0Zi12Nm9wcy1zbGFhYy1yZW51bUBpZXRmLm9yZzwvYT47PGJyPg0KJmd0OyA8YSBocmVm PSJtYWlsdG86djZvcHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj52Nm9wc0BpZXRmLm9yZzwv YT47IDxhIGhyZWY9Im1haWx0bzp3YXJyZW5Aa3VtYXJpLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPg0K d2FycmVuQGt1bWFyaS5uZXQ8L2E+OyA8YSBocmVmPSJtYWlsdG86djZvcHMtY2hhaXJzQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+djZvcHMtY2hhaXJzQGlldGYub3JnPC9hPjsgT3dlbiBEZUxv bmc8YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86b3dlbkBkZWxvbmcuY29tIiB0YXJnZXQ9 Il9ibGFuayI+b3dlbkBkZWxvbmcuY29tPC9hPiZndDs8YnI+DQomZ3Q7IFN1YmplY3Q6IFt2Nm9w c10gRGF0YXRyYWNrZXIgU3RhdGUgVXBkYXRlIE5vdGljZTogJmx0O2RyYWZ0LWlldGYtdjZvcHMt c2xhYWMtPGJyPg0KJmd0OyByZW51bS0wNC50eHQmZ3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IElF U0cgc3RhdGUgY2hhbmdlZDo8YnI+DQomZ3Q7IDxicj4NCiZndDsgTmV3IFN0YXRlOiBJRVNHIEV2 YWx1YXRpb246OlJldmlzZWQgSS1EIE5lZWRlZDxicj4NCiZndDsgPGJyPg0KJmd0OyAoVGhlIHBy ZXZpb3VzIHN0YXRlIHdhcyBJRVNHIEV2YWx1YXRpb24pPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxi cj4NCiZndDsgRGF0YXRyYWNrZXIgVVJMOiA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLXY2b3BzLXNsYWFjLSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12Nm9wcy1zbGFhYy08L2E+ PGJyPg0KJmd0OyByZW51bS88YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgdjZvcHMg bWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86djZvcHNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj52Nm9wc0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPC9hPjxicj4NCjxicj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KdjZv cHMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnY2b3BzQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_889d7d6719ee44cea52020bb37383571huaweicom_-- From nobody Tue Oct 27 10:32:12 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 AB16D3A1268 for ; Tue, 27 Oct 2020 10:32:11 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_DNS_FOR_FROM=0.001, 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=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 f4kYhJAVebP5 for ; Tue, 27 Oct 2020 10:32:10 -0700 (PDT) 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 4A1033A1265 for ; Tue, 27 Oct 2020 10:32:09 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id z6so1955528qkz.4 for ; Tue, 27 Oct 2020 10:32:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7kGwzB0rWbYN7f9D/AirFNnPe2TsIwKGXVjaNch/L50=; b=Xe+f2CiBI5kgzqk5sYcTYY5XX/qrwHnvwDMVV/krXO0KdQr+8ml/VN7sZtewL8aLXc rWPecOyJhn4oZXejzzURAPG0xfiBCJeYOAiz7SKBZIPc35BdIb9Y8t3Cr+KYcFELz2Oj AX9daCpaWIRS9U3L/o86P6EWFouVodpaO8xOo1LJAYKNEHwHZ0yF9k46jaCFe7o5+sgY yxkisvO6FDWwbaeO0xTjUIoCySY6MurtDmNX67pL260Bg8WTYAhshPPpdQHlUNhFSGNA wSmkJPrExvi6GirOqyAxg9nXZ7j3s3vJUE3NZkInMov3kWwgoWR3dAyLNUYCYy9Y+eQE RM2w== 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=7kGwzB0rWbYN7f9D/AirFNnPe2TsIwKGXVjaNch/L50=; b=L0RdntdXi25pSajGfVhbqE0z7ocsQEKu+lw9i5mtQOnQ7vklisYry1qIBj92cY6Pks VZpIJhJVaH58HRCLYr3f3GVr1haIyjfug7pQN9n5IbzxVAuEn1a4cu8LkZMPvDT0Yz1E FQtS493vZeumAqHOKhIxQEeT0KrDdIddstZ8keu6KSEwedyoJT/ILjTUgoh0UXt1gSIM tYjVvGEfy65ksj3H2gKJgskudxAidqE+jKexUDgLxVbITyfHIhF/4qRKKj7jyBy9QDrw tOrgVq1G/B4nQ/vhYwVQ/H/vWFjOp9qykrV8gRim5S9qclrOtLXC8Yq+uxGTkiY7pYI3 H1/g== X-Gm-Message-State: AOAM533uAefCRFSw+40y79zkQWuc+WD6Hua/Gd1cuawfEaU9PLqHEGQr s4SrPUEUW/iGwu7SlumoOQl6XQ== X-Google-Smtp-Source: ABdhPJy5diaWNoFKSkygJJmfwcgZIWnjS1aAB95ryvlERhxgLowiZHN0xM7l/d5IEuyXvQck6CArqg== X-Received: by 2002:a05:620a:842:: with SMTP id u2mr3199634qku.214.1603819929006; Tue, 27 Oct 2020 10:32:09 -0700 (PDT) Received: from [192.168.4.70] (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id k30sm1279043qte.21.2020.10.27.10.32.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Oct 2020 10:32:08 -0700 (PDT) From: Ted Lemon Message-Id: <774FF035-060D-4CDC-A66C-8B6F521368D1@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_AC909FA1-BB72-4667-A6B8-45B1D5C7616C" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Tue, 27 Oct 2020 13:32:07 -0400 In-Reply-To: <889d7d6719ee44cea52020bb37383571@huawei.com> Cc: Richard Patterson , IPv6 Operations To: Vasilenko Eduard References: <54abce3e4abc449fa896a6ae318a6128@huawei.com> <12e219a6add2417685d386c026dce8e4@huawei.com> <889d7d6719ee44cea52020bb37383571@huawei.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance 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, 27 Oct 2020 17:32:12 -0000 --Apple-Mail=_AC909FA1-BB72-4667-A6B8-45B1D5C7616C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Oct 27, 2020, at 1:29 PM, Vasilenko Eduard = wrote: > This =E2=80=9Cand then got successfully authenticated later on=E2=80=9D = mislead that it is somehow related to the previous sentence about = 802.1x. > It is not. > It could happen by other mechanism, not by 802.1x. Can you explain why you think it would not be possible to authenticate = with 802.1x after registering in quarantine? --Apple-Mail=_AC909FA1-BB72-4667-A6B8-45B1D5C7616C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Oct 27, 2020, at 1:29 PM, Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote:
This =E2=80=9Cand then got successfully = authenticated later on=E2= =80=9D mislead that it is somehow related to the previous sentence about = 802.1x.
It is not.
It could happen by = other mechanism, not by 802.1x.

Can you explain why you think it would not be = possible to authenticate with 802.1x after registering in = quarantine?

= --Apple-Mail=_AC909FA1-BB72-4667-A6B8-45B1D5C7616C-- From nobody Tue Oct 27 10:42: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 95DD83A12AC for ; Tue, 27 Oct 2020 10:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 A452odLD-8-Y for ; Tue, 27 Oct 2020 10:42:25 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 654C33A0D87 for ; Tue, 27 Oct 2020 10:42:25 -0700 (PDT) Received: from lhreml701-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 10BBDA6C33B1EDF8DC0C; Tue, 27 Oct 2020 17:42:24 +0000 (GMT) Received: from msceml703-chm.china.huawei.com (10.219.141.161) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Tue, 27 Oct 2020 17:42:23 +0000 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml703-chm.china.huawei.com (10.219.141.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 27 Oct 2020 20:42:23 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Tue, 27 Oct 2020 20:42:23 +0300 From: Vasilenko Eduard To: Ted Lemon CC: Richard Patterson , IPv6 Operations Thread-Topic: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance Thread-Index: AdarfiOiihVVds8iT0KdHPG3+auXlwAyC3uAAAafLvD//+bfgP//oBeggACQy4D//8jcoA== Date: Tue, 27 Oct 2020 17:42:22 +0000 Message-ID: References: <12e219a6add2417685d386c026dce8e4@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.197.128] Content-Type: multipart/alternative; boundary="_000_b82c0f794f944f9aabf8a0320ffa54fbhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance 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, 27 Oct 2020 17:42:34 -0000 --_000_b82c0f794f944f9aabf8a0320ffa54fbhuaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgaG9zdCB3b3VsZCByZWNlaXZlIHByb3BlciBjcmVkZW50aWFscyBmb3IgODAyLjF4IGF1dGhl bnRpY2F0aW9uLA0KVGhlbiBjaGFuZ2UgaW4gODAyLjF4IGNvbmZpZ3VyYXRpb24gd291bGQgcmUt aW5pdGlhbGl6ZSB0aGUgbGluayBhdCBMMi4NCklQIGFkZHJlc3NlcyB3b3VsZCBjbGVhcmVkIGF1 dG9tYXRpY2FsbHkuDQoNCkRvIHlvdSBoYXZlIGFueSBuYW1lIG9mIHRoZSB2ZW5kb3IgKGFuZCBw cm9kdWN0KSB0aGF0IGRpZCBpdCBkaWZmZXJlbnRseT8NCg0KRWQvDQpGcm9tOiBUZWQgTGVtb24g W21haWx0bzptZWxsb25AZnVndWUuY29tXQ0KU2VudDogMjcg0L7QutGC0Y/QsdGA0Y8gMjAyMCDQ sy4gMjA6MjMNClRvOiBWYXNpbGVua28gRWR1YXJkIDx2YXNpbGVua28uZWR1YXJkQGh1YXdlaS5j b20+DQpDYzogUmljaGFyZCBQYXR0ZXJzb24gPHJpY2hhcmRAaGVsaXgubmV0Lm56PjsgSVB2NiBP cGVyYXRpb25zIDx2Nm9wc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbdjZvcHNdIGRyYWZ0LWll dGYtdjZvcHMtc2xhYWMtcmVudW0tMDQgLSA4MDIuMXggcmVsZXZhbmNlDQoNCk9uIE9jdCAyNywg MjAyMCwgYXQgMToxNCBQTSwgVmFzaWxlbmtvIEVkdWFyZCA8dmFzaWxlbmtvLmVkdWFyZEBodWF3 ZWkuY29tPG1haWx0bzp2YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb20+PiB3cm90ZToNCkkgaGF2 ZSBpbnZlc3RpZ2F0ZWQgMyB2ZW5kb3JzLiA4MDIuMXggaXMgdG8gZmluaXNoIHRoZSBwYXRjaGNv cmQgY29ubmVjdGlvbiBvbiBMMi4gTDMgY291bGQgaGFwcGVuIG9ubHkgYWZ0ZXIgdGhpcy4gSWYg YW55IHZlbmRvciB3b3VsZCBpbXBsZW1lbnQgaXQgZGlmZmVyZW50bHkgLSBpdCB3b3VsZCBiZSBp bnRlcmVzdGluZyB0byBoZWFyLg0KQnV0IHdoeSB3ZSBoYXZlIHJldmVydGVkIHRoaXMgcXVlc3Rp b24/IEkgYmVsaWV2ZSB0aGF0IHByb3ZlcyBzaG91bGQgYmUgZnJvbSB0aGUgb25lIHdobyBoYXMg cHV0IDgwMi4xeCBhcyB0aGUgcmVhc29uIGludG8gdGhlIGRvY3VtZW50Lg0KDQpUaGUgcHJvYmxl bSB3aXRoIHlvdXIgdGhlb3J5IGlzIHRoYXQgeW91IGhhdmVu4oCZdCBhY3R1YWxseSB1bmRlcnN0 b29kIHRoZSBwb2ludCB5b3UgYXJlIGNvbnRyYWRpY3RpbmcuICBUaGUgc2l0dWF0aW9uIHRoYXQg d2FzIGRlc2NyaWJlZCBpcyBhcyBmb2xsb3dzOg0KDQoxLiBob3N0IGF0dGVtcHRzIHRvIGNvbm5l Y3QgdG8gODAyLjF4LCBpcyB1bmFibGUgdG8gYXV0aGVudGljYXRlLCBpcyBjb25uZWN0ZWQgdG8g cXVhcmFudGluZSB2bGFuDQoyLiBob3N0IGFjcXVpcmVzIGwzIGluZm8gZm9yIHF1YXJhbnRpbmUg dmxhbg0KMy4gdXNlciBhY3F1aXJlcyBhdXRoZW50aWNhdGlvbiBpbmZvcm1hdGlvbiBmb3IgODAy LjF4IHRocm91Z2ggdGhlIHF1YXJhbnRpbmUgcHJvY2Vzcw0KNC4gdXNlciBhdXRoZW50aWNhdGVz IHRvIDgwMi4xeA0KNS4gaG9zdCBpcyBub3cgY29ubmVjdGVkIHRvIGludGVybmFsIHZsYW4sIGFu ZCBpcyBubyBsb25nZXIgY29ubmVjdGVkIHRvIHF1YXJhbnRpbmUgdmxhbg0KNi4gaG9zdCBsYXll ciAzIGRvZXMgbm90IHNlZSBhIGxpbmsgc3RhdGUgdHJhbnNpdGlvbiwgYW5kIGRvZXMgbm90IGlu dmFsaWRhdGUgc3RhdGUgYWNxdWlyZWQgb24gcXVhcmFudGluZSB2bGFuDQo3LiBjb21tdW5pY2F0 aW9uIGlzIHVucmVsaWFibGUgYmVjYXVzZSBxdWFyYW50aW5lIHZsYW4gYWRkcmVzc2VzIGFyZSBu b3QgdmFsaWQsIGJ1dCBhcmUgY29uc2lkZXJlZCB2YWxpZCBjYW5kaWRhdGVzIGZvciB1c2UuDQoN CkRvZXMgdGhpcyBtYWtlIHRoZSBzaXR1YXRpb24gY2xlYXJlcj8NCg0K --_000_b82c0f794f944f9aabf8a0320ffa54fbhuaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpNZW5sby1SZWd1bGFyOw0KCXBhbm9zZS0x OjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklmIGhvc3Qgd291bGQgcmVj ZWl2ZSBwcm9wZXIgY3JlZGVudGlhbHMgZm9yIDgwMi4xeCBhdXRoZW50aWNhdGlvbiw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+VGhlbiBjaGFuZ2UgaW4gODAyLjF4IGNvbmZpZ3VyYXRpb24gd291bGQgcmUt aW5pdGlhbGl6ZSB0aGUgbGluayBhdCBMMi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SVAgYWRkcmVzc2Vz IHdvdWxkIGNsZWFyZWQgYXV0b21hdGljYWxseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkRvIHlvdSBoYXZlIGFueSBuYW1lIG9mIHRoZSB2ZW5kb3IgKGFuZCBw cm9kdWN0KSB0aGF0IGRpZCBpdCBkaWZmZXJlbnRseT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkVkLzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNt IDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4gVGVkIExlbW9uIFttYWlsdG86bWVsbG9uQGZ1Z3VlLmNvbV0NCjxicj4NCjxiPlNl bnQ6PC9iPiAyNyDQvtC60YLRj9Cx0YDRjyAyMDIwINCzLiAyMDoyMzxicj4NCjxiPlRvOjwvYj4g VmFzaWxlbmtvIEVkdWFyZCAmbHQ7dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tJmd0Ozxicj4N CjxiPkNjOjwvYj4gUmljaGFyZCBQYXR0ZXJzb24gJmx0O3JpY2hhcmRAaGVsaXgubmV0Lm56Jmd0 OzsgSVB2NiBPcGVyYXRpb25zICZsdDt2Nm9wc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFt2Nm9wc10gZHJhZnQtaWV0Zi12Nm9wcy1zbGFhYy1yZW51bS0wNCAtIDgwMi4x eCByZWxldmFuY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBPY3QgMjcsIDIwMjAsIGF0IDE6MTQgUE0sIFZhc2lsZW5rbyBFZHVhcmQgJmx0OzxhIGhy ZWY9Im1haWx0bzp2YXNpbGVua28uZWR1YXJkQGh1YXdlaS5jb20iPnZhc2lsZW5rby5lZHVhcmRA aHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O01lbmxvLVJlZ3VsYXImcXVvdDssc2VyaWYiPkkgaGF2ZSBpbnZlc3RpZ2F0 ZWQgMyB2ZW5kb3JzLiA4MDIuMXggaXMgdG8gZmluaXNoIHRoZSBwYXRjaGNvcmQgY29ubmVjdGlv biBvbiBMMi4gTDMgY291bGQgaGFwcGVuIG9ubHkgYWZ0ZXIgdGhpcy4gSWYgYW55IHZlbmRvciB3 b3VsZCBpbXBsZW1lbnQgaXQgZGlmZmVyZW50bHkgLSBpdCB3b3VsZA0KIGJlIGludGVyZXN0aW5n IHRvIGhlYXIuPGJyPg0KQnV0IHdoeSB3ZSBoYXZlIHJldmVydGVkIHRoaXMgcXVlc3Rpb24/IEkg YmVsaWV2ZSB0aGF0IHByb3ZlcyBzaG91bGQgYmUgZnJvbSB0aGUgb25lIHdobyBoYXMgcHV0IDgw Mi4xeCBhcyB0aGUgcmVhc29uIGludG8gdGhlIGRvY3VtZW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcHJv YmxlbSB3aXRoIHlvdXIgdGhlb3J5IGlzIHRoYXQgeW91IGhhdmVu4oCZdCBhY3R1YWxseSB1bmRl cnN0b29kIHRoZSBwb2ludCB5b3UgYXJlIGNvbnRyYWRpY3RpbmcuICZuYnNwO1RoZSBzaXR1YXRp b24gdGhhdCB3YXMgZGVzY3JpYmVkIGlzIGFzIGZvbGxvd3M6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEuIGhvc3QgYXR0ZW1wdHMgdG8gY29u bmVjdCB0byA4MDIuMXgsIGlzIHVuYWJsZSB0byBhdXRoZW50aWNhdGUsIGlzIGNvbm5lY3RlZCB0 byBxdWFyYW50aW5lIHZsYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjIuIGhvc3QgYWNxdWlyZXMgbDMgaW5mbyBmb3IgcXVhcmFudGluZSB2bGFu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4zLiB1 c2VyIGFjcXVpcmVzIGF1dGhlbnRpY2F0aW9uIGluZm9ybWF0aW9uIGZvciA4MDIuMXggdGhyb3Vn aCB0aGUgcXVhcmFudGluZSBwcm9jZXNzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj40LiB1c2VyIGF1dGhlbnRpY2F0ZXMgdG8gODAyLjF4PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj41LiBob3N0IGlz IG5vdyBjb25uZWN0ZWQgdG8gaW50ZXJuYWwgdmxhbiwgYW5kIGlzIG5vIGxvbmdlciBjb25uZWN0 ZWQgdG8gcXVhcmFudGluZSB2bGFuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj42LiBob3N0IGxheWVyIDMgZG9lcyBub3Qgc2VlIGEgbGluayBzdGF0 ZSB0cmFuc2l0aW9uLCBhbmQgZG9lcyBub3QgaW52YWxpZGF0ZSBzdGF0ZSBhY3F1aXJlZCBvbiBx dWFyYW50aW5lIHZsYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjcuIGNvbW11bmljYXRpb24gaXMgdW5yZWxpYWJsZSBiZWNhdXNlIHF1YXJhbnRp bmUgdmxhbiBhZGRyZXNzZXMgYXJlIG5vdCB2YWxpZCwgYnV0IGFyZSBjb25zaWRlcmVkIHZhbGlk IGNhbmRpZGF0ZXMgZm9yIHVzZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+RG9lcyB0aGlzIG1ha2UgdGhlIHNpdHVhdGlvbiBjbGVhcmVyPzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_b82c0f794f944f9aabf8a0320ffa54fbhuaweicom_-- From nobody Tue Oct 27 10:49: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 D78763A12CC for ; Tue, 27 Oct 2020 10:49:13 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hz2i0YHxg-LZ for ; Tue, 27 Oct 2020 10:49:12 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 114FD3A12BE for ; Tue, 27 Oct 2020 10:49:10 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id a23so1983321qkg.13 for ; Tue, 27 Oct 2020 10:49:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=BsvM38G9Of51q07JlbeU28qtAJ4Zn0RFjXoqGn9K65c=; b=vlVyYDcxsU4eGXI4hHS6VTBWVmGDGCe28sJvMxJCAbASkP4W2dV+s9qGXx0stu2RgU Cm3fCOlvPFi/eDrhZwljGYmd+YLa8avwhD7VoiU63ZSes9JTujQWQAWo5poU2t0wmmYX XAHKecdRfAZ4P1H0tmzwYpoFltPjn4M41ddP4qlAya53PZg+BJgZOml+IR9BHfVAw0N3 jzrPzOIboKWdlL5B4WMGu6XmIvnnMn+sH2wXvn+h5REm3bPSVRJuFQG6elZOuPGD2l7Z eF098uCxnE+aLTFuJELeWf83QOF3+Asr+2ImGNP0eITzOJO+WAfZXMJASSB3LxhTaFKM BTng== 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=BsvM38G9Of51q07JlbeU28qtAJ4Zn0RFjXoqGn9K65c=; b=gdBkk/ZW51hrMXCFZev5+wLfrQAMvv/2jjrgHPpE5qpjKtlFIvBwqmdnUV+vb4fZIM Xc8qe2jhpRqqqlJU0/Pl7b8wiG24oyzEt5/9eZOq+G9DFsE+MNvr1AlADE8HXiH0iiM9 2QiiCvYGIZv0+TyDPcXeJWQ9SqaYTOey9AwQoiunhx+RDG5ePFhlssALdLLCHxdlw7K7 nxc6zWdOffBm32D5nOPY2l/dKEgthl1fhaUJZ2Nw5sXh58TMF1B6Cf1jvhrqBGNUGPo5 vKF5Bi/FUAcsnTlXeBDxvO9nVWpmH0XtLknOdgOgxfLYzvCc0oM5rZ32+rtqHqLg0PZi 1rgQ== X-Gm-Message-State: AOAM533N9WQnA1B7AIG8bbIrgLyU8gFLHxe3umc5ntE1ZaYe4aG4euyL aTfgz5ZVBhQOc7HVOd4k8O7ethw8ov6aaw== X-Google-Smtp-Source: ABdhPJyGyu5b0kIg4FmEiEh29MIscIGxROAQFjGjP0PjmEEf6cqajRxYZXg6//uctSrMUYk1cmmpXw== X-Received: by 2002:ae9:e702:: with SMTP id m2mr3217436qka.387.1603820950090; Tue, 27 Oct 2020 10:49:10 -0700 (PDT) Received: from [192.168.4.70] (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id 198sm1185639qki.117.2020.10.27.10.49.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Oct 2020 10:49:09 -0700 (PDT) From: Ted Lemon Message-Id: <35E2406D-0227-4728-BD85-1A5735FD9453@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3A0D642C-AC24-4302-AF6D-F74AB26A4210" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Tue, 27 Oct 2020 13:49:08 -0400 In-Reply-To: Cc: Richard Patterson , IPv6 Operations To: Vasilenko Eduard References: <12e219a6add2417685d386c026dce8e4@huawei.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance 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, 27 Oct 2020 17:49:21 -0000 --Apple-Mail=_3A0D642C-AC24-4302-AF6D-F74AB26A4210 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Oct 27, 2020, at 1:42 PM, Vasilenko Eduard = wrote: > If host would receive proper credentials for 802.1x authentication, > Then change in 802.1x configuration would re-initialize the link at = L2. > IP addresses would cleared automatically. The example used in this case was for a host where the implementation = does not =E2=80=9Cclear IP addresses automatically.=E2=80=9D Do you know = for a fact that there are no such operating systems? If so, can you = explain how you know? --Apple-Mail=_3A0D642C-AC24-4302-AF6D-F74AB26A4210 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Oct 27, 2020, at 1:42 PM, Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote:
If host would receive = proper credentials for 802.1x authentication,
Then change in 802.1x = configuration would re-initialize the link at L2.
IP addresses would = cleared automatically.

The example used in this case was for a host = where the implementation does not =E2=80=9Cclear IP addresses = automatically.=E2=80=9D Do you know for a fact that there are no such = operating systems? If so, can you explain how you know?

= --Apple-Mail=_3A0D642C-AC24-4302-AF6D-F74AB26A4210-- From nobody Tue Oct 27 11:08: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 5A1363A0E0F for ; Tue, 27 Oct 2020 11:08:34 -0700 (PDT) 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 CBlrzf598cwf for ; Tue, 27 Oct 2020 11:08:32 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E45E13A0E01 for ; Tue, 27 Oct 2020 11:08:31 -0700 (PDT) Received: from [IPv6:2a01:79c:cebd:9724:8d42:f5b3:1c0:2961] (unknown [IPv6:2a01:79c:cebd:9724:8d42:f5b3:1c0:2961]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 331584E11AAC; Tue, 27 Oct 2020 18:08:31 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-B4828E71-1E64-442B-8E05-FD2AA74C7FCC Content-Transfer-Encoding: 7bit From: Ole Troan Mime-Version: 1.0 (1.0) Date: Tue, 27 Oct 2020 19:08:27 +0100 Message-Id: <13238DF7-2F43-437E-865B-4832F96117D8@employees.org> References: <35E2406D-0227-4728-BD85-1A5735FD9453@fugue.com> Cc: Vasilenko Eduard , IPv6 Operations In-Reply-To: <35E2406D-0227-4728-BD85-1A5735FD9453@fugue.com> To: Ted Lemon X-Mailer: iPhone Mail (18A8395) Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance 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, 27 Oct 2020 18:08:34 -0000 --Apple-Mail-B4828E71-1E64-442B-8E05-FD2AA74C7FCC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ted, I think you reverse the burden of proof here.=20 Is the use case made up that the authenticator behaves this way? Based on bu= ggy implementation or based on specification? Ole > On 27 Oct 2020, at 18:50, Ted Lemon wrote: >=20 > =EF=BB=BFOn Oct 27, 2020, at 1:42 PM, Vasilenko Eduard wrote: >> If host would receive proper credentials for 802.1x authentication, >> Then change in 802.1x configuration would re-initialize the link at L2. >> IP addresses would cleared automatically. >=20 > The example used in this case was for a host where the implementation does= not =E2=80=9Cclear IP addresses automatically.=E2=80=9D Do you know for a f= act that there are no such operating systems? If so, can you explain how you= know? >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-B4828E71-1E64-442B-8E05-FD2AA74C7FCC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Ted,

I think you reverse the burden of proof here.&nb= sp;
Is the use case made up that the authenticator beh= aves this way? Based on buggy implementation or based on specification?

Ole

<= blockquote type=3D"cite">On 27 Oct 2020, at 18:50, Ted Lemon <mellon@fugu= e.com> wrote:


The example used in this case wa= s for a host where the implementation does not =E2=80=9Cclear IP addresses a= utomatically.=E2=80=9D Do you know for a fact that there are no such operati= ng systems? If so, can you explain how you know?

_______________________________________________<= br>v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops
= --Apple-Mail-B4828E71-1E64-442B-8E05-FD2AA74C7FCC-- From nobody Tue Oct 27 11:12: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 D97903A1293 for ; Tue, 27 Oct 2020 11:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 jVIf0Unlov9s for ; Tue, 27 Oct 2020 11:11:58 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 857F63A0E0F for ; Tue, 27 Oct 2020 11:11:58 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id r8so1686940qtp.13 for ; Tue, 27 Oct 2020 11:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=6AQjtPo7eCzQjfKFDFwq2nhMZTv43F6P11qclW4Zo1I=; b=V6FHsv7MPlx9rrLEG4YbGHr/4f0//yiwbeZKI1KScnB0S/ACuxWALdhWbqCcajHOOf c5TNfhq9JJv2aA36Bb8qWIeI7zx/HFFhi3mtTa2SUTUgi2IUrkKCVKL5JiUStPxkxSXN ilWXFAZqizFhN88q56RCkDBeOxWAcAdPleVYaO0RhtdSIZiJS77CHtDzLfzrZtib2IVB dK93HsVkVACJEqacFU6WDVveM69UilRzzAcw9DgXRh8uyn0+AVHMvAVr0Umm0b7uoktA VWEWJrqTEZLPmhWvWmOlJl6XyxiRkCUBigwzaMg7fKOJXdUs9PaZyKUtRy/4OM0M6EDL jS2A== 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=6AQjtPo7eCzQjfKFDFwq2nhMZTv43F6P11qclW4Zo1I=; b=YDy3oEU4ktJju4SlhHRI0GVvUyNO80RGkJV2n9YLoDDurccrjsXJkD8LXr2+1HfZa/ q+NbSM9bE1L4w40Pf039GGpCip9EHLmhOxKZFqicXA73Xk3ckNeOUAHd/7GjCudHdG9J q8JhDLj0oYPM31Fiss5mYokFTYu88h8MB6TtT4T8gSAw/EDA/Cq4jYaLBlXmikHBGmL6 HO0POYAtlLZsdkcUxHm6Hd3fyhSL37GM7NMwXCRbON27rTWnQhdL/3xT1sZS0OhbT6Qa 7DDLJKww7sCTm8LKxJ9Bs954Ls3lpJI9IKhOynwyB1zglHKKuQsxYu5q4PJhjop8l7Jz BwOg== X-Gm-Message-State: AOAM5326l6NFLMmYfU2foWXZe79ru/pUFvxhl7kqHd6C2aiXx+YdAnkK 9ypEoy919uTIAN3qzalE2eziNA== X-Google-Smtp-Source: ABdhPJxIA3X4MOZKvS42AWSsMeysXx4UzhAK9HU9jAlzgIzXk+Fc5JYKhFR3uOi5iNZGE2XtLqvGHg== X-Received: by 2002:ac8:46c1:: with SMTP id h1mr3442152qto.361.1603822317397; Tue, 27 Oct 2020 11:11:57 -0700 (PDT) Received: from [192.168.4.70] (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id u31sm1371812qtu.87.2020.10.27.11.11.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Oct 2020 11:11:56 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_31C460B5-1E3E-48E4-A0E9-29812BA8CE2F" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Tue, 27 Oct 2020 14:11:54 -0400 In-Reply-To: <13238DF7-2F43-437E-865B-4832F96117D8@employees.org> Cc: Vasilenko Eduard , IPv6 Operations To: Ole Troan References: <35E2406D-0227-4728-BD85-1A5735FD9453@fugue.com> <13238DF7-2F43-437E-865B-4832F96117D8@employees.org> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance 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, 27 Oct 2020 18:12:00 -0000 --Apple-Mail=_31C460B5-1E3E-48E4-A0E9-29812BA8CE2F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Oct 27, 2020, at 2:08 PM, Ole Troan wrote: > I think you reverse the burden of proof here.=20 > Is the use case made up that the authenticator behaves this way? Based = on buggy implementation or based on specification? I don=E2=80=99t know=E2=80=94I=E2=80=99m not the author of the document. = I=E2=80=99m just seeing a lot of unsubstantiated assertions from Eduard, = and would wish that if he=E2=80=99s going to make assertions that = something is impossible, he tell us why we should believe his = assertions. Otherwise it just seems argumentative. --Apple-Mail=_31C460B5-1E3E-48E4-A0E9-29812BA8CE2F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Oct 27, 2020, at 2:08 PM, Ole Troan <otroan@employees.org> wrote:
I = think you reverse the burden of proof here. 
Is = the use case made up that the authenticator behaves this way? Based on = buggy implementation or based on = specification?

I don=E2=80=99t know=E2=80=94I=E2=80=99m not the author of = the document. I=E2=80=99m just seeing a lot of unsubstantiated = assertions from Eduard, and would wish that if he=E2=80=99s going to = make assertions that something is impossible, he tell us why we should = believe his assertions. Otherwise it just seems argumentative.

= --Apple-Mail=_31C460B5-1E3E-48E4-A0E9-29812BA8CE2F-- From nobody Tue Oct 27 12:03: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 82FA73A1523 for ; Tue, 27 Oct 2020 12:03:27 -0700 (PDT) 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 KOMiGsspsrtp for ; Tue, 27 Oct 2020 12:03:26 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D57C43A1509 for ; Tue, 27 Oct 2020 12:03:00 -0700 (PDT) Received: from [IPv6:2a01:79c:cebd:9724:8d42:f5b3:1c0:2961] (unknown [IPv6:2a01:79c:cebd:9724:8d42:f5b3:1c0:2961]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 15C4F4E11ADA; Tue, 27 Oct 2020 19:03:00 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-30908C49-9CFE-44DC-B22F-60B62D9C9FA9 Content-Transfer-Encoding: 7bit From: Ole Troan Mime-Version: 1.0 (1.0) Date: Tue, 27 Oct 2020 20:02:58 +0100 Message-Id: <6EB8781C-F489-4F07-9224-6862066632D3@employees.org> References: Cc: Vasilenko Eduard , IPv6 Operations In-Reply-To: To: Ted Lemon X-Mailer: iPhone Mail (18A8395) Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance 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, 27 Oct 2020 19:03:28 -0000 --Apple-Mail-30908C49-9CFE-44DC-B22F-60B62D9C9FA9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The use of terms like =E2=80=9Cunsubstantiated assertions=E2=80=9D isn=E2=80= =99t so helpful for the discourse. The 802.1x specification is available to= you too. Cheers=20 Ole > On 27 Oct 2020, at 19:12, Ted Lemon wrote: >=20 > =EF=BB=BFOn Oct 27, 2020, at 2:08 PM, Ole Troan wro= te: >> I think you reverse the burden of proof here.=20 >> Is the use case made up that the authenticator behaves this way? Based on= buggy implementation or based on specification? >=20 > I don=E2=80=99t know=E2=80=94I=E2=80=99m not the author of the document. I= =E2=80=99m just seeing a lot of unsubstantiated assertions from Eduard, and w= ould wish that if he=E2=80=99s going to make assertions that something is im= possible, he tell us why we should believe his assertions. Otherwise it just= seems argumentative. >=20 --Apple-Mail-30908C49-9CFE-44DC-B22F-60B62D9C9FA9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The use of terms like =E2=80= =9Cunsubstantiated assertions=E2=80=9D isn=E2=80=99t so helpful for the disc= ourse. The 802.1x specification is available  to you too.

Cheers 
Ole

On 27 Oct 2020, at 19:12,= Ted Lemon <mellon@fugue.com> wrote:

=EF=BB=BFOn Oct 27, 2020, at 2:08 PM, Ole T= roan <otroan@employees= .org> wrote:
I think you reverse the bur= den of proof here. 
Is the use case made up that the authenticator behaves this way? Based on b= uggy implementation or based on specification?

I don=E2=80=99t know=E2=80=94I=E2=80=99m not= the author of the document. I=E2=80=99m just seeing a lot of unsubstantiate= d assertions from Eduard, and would wish that if he=E2=80=99s going to make a= ssertions that something is impossible, he tell us why we should believe his= assertions. Otherwise it just seems argumentative.
= --Apple-Mail-30908C49-9CFE-44DC-B22F-60B62D9C9FA9-- From nobody Tue Oct 27 12:20:04 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 626A13A152A for ; Tue, 27 Oct 2020 12:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 Sri1a5GJiD0g for ; Tue, 27 Oct 2020 12:20:01 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 6EB403A1531 for ; Tue, 27 Oct 2020 12:20:01 -0700 (PDT) Received: from lhreml735-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 206AC8B158D9CA9C2923; Tue, 27 Oct 2020 19:20:00 +0000 (GMT) Received: from msceml704-chm.china.huawei.com (10.219.141.143) by lhreml735-chm.china.huawei.com (10.201.108.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 27 Oct 2020 19:19:59 +0000 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml704-chm.china.huawei.com (10.219.141.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 27 Oct 2020 22:19:59 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Tue, 27 Oct 2020 22:19:59 +0300 From: Vasilenko Eduard To: Ted Lemon , Ole Troan CC: IPv6 Operations Thread-Topic: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance Thread-Index: AdarfiOiihVVds8iT0KdHPG3+auXlwAyC3uAAAafLvD//+bfgP//oBeggACQy4D//8jcoIAAPmwAgAAFZYCAAAD3AP//v7iA Date: Tue, 27 Oct 2020 19:19:59 +0000 Message-ID: <717ae0d6cd5341f08edd8810f7dec43f@huawei.com> References: <35E2406D-0227-4728-BD85-1A5735FD9453@fugue.com> <13238DF7-2F43-437E-865B-4832F96117D8@employees.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.197.128] Content-Type: multipart/alternative; boundary="_000_717ae0d6cd5341f08edd8810f7dec43fhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance 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, 27 Oct 2020 19:20:03 -0000 --_000_717ae0d6cd5341f08edd8810f7dec43fhuaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q2hhcHRlciA2LjMuNCBJbnRlcm9wZXJhYmlsaXR5IGFuZCBjb25uZWN0aXZpdHkNCkNoYW5nZXMg aW4gdGhlIG5hdHVyZSBvZiB0aGUgQ29udHJvbGxlZCBQb3J0LuKAmXMgY29ubmVjdGl2aXR5IChm cm9tIG9uZSBvZiB1bmF1dGhlbnRpY2F0ZWQsIHVuc2VjdXJlZCwgb3INCnNlY3VyZWQsIHRvIGFu b3RoZXIpIGFuZCBjaGFuZ2VzIGluIHNlY3VyZWQgY29ubmVjdGl2aXR5IChjaGFuZ2VzIGluIHRo ZSBDQSksIGFyZSBhY2NvbXBhbmllZCBieQ0KY29udHJvbFBvcnRFbmFibGVkIHRyYW5zaXRpb25z LCBhbmQgYXJlIHNlZW4gYnkgY2xpZW50cyBvZiB0aGUgQ29udHJvbGxlZCBQb3J0IGFzIGludGVy cnVwdGlvbnMgaW4NCmNvbm5lY3Rpdml0eS4gVGhlc2UgaW50ZXJydXB0aW9ucyAoc2lnbmFsZWQg YnkgY2hhbmdlcyBpbiBNQUNfT3BlcmF0aW9uYWwgZm9yIHRoZSBwb3J0KSBzaG91bGQgYmUgdXNl ZCB0bw0KcmVzdGFydCBjbGllbnQgcHJvdG9jb2wgc3RhdGUgbWFjaGluZXMgdGhhdCB0YWtlIGV4 Y2VwdGlvbmFsIG9yIGFjY2VsZXJhdGVkIGFjdGlvbiB3aGVuIGNvbm5lY3Rpdml0eSBpcyBmaXJz dA0KYXZhaWxhYmxlLiBGb3IgZXhhbXBsZSwgYSBuZXR3b3JrIGFjY2VzcyBwb2ludCB0aGF0IHBy b3ZpZGVzIHVuYXV0aGVudGljYXRlZCBjb25uZWN0aXZpdHkgdG8gYSBob3N0IGNhbg0KcHJvdmlk ZSB0aGF0IGhvc3QgYWNjZXNzIHRvIGEgZGlmZmVyZW50IElQIHN1Ym5ldCBvbmNlIGl0IGhhcyBi ZWVuIGF1dGhlbnRpY2F0ZWQsIGFuZCBpdCBpcyBhcHByb3ByaWF0ZSB0bw0KcmVpbml0aWFsaXpl IERIQ1Agc28gdGhlIGhvc3QgY2FuIG9idGFpbiBhIGZyZXNoIElQIGFkZHJlc3MuDQoNCkhlbmNl LCBpZiBhbnkgdmVuZG9yIHdvdWxkIG5vdCDigJxzaWduYWxlZCBieSBjaGFuZ2VzIGluIE1BQ19P cGVyYXRpb25hbCBmb3IgdGhlIHBvcnTigJ0g4oCTIGl0IHdvdWxkIGJlIDgwMi4xeC0yMDEwIHZp b2xhdGlvbi4NCg0KRWQvDQpGcm9tOiBUZWQgTGVtb24gW21haWx0bzptZWxsb25AZnVndWUuY29t XQ0KU2VudDogMjcg0L7QutGC0Y/QsdGA0Y8gMjAyMCDQsy4gMjE6MTINClRvOiBPbGUgVHJvYW4g PG90cm9hbkBlbXBsb3llZXMub3JnPg0KQ2M6IFZhc2lsZW5rbyBFZHVhcmQgPHZhc2lsZW5rby5l ZHVhcmRAaHVhd2VpLmNvbT47IElQdjYgT3BlcmF0aW9ucyA8djZvcHNAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLXNsYWFjLXJlbnVtLTA0IC0gODAyLjF4 IHJlbGV2YW5jZQ0KDQpPbiBPY3QgMjcsIDIwMjAsIGF0IDI6MDggUE0sIE9sZSBUcm9hbiA8b3Ry b2FuQGVtcGxveWVlcy5vcmc8bWFpbHRvOm90cm9hbkBlbXBsb3llZXMub3JnPj4gd3JvdGU6DQpJ IHRoaW5rIHlvdSByZXZlcnNlIHRoZSBidXJkZW4gb2YgcHJvb2YgaGVyZS4NCklzIHRoZSB1c2Ug Y2FzZSBtYWRlIHVwIHRoYXQgdGhlIGF1dGhlbnRpY2F0b3IgYmVoYXZlcyB0aGlzIHdheT8gQmFz ZWQgb24gYnVnZ3kgaW1wbGVtZW50YXRpb24gb3IgYmFzZWQgb24gc3BlY2lmaWNhdGlvbj8NCg0K SSBkb27igJl0IGtub3figJRJ4oCZbSBub3QgdGhlIGF1dGhvciBvZiB0aGUgZG9jdW1lbnQuIEni gJltIGp1c3Qgc2VlaW5nIGEgbG90IG9mIHVuc3Vic3RhbnRpYXRlZCBhc3NlcnRpb25zIGZyb20g RWR1YXJkLCBhbmQgd291bGQgd2lzaCB0aGF0IGlmIGhl4oCZcyBnb2luZyB0byBtYWtlIGFzc2Vy dGlvbnMgdGhhdCBzb21ldGhpbmcgaXMgaW1wb3NzaWJsZSwgaGUgdGVsbCB1cyB3aHkgd2Ugc2hv dWxkIGJlbGlldmUgaGlzIGFzc2VydGlvbnMuIE90aGVyd2lzZSBpdCBqdXN0IHNlZW1zIGFyZ3Vt ZW50YXRpdmUuDQoNCg== --_000_717ae0d6cd5341f08edd8810f7dec43fhuaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRpbWVzTmV3Um9tYW47 DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJBcmlhbFwsQm9sZCI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBT dHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05v cm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkNoYXB0ZXINCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbFwsQm9sZCZxdW90OyI+Ni4zLjQgSW50ZXJvcGVyYWJpbGl0eSBh bmQgY29ubmVjdGl2aXR5PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQt YXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OlRpbWVzTmV3Um9tYW4iPkNoYW5nZXMgaW4gdGhlIG5hdHVyZSBvZiB0aGUgQ29udHJvbGxlZCBQ b3J0LuKAmXMgY29ubmVjdGl2aXR5IChmcm9tIG9uZSBvZiB1bmF1dGhlbnRpY2F0ZWQsIHVuc2Vj dXJlZCwgb3I8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6VGltZXNOZXdSb21hbiI+c2VjdXJlZCwgdG8gYW5vdGhlcikgYW5kIGNoYW5nZXMg aW4gc2VjdXJlZCBjb25uZWN0aXZpdHkgKGNoYW5nZXMgaW4gdGhlIENBKSwgYXJlIGFjY29tcGFu aWVkIGJ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OlRpbWVzTmV3Um9tYW4iPmNvbnRyb2xQb3J0RW5hYmxlZCB0cmFuc2l0aW9ucywgYW5k IGFyZSBzZWVuIGJ5IGNsaWVudHMgb2YgdGhlIENvbnRyb2xsZWQgUG9ydCBhcyBpbnRlcnJ1cHRp b25zIGluPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OlRpbWVzTmV3Um9tYW4iPmNvbm5lY3Rpdml0eS4gVGhlc2UgaW50ZXJydXB0aW9ucyAo c2lnbmFsZWQgYnkgY2hhbmdlcyBpbiBNQUNfT3BlcmF0aW9uYWwgZm9yIHRoZSBwb3J0KSBzaG91 bGQgYmUgdXNlZCB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTpUaW1lc05ld1JvbWFuIj5yZXN0YXJ0IGNsaWVudCBwcm90b2NvbCBzdGF0 ZSBtYWNoaW5lcyB0aGF0IHRha2UgZXhjZXB0aW9uYWwgb3IgYWNjZWxlcmF0ZWQgYWN0aW9uIHdo ZW4gY29ubmVjdGl2aXR5IGlzIGZpcnN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlRpbWVzTmV3Um9tYW4iPmF2YWlsYWJsZS4gRm9yIGV4 YW1wbGUsIGEgbmV0d29yayBhY2Nlc3MgcG9pbnQgdGhhdCBwcm92aWRlcyB1bmF1dGhlbnRpY2F0 ZWQgY29ubmVjdGl2aXR5IHRvIGEgaG9zdCBjYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6VGltZXNOZXdSb21hbiI+cHJvdmlkZSB0aGF0 IGhvc3QgYWNjZXNzIHRvIGEgZGlmZmVyZW50IElQIHN1Ym5ldCBvbmNlIGl0IGhhcyBiZWVuIGF1 dGhlbnRpY2F0ZWQsIGFuZCBpdCBpcyBhcHByb3ByaWF0ZSB0bzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpUaW1lc05ld1JvbWFuIj5yZWlu aXRpYWxpemUgREhDUCBzbyB0aGUgaG9zdCBjYW4gb2J0YWluIGEgZnJlc2ggSVAgYWRkcmVzcy48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpUaW1lc05ld1Jv bWFuIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OlRpbWVzTmV3Um9tYW4iPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5IZW5jZSwgaWYgYW55IHZlbmRvciB3b3VsZCBub3Qg4oCcPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlRpbWVzTmV3Um9tYW4i PnNpZ25hbGVkIGJ5IGNoYW5nZXMgaW4gTUFDX09wZXJhdGlvbmFsIGZvciB0aGUgcG9ydDwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+4oCdDQog4oCTIGl0IHdvdWxkIGJlIDgw Mi4xeC0yMDEwIHZpb2xhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPkVkLzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVGVk IExlbW9uIFttYWlsdG86bWVsbG9uQGZ1Z3VlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAyNyDQ vtC60YLRj9Cx0YDRjyAyMDIwINCzLiAyMToxMjxicj4NCjxiPlRvOjwvYj4gT2xlIFRyb2FuICZs dDtvdHJvYW5AZW1wbG95ZWVzLm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+IFZhc2lsZW5rbyBFZHVh cmQgJmx0O3Zhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbSZndDs7IElQdjYgT3BlcmF0aW9ucyAm bHQ7djZvcHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIGRy YWZ0LWlldGYtdjZvcHMtc2xhYWMtcmVudW0tMDQgLSA4MDIuMXggcmVsZXZhbmNlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gT2N0IDI3LCAyMDIwLCBh dCAyOjA4IFBNLCBPbGUgVHJvYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpvdHJvYW5AZW1wbG95ZWVz Lm9yZyI+b3Ryb2FuQGVtcGxveWVlcy5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPkkgdGhpbmsgeW91IHJldmVyc2UgdGhlIGJ1cmRlbiBvZiBwcm9vZiBoZXJlLiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj5JcyB0aGUgdXNlIGNhc2UgbWFkZSB1cCB0aGF0IHRoZSBh dXRoZW50aWNhdG9yIGJlaGF2ZXMgdGhpcyB3YXk/IEJhc2VkIG9uIGJ1Z2d5IGltcGxlbWVudGF0 aW9uIG9yIGJhc2VkIG9uIHNwZWNpZmljYXRpb24/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkb27i gJl0IGtub3figJRJ4oCZbSBub3QgdGhlIGF1dGhvciBvZiB0aGUgZG9jdW1lbnQuIEnigJltIGp1 c3Qgc2VlaW5nIGEgbG90IG9mIHVuc3Vic3RhbnRpYXRlZCBhc3NlcnRpb25zIGZyb20gRWR1YXJk LCBhbmQgd291bGQgd2lzaCB0aGF0IGlmIGhl4oCZcyBnb2luZyB0byBtYWtlIGFzc2VydGlvbnMg dGhhdCBzb21ldGhpbmcgaXMgaW1wb3NzaWJsZSwgaGUgdGVsbCB1cyB3aHkgd2Ugc2hvdWxkIGJl bGlldmUgaGlzIGFzc2VydGlvbnMuDQogT3RoZXJ3aXNlIGl0IGp1c3Qgc2VlbXMgYXJndW1lbnRh dGl2ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_717ae0d6cd5341f08edd8810f7dec43fhuaweicom_-- From nobody Tue Oct 27 12:29: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 9E55F3A1538 for ; Tue, 27 Oct 2020 12:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 flc9lLE3pSdk for ; Tue, 27 Oct 2020 12:29:21 -0700 (PDT) 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 0060A3A147C for ; Tue, 27 Oct 2020 12:29:20 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id m14so1888694qtc.12 for ; Tue, 27 Oct 2020 12:29:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=y+p74Kt7hqMP4piqqldMjyCR9aFOIvk4RuW4ENNVlns=; b=h7UQN2QHgeaz/AwjeFc87aK9UoMjosQvy+TfiT17U0gOaWwUEfDyqH6FC+cLRieMNO YJgJ4P+6fsDrdhBQY7P8y12aiTD5G30eT/nuV9yZq99dMCJy110S+SYkOgbiJstrByUG +J2EeloWEMAVgJZQ/NleN+jbqVUCsq7c06cgiMxLWslONQu0x+WqvOosShVHcjW6VHWv bw/YG1a/XcGTgxlavSYgR6FWxmiw+3WaguxJO0ZhklrAAeiBMNcjNQ4tYDLF/+dYugDw bbbVLoeLiK1rsz2YoRODbMuA+tqWFBmCiWlneHpw7Iug/gJybVYDt3a1zU05QrRy88FZ ymyA== 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=y+p74Kt7hqMP4piqqldMjyCR9aFOIvk4RuW4ENNVlns=; b=N4bboGizOYG/r1eFlKyAudQOfeILZ4PAaiLnzDAF3FDZ9tMlwTDJalDL8GDk+N/AAt /TPbfwGXncMz68X1bTLgHwlNbJtFn3eJuAg/1V/L+xSmukasidNCStCQuruJusXChmqx 8uSwTJcObpjDQZxpChfN1dN2xrRb1+1AMsqdwPO6CJddV3bTpjybqBeZIvAWfWoNM8Mc j1EKmA4H/vmEFiKlHMGdj7ssdoBa0RQBDn3dDCQ1HLuIl0CAFJicLRulS5M+bq2t/DDF ls0UMVbRsM1HbLIbV+zRCyPGwX/bmR/KiN4TEYnLkRjnGgOSj+2bmO41oYDeuQNrq4cK LC+A== X-Gm-Message-State: AOAM532HVoREDKQKcDEhGpLD3aX9iw1+Aqp2KuAY0ueZPlracCOs+iAO IyDEpAptW94q94Z0OG/tFmMnhvfZsleirA== X-Google-Smtp-Source: ABdhPJxLBi4JEPATiNLTH8tz5jdNSiJuODidHVghGjeYtnVypsoj5QhL4aEVvHPRbsSdYYtI9S1fjg== X-Received: by 2002:ac8:5c50:: with SMTP id j16mr3676593qtj.214.1603826959629; Tue, 27 Oct 2020 12:29:19 -0700 (PDT) Received: from mithrandir.lan (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id u26sm1390136qkj.17.2020.10.27.12.29.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Oct 2020 12:29:18 -0700 (PDT) From: Ted Lemon Message-Id: <7BDC1678-B356-4F98-8164-6ED4365F01B6@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8440D643-8443-48BC-B785-478EE8BA5E47" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.11\)) Date: Tue, 27 Oct 2020 15:29:17 -0400 In-Reply-To: <6EB8781C-F489-4F07-9224-6862066632D3@employees.org> Cc: Vasilenko Eduard , IPv6 Operations To: Ole Troan References: <6EB8781C-F489-4F07-9224-6862066632D3@employees.org> X-Mailer: Apple Mail (2.3654.20.0.2.11) Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance 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, 27 Oct 2020 19:29:23 -0000 --Apple-Mail=_8440D643-8443-48BC-B785-478EE8BA5E47 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Oct 27, 2020, at 3:02 PM, Ole Troan wrote: > The use of terms like =E2=80=9Cunsubstantiated assertions=E2=80=9D = isn=E2=80=99t so helpful for the discourse. The 802.1x specification is = available to you too. We haven=E2=80=99t all read every specification. If Eduard believes that = the specification says that this is impossible, why can he not just say = that, and point to where it says that? What is so hard about that? This isn=E2=80=99t a game. Wasting each others=E2=80=99 time by making = assertions that have to be laboriously checked by anyone following the = conversation is extremely unhelpful. Clearly Eduard feels that it is = important for Fernando not to say that 802.1x implements behave the way = Fernando says they do. He wants that text removed. Is it not = unreasonable for us to expect him to explain why in enough detail that = we aren=E2=80=99t left to either take him at his word or go try to = reconstruct his reasoning on our own? --Apple-Mail=_8440D643-8443-48BC-B785-478EE8BA5E47 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Oct 27, 2020, at 3:02 PM, Ole Troan <otroan@employees.org> wrote:
The use of terms like = =E2=80=9Cunsubstantiated assertions=E2=80=9D isn=E2=80=99t so helpful = for the discourse. The 802.1x specification is available  to you = too.

We haven=E2=80=99t = all read every specification. If Eduard believes that the specification = says that this is impossible, why can he not just say that, and point to = where it says that? What is so hard about that?

This isn=E2=80=99t a game. Wasting each others=E2=80= =99 time by making assertions that have to be laboriously checked by = anyone following the conversation is extremely unhelpful. Clearly Eduard = feels that it is important for Fernando not to say that 802.1x = implements behave the way Fernando says they do. He wants that text = removed. Is it not unreasonable for us to expect him to explain why in = enough detail that we aren=E2=80=99t left to either take him at his word = or go try to reconstruct his reasoning on our own?

= --Apple-Mail=_8440D643-8443-48BC-B785-478EE8BA5E47-- From nobody Tue Oct 27 12: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 D51663A1541 for ; Tue, 27 Oct 2020 12:32:38 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4naD8YCpBUW for ; Tue, 27 Oct 2020 12:32:37 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 218313A153B for ; Tue, 27 Oct 2020 12:32:37 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id h19so1905096qtq.4 for ; Tue, 27 Oct 2020 12:32:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=tAiOUT5Ut17LSN7yJ5xyOHg8kXVpxgO/c73NLFuqk+w=; b=q6fSIFWknDbOwswB1gRQSoXEX5dn1NmVAAt5PCQSOU0KNMJXLG3hx/sMJihmPaPMvs 1lpajK/amyFUruQKLMOL+Y976N7KsyZ2fHR0DDp8f8UkAZHh1f+wMasGRQ71VT8wdiJi lqPF+ZkZts7kvHDYC+YJmr3sLMvhRnk394keTDJpnSKiLi6IJ4Hnxinkn6YaZs5BGWtv MzwMAq7VA70PyLCl9/Qzz2EWb/nbti2qZuFlsDTKaYlfQQDsRQN0rO0GQYnhfzK8zVLg vkz25H8LdJ4OF0eeaFsm0IuVJ+MjWg1i+IHMMPUcsjAKiJObinCCvZLsccLGuUIPFMxx PjRw== 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=tAiOUT5Ut17LSN7yJ5xyOHg8kXVpxgO/c73NLFuqk+w=; b=somX3iMsGpkyd4Wngn2aTxR52q9TZ6Zt8UQRDZgiMMZtDfyMVd2HKJpt2a5fHbiIaU lXrjlG1bewq8qYFPk0MHLRreMjLMRUlkVfmFEKs7UNv45xUYB4EZrOYGU2zQdtgpPW0d 4Fc2i2UMFd33jKbizUvNPUF4VgRVsrETm1dtvVM/CTp+nHcK+giVz1QLdy+IRtlsm50H UaUwpriZfHBTO88Mh9e/fcKKcCOu5pav1eRkAgmoUm0QxszcMiQADQIm8UejoFbliuRG r1LjGlI/QHMPrEC9ejsMsCcJhFaDuZLjEHulsmHTG5rk36E/0yySDlMRkKmLbsruw9LR Y4Eg== X-Gm-Message-State: AOAM532WCFl+h6cJicS9B2D0ZtEy+9wyQHvWW35ooDwrPOTn3yL5X9Xt dfzFaHEW44vAbHc9E/Wrb3CeAL5ekWE/Lg== X-Google-Smtp-Source: ABdhPJzxj+hG757nrSGzfwwQUdPxeG44aV5QBE+PZP+ndA4lIKj0ePPUIIOzGVi4/zh9QkFJAOgUng== X-Received: by 2002:ac8:90a:: with SMTP id t10mr3947002qth.303.1603827156120; Tue, 27 Oct 2020 12:32:36 -0700 (PDT) Received: from mithrandir.lan (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id 198sm1400320qki.117.2020.10.27.12.32.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Oct 2020 12:32:35 -0700 (PDT) From: Ted Lemon Message-Id: <09D764EF-23D6-4EF6-8E73-6E0DB1EEA09E@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_A955F243-52D5-4019-952D-6A49179B781E" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.11\)) Date: Tue, 27 Oct 2020 15:32:34 -0400 In-Reply-To: <717ae0d6cd5341f08edd8810f7dec43f@huawei.com> Cc: Ole Troan , IPv6 Operations To: Vasilenko Eduard References: <35E2406D-0227-4728-BD85-1A5735FD9453@fugue.com> <13238DF7-2F43-437E-865B-4832F96117D8@employees.org> <717ae0d6cd5341f08edd8810f7dec43f@huawei.com> X-Mailer: Apple Mail (2.3654.20.0.2.11) Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance 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, 27 Oct 2020 19:32:39 -0000 --Apple-Mail=_A955F243-52D5-4019-952D-6A49179B781E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Oct 27, 2020, at 3:19 PM, Vasilenko Eduard = wrote: > Chapter 6.3.4 Interoperability and connectivity > Changes in the nature of the Controlled Port.=E2=80=99s connectivity = (from one of unauthenticated, unsecured, or > secured, to another) and changes in secured connectivity (changes in = the CA), are accompanied by > controlPortEnabled transitions, and are seen by clients of the = Controlled Port as interruptions in > connectivity. These interruptions (signaled by changes in = MAC_Operational for the port) should be used to > restart client protocol state machines that take exceptional or = accelerated action when connectivity is first > available. For example, a network access point that provides = unauthenticated connectivity to a host can > provide that host access to a different IP subnet once it has been = authenticated, and it is appropriate to > reinitialize DHCP so the host can obtain a fresh IP address. > =20 > Hence, if any vendor would not =E2=80=9Csignaled by changes in = MAC_Operational for the port=E2=80=9D =E2=80=93 it would be 802.1x-2010 = violation. Thanks. I will note that you have not actually contradicted what = Fernando said: that there are implementations that do not behave as the = spec says they should. --Apple-Mail=_A955F243-52D5-4019-952D-6A49179B781E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Oct 27, 2020, at 3:19 PM, Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote:
Chapter 6.3.4 Interoperability and connectivity
Changes = in the nature of the Controlled Port.=E2=80=99s connectivity (from one = of unauthenticated, unsecured, or
secured,= to another) and changes in secured connectivity (changes in the CA), = are accompanied by
controlPortEnabled transitions, = and are seen by clients of the Controlled Port as interruptions in
connectivity. These interruptions (signaled = by changes in MAC_Operational for the port) should be used to
restart client protocol state machines that = take exceptional or accelerated action when connectivity is first
available. For example, a network access = point that provides unauthenticated connectivity to a host can
provide that host access to a different IP = subnet once it has been authenticated, and it is appropriate to
reinitialize DHCP so the host can obtain a = fresh IP address.
 
Hence, if any vendor = would not =E2=80=9Csignaled by changes in MAC_Operational for = the port=E2=80=9D =E2=80=93 it = would be 802.1x-2010 violation.

Thanks. I will note that you have not = actually contradicted what Fernando said: that there are implementations = that do not behave as the spec says they should.

= --Apple-Mail=_A955F243-52D5-4019-952D-6A49179B781E-- From nobody Tue Oct 27 12:35: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 E7CF43A1545 for ; Tue, 27 Oct 2020 12:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 hIoQ2mQWMiwW for ; Tue, 27 Oct 2020 12:35:26 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 22B743A154F for ; Tue, 27 Oct 2020 12:35:26 -0700 (PDT) Received: from lhreml717-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 2D4133245106D4FD20AB; Tue, 27 Oct 2020 19:35:23 +0000 (GMT) Received: from msceml704-chm.china.huawei.com (10.219.141.143) by lhreml717-chm.china.huawei.com (10.201.108.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 27 Oct 2020 19:35:22 +0000 Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml704-chm.china.huawei.com (10.219.141.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 27 Oct 2020 22:35:22 +0300 Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Tue, 27 Oct 2020 22:35:22 +0300 From: Vasilenko Eduard To: Ted Lemon , Ole Troan CC: IPv6 Operations Thread-Topic: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance Thread-Index: AdarfiOiihVVds8iT0KdHPG3+auXlwAyC3uAAAafLvD//+bfgP//oBeggACQy4D//8jcoIAAPmwAgAAFZYCAAAD3AIAADkUAgAAHWoD//8ztcA== Date: Tue, 27 Oct 2020 19:35:22 +0000 Message-ID: References: <6EB8781C-F489-4F07-9224-6862066632D3@employees.org> <7BDC1678-B356-4F98-8164-6ED4365F01B6@fugue.com> In-Reply-To: <7BDC1678-B356-4F98-8164-6ED4365F01B6@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.197.128] Content-Type: multipart/alternative; boundary="_000_eeaf6ee6d3ee4c0fb823be0abb44af2dhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance 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, 27 Oct 2020 19:35:28 -0000 --_000_eeaf6ee6d3ee4c0fb823be0abb44af2dhuaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGVkLA0KSSBkaWQgY2hlY2sgaXQgYWxyZWFkeSDigJMgODAyLjF4IHNwZWNpZmljYXRpb24gY2xl YXJseSBwcm9oaWJpdHMgc3VjaCBiZWhhdmlvci4gU2VlIGRpZmZlcmVudCBtZXNzYWdlLg0KDQpJ IGhhdmUgc3RhcnRlZCB0aGlzIHRocmVhZCB3aXRoOg0KU29ycnkuIEkgaGF2ZSBzcG90dGVkIGl0 IGp1c3Qgbm93Lg0KDQpJIGRvIGFzc3VtZSB0aGF0IEZlcm5hbmRvIGhhcyBwdXQgdGhpcyB0ZXh0 IGZvciB0aGUgcmVhc29uLg0KSSBhbSBqdXN0IGFza2luZyBmb3IgdGhpcyByZWFzb24uDQpJdCBp cyBjbGVhcmx5IG5vdyB0aGF0IHNwZWNpZmljYXRpb24gcHJvaGliaXRzIHRoaXMuDQpUaGVuIHdo byB3YXMgdGhlIHZlbmRvci9wcm9kdWN0IHRoYXQgdmlvbGF0ZWQgODAyLjF4Pw0KSnVzdCBzYXkg dGhlIG5hbWXigKYNCg0KRWR1YXJkDQpGcm9tOiBUZWQgTGVtb24gW21haWx0bzptZWxsb25AZnVn dWUuY29tXQ0KU2VudDogMjcg0L7QutGC0Y/QsdGA0Y8gMjAyMCDQsy4gMjI6MjkNClRvOiBPbGUg VHJvYW4gPG90cm9hbkBlbXBsb3llZXMub3JnPg0KQ2M6IFZhc2lsZW5rbyBFZHVhcmQgPHZhc2ls ZW5rby5lZHVhcmRAaHVhd2VpLmNvbT47IElQdjYgT3BlcmF0aW9ucyA8djZvcHNAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogW3Y2b3BzXSBkcmFmdC1pZXRmLXY2b3BzLXNsYWFjLXJlbnVtLTA0IC0g ODAyLjF4IHJlbGV2YW5jZQ0KDQpPbiBPY3QgMjcsIDIwMjAsIGF0IDM6MDIgUE0sIE9sZSBUcm9h biA8b3Ryb2FuQGVtcGxveWVlcy5vcmc8bWFpbHRvOm90cm9hbkBlbXBsb3llZXMub3JnPj4gd3Jv dGU6DQpUaGUgdXNlIG9mIHRlcm1zIGxpa2Ug4oCcdW5zdWJzdGFudGlhdGVkIGFzc2VydGlvbnPi gJ0gaXNu4oCZdCBzbyBoZWxwZnVsIGZvciB0aGUgZGlzY291cnNlLiBUaGUgODAyLjF4IHNwZWNp ZmljYXRpb24gaXMgYXZhaWxhYmxlICB0byB5b3UgdG9vLg0KDQpXZSBoYXZlbuKAmXQgYWxsIHJl YWQgZXZlcnkgc3BlY2lmaWNhdGlvbi4gSWYgRWR1YXJkIGJlbGlldmVzIHRoYXQgdGhlIHNwZWNp ZmljYXRpb24gc2F5cyB0aGF0IHRoaXMgaXMgaW1wb3NzaWJsZSwgd2h5IGNhbiBoZSBub3QganVz dCBzYXkgdGhhdCwgYW5kIHBvaW50IHRvIHdoZXJlIGl0IHNheXMgdGhhdD8gV2hhdCBpcyBzbyBo YXJkIGFib3V0IHRoYXQ/DQoNClRoaXMgaXNu4oCZdCBhIGdhbWUuIFdhc3RpbmcgZWFjaCBvdGhl cnPigJkgdGltZSBieSBtYWtpbmcgYXNzZXJ0aW9ucyB0aGF0IGhhdmUgdG8gYmUgbGFib3Jpb3Vz bHkgY2hlY2tlZCBieSBhbnlvbmUgZm9sbG93aW5nIHRoZSBjb252ZXJzYXRpb24gaXMgZXh0cmVt ZWx5IHVuaGVscGZ1bC4gQ2xlYXJseSBFZHVhcmQgZmVlbHMgdGhhdCBpdCBpcyBpbXBvcnRhbnQg Zm9yIEZlcm5hbmRvIG5vdCB0byBzYXkgdGhhdCA4MDIuMXggaW1wbGVtZW50cyBiZWhhdmUgdGhl IHdheSBGZXJuYW5kbyBzYXlzIHRoZXkgZG8uIEhlIHdhbnRzIHRoYXQgdGV4dCByZW1vdmVkLiBJ cyBpdCBub3QgdW5yZWFzb25hYmxlIGZvciB1cyB0byBleHBlY3QgaGltIHRvIGV4cGxhaW4gd2h5 IGluIGVub3VnaCBkZXRhaWwgdGhhdCB3ZSBhcmVu4oCZdCBsZWZ0IHRvIGVpdGhlciB0YWtlIGhp bSBhdCBoaXMgd29yZCBvciBnbyB0cnkgdG8gcmVjb25zdHJ1Y3QgaGlzIHJlYXNvbmluZyBvbiBv dXIgb3duPw0KDQo= --_000_eeaf6ee6d3ee4c0fb823be0abb44af2dhuaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4w cHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRlZCw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+SSBkaWQgY2hlY2sgaXQgYWxyZWFkeSDigJMgODAyLjF4IHNwZWNpZmljYXRpb24gY2xlYXJs eSBwcm9oaWJpdHMgc3VjaCBiZWhhdmlvci4gU2VlIGRpZmZlcmVudCBtZXNzYWdlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBoYXZlIHN0YXJ0ZWQgdGhpcyB0 aHJlYWQgd2l0aDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5T b3JyeS4gSSBoYXZlIHNwb3R0ZWQgaXQganVzdCBub3cuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBkbyBh c3N1bWUgdGhhdCBGZXJuYW5kbyBoYXMgcHV0IHRoaXMgdGV4dCBmb3IgdGhlIHJlYXNvbi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+SSBhbSBqdXN0IGFza2luZyBmb3IgdGhpcyByZWFzb24uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkl0IGlzIGNsZWFybHkgbm93IHRoYXQgc3BlY2lmaWNhdGlvbiBwcm9oaWJpdHMg dGhpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlbiB3aG8gd2FzIHRoZSB2ZW5kb3IvcHJvZHVjdCB0 aGF0IHZpb2xhdGVkIDgwMi4xeD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SnVzdCBzYXkgdGhlIG5hbWXi gKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkVkdWFyZDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVGVkIExlbW9uIFttYWlsdG86 bWVsbG9uQGZ1Z3VlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiAyNyDQvtC60YLRj9Cx0YDRjyAy MDIwINCzLiAyMjoyOTxicj4NCjxiPlRvOjwvYj4gT2xlIFRyb2FuICZsdDtvdHJvYW5AZW1wbG95 ZWVzLm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+IFZhc2lsZW5rbyBFZHVhcmQgJmx0O3Zhc2lsZW5r by5lZHVhcmRAaHVhd2VpLmNvbSZndDs7IElQdjYgT3BlcmF0aW9ucyAmbHQ7djZvcHNAaWV0Zi5v cmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbdjZvcHNdIGRyYWZ0LWlldGYtdjZvcHMt c2xhYWMtcmVudW0tMDQgLSA4MDIuMXggcmVsZXZhbmNlPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gT2N0IDI3LCAyMDIwLCBhdCAzOjAyIFBNLCBPbGUg VHJvYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpvdHJvYW5AZW1wbG95ZWVzLm9yZyI+b3Ryb2FuQGVt cGxveWVlcy5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSB1c2Ug b2YgdGVybXMgbGlrZSDigJx1bnN1YnN0YW50aWF0ZWQgYXNzZXJ0aW9uc+KAnSBpc27igJl0IHNv IGhlbHBmdWwgZm9yIHRoZSBkaXNjb3Vyc2UuIFRoZSA4MDIuMXggc3BlY2lmaWNhdGlvbiBpcyBh dmFpbGFibGUgJm5ic3A7dG8geW91IHRvby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBoYXZlbuKA mXQgYWxsIHJlYWQgZXZlcnkgc3BlY2lmaWNhdGlvbi4gSWYgRWR1YXJkIGJlbGlldmVzIHRoYXQg dGhlIHNwZWNpZmljYXRpb24gc2F5cyB0aGF0IHRoaXMgaXMgaW1wb3NzaWJsZSwgd2h5IGNhbiBo ZSBub3QganVzdCBzYXkgdGhhdCwgYW5kIHBvaW50IHRvIHdoZXJlIGl0IHNheXMgdGhhdD8gV2hh dCBpcyBzbyBoYXJkIGFib3V0IHRoYXQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXNu4oCZdCBhIGdhbWUuIFdhc3RpbmcgZWFjaCBv dGhlcnPigJkgdGltZSBieSBtYWtpbmcgYXNzZXJ0aW9ucyB0aGF0IGhhdmUgdG8gYmUgbGFib3Jp b3VzbHkgY2hlY2tlZCBieSBhbnlvbmUgZm9sbG93aW5nIHRoZSBjb252ZXJzYXRpb24gaXMgZXh0 cmVtZWx5IHVuaGVscGZ1bC4gQ2xlYXJseSBFZHVhcmQgZmVlbHMgdGhhdCBpdCBpcyBpbXBvcnRh bnQgZm9yIEZlcm5hbmRvIG5vdCB0byBzYXkgdGhhdCA4MDIuMXgNCiBpbXBsZW1lbnRzIGJlaGF2 ZSB0aGUgd2F5IEZlcm5hbmRvIHNheXMgdGhleSBkby4gSGUgd2FudHMgdGhhdCB0ZXh0IHJlbW92 ZWQuIElzIGl0IG5vdCB1bnJlYXNvbmFibGUgZm9yIHVzIHRvIGV4cGVjdCBoaW0gdG8gZXhwbGFp biB3aHkgaW4gZW5vdWdoIGRldGFpbCB0aGF0IHdlIGFyZW7igJl0IGxlZnQgdG8gZWl0aGVyIHRh a2UgaGltIGF0IGhpcyB3b3JkIG9yIGdvIHRyeSB0byByZWNvbnN0cnVjdCBoaXMgcmVhc29uaW5n IG9uIG91ciBvd24/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_eeaf6ee6d3ee4c0fb823be0abb44af2dhuaweicom_-- From nobody Tue Oct 27 12:46: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 892B93A0EBA for ; Tue, 27 Oct 2020 12:46:41 -0700 (PDT) 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, 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=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 NdK4g-JR_WdX for ; Tue, 27 Oct 2020 12:46:39 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 9CFF03A0EBC for ; Tue, 27 Oct 2020 12:46:39 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id h12so1955285qtu.1 for ; Tue, 27 Oct 2020 12:46:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=XG+jyUswXyKp5vomfQm1sKAI8nYJ4VAZar2Ly1F8ivU=; b=t/2ZD/5RI0R1803GwjHSKYYnuWOJ22ihrsNYy0Ye1Db3vgD0B/GfdgGBoAUTUzhVwo IyjdNIp+VaySHuKg6EEMC/C1bXWUmZ5QrNMAMg1wJ4NVUU2jtRqBXKMnih/B7eRJbTFF 82yceIhULbm9XvdUu248GsiFegII2durhJ9sginytJZoM7sljMPqiQy6NPGXSmvgCGdq +IOADFHy3tYn6tac/icA2d4XIsQ2740D8fK1FsG5vApXcUByZ/qchS78T9YYKe+S91F1 1Cl83ULb2Ah0RPyDOwro9HwPzRbihgQUGB8vgvo524aZerjn+7WitvUPO1gL6j/+h4je jiQA== 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=XG+jyUswXyKp5vomfQm1sKAI8nYJ4VAZar2Ly1F8ivU=; b=By4Ks1Hz0BCtioRKS7HRRrJ4kk3SAdKcJ+dQpr68QOJ87WCwoalX4BJCS8PKzhj4Db q8F7NbKcXGjDXfcDvmr0SZ2YJW/By0K4HPJL/GZEDWEVFyQ7kwdF3w/NekxYMYNVmPdz KP0RtgVyGGjS69mu7cOgvq7S3XuJrIH9v5wr3TzK6bNe9qh741RczSqHlhcrEZwpnkj4 XDDpF4TeGQG3H4Z/0bWXRaIi9lOUOf1LNWv3xWO5GqZagct0Y3K+qJPpBxcdMumZWCMv u7LmkBqT1aGXtytCFM6PkAWV6fslyH8iOpW6wb/k518uVi+5xlcDu0MF3bFQc8v1Mnde YNfA== X-Gm-Message-State: AOAM533N0nv+qzcsVhYn4ApspEu6R/9hq/+nwyUCEFcnGLTgZ6qoj8Wm pQeqqS6fsPez6wgTubv2s4QyHQ== X-Google-Smtp-Source: ABdhPJwnpOl8KmFmF/INqFKfmwITmqNrjQKjT6ArBPdBpwTtmPTlztYMEO6w21kFc8aP7NmYpBfatA== X-Received: by 2002:aed:2ba6:: with SMTP id e35mr3914821qtd.251.1603827998406; Tue, 27 Oct 2020 12:46:38 -0700 (PDT) Received: from mithrandir.lan (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id p77sm1326981qke.39.2020.10.27.12.46.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Oct 2020 12:46:37 -0700 (PDT) From: Ted Lemon Message-Id: <59F7A0FE-67FC-42E7-AAE6-E738D5467158@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_FCBE826D-627A-45B4-82B8-08EE61670FAA" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.11\)) Date: Tue, 27 Oct 2020 15:46:36 -0400 In-Reply-To: Cc: Ole Troan , IPv6 Operations To: Vasilenko Eduard References: <6EB8781C-F489-4F07-9224-6862066632D3@employees.org> <7BDC1678-B356-4F98-8164-6ED4365F01B6@fugue.com> X-Mailer: Apple Mail (2.3654.20.0.2.11) Archived-At: Subject: Re: [v6ops] draft-ietf-v6ops-slaac-renum-04 - 802.1x relevance 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, 27 Oct 2020 19:46:42 -0000 --Apple-Mail=_FCBE826D-627A-45B4-82B8-08EE61670FAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Oct 27, 2020, at 3:35 PM, Vasilenko Eduard = wrote: > Then who was the vendor/product that violated 802.1x? > Just say the name=E2=80=A6 That=E2=80=99s a fair question, but e.g. if I were to say something like = that, I would be prohibited by my employee agreement from saying who. As = a general rule in the IETF we don=E2=80=99t call corporations out = directly for mistakes like this because doing so puts our employers and = the IETF at risk of lawsuit. I know this because I used to make demands = of the sort you are making, and had it explained to me rather vigorously = by a then-AD. Another reason not to answer this in an RFC or on a public mailing list = is that the vendor might fix their implementation, but the assertion = would forever remain on the record, and might continue to be believed. = So it=E2=80=99s not a good practice. A better question for Fernando would be =E2=80=9Cdo you know of specific = current implementations which get this wrong?=E2=80=9D Without asking = him to say which specific implementations. If he says =E2=80=9Cno, I = don=E2=80=99t know of any, I=E2=80=99m just theorizing,=E2=80=9D then = you are right to ask him to take out the text. If he says =E2=80=9Cyes,=E2= =80=9D then it would be more collegial to take him at his word then to = insist that he take it out if he can=E2=80=99t make specific = accusations. Why would someone lie about this? --Apple-Mail=_FCBE826D-627A-45B4-82B8-08EE61670FAA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Oct 27, 2020, at 3:35 PM, Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote:
Then who was the vendor/product that = violated 802.1x?
Just say the name=E2=80=A6

That=E2=80=99s a fair question, but e.g. = if I were to say something like that, I would be prohibited by my = employee agreement from saying who. As a general rule in the IETF we = don=E2=80=99t call corporations out directly for mistakes like this = because doing so puts our employers and the IETF at risk of lawsuit. I = know this because I used to make demands of the sort you are making, and = had it explained to me rather vigorously by a then-AD.

Another reason not to = answer this in an RFC or on a public mailing list is that the vendor = might fix their implementation, but the assertion would forever remain = on the record, and might continue to be believed. So it=E2=80=99s not a = good practice.

A= better question for Fernando would be =E2=80=9Cdo you know of specific = current implementations which get this wrong?=E2=80=9D Without asking = him to say which specific implementations. If he says =E2=80=9Cno, I = don=E2=80=99t know of any, I=E2=80=99m just theorizing,=E2=80=9D then = you are right to ask him to take out the text. If he says =E2=80=9Cyes,=E2= =80=9D then it would be more collegial to take him at his word then to = insist that he take it out if he can=E2=80=99t make specific = accusations. Why would someone lie about this?

= --Apple-Mail=_FCBE826D-627A-45B4-82B8-08EE61670FAA-- From nobody Tue Oct 27 14:42: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 5E6863A0FDE for ; Tue, 27 Oct 2020 14:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.587 X-Spam-Level: X-Spam-Status: No, score=-0.587 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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=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 yGx2FMU_A9Lf for ; Tue, 27 Oct 2020 14:42:53 -0700 (PDT) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA9533A0FB0 for ; Tue, 27 Oct 2020 14:42:53 -0700 (PDT) Received: by mail-oi1-x231.google.com with SMTP id y186so2875266oia.3 for ; Tue, 27 Oct 2020 14:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M2aL1EBKPIctGbcBonuvI2dwCZo0VxK8sMMeR+2Qfqo=; b=o2InlAwoAwM5aFG/QIljw79SnLZ72h/35oZPMCGcujyNBs8R7yHi2G8F1t4efGxbY/ vNxLCKqR5yyUUkc/hQM9axJ4vfL6+Dsu8YCj74K/ST+mfsmfqmFeK/b6/6tdbju1Vfzf HEkhqi9Q1U1j988VtaS/59PF3liLn8eK0R5XrAgpRqXh1pngPf5SisjUABCaBlnqjivG voO3eBueS3f3RgDQNSsmLob/hglGGbxTN8yolWyEQgeiG3BfOly4EaWfqm2mx+y9H5aS nl/hkYWXQ4hKRRA8JEoHadOGZDj80V0WEEi2lPSWIHKC+N9FyBAnjtIWmwPVC3sSWfFo 4bYg== 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=M2aL1EBKPIctGbcBonuvI2dwCZo0VxK8sMMeR+2Qfqo=; b=gqgEw9Vo7UnbjJyJWi4ifCI2nNlozxiy9RJbPpWSA4kRguHCMFZ5z55VsYKzthUhaA MRkfU672y6tbbOJdzpmLjmBn1klcFHK6IUyx2e7JIlM2PMsRHvwlAzleyB2Z2E5/UlLg 1FTlIpZ1L6AbopjTS+Qsv+kV5yu/bppfr/rrczUlQdgQL6h+J32M5zZv85dVbUwP62uu AEvVfjAb/1dertCxggi6MaM9InoW/X9W0j68LKmqAqtvTo2+6FQfPOeO9NFkuzDrsRvJ Vsq4w0cjIDPSCRu8VDtC3uGdEX2iqV0GFc4EWaXrKB2cS8OTJt9m80aTkflj9vss2YD+ 10lA== X-Gm-Message-State: AOAM5332n5R1DyHahHFRA/mslG4Ex8c8mxL9kyQ/5nTdopBJjiWxq+fP JIiSi7uWu6n6JUmovTr0iYkD46E5ONBZcXmFJCw= X-Google-Smtp-Source: ABdhPJwPkuWTDfNvLCENJ1CfFbVuhlHYodSqTGHrrEhOeV1JWnMkq0myUT7Ky/Hc8ndSkfYxNqD2EI+PDM4rGo3J0FE= X-Received: by 2002:aca:c1c3:: with SMTP id r186mr2906875oif.164.1603834972903; Tue, 27 Oct 2020 14:42:52 -0700 (PDT) MIME-Version: 1.0 References: <19EE82F7-8D52-4519-8087-0DF17435A3B8@gmail.com> In-Reply-To: From: Mark Smith Date: Wed, 28 Oct 2020 08:42:41 +1100 Message-ID: To: Gyan Mishra Cc: Greg Mirsky , Jeff Tantsura , v6ops list Content-Type: multipart/alternative; boundary="000000000000d69bfc05b2aded98" Archived-At: Subject: Re: [v6ops] draft-smith-v6ops-larger-ipv6-loopback-prefix-04 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, 27 Oct 2020 21:42:55 -0000 --000000000000d69bfc05b2aded98 Content-Type: text/plain; charset="UTF-8" Hi Gyan, On Tue, 27 Oct 2020, 14:38 Gyan Mishra, wrote: > > Hi Mark > > Thanks for responding. > > The use case was for BFD continuity test for special use cases or MPLS lsp > ping and now draft for vxlan BFD, where for IPv4 for continuity test you > have 127/8 loopback but for IPv6 there is only one loopback address ::/128. > > > For IPv6 we ended up using IPv4 mapped IPv6 addresses for MPLS LSP ping > used to bootstrap to FEC LSP ping to BFD. So now for new vxlan BFD the > topic came up and again for another draft which now as a standard we are > now planning to use IPv4 mapped IPv6 for BFD continuity test. > I think it would be better to come up with a native IPv6 method rather than importing IPv4 addresses into IPv6 just to get the capability you need. Ultimately I think an IPv6 only network should have no IPv4 in it at all, including no IPv4 mapped addresses. > That BFD thread brought back the IPv6 RFC 4291 standard that IPv6 only has > one loopback where IPv4 has a /8 worth. > > As you stated per RFC 4291, there is supposedly a link local /64 fe80::/64 > loopback on the loopback interface which has plenty of space. I have to > check on a router but I am guessing If that is implemented by all router > vendors following RFC 4291, then that would be an alternative option to > IPv4 mapped IPv6 for BFD continuity tests. > Using link-locals would be the better option. If you need to encode special forwarding handling, other than standard unicast forwarding, then I think a special well known prefix e.g. an IANA assigned/64 or /48 for this purpose would be the best option. There are already a number of IPv6 examples where special forwarding rules are defined for a well known prefix - link-local address space, the ff00::/8 multicast address space, and the RFC6666 discard prefix. Regards, Mark. > Thanks > > Gyan > > On Mon, Oct 26, 2020 at 9:22 PM Mark Smith wrote: > >> Hi Gyan, >> >> Sorry not to get back to you sooner. >> >> On Tue, 20 Oct 2020 at 00:26, Gyan Mishra wrote: >> > >> > >> > Hi Mark >> > >> > What ended up happening with this draft >> >> I let it expire, as I didn't think it would be adopted by the WG. >> >> There seemed to be a bit of resistance to it as people said that ULAs >> could be used instead. >> >> The link local prefix is also required on any IPv6 interface, per >> RFC4291, so there is supposed to be a link-local /64 on the loopback >> interface(s) providing many addresses to which a process could be >> separately bound, although a drawback of using the link-local prefix >> is having to deal with scope/zone IDs (although Linux doesn't comply >> with that requirement, it doesn't have a link-local address on the >> loopback interface by default). >> >> > and was the work picked up in any other draft. >> >> Not as far as I'm aware. >> >> What is your use case? >> >> Regards, >> Mark. >> >> >> > >> > Thanks >> > >> > Gyan >> > >> > Sent from my iPhone >> > -- > > > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > > > *M 301 502-134713101 Columbia Pike *Silver Spring, MD > > --000000000000d69bfc05b2aded98 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Gyan,

On Tue, 27 Oct 2020, 14:38 Gyan Mishra, <<= a href=3D"mailto:hayabusagsm@gmail.com" rel=3D"noreferrer noreferrer" targe= t=3D"_blank">hayabusagsm@gmail.com> wrote:

Hi Mark

Thanks for responding.

The use case was for BFD continuity test for= special use cases or MPLS lsp ping and now draft for =C2=A0vxlan BFD, wher= e for IPv4 for continuity test you have 127/8 loopback but for IPv6 there i= s only one loopback address ::/128. =C2=A0

For IPv6 we ended up using IPv4 mapped IPv6 addresses fo= r MPLS LSP ping used to bootstrap to FEC LSP ping to BFD.=C2=A0 So now for = new vxlan BFD the topic came up and again for another draft which now as a = standard we are now planning to use IPv4 mapped IPv6 for BFD continuity tes= t.

I think it would be better to come up with a native IPv6 method rather = than importing IPv4 addresses into IPv6 just to get the capability you need= .

Ultimately I think an = IPv6 only network should have no IPv4 in it at all, including no IPv4 mappe= d addresses.


<= div dir=3D"auto">
=

That BFD thread brought back = the IPv6 RFC 4291 standard that IPv6 only has one loopback where IPv4 has a= /8 worth. =C2=A0

As you= stated per RFC 4291, there is supposedly a link local /64 fe80::/64 loopba= ck on the loopback interface which has plenty of space.=C2=A0 I have to che= ck on a router but I am guessing If that is implemented by all router vendo= rs following RFC 4291, then that would be an alternative option to IPv4 map= ped IPv6 for BFD continuity tests.=C2=A0

Using link-locals would be the be= tter option.

If you need= to encode special forwarding handling, other than standard unicast forward= ing, then I think a special well known prefix e.g. an IANA assigned/64 or /= 48 for this purpose would be the best option.

There are already a number of IPv6 examples where spe= cial forwarding rules are defined for a well known prefix - link-local addr= ess space, the ff00::/8 multicast address space, and the RFC6666 discard pr= efix.

Regards,
Mark.

Thanks=C2=A0

Gyan

On Mon, Oct 26, 2020 at 9:22 PM Mark Smith <markzzzsmith@gmail.com> wrote:
Hi Gyan,

Sorry not to get back to you sooner.

On Tue, 20 Oct 2020 at 00:26, Gyan Mishra <haya= busagsm@gmail.com> wrote:
>
>
> Hi Mark
>
> What ended up happening with this draft

I let it expire, as I didn't think it would be adopted by the WG.

There seemed to be a bit of resistance to it as people said that ULAs
could be used instead.

The link local prefix is also required on any IPv6 interface, per
RFC4291, so there is supposed to be a link-local /64 on the loopback
interface(s) providing many addresses to which a process could be
separately bound, although a drawback of using the link-local prefix
is having to deal with scope/zone IDs (although Linux doesn't comply with that requirement, it doesn't have a link-local address on the
loopback interface by default).

> and was the work picked up in any other draft.

Not as far as I'm aware.

What is your use case?

Regards,
Mark.


>
> Thanks
>
> Gyan
>
> Sent from my iPhone
--


Gyan Mishra

= Network Solutions Architect=C2=A0

M 301 502-1347<= br>13101 Columbia Pike=C2=A0
Silver Spring, MD

=
--000000000000d69bfc05b2aded98-- From nobody Tue Oct 27 15:10: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 8606A3A0F61 for ; Tue, 27 Oct 2020 15:10:52 -0700 (PDT) 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 QlB7nzfYmn45 for ; Tue, 27 Oct 2020 15:10:50 -0700 (PDT) Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (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 911353A1675 for ; Tue, 27 Oct 2020 15:10:36 -0700 (PDT) Received: by mail-vk1-xa35.google.com with SMTP id i62so739177vkb.7 for ; Tue, 27 Oct 2020 15:10:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jNSzN0xGpDPo8Uq60Ro1JJF4sWWU01A51i3aA+I9V/U=; b=K0zFZJXJdWWLLtzOqYfimzLZ/NBR5pfRJU50tYeyftJ/xD1X8ys9GBhP+r1oQioxWI I4uga2ozoFJvHEhd//zDz7h2Ask541IixaUJgUeT0KLA8PhH1B+OBx2XBdYvQZINw8sz Dc6+AytwAEnvUsDEWf6wyTL+1BvoqeWZYzpVMAcRUkXQ+yQmK9dGp+fOS49qGdxsvEvE dbt6Ln+fikNeuiX6fr6pU3gkcTSAIdBxBh82QC9WvoBe2OtHLJv1v4AKpHEodn+qEuCH usIfgRvgZl9cqwIirYgym6TQ4obfhLiUpJMwLc07dIBFjeEu2cDsg0/QXFYTxyTeDbWg tKFA== 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=jNSzN0xGpDPo8Uq60Ro1JJF4sWWU01A51i3aA+I9V/U=; b=ORTlBzg2biIDIPZgXBDP+MbV4AbiRrWW9mCepVhmx5gJ4K8GPkC6wyEaHn9UN0Zxkn rtqnWctiwJhgyxnCjvhHzZBZDk6XTNPtNIValqa5NYQgOMBAOOCtECQzazaomQ7oSlmM mjuJCkd7AdDLCTHJyYuEgivUHHt02+Yv4F9cNptnmvjIePNy9a7KT+1cocuz25dax8e/ lL/vSBgspGUH6w7iZjOaKZcwOYp9tzlVNdcs7me7H3RAj32rJhy3H5jCjDJYiX3TO+Oz nUondaES70tzMfxTB9ceVSYmhxet2grqKHWOOXDrATMPd3raK1Ik8ar2HriUNe5ccO8V 6fUA== X-Gm-Message-State: AOAM533+EO7/0kILyogT+ekUXxwku8LD9iKvIroKq0F1OTpbW4QIIwWZ DBT+m84MCtdvRj+wxCvn54x8lHEbqmKYahRVCP8= X-Google-Smtp-Source: ABdhPJwsZ8udbp+zfwjGGYhsJbfGXLqNlMIh7sqTiwB8IQ5bMtQ/LNSFjvDApwMTfkzYEa0xMVqHpzr1vgh+3A5varY= X-Received: by 2002:ac5:c80e:: with SMTP id y14mr3470989vkl.3.1603836635305; Tue, 27 Oct 2020 15:10:35 -0700 (PDT) MIME-Version: 1.0 References: <19EE82F7-8D52-4519-8087-0DF17435A3B8@gmail.com> In-Reply-To: From: Gyan Mishra Date: Tue, 27 Oct 2020 18:10:24 -0400 Message-ID: To: Mark Smith Cc: Greg Mirsky , Jeff Tantsura , v6ops list Content-Type: multipart/alternative; boundary="000000000000ecd8f805b2ae5026" Archived-At: Subject: Re: [v6ops] draft-smith-v6ops-larger-ipv6-loopback-prefix-04 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, 27 Oct 2020 22:10:53 -0000 --000000000000ecd8f805b2ae5026 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mark Thanks for a lot of very good points and ideas! On Tue, Oct 27, 2020 at 5:42 PM Mark Smith wrote: > Hi Gyan, > > On Tue, 27 Oct 2020, 14:38 Gyan Mishra, wrote: > >> >> Hi Mark >> >> Thanks for responding. >> >> The use case was for BFD continuity test for special use cases or MPLS >> lsp ping and now draft for vxlan BFD, where for IPv4 for continuity tes= t >> you have 127/8 loopback but for IPv6 there is only one loopback address >> ::/128. >> >> For IPv6 we ended up using IPv4 mapped IPv6 addresses for MPLS LSP ping >> used to bootstrap to FEC LSP ping to BFD. So now for new vxlan BFD the >> topic came up and again for another draft which now as a standard we are >> now planning to use IPv4 mapped IPv6 for BFD continuity test. >> > > I think it would be better to come up with a native IPv6 method rather > than importing IPv4 addresses into IPv6 just to get the capability you ne= ed. > Gyan> I was thinking the same about the very very soon eventual IPv6 only core transports. I have a draft in BESS WG that I am presenting at IETF 109 that is based on RFC 6555 softwire mesh framework basically 4 edge over a v6 only core which using RFC 5549 next hop encoding we can eliminate for operators all IPv4 peering down that it IPv4 AFI NLRI is stacked on top of IPv6 BGP peer. With that model IPv4 would be 100% eliminated from the core transport. The BFD continuity test is on the core transport so I definitely can see the downside of IPv4 mapped IPV6 when IPV4 is eliminated from the core. I don=E2=80=99t think we want any IPv6 being underpinned by= IPv4 which is what happens with doing the IPv4 mapped IPv6. > > Ultimately I think an IPv6 only network should have no IPv4 in it at all, > including no IPv4 mapped addresses. > Gyan> Agreed > > > >> That BFD thread brought back the IPv6 RFC 4291 standard that IPv6 only >> has one loopback where IPv4 has a /8 worth. >> >> As you stated per RFC 4291, there is supposedly a link local /64 >> fe80::/64 loopback on the loopback interface which has plenty of space. = I >> have to check on a router but I am guessing If that is implemented by al= l >> router vendors following RFC 4291, then that would be an alternative opt= ion >> to IPv4 mapped IPv6 for BFD continuity tests. >> > > Using link-locals would be the better option. > Gyan> Agreed > > If you need to encode special forwarding handling, other than standard > unicast forwarding, then I think a special well known prefix e.g. an IANA > assigned/64 or /48 for this purpose would be the best option. > > There are already a number of IPv6 examples where special forwarding rule= s > are defined for a well known prefix - link-local address space, the > ff00::/8 multicast address space, and the RFC6666 discard prefix. > Gyan> That is definitely an interesting idea and I think makes sense and viable for sure. There maybe other use cases I am thinking out loud maybe with BIER IPv6 MVPN and possible some other use cases. I wonder even for the SRv6 locator maybe having a special range outside of GUI allocation as it has special handling with steering. Another question related to IPv6 Anycast. IPv6 has built in anycast address, I believe it=E2=80=99s the last 7 bits subnet router Anycast addre= ss. Since any routable prefix can be Anycasted for services proximity routing, what is the real use case or functionality of the IPv6 built in Anycast /121 range. > > Regards, > Mark. > > >> Thanks >> >> Gyan >> >> On Mon, Oct 26, 2020 at 9:22 PM Mark Smith >> wrote: >> >>> Hi Gyan, >>> >>> Sorry not to get back to you sooner. >>> >>> On Tue, 20 Oct 2020 at 00:26, Gyan Mishra wrote= : >>> > >>> > >>> > Hi Mark >>> > >>> > What ended up happening with this draft >>> >>> I let it expire, as I didn't think it would be adopted by the WG. >>> >>> There seemed to be a bit of resistance to it as people said that ULAs >>> could be used instead. >>> >>> The link local prefix is also required on any IPv6 interface, per >>> RFC4291, so there is supposed to be a link-local /64 on the loopback >>> interface(s) providing many addresses to which a process could be >>> separately bound, although a drawback of using the link-local prefix >>> is having to deal with scope/zone IDs (although Linux doesn't comply >>> with that requirement, it doesn't have a link-local address on the >>> loopback interface by default). >>> >>> > and was the work picked up in any other draft. >>> >>> Not as far as I'm aware. >>> >>> What is your use case? >>> >>> Regards, >>> Mark. >>> >>> >>> > >>> > Thanks >>> > >>> > Gyan >>> > >>> > Sent from my iPhone >>> >> -- >> >> >> >> *Gyan Mishra* >> >> *Network Solutions A**rchitect * >> >> >> >> *M 301 502-134713101 Columbia Pike >> *Silver >> Spring, MD >> >> >> -- *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD --000000000000ecd8f805b2ae5026 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mark=C2=A0

Thanks for a lot of very good points and ideas!


On Tue, Oct 27, 2020 at 5:42 PM Mark Smith <markzzzsmith@gmail.com> wrote:
Hi Gyan,

On Tue, 27 Oc= t 2020, 14:38 Gyan Mishra, <hayabusagsm@gmail.com> = wrote:

Hi Mark

Thanks for = responding.

The use case= was for BFD continuity test for special use cases or MPLS lsp ping and now= draft for =C2=A0vxlan BFD, where for IPv4 for continuity test you have 127= /8 loopback but for IPv6 there is only one loopback address ::/128. =C2=A0<= /div>

For IPv6 we ended up usi= ng IPv4 mapped IPv6 addresses for MPLS LSP ping used to bootstrap to FEC LS= P ping to BFD.=C2=A0 So now for new vxlan BFD the topic came up and again f= or another draft which now as a standard we are now planning to use IPv4 ma= pped IPv6 for BFD continuity test.

I think it would be better to come up= with a native IPv6 method rather than importing IPv4 addresses into IPv6 j= ust to get the capability you need.

=C2=A0 =C2=A0 Gyan> I was thinking the sa= me about the very very soon eventual IPv6 only core transports.=C2=A0 I hav= e a draft in BESS WG that I am presenting at IETF 109 that is based on RFC = 6555 softwire mesh framework basically 4 edge over a v6 only core which usi= ng RFC 5549 next hop encoding we can eliminate for operators all IPv4 peeri= ng down that it IPv4 AFI NLRI =C2=A0is stacked on top of IPv6 BGP peer.=C2= =A0 With that model IPv4 would be 100% eliminated from the core transport.= =C2=A0 The BFD continuity test is on the core transport so I definitely can= see the downside of IPv4 mapped IPV6 when IPV4 is eliminated from the core= .=C2=A0 I don=E2=80=99t think we want any IPv6 being underpinned by IPv4 wh= ich is what happens with doing the IPv4 mapped IPv6.
<= br>
Ultimately I think an IPv6 only network should h= ave no IPv4 in it at all, including no IPv4 mapped addresses.
=C2=A0=C2=A0
Gyan> Agreed=C2=A0



That BFD thread brought back the= IPv6 RFC 4291 standard that IPv6 only has one loopback where IPv4 has a /8= worth. =C2=A0

As you st= ated per RFC 4291, there is supposedly a link local /64 fe80::/64 loopback = on the loopback interface which has plenty of space.=C2=A0 I have to check = on a router but I am guessing If that is implemented by all router vendors = following RFC 4291, then that would be an alternative option to IPv4 mapped= IPv6 for BFD continuity tests.=C2=A0

=C2=A0 =C2=A0Gyan> Agreed=C2=A0

If you need to encode special forwarding handling, other than= standard unicast forwarding, then I think a special well known prefix e.g.= an IANA assigned/64 or /48 for this purpose would be the best option.

There are already a number of IPv6 = examples where special forwarding rules are defined for a well known prefix= - link-local address space, the ff00::/8 multicast address space, and the = RFC6666 discard prefix.

=C2=A0 =C2=A0 Gyan> That is definitely an interesting= idea and I think makes sense and viable for sure.=C2=A0 There maybe other = use cases I am thinking out loud maybe with BIER IPv6 =C2=A0MVPN and possib= le some other use cases.=C2=A0 I wonder even for the SRv6 locator maybe hav= ing a special range outside of GUI allocation as it has special handling wi= th steering. =C2=A0

Anot= her question related to IPv6 Anycast.=C2=A0 IPv6 has built in anycast addre= ss, I believe it=E2=80=99s the last 7 bits subnet router Anycast address.= =C2=A0 Since any routable prefix can be Anycasted for services proximity ro= uting, =C2=A0what is the real use case or functionality of the IPv6 built i= n Anycast /121 range. =C2=A0

Regards,
Mark.


Tha= nks=C2=A0

Gyan

On Mo= n, Oct 26, 2020 at 9:22 PM Mark Smith <markzzz= smith@gmail.com> wrote:
Hi Gyan,

Sorry not to get back to you sooner.

On Tue, 20 Oct 2020 at 00:26, Gyan Mishra <haya= busagsm@gmail.com> wrote:
>
>
> Hi Mark
>
> What ended up happening with this draft

I let it expire, as I didn't think it would be adopted by the WG.

There seemed to be a bit of resistance to it as people said that ULAs
could be used instead.

The link local prefix is also required on any IPv6 interface, per
RFC4291, so there is supposed to be a link-local /64 on the loopback
interface(s) providing many addresses to which a process could be
separately bound, although a drawback of using the link-local prefix
is having to deal with scope/zone IDs (although Linux doesn't comply with that requirement, it doesn't have a link-local address on the
loopback interface by default).

> and was the work picked up in any other draft.

Not as far as I'm aware.

What is your use case?

Regards,
Mark.


>
> Thanks
>
> Gyan
>
> Sent from my iPhone
--


Gyan Mishra

= Network Solutions Architect=C2=A0

M 301 502-1347<= br>13101 Columbia Pike=C2=A0
Silver Spring= , MD


=
--
--000000000000ecd8f805b2ae5026-- From nobody Tue Oct 27 20:50: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 024423A0D49 for ; Tue, 27 Oct 2020 20:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 ef0fdZa8r3RB for ; Tue, 27 Oct 2020 20:49:58 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 67DB73A0D47 for ; Tue, 27 Oct 2020 20:49:58 -0700 (PDT) Received: from lhreml749-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 93243CD02991C017C5C7; Wed, 28 Oct 2020 03:49:55 +0000 (GMT) Received: from nkgeml706-chm.china.huawei.com (10.98.57.153) by lhreml749-chm.china.huawei.com (10.201.108.199) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 28 Oct 2020 03:49:54 +0000 Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml706-chm.china.huawei.com (10.98.57.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Wed, 28 Oct 2020 11:49:52 +0800 Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Wed, 28 Oct 2020 11:49:52 +0800 From: "Xiejingrong (Jingrong)" To: Gyan Mishra , Mark Smith CC: Greg Mirsky , Jeff Tantsura , v6ops list Thread-Topic: [v6ops] draft-smith-v6ops-larger-ipv6-loopback-prefix-04 Thread-Index: AQHWphuXMxEIxTwgM0aGJwxQrGRXm6mqLLcAgAAmTACAAS7agIAAB78AgADiObA= Date: Wed, 28 Oct 2020 03:49:52 +0000 Message-ID: <209001a434c84ceb8669b5f0e7e7b063@huawei.com> References: <19EE82F7-8D52-4519-8087-0DF17435A3B8@gmail.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.108.201.174] Content-Type: multipart/related; boundary="_004_209001a434c84ceb8669b5f0e7e7b063huaweicom_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [v6ops] draft-smith-v6ops-larger-ipv6-loopback-prefix-04 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, 28 Oct 2020 03:50:01 -0000 --_004_209001a434c84ceb8669b5f0e7e7b063huaweicom_ Content-Type: multipart/alternative; boundary="_000_209001a434c84ceb8669b5f0e7e7b063huaweicom_" --_000_209001a434c84ceb8669b5f0e7e7b063huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpBZ3JlZWQgdmVyeSBtdWNoIHRoYXQgbGFyZ2VyLWlwdjYtbG9vcGJhY2stcHJlZml4IGlz IHVzZWZ1bCBmb3IgSVB2Ni1vbmx5IG5ldHdvcmsuIFRoYW5rcyBmb3IgZGlnZ2luZyBvdXQgdGhp cyDigKYNCkFzIHRoZSBkcmFmdCBhbHJlYWR5IHN0YXRlZCBhdCB0aGUgdmVyeSBiZWdpbm5pbmcs ICDigJx0byBydW4gbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoZSBhcHBsaWNhdGlvbiB1c2luZyB0 aGUgc2FtZSB0cmFuc3BvcnQgbGF5ZXIgcHJvdG9jb2wgcG9ydCBvbiB0aGUgc2FtZSBkZXZlbG9w bWVudCBob3N0LuKAnQ0KQWxzbyB1c2VmdWwgdG8gZWxpbWluYXRlIHRoZSBuZWVkIG9mIHRvbyBt YW55IFVEUCBwb3J0cyAoYXR0YWNrIHN1cmZhY2UpIG9wZW5pbmcgYnkgdGhlIHZhcmlvdXMgT0FN IHRvb2xzIFRXQU1QL1NUQU1QL0JGRC9TQkZEL3Bpbmcv4oCm4oCmDQoNClJlZ2FyZHMsDQpKaW5n cm9uZw0KDQpGcm9tOiB2Nm9wcyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBHeWFuIE1pc2hyYQ0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDI4LCAyMDIwIDY6 MTAgQU0NClRvOiBNYXJrIFNtaXRoIDxtYXJrenp6c21pdGhAZ21haWwuY29tPg0KQ2M6IEdyZWcg TWlyc2t5IDxncmVnaW1pcnNreUBnbWFpbC5jb20+OyBKZWZmIFRhbnRzdXJhIDxqZWZmdGFudC5p ZXRmQGdtYWlsLmNvbT47IHY2b3BzIGxpc3QgPHY2b3BzQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFt2Nm9wc10gZHJhZnQtc21pdGgtdjZvcHMtbGFyZ2VyLWlwdjYtbG9vcGJhY2stcHJlZml4LTA0 DQoNCkhpIE1hcmsNCg0KVGhhbmtzIGZvciBhIGxvdCBvZiB2ZXJ5IGdvb2QgcG9pbnRzIGFuZCBp ZGVhcyENCg0KDQpPbiBUdWUsIE9jdCAyNywgMjAyMCBhdCA1OjQyIFBNIE1hcmsgU21pdGggPG1h cmt6enpzbWl0aEBnbWFpbC5jb208bWFpbHRvOm1hcmt6enpzbWl0aEBnbWFpbC5jb20+PiB3cm90 ZToNCkhpIEd5YW4sDQpPbiBUdWUsIDI3IE9jdCAyMDIwLCAxNDozOCBHeWFuIE1pc2hyYSwgPGhh eWFidXNhZ3NtQGdtYWlsLmNvbTxtYWlsdG86aGF5YWJ1c2Fnc21AZ21haWwuY29tPj4gd3JvdGU6 DQoNCkhpIE1hcmsNCg0KVGhhbmtzIGZvciByZXNwb25kaW5nLg0KDQpUaGUgdXNlIGNhc2Ugd2Fz IGZvciBCRkQgY29udGludWl0eSB0ZXN0IGZvciBzcGVjaWFsIHVzZSBjYXNlcyBvciBNUExTIGxz cCBwaW5nIGFuZCBub3cgZHJhZnQgZm9yICB2eGxhbiBCRkQsIHdoZXJlIGZvciBJUHY0IGZvciBj b250aW51aXR5IHRlc3QgeW91IGhhdmUgMTI3LzggbG9vcGJhY2sgYnV0IGZvciBJUHY2IHRoZXJl IGlzIG9ubHkgb25lIGxvb3BiYWNrIGFkZHJlc3MgOjovMTI4Lg0KDQpGb3IgSVB2NiB3ZSBlbmRl ZCB1cCB1c2luZyBJUHY0IG1hcHBlZCBJUHY2IGFkZHJlc3NlcyBmb3IgTVBMUyBMU1AgcGluZyB1 c2VkIHRvIGJvb3RzdHJhcCB0byBGRUMgTFNQIHBpbmcgdG8gQkZELiAgU28gbm93IGZvciBuZXcg dnhsYW4gQkZEIHRoZSB0b3BpYyBjYW1lIHVwIGFuZCBhZ2FpbiBmb3IgYW5vdGhlciBkcmFmdCB3 aGljaCBub3cgYXMgYSBzdGFuZGFyZCB3ZSBhcmUgbm93IHBsYW5uaW5nIHRvIHVzZSBJUHY0IG1h cHBlZCBJUHY2IGZvciBCRkQgY29udGludWl0eSB0ZXN0Lg0KDQpJIHRoaW5rIGl0IHdvdWxkIGJl IGJldHRlciB0byBjb21lIHVwIHdpdGggYSBuYXRpdmUgSVB2NiBtZXRob2QgcmF0aGVyIHRoYW4g aW1wb3J0aW5nIElQdjQgYWRkcmVzc2VzIGludG8gSVB2NiBqdXN0IHRvIGdldCB0aGUgY2FwYWJp bGl0eSB5b3UgbmVlZC4NCg0KICAgIEd5YW4+IEkgd2FzIHRoaW5raW5nIHRoZSBzYW1lIGFib3V0 IHRoZSB2ZXJ5IHZlcnkgc29vbiBldmVudHVhbCBJUHY2IG9ubHkgY29yZSB0cmFuc3BvcnRzLiAg SSBoYXZlIGEgZHJhZnQgaW4gQkVTUyBXRyB0aGF0IEkgYW0gcHJlc2VudGluZyBhdCBJRVRGIDEw OSB0aGF0IGlzIGJhc2VkIG9uIFJGQyA2NTU1IHNvZnR3aXJlIG1lc2ggZnJhbWV3b3JrIGJhc2lj YWxseSA0IGVkZ2Ugb3ZlciBhIHY2IG9ubHkgY29yZSB3aGljaCB1c2luZyBSRkMgNTU0OSBuZXh0 IGhvcCBlbmNvZGluZyB3ZSBjYW4gZWxpbWluYXRlIGZvciBvcGVyYXRvcnMgYWxsIElQdjQgcGVl cmluZyBkb3duIHRoYXQgaXQgSVB2NCBBRkkgTkxSSSAgaXMgc3RhY2tlZCBvbiB0b3Agb2YgSVB2 NiBCR1AgcGVlci4gIFdpdGggdGhhdCBtb2RlbCBJUHY0IHdvdWxkIGJlIDEwMCUgZWxpbWluYXRl ZCBmcm9tIHRoZSBjb3JlIHRyYW5zcG9ydC4gIFRoZSBCRkQgY29udGludWl0eSB0ZXN0IGlzIG9u IHRoZSBjb3JlIHRyYW5zcG9ydCBzbyBJIGRlZmluaXRlbHkgY2FuIHNlZSB0aGUgZG93bnNpZGUg b2YgSVB2NCBtYXBwZWQgSVBWNiB3aGVuIElQVjQgaXMgZWxpbWluYXRlZCBmcm9tIHRoZSBjb3Jl LiAgSSBkb27igJl0IHRoaW5rIHdlIHdhbnQgYW55IElQdjYgYmVpbmcgdW5kZXJwaW5uZWQgYnkg SVB2NCB3aGljaCBpcyB3aGF0IGhhcHBlbnMgd2l0aCBkb2luZyB0aGUgSVB2NCBtYXBwZWQgSVB2 Ni4NCg0KVWx0aW1hdGVseSBJIHRoaW5rIGFuIElQdjYgb25seSBuZXR3b3JrIHNob3VsZCBoYXZl IG5vIElQdjQgaW4gaXQgYXQgYWxsLCBpbmNsdWRpbmcgbm8gSVB2NCBtYXBwZWQgYWRkcmVzc2Vz Lg0KDQpHeWFuPiBBZ3JlZWQNCg0KDQoNClRoYXQgQkZEIHRocmVhZCBicm91Z2h0IGJhY2sgdGhl IElQdjYgUkZDIDQyOTEgc3RhbmRhcmQgdGhhdCBJUHY2IG9ubHkgaGFzIG9uZSBsb29wYmFjayB3 aGVyZSBJUHY0IGhhcyBhIC84IHdvcnRoLg0KDQpBcyB5b3Ugc3RhdGVkIHBlciBSRkMgNDI5MSwg dGhlcmUgaXMgc3VwcG9zZWRseSBhIGxpbmsgbG9jYWwgLzY0IGZlODA6Oi82NCBsb29wYmFjayBv biB0aGUgbG9vcGJhY2sgaW50ZXJmYWNlIHdoaWNoIGhhcyBwbGVudHkgb2Ygc3BhY2UuICBJIGhh dmUgdG8gY2hlY2sgb24gYSByb3V0ZXIgYnV0IEkgYW0gZ3Vlc3NpbmcgSWYgdGhhdCBpcyBpbXBs ZW1lbnRlZCBieSBhbGwgcm91dGVyIHZlbmRvcnMgZm9sbG93aW5nIFJGQyA0MjkxLCB0aGVuIHRo YXQgd291bGQgYmUgYW4gYWx0ZXJuYXRpdmUgb3B0aW9uIHRvIElQdjQgbWFwcGVkIElQdjYgZm9y IEJGRCBjb250aW51aXR5IHRlc3RzLg0KDQpVc2luZyBsaW5rLWxvY2FscyB3b3VsZCBiZSB0aGUg YmV0dGVyIG9wdGlvbi4NCg0KICAgR3lhbj4gQWdyZWVkDQoNCklmIHlvdSBuZWVkIHRvIGVuY29k ZSBzcGVjaWFsIGZvcndhcmRpbmcgaGFuZGxpbmcsIG90aGVyIHRoYW4gc3RhbmRhcmQgdW5pY2Fz dCBmb3J3YXJkaW5nLCB0aGVuIEkgdGhpbmsgYSBzcGVjaWFsIHdlbGwga25vd24gcHJlZml4IGUu Zy4gYW4gSUFOQSBhc3NpZ25lZC82NCBvciAvNDggZm9yIHRoaXMgcHVycG9zZSB3b3VsZCBiZSB0 aGUgYmVzdCBvcHRpb24uDQoNClRoZXJlIGFyZSBhbHJlYWR5IGEgbnVtYmVyIG9mIElQdjYgZXhh bXBsZXMgd2hlcmUgc3BlY2lhbCBmb3J3YXJkaW5nIHJ1bGVzIGFyZSBkZWZpbmVkIGZvciBhIHdl bGwga25vd24gcHJlZml4IC0gbGluay1sb2NhbCBhZGRyZXNzIHNwYWNlLCB0aGUgZmYwMDo6Lzgg bXVsdGljYXN0IGFkZHJlc3Mgc3BhY2UsIGFuZCB0aGUgUkZDNjY2NiBkaXNjYXJkIHByZWZpeC4N Cg0KICAgIEd5YW4+IFRoYXQgaXMgZGVmaW5pdGVseSBhbiBpbnRlcmVzdGluZyBpZGVhIGFuZCBJ IHRoaW5rIG1ha2VzIHNlbnNlIGFuZCB2aWFibGUgZm9yIHN1cmUuICBUaGVyZSBtYXliZSBvdGhl ciB1c2UgY2FzZXMgSSBhbSB0aGlua2luZyBvdXQgbG91ZCBtYXliZSB3aXRoIEJJRVIgSVB2NiAg TVZQTiBhbmQgcG9zc2libGUgc29tZSBvdGhlciB1c2UgY2FzZXMuICBJIHdvbmRlciBldmVuIGZv ciB0aGUgU1J2NiBsb2NhdG9yIG1heWJlIGhhdmluZyBhIHNwZWNpYWwgcmFuZ2Ugb3V0c2lkZSBv ZiBHVUkgYWxsb2NhdGlvbiBhcyBpdCBoYXMgc3BlY2lhbCBoYW5kbGluZyB3aXRoIHN0ZWVyaW5n Lg0KDQpBbm90aGVyIHF1ZXN0aW9uIHJlbGF0ZWQgdG8gSVB2NiBBbnljYXN0LiAgSVB2NiBoYXMg YnVpbHQgaW4gYW55Y2FzdCBhZGRyZXNzLCBJIGJlbGlldmUgaXTigJlzIHRoZSBsYXN0IDcgYml0 cyBzdWJuZXQgcm91dGVyIEFueWNhc3QgYWRkcmVzcy4gIFNpbmNlIGFueSByb3V0YWJsZSBwcmVm aXggY2FuIGJlIEFueWNhc3RlZCBmb3Igc2VydmljZXMgcHJveGltaXR5IHJvdXRpbmcsICB3aGF0 IGlzIHRoZSByZWFsIHVzZSBjYXNlIG9yIGZ1bmN0aW9uYWxpdHkgb2YgdGhlIElQdjYgYnVpbHQg aW4gQW55Y2FzdCAvMTIxIHJhbmdlLg0KDQpSZWdhcmRzLA0KTWFyay4NCg0KDQpUaGFua3MNCg0K R3lhbg0KDQpPbiBNb24sIE9jdCAyNiwgMjAyMCBhdCA5OjIyIFBNIE1hcmsgU21pdGggPG1hcmt6 enpzbWl0aEBnbWFpbC5jb208bWFpbHRvOm1hcmt6enpzbWl0aEBnbWFpbC5jb20+PiB3cm90ZToN CkhpIEd5YW4sDQoNClNvcnJ5IG5vdCB0byBnZXQgYmFjayB0byB5b3Ugc29vbmVyLg0KDQpPbiBU dWUsIDIwIE9jdCAyMDIwIGF0IDAwOjI2LCBHeWFuIE1pc2hyYSA8aGF5YWJ1c2Fnc21AZ21haWwu Y29tPG1haWx0bzpoYXlhYnVzYWdzbUBnbWFpbC5jb20+PiB3cm90ZToNCj4NCj4NCj4gSGkgTWFy aw0KPg0KPiBXaGF0IGVuZGVkIHVwIGhhcHBlbmluZyB3aXRoIHRoaXMgZHJhZnQNCg0KSSBsZXQg aXQgZXhwaXJlLCBhcyBJIGRpZG4ndCB0aGluayBpdCB3b3VsZCBiZSBhZG9wdGVkIGJ5IHRoZSBX Ry4NCg0KVGhlcmUgc2VlbWVkIHRvIGJlIGEgYml0IG9mIHJlc2lzdGFuY2UgdG8gaXQgYXMgcGVv cGxlIHNhaWQgdGhhdCBVTEFzDQpjb3VsZCBiZSB1c2VkIGluc3RlYWQuDQoNClRoZSBsaW5rIGxv Y2FsIHByZWZpeCBpcyBhbHNvIHJlcXVpcmVkIG9uIGFueSBJUHY2IGludGVyZmFjZSwgcGVyDQpS RkM0MjkxLCBzbyB0aGVyZSBpcyBzdXBwb3NlZCB0byBiZSBhIGxpbmstbG9jYWwgLzY0IG9uIHRo ZSBsb29wYmFjaw0KaW50ZXJmYWNlKHMpIHByb3ZpZGluZyBtYW55IGFkZHJlc3NlcyB0byB3aGlj aCBhIHByb2Nlc3MgY291bGQgYmUNCnNlcGFyYXRlbHkgYm91bmQsIGFsdGhvdWdoIGEgZHJhd2Jh Y2sgb2YgdXNpbmcgdGhlIGxpbmstbG9jYWwgcHJlZml4DQppcyBoYXZpbmcgdG8gZGVhbCB3aXRo IHNjb3BlL3pvbmUgSURzIChhbHRob3VnaCBMaW51eCBkb2Vzbid0IGNvbXBseQ0Kd2l0aCB0aGF0 IHJlcXVpcmVtZW50LCBpdCBkb2Vzbid0IGhhdmUgYSBsaW5rLWxvY2FsIGFkZHJlc3Mgb24gdGhl DQpsb29wYmFjayBpbnRlcmZhY2UgYnkgZGVmYXVsdCkuDQoNCj4gYW5kIHdhcyB0aGUgd29yayBw aWNrZWQgdXAgaW4gYW55IG90aGVyIGRyYWZ0Lg0KDQpOb3QgYXMgZmFyIGFzIEknbSBhd2FyZS4N Cg0KV2hhdCBpcyB5b3VyIHVzZSBjYXNlPw0KDQpSZWdhcmRzLA0KTWFyay4NCg0KDQo+DQo+IFRo YW5rcw0KPg0KPiBHeWFuDQo+DQo+IFNlbnQgZnJvbSBteSBpUGhvbmUNCi0tDQoNClvlm77lg4/l t7Looqvlj5Hku7bkurrliKDpmaTjgIJdPGh0dHA6Ly93d3cudmVyaXpvbi5jb20vPg0KDQpHeWFu IE1pc2hyYQ0KDQpOZXR3b3JrIFNvbHV0aW9ucyBBcmNoaXRlY3QNCg0KTSAzMDEgNTAyLTEzNDcN CjEzMTAxIENvbHVtYmlhIFBpa2UgPGh0dHBzOi8vd3d3Lmdvb2dsZS5jb20vbWFwcy9zZWFyY2gv MTMxMDErQ29sdW1iaWErUGlrZSVDMiVBMCtTaWx2ZXIrU3ByaW5nLCtNRD9lbnRyeT1nbWFpbCZz b3VyY2U9Zz4NClNpbHZlciBTcHJpbmcsIE1EPGh0dHBzOi8vd3d3Lmdvb2dsZS5jb20vbWFwcy9z ZWFyY2gvMTMxMDErQ29sdW1iaWErUGlrZSVDMiVBMCtTaWx2ZXIrU3ByaW5nLCtNRD9lbnRyeT1n bWFpbCZzb3VyY2U9Zz4NCg0KLS0NCg0KW+WbvuWDj+W3suiiq+WPkeS7tuS6uuWIoOmZpOOAgl08 aHR0cDovL3d3dy52ZXJpem9uLmNvbS8+DQoNCkd5YW4gTWlzaHJhDQoNCk5ldHdvcmsgU29sdXRp b25zIEFyY2hpdGVjdA0KDQpNIDMwMSA1MDItMTM0Nw0KMTMxMDEgQ29sdW1iaWEgUGlrZQ0KU2ls dmVyIFNwcmluZywgTUQNCg0K --_000_209001a434c84ceb8669b5f0e7e7b063huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpHZW9yZ2lhOw0KCXBhbm9zZS0xOjIgNCA1IDIgNSA0IDUgMiAzIDM7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5 cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dl ZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseTrlrovkvZM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFG NDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+QWdyZWVkIHZlcnkgbXVjaCB0aGF0IGxhcmdlci1pcHY2LWxvb3BiYWNrLXByZWZpeCBp cyB1c2VmdWwgZm9yIElQdjYtb25seSBuZXR3b3JrLiBUaGFua3MgZm9yIGRpZ2dpbmcgb3V0IHRo aXMg4oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BcyB0aGUgZHJhZnQgYWxyZWFk eSBzdGF0ZWQgYXQgdGhlIHZlcnkgYmVnaW5uaW5nLCAmbmJzcDvigJx0byBydW4gbXVsdGlwbGUg aW5zdGFuY2VzIG9mIHRoZSBhcHBsaWNhdGlvbiB1c2luZyB0aGUgc2FtZSB0cmFuc3BvcnQgbGF5 ZXIgcHJvdG9jb2wgcG9ydCBvbg0KIHRoZSBzYW1lIGRldmVsb3BtZW50IGhvc3Qu4oCdPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BbHNvIHVzZWZ1bCB0byBlbGltaW5hdGUgdGhlIG5l ZWQgb2YgdG9vIG1hbnkgVURQIHBvcnRzIChhdHRhY2sgc3VyZmFjZSkgb3BlbmluZyBieSB0aGUg dmFyaW91cyBPQU0gdG9vbHMgVFdBTVAvU1RBTVAvQkZEL1NCRkQvcGluZy/igKbigKYNCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SmluZ3Jvbmc8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gdjZvcHMgW21h aWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5HeWFuIE1p c2hyYTxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE9jdG9iZXIgMjgsIDIwMjAgNjoxMCBB TTxicj4NCjxiPlRvOjwvYj4gTWFyayBTbWl0aCAmbHQ7bWFya3p6enNtaXRoQGdtYWlsLmNvbSZn dDs8YnI+DQo8Yj5DYzo8L2I+IEdyZWcgTWlyc2t5ICZsdDtncmVnaW1pcnNreUBnbWFpbC5jb20m Z3Q7OyBKZWZmIFRhbnRzdXJhICZsdDtqZWZmdGFudC5pZXRmQGdtYWlsLmNvbSZndDs7IHY2b3Bz IGxpc3QgJmx0O3Y2b3BzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Y2 b3BzXSBkcmFmdC1zbWl0aC12Nm9wcy1sYXJnZXItaXB2Ni1sb29wYmFjay1wcmVmaXgtMDQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBNYXJrJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFua3MgZm9yIGEgbG90IG9mIHZlcnkgZ29v ZCBwb2ludHMgYW5kIGlkZWFzITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gVHVlLCBPY3QgMjcsIDIw MjAgYXQgNTo0MiBQTSBNYXJrIFNtaXRoICZsdDs8YSBocmVmPSJtYWlsdG86bWFya3p6enNtaXRo QGdtYWlsLmNvbSI+bWFya3p6enNtaXRoQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+SGkgR3lhbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBUdWUsIDI3IE9jdCAyMDIwLCAx NDozOCBHeWFuIE1pc2hyYSwgJmx0OzxhIGhyZWY9Im1haWx0bzpoYXlhYnVzYWdzbUBnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj5oYXlhYnVzYWdzbUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5IaSBNYXJrPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5UaGFua3MgZm9yIHJlc3BvbmRpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgdXNlIGNhc2Ugd2FzIGZvciBCRkQgY29udGludWl0eSB0 ZXN0IGZvciBzcGVjaWFsIHVzZSBjYXNlcyBvciBNUExTIGxzcCBwaW5nIGFuZCBub3cgZHJhZnQg Zm9yICZuYnNwO3Z4bGFuIEJGRCwgd2hlcmUgZm9yIElQdjQgZm9yIGNvbnRpbnVpdHkgdGVzdCB5 b3UgaGF2ZSAxMjcvOCBsb29wYmFjayBidXQgZm9yIElQdjYgdGhlcmUgaXMgb25seSBvbmUgbG9v cGJhY2sgYWRkcmVzcw0KIDo6LzEyOC4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gb3IgSVB2NiB3ZSBlbmRlZCB1cCB1c2luZyBJUHY0IG1h cHBlZCBJUHY2IGFkZHJlc3NlcyBmb3IgTVBMUyBMU1AgcGluZyB1c2VkIHRvIGJvb3RzdHJhcCB0 byBGRUMgTFNQIHBpbmcgdG8gQkZELiZuYnNwOyBTbyBub3cgZm9yIG5ldyB2eGxhbiBCRkQgdGhl IHRvcGljIGNhbWUgdXAgYW5kIGFnYWluIGZvciBhbm90aGVyIGRyYWZ0IHdoaWNoIG5vdyBhcyBh IHN0YW5kYXJkIHdlIGFyZQ0KIG5vdyBwbGFubmluZyB0byB1c2UgSVB2NCBtYXBwZWQgSVB2NiBm b3IgQkZEIGNvbnRpbnVpdHkgdGVzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIHRoaW5rIGl0 IHdvdWxkIGJlIGJldHRlciB0byBjb21lIHVwIHdpdGggYSBuYXRpdmUgSVB2NiBtZXRob2QgcmF0 aGVyIHRoYW4gaW1wb3J0aW5nIElQdjQgYWRkcmVzc2VzIGludG8gSVB2NiBqdXN0IHRvIGdldCB0 aGUgY2FwYWJpbGl0eSB5b3UgbmVlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwOyBHeWFu Jmd0OyBJIHdhcyB0aGlua2luZyB0aGUgc2FtZSBhYm91dCB0aGUgdmVyeSB2ZXJ5IHNvb24gZXZl bnR1YWwgSVB2NiBvbmx5IGNvcmUgdHJhbnNwb3J0cy4mbmJzcDsgSSBoYXZlIGEgZHJhZnQgaW4g QkVTUyBXRyB0aGF0IEkgYW0gcHJlc2VudGluZyBhdCBJRVRGIDEwOSB0aGF0IGlzIGJhc2VkIG9u IFJGQyA2NTU1IHNvZnR3aXJlIG1lc2ggZnJhbWV3b3JrIGJhc2ljYWxseSA0DQogZWRnZSBvdmVy IGEgdjYgb25seSBjb3JlIHdoaWNoIHVzaW5nIFJGQyA1NTQ5IG5leHQgaG9wIGVuY29kaW5nIHdl IGNhbiBlbGltaW5hdGUgZm9yIG9wZXJhdG9ycyBhbGwgSVB2NCBwZWVyaW5nIGRvd24gdGhhdCBp dCBJUHY0IEFGSSBOTFJJICZuYnNwO2lzIHN0YWNrZWQgb24gdG9wIG9mIElQdjYgQkdQIHBlZXIu Jm5ic3A7IFdpdGggdGhhdCBtb2RlbCBJUHY0IHdvdWxkIGJlIDEwMCUgZWxpbWluYXRlZCBmcm9t IHRoZSBjb3JlIHRyYW5zcG9ydC4mbmJzcDsgVGhlIEJGRA0KIGNvbnRpbnVpdHkgdGVzdCBpcyBv biB0aGUgY29yZSB0cmFuc3BvcnQgc28gSSBkZWZpbml0ZWx5IGNhbiBzZWUgdGhlIGRvd25zaWRl IG9mIElQdjQgbWFwcGVkIElQVjYgd2hlbiBJUFY0IGlzIGVsaW1pbmF0ZWQgZnJvbSB0aGUgY29y ZS4mbmJzcDsgSSBkb27igJl0IHRoaW5rIHdlIHdhbnQgYW55IElQdjYgYmVpbmcgdW5kZXJwaW5u ZWQgYnkgSVB2NCB3aGljaCBpcyB3aGF0IGhhcHBlbnMgd2l0aCBkb2luZyB0aGUgSVB2NCBtYXBw ZWQgSVB2Ni48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+VWx0aW1hdGVseSBJIHRoaW5rIGFuIElQdjYgb25seSBuZXR3 b3JrIHNob3VsZCBoYXZlIG5vIElQdjQgaW4gaXQgYXQgYWxsLCBpbmNsdWRpbmcgbm8gSVB2NCBt YXBwZWQgYWRkcmVzc2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5HeWFuJmd0OyBBZ3JlZWQmbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGF0IEJGRCB0aHJlYWQg YnJvdWdodCBiYWNrIHRoZSBJUHY2IFJGQyA0MjkxIHN0YW5kYXJkIHRoYXQgSVB2NiBvbmx5IGhh cyBvbmUgbG9vcGJhY2sgd2hlcmUgSVB2NCBoYXMgYSAvOCB3b3J0aC4gJm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BcyB5b3Ugc3RhdGVkIHBl ciBSRkMgNDI5MSwgdGhlcmUgaXMgc3VwcG9zZWRseSBhIGxpbmsgbG9jYWwgLzY0IGZlODA6Oi82 NCBsb29wYmFjayBvbiB0aGUgbG9vcGJhY2sgaW50ZXJmYWNlIHdoaWNoIGhhcyBwbGVudHkgb2Yg c3BhY2UuJm5ic3A7IEkgaGF2ZSB0byBjaGVjayBvbiBhIHJvdXRlciBidXQgSSBhbSBndWVzc2lu ZyBJZiB0aGF0IGlzIGltcGxlbWVudGVkIGJ5IGFsbCByb3V0ZXINCiB2ZW5kb3JzIGZvbGxvd2lu ZyBSRkMgNDI5MSwgdGhlbiB0aGF0IHdvdWxkIGJlIGFuIGFsdGVybmF0aXZlIG9wdGlvbiB0byBJ UHY0IG1hcHBlZCBJUHY2IGZvciBCRkQgY29udGludWl0eSB0ZXN0cy4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5Vc2luZyBsaW5rLWxvY2FscyB3b3VsZCBiZSB0aGUgYmV0dGVyIG9wdGlv bi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwO0d5YW4mZ3Q7IEFncmVlZCZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5JZiB5b3UgbmVlZCB0byBlbmNvZGUgc3BlY2lhbCBmb3J3YXJkaW5nIGhhbmRsaW5n LCBvdGhlciB0aGFuIHN0YW5kYXJkIHVuaWNhc3QgZm9yd2FyZGluZywgdGhlbiBJIHRoaW5rIGEg c3BlY2lhbCB3ZWxsIGtub3duIHByZWZpeCBlLmcuIGFuIElBTkEgYXNzaWduZWQvNjQgb3IgLzQ4 IGZvciB0aGlzIHB1cnBvc2Ugd291bGQgYmUgdGhlIGJlc3Qgb3B0aW9uLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZXJlIGFyZSBhbHJlYWR5IGEgbnVtYmVyIG9mIElQdjYg ZXhhbXBsZXMgd2hlcmUgc3BlY2lhbCBmb3J3YXJkaW5nIHJ1bGVzIGFyZSBkZWZpbmVkIGZvciBh IHdlbGwga25vd24gcHJlZml4IC0gbGluay1sb2NhbCBhZGRyZXNzIHNwYWNlLCB0aGUgZmYwMDo6 LzggbXVsdGljYXN0IGFkZHJlc3Mgc3BhY2UsIGFuZCB0aGUgUkZDNjY2NiBkaXNjYXJkIHByZWZp eC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7ICZuYnNwOyBHeWFuJmd0OyBUaGF0IGlzIGRlZmluaXRl bHkgYW4gaW50ZXJlc3RpbmcgaWRlYSBhbmQgSSB0aGluayBtYWtlcyBzZW5zZSBhbmQgdmlhYmxl IGZvciBzdXJlLiZuYnNwOyBUaGVyZSBtYXliZSBvdGhlciB1c2UgY2FzZXMgSSBhbSB0aGlua2lu ZyBvdXQgbG91ZCBtYXliZSB3aXRoIEJJRVIgSVB2NiAmbmJzcDtNVlBOIGFuZCBwb3NzaWJsZSBz b21lIG90aGVyIHVzZSBjYXNlcy4mbmJzcDsgSSB3b25kZXINCiBldmVuIGZvciB0aGUgU1J2NiBs b2NhdG9yIG1heWJlIGhhdmluZyBhIHNwZWNpYWwgcmFuZ2Ugb3V0c2lkZSBvZiBHVUkgYWxsb2Nh dGlvbiBhcyBpdCBoYXMgc3BlY2lhbCBoYW5kbGluZyB3aXRoIHN0ZWVyaW5nLiAmbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFub3RoZXIgcXVl c3Rpb24gcmVsYXRlZCB0byBJUHY2IEFueWNhc3QuJm5ic3A7IElQdjYgaGFzIGJ1aWx0IGluIGFu eWNhc3QgYWRkcmVzcywgSSBiZWxpZXZlIGl04oCZcyB0aGUgbGFzdCA3IGJpdHMgc3VibmV0IHJv dXRlciBBbnljYXN0IGFkZHJlc3MuJm5ic3A7IFNpbmNlIGFueSByb3V0YWJsZSBwcmVmaXggY2Fu IGJlIEFueWNhc3RlZCBmb3Igc2VydmljZXMgcHJveGltaXR5IHJvdXRpbmcsICZuYnNwO3doYXQN CiBpcyB0aGUgcmVhbCB1c2UgY2FzZSBvciBmdW5jdGlvbmFsaXR5IG9mIHRoZSBJUHY2IGJ1aWx0 IGluIEFueWNhc3QgLzEyMSByYW5nZS4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHMsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPk1hcmsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowY20iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzJm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5HeWFuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIE1vbiwgT2N0IDI2LCAyMDIwIGF0IDk6MjIg UE0gTWFyayBTbWl0aCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcmt6enpzbWl0aEBnbWFpbC5jb20i IHRhcmdldD0iX2JsYW5rIj5tYXJrenp6c21pdGhAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIEd5YW4sPGJyPg0KPGJyPg0KU29ycnkgbm90IHRv IGdldCBiYWNrIHRvIHlvdSBzb29uZXIuPGJyPg0KPGJyPg0KT24gVHVlLCAyMCBPY3QgMjAyMCBh dCAwMDoyNiwgR3lhbiBNaXNocmEgJmx0OzxhIGhyZWY9Im1haWx0bzpoYXlhYnVzYWdzbUBnbWFp bC5jb20iIHRhcmdldD0iX2JsYW5rIj5oYXlhYnVzYWdzbUBnbWFpbC5jb208L2E+Jmd0OyB3cm90 ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgSGkgTWFyazxicj4NCiZndDs8YnI+DQom Z3Q7IFdoYXQgZW5kZWQgdXAgaGFwcGVuaW5nIHdpdGggdGhpcyBkcmFmdDxicj4NCjxicj4NCkkg bGV0IGl0IGV4cGlyZSwgYXMgSSBkaWRuJ3QgdGhpbmsgaXQgd291bGQgYmUgYWRvcHRlZCBieSB0 aGUgV0cuPGJyPg0KPGJyPg0KVGhlcmUgc2VlbWVkIHRvIGJlIGEgYml0IG9mIHJlc2lzdGFuY2Ug dG8gaXQgYXMgcGVvcGxlIHNhaWQgdGhhdCBVTEFzPGJyPg0KY291bGQgYmUgdXNlZCBpbnN0ZWFk Ljxicj4NCjxicj4NClRoZSBsaW5rIGxvY2FsIHByZWZpeCBpcyBhbHNvIHJlcXVpcmVkIG9uIGFu eSBJUHY2IGludGVyZmFjZSwgcGVyPGJyPg0KUkZDNDI5MSwgc28gdGhlcmUgaXMgc3VwcG9zZWQg dG8gYmUgYSBsaW5rLWxvY2FsIC82NCBvbiB0aGUgbG9vcGJhY2s8YnI+DQppbnRlcmZhY2Uocykg cHJvdmlkaW5nIG1hbnkgYWRkcmVzc2VzIHRvIHdoaWNoIGEgcHJvY2VzcyBjb3VsZCBiZTxicj4N CnNlcGFyYXRlbHkgYm91bmQsIGFsdGhvdWdoIGEgZHJhd2JhY2sgb2YgdXNpbmcgdGhlIGxpbmst bG9jYWwgcHJlZml4PGJyPg0KaXMgaGF2aW5nIHRvIGRlYWwgd2l0aCBzY29wZS96b25lIElEcyAo YWx0aG91Z2ggTGludXggZG9lc24ndCBjb21wbHk8YnI+DQp3aXRoIHRoYXQgcmVxdWlyZW1lbnQs IGl0IGRvZXNuJ3QgaGF2ZSBhIGxpbmstbG9jYWwgYWRkcmVzcyBvbiB0aGU8YnI+DQpsb29wYmFj ayBpbnRlcmZhY2UgYnkgZGVmYXVsdCkuPGJyPg0KPGJyPg0KJmd0OyBhbmQgd2FzIHRoZSB3b3Jr IHBpY2tlZCB1cCBpbiBhbnkgb3RoZXIgZHJhZnQuPGJyPg0KPGJyPg0KTm90IGFzIGZhciBhcyBJ J20gYXdhcmUuPGJyPg0KPGJyPg0KV2hhdCBpcyB5b3VyIHVzZSBjYXNlPzxicj4NCjxicj4NClJl Z2FyZHMsPGJyPg0KTWFyay48YnI+DQo8YnI+DQo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGFua3M8 YnI+DQomZ3Q7PGJyPg0KJmd0OyBHeWFuPGJyPg0KJmd0Ozxicj4NCiZndDsgU2VudCBmcm9tIG15 IGlQaG9uZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LS0gPG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjoj MjIyMjIyIj48YSBocmVmPSJodHRwOi8vd3d3LnZlcml6b24uY29tLyIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjojMTE1NUNDO2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0 O3BhZGRpbmc6MGNtO3RleHQtZGVjb3JhdGlvbjpub25lIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9 IjgxIiBoZWlnaHQ9IjE4IiBpZD0iX3gwMDAwX2kxMDI1IiBzcmM9ImNpZDppbWFnZTAwMS5qcGdA MDFENkFEMUYuOTdCMTAzMDAiIGFsdD0i5Zu+5YOP5bey6KKr5Y+R5Lu25Lq65Yig6Zmk44CCIj48 L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21h cmdpbi1ib3R0b206LjAwMDFwdDttc28tbGluZS1oZWlnaHQtYWx0OjkuNzVwdCI+PGI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj5HeWFuIE1pc2hyYTwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4t Ym90dG9tOi4wMDAxcHQ7bXNvLWxpbmUtaGVpZ2h0LWFsdDo5Ljc1cHQiPjxpPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90OyxzZXJpZjtjb2xv cjpibGFjayI+TmV0d29yayBTb2x1dGlvbnMgQXJjaGl0ZWN0Jm5ic3A7PC9zcGFuPjwvaT48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMyMjIyMjIiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDttc28tbGluZS1o ZWlnaHQtYWx0OjkuNzVwdCI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtHZW9yZ2lhJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj5NIDMwMSA1MDItMTM0Nzxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmdvb2dsZS5jb20vbWFwcy9zZWFyY2gvMTMxMDEmIzQz O0NvbHVtYmlhJiM0MztQaWtlJUMyJUEwJiM0MztTaWx2ZXImIzQzO1NwcmluZywmIzQzO01EP2Vu dHJ5PWdtYWlsJmFtcDtzb3VyY2U9ZyI+MTMxMDEgQ29sdW1iaWEgUGlrZSZuYnNwOzwvYT48YnI+ DQo8L3NwYW4+PC9pPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhy ZWY9Imh0dHBzOi8vd3d3Lmdvb2dsZS5jb20vbWFwcy9zZWFyY2gvMTMxMDEmIzQzO0NvbHVtYmlh JiM0MztQaWtlJUMyJUEwJiM0MztTaWx2ZXImIzQzO1NwcmluZywmIzQzO01EP2VudHJ5PWdtYWls JmFtcDtzb3VyY2U9ZyI+U2lsdmVyIFNwcmluZywgTUQ8L2E+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LS0gPG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMjIy MjIyIj48YSBocmVmPSJodHRwOi8vd3d3LnZlcml6b24uY29tLyIgdGFyZ2V0PSJfYmxhbmsiPjxz cGFuIHN0eWxlPSJjb2xvcjojMTE1NUNDO2JvcmRlcjpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3Bh ZGRpbmc6MGNtO3RleHQtZGVjb3JhdGlvbjpub25lIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9Ijgx IiBoZWlnaHQ9IjE4IiBpZD0iX3gwMDAwX2kxMDI2IiBzcmM9ImNpZDppbWFnZTAwMS5qcGdAMDFE NkFEMUYuOTdCMTAzMDAiIGFsdD0i5Zu+5YOP5bey6KKr5Y+R5Lu25Lq65Yig6Zmk44CCIj48L3Nw YW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdp bi1ib3R0b206LjAwMDFwdDttc28tbGluZS1oZWlnaHQtYWx0OjkuNzVwdCI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5HeWFuIE1pc2hyYTwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90 dG9tOi4wMDAxcHQ7bXNvLWxpbmUtaGVpZ2h0LWFsdDo5Ljc1cHQiPjxpPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90OyxzZXJpZjtjb2xvcjpi bGFjayI+TmV0d29yayBTb2x1dGlvbnMgQXJjaGl0ZWN0Jm5ic3A7PC9zcGFuPjwvaT48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMyMjIyMjIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDttc28tbGluZS1oZWln aHQtYWx0OjkuNzVwdCI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtHZW9yZ2lhJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj5NIDMwMSA1MDItMTM0Nzxicj4N CjEzMTAxIENvbHVtYmlhIFBpa2UmbmJzcDs8YnI+DQo8L3NwYW4+PC9pPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPlNpbHZlciBTcHJpbmcsIE1EPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_209001a434c84ceb8669b5f0e7e7b063huaweicom_-- --_004_209001a434c84ceb8669b5f0e7e7b063huaweicom_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=356; creation-date="Wed, 28 Oct 2020 03:49:52 GMT"; modification-date="Wed, 28 Oct 2020 03:49:52 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/wAALCAASAFEBAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZqKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK/9k= --_004_209001a434c84ceb8669b5f0e7e7b063huaweicom_-- From nobody Thu Oct 29 01:43:12 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 88F453A0B60 for ; Thu, 29 Oct 2020 01:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.587 X-Spam-Level: X-Spam-Status: No, score=-0.587 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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=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 mfK5fK6vY-ii for ; Thu, 29 Oct 2020 01:43:08 -0700 (PDT) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 D1D7C3A0B5F for ; Thu, 29 Oct 2020 01:43:08 -0700 (PDT) Received: by mail-ot1-x32c.google.com with SMTP id 32so1621378otm.3 for ; Thu, 29 Oct 2020 01:43:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IsK7qf3Ty1JbTgVpUeY9Olo9KMALON6USNANLllE3Dk=; b=h+9/IMbqD3buf0t+rVLne4flIdUl/CKtCneRsEDE20ptK0Rl6mJ5WaRTQru9PFnKNH YMpH3hHOjwrknLvtLfJNOnh8U9Dh0rFeSnPZn2tgqbRjP4qxkWCO1T/V5/fUNNyvst1e 1deIuhTOU/3FKeN9Dqzd7AeHYIqIWbJnWncazx8tbnI4SgkM7DMqFFgSanizFsFArGbc ACQCkP42/HjMT6gyJNLtxThb7e2ROP+rvOCjhIqzMCbMmWNh0eJOw5dasck3JS5IZ+os AmcdPRMawz2a02ZaAzjd/x4BD8WaBCOG0w5mGqw6QxS8LSCazoFISIwcZc1G3l+4hS0f bTlQ== 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=IsK7qf3Ty1JbTgVpUeY9Olo9KMALON6USNANLllE3Dk=; b=WBfrSfcWW7FmxXd0GHS9QQqxodScsWspLpVzJ/kaO3YjO2EDoUevq9wuqCAGTEokCi 7pPOGNsD2AZA/4qTLJSXKSz3isAQTj5cCmNoZafUBi2Qawq0nPA/yQ0/0oowLrt8mxeE MVnalgp11uSpDx7b9nt0p/P7fY49/eVubtlu2xouj3/iua6rp35GWn6S/RtcFs2enlsG QkUDehpROcgZpBYDHbiYQuSbjHCiPz8Q5n452+LbCuztD4oCl/E6DdWD2V5zjnUXmjMu 196V+bENpUfaq17sbLB/p+bmwFV+6Vh4X6vzetq++3PR0CEQUcmGEySM4EChdmjw+dS5 oTqQ== X-Gm-Message-State: AOAM5308r1jq5dN1aKnQiTVtXYUKKF4qojb8Hs5vjUUiL6dUzInvDnZw gJ/+FVPHsDlvrdJzd6tQV+nFdaF8MoF1KK65aY4= X-Google-Smtp-Source: ABdhPJwulCRV+NyGiywwwbWTgRvzGV9sslPC5C3a2oXsqGV4SX5o5rjNzGqvqW1TBcSEUT1oiu5nlQTDI3ghjgqUWFs= X-Received: by 2002:a9d:44:: with SMTP id 62mr2491494ota.153.1603960988136; Thu, 29 Oct 2020 01:43:08 -0700 (PDT) MIME-Version: 1.0 References: <19EE82F7-8D52-4519-8087-0DF17435A3B8@gmail.com> In-Reply-To: From: Mark Smith Date: Thu, 29 Oct 2020 19:42:41 +1100 Message-ID: To: Gyan Mishra Cc: Greg Mirsky , Jeff Tantsura , v6ops list Content-Type: multipart/alternative; boundary="000000000000ee7bcc05b2cb44e3" Archived-At: Subject: Re: [v6ops] draft-smith-v6ops-larger-ipv6-loopback-prefix-04 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, 29 Oct 2020 08:43:11 -0000 --000000000000ee7bcc05b2cb44e3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Gyan, On Wed, 28 Oct 2020, 09:10 Gyan Mishra, wrote: > Hi Mark > > > > Gyan> That is definitely an interesting idea and I think makes sense > and viable for sure. There maybe other use cases I am thinking out loud > maybe with BIER IPv6 MVPN and possible some other use cases. I wonder > even for the SRv6 locator maybe having a special range outside of GUI > allocation as it has special handling with steering. > > Another question related to IPv6 Anycast. IPv6 has built in anycast > address, I believe it=E2=80=99s the last 7 bits subnet router Anycast add= ress. > Since any routable prefix can be Anycasted for services proximity routing= , > what is the real use case or functionality of the IPv6 built in Anycast > /121 range. > There isn't really an IPv6 anycast range, IPv6 anycast addresses come out of the unicast address space, and are only designated as anycast either by announcing a "unicast" route from multiple different locations on purpose (if it's not on purpose, it's a fault), and by configuring the host with the anycast address to know that it is an anycast address. I've thought that the use of Anycast would increase, and have thought that it would be useful to have a specially designated anycast prefix. It has also occurred to me that anycast has some of the properties of unicast as well as some of the properties of multicast, so could be seen to fit in between unicast and multicast (1:1 -> 1:Any -> 1:Many) "IPv6 Formal Anycast and Functional Anycast Addresses" IETF 106 presentation - https://www.ietf.org/proceedings/106/slides/slides-106-6man-sessa-ipv6-form= al-anycast-addresses-and-functional-anycast-addresses-00.pdf Draft - https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-01 Regards, Mark. > >> Regards, >> Mark. >> >> >>> Thanks >>> >>> Gyan >>> >>> On Mon, Oct 26, 2020 at 9:22 PM Mark Smith >>> wrote: >>> >>>> Hi Gyan, >>>> >>>> Sorry not to get back to you sooner. >>>> >>>> On Tue, 20 Oct 2020 at 00:26, Gyan Mishra >>>> wrote: >>>> > >>>> > >>>> > Hi Mark >>>> > >>>> > What ended up happening with this draft >>>> >>>> I let it expire, as I didn't think it would be adopted by the WG. >>>> >>>> There seemed to be a bit of resistance to it as people said that ULAs >>>> could be used instead. >>>> >>>> The link local prefix is also required on any IPv6 interface, per >>>> RFC4291, so there is supposed to be a link-local /64 on the loopback >>>> interface(s) providing many addresses to which a process could be >>>> separately bound, although a drawback of using the link-local prefix >>>> is having to deal with scope/zone IDs (although Linux doesn't comply >>>> with that requirement, it doesn't have a link-local address on the >>>> loopback interface by default). >>>> >>>> > and was the work picked up in any other draft. >>>> >>>> Not as far as I'm aware. >>>> >>>> What is your use case? >>>> >>>> Regards, >>>> Mark. >>>> >>>> >>>> > >>>> > Thanks >>>> > >>>> > Gyan >>>> > >>>> > Sent from my iPhone >>>> >>> -- >>> >>> >>> >>> *Gyan Mishra* >>> >>> *Network Solutions A**rchitect * >>> >>> >>> >>> *M 301 502-134713101 Columbia Pike >>> *Silver >>> Spring, MD >>> >>> >>> -- > > > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > > > *M 301 502-134713101 Columbia Pike *Silver Spring, MD > > --000000000000ee7bcc05b2cb44e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --


Gyan M= ishra

<= font face=3D"georgia, serif" style=3D"color:black;font-size:1em">Network= Solutions Ar= chitect=C2=A0

M 301 502-1347
1310= 1 Columbia Pike=C2=A0
Silver Spring, MD


Hi Gyan,

On Wed, 28 Oct 2020,= 09:10 Gyan Mishra, <hayabusagsm@gmail.com> wrote:
Hi Mark=C2=A0

<snip>
=

=C2=A0 =C2=A0 Gyan> That i= s definitely an interesting idea and I think makes sense and viable for sur= e.=C2=A0 There maybe other use cases I am thinking out loud maybe with BIER= IPv6 =C2=A0MVPN and possible some other use cases.=C2=A0 I wonder even for= the SRv6 locator maybe having a special range outside of GUI allocation as= it has special handling with steering. =C2=A0

<= /div>
Another question related to IPv6 Anycast.=C2=A0 IPv6= has built in anycast address, I believe it=E2=80=99s the last 7 bits subne= t router Anycast address.=C2=A0 Since any routable prefix can be Anycasted = for services proximity routing, =C2=A0what is the real use case or function= ality of the IPv6 built in Anycast /121 range. =C2=A0


There isn't really an IPv6 = anycast range, IPv6 anycast addresses come out of the unicast address space= , and are only designated as anycast either by announcing a "unicast&q= uot; route from multiple different locations on purpose (if it's not on= purpose, it's a fault), and by configuring the host with the anycast a= ddress to know that it is an anycast address.

I've thought that the use of Anycast would increase, and have th= ought that it would be useful to have a specially designated anycast prefix= . It has also occurred to me that anycast has some of the properties of uni= cast as well as some of the properties of multicast, so could be seen to fi= t in between unicast and multicast (1:1 -> 1:Any -> 1:Many)

"IPv6 Formal Anycast and Functional Anycast Addresses&= quot;
=C2=A0
Regards,
Mark.
=


Thanks=C2=A0
<= br>
Gyan

On Mon, Oct 26, 2020 at 9:22 PM Mark Sm= ith <markzzzsmith@gmail.com>= wrote:
Hi Gyan,=

Sorry not to get back to you sooner.

On Tue, 20 Oct 2020 at 00:26, Gyan Mishra <hayabusagsm@gmail.com> wrote:
>
>
> Hi Mark
>
> What ended up happening with this draft

I let it expire, as I didn't think it would be adopted by the WG.

There seemed to be a bit of resistance to it as people said that ULAs
could be used instead.

The link local prefix is also required on any IPv6 interface, per
RFC4291, so there is supposed to be a link-local /64 on the loopback
interface(s) providing many addresses to which a process could be
separately bound, although a drawback of using the link-local prefix
is having to deal with scope/zone IDs (although Linux doesn't comply with that requirement, it doesn't have a link-local address on the
loopback interface by default).

> and was the work picked up in any other draft.

Not as far as I'm aware.

What is your use case?

Regards,
Mark.


>
> Thanks
>
> Gyan
>
> Sent from my iPhone
--


Gyan Mishra

Network Solutions Architect=C2=A0

M 301 502-1347
13101 Columbia Pike=C2=A0
<= /i>Silver Spring, MD


--000000000000ee7bcc05b2cb44e3-- From nobody Thu Oct 29 09:24: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 45B233A07E6; Thu, 29 Oct 2020 09:24:17 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=gmx.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 W5MGC00DDUfP; Thu, 29 Oct 2020 09:24:15 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 A75383A00C9; Thu, 29 Oct 2020 09:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1603988645; bh=+9VUI4kR5m1joxLAQOpi+IiPQZ76YpN6TCIZiPmusuQ=; h=X-UI-Sender-Class:From:Subject:Date:In-Reply-To:Cc:To:References; b=SyOLkDiit4rF8jV2zF06GBe9LTx7+Yqi68YuMkpmDHAN8ibGKRcoAvPMDWMw+N5ut N0EVbstIZ72K9IFJ7DPPVMKXN9WWB1o1I8AJNncKk/OhOuUyJ9BoqU4+Zw9BNqrMzV /n6+eWvEITHSgZdjOuckb8UpK/v95Kcu30EMNTMg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.128.43] ([78.35.231.242]) by mail.gmx.com (mrgmx005 [212.227.17.184]) with ESMTPSA (Nemesis) id 1M26rD-1kWEua02jR-002ZlF; Thu, 29 Oct 2020 17:24:05 +0100 From: ianfarrer@gmx.com Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_18A64C07-EA05-4998-A2EF-BD9727C302FF" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 29 Oct 2020 17:24:02 +0100 In-Reply-To: Cc: Michael Richardson , dhcwg , v6ops list To: Jen Linkova , "Bernie Volz (volz)" References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <19432.1602258078@localhost> <644565BC-5818-4244-A34A-1B39C3FC9175@gmx.com> X-Mailer: Apple Mail (2.3445.104.11) X-Provags-ID: V03:K1:rqvgvSzKjVDNLsOXqJ+gRWILOqxgUXyOKSC6v2/Yw3bwEtMFgKE jX4Z/WtkrugX6u8EIJQ8suUUCHRfCxwU7fjb2Zg90qIbLqh5pMGAfT52j/hGqn94HDgodQd GgEIcqmB9W7VKuN47euBVXbIP+JFJ7ofAyI9dMPjkIEJgkbjsK0jDf5L5ybxNx77V2rg3r5 z+By3IzhUPYIu8PEbE8WQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:t33abuAGv1g=:aVp2/PCKl/QA0fSArFhX03 lA0F4kaTeF5TD2VV8qRxj/rtRXMAc9EzdH/GWg3yXK2MryxtPN1xb803ANI8KPDmzkiF4GVsl eg9LAP/g6//5/4Q9MdVTYWwzT8/KO7mv9u8ZpVythOgR1OxHhympmll8BmPmH5ctduOCi9+lS i3n8rNwqQFzq8mIqwPPVzh7aTNsvl062jidlj5e6TsETbyEBYVhPx0/LuIxvIkhdlKH0K6174 yTVFkKr3a2ZSLJWIg+wGGo5DAb+nZtU1iAoXb+NlCcrO4GQH2XxgXSeM1I9/hH7qrMfAMxG78 ArFlpr5xt4qnNq/a5yfJdKhNlH0ULNLRrDjeJNFXAzowyRtjB72ZCGTjUkY0XtzSgYQpbNUn9 k6Jbjwr2zwqQUIJiJj8SffVszUIVepRqgh8XIGr0t9OYtWQDuiRPsvOb0Snfi2Dl4+6HCtSrG R7wXrbL/lEaaMdHikFpr+YbERAFtFtoBtDvdiiTS505mV7KIpp3myIDDAm0IAU2Gwt786FZlh xzFRCcaYdwRIDxHstHxu0lIIozibp3clwIBzJ2kqogjXTTMtTunVNFT7DLBwK87CTk4UN9h6B UaJ0c2/xMsM3TLdpL5M9wgflG/lFvwCgH0lvW3og6Q/fUP83CUwR2zGylduykIf3BFpJ0BB3b /svUjFwMcGsuqfxplaAIaiPjE1ktahZ5vgAu1KUccks35X+viysN6TNBXJxGYFUcHMvmSiYCP A7/wdcfS3WHd4q4XXA13IJqD4tNmnLjh3t0E+2aogQSz1SfYSXOa/Og6DQtjZ3Rh+qj7nPg5e 47TaaPYGYyW+4097SbUI+5rQ4PugHIUczuNRqQ5NPw3S/YhW387vvbCzAu/9KaZr+Efr6Frod 8uCmWrlLH0WOsqXq2Ekg== Archived-At: Subject: Re: [v6ops] [dhcwg] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Thu, 29 Oct 2020 16:24:17 -0000 --Apple-Mail=_18A64C07-EA05-4998-A2EF-BD9727C302FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Sorry for the delay in reply, I=E2=80=99ve been out of the office for = the last few weeks for various reasons. Here=E2=80=99s a new wording proposal incorporating Jen & Bernie=E2=80=99s= suggestions: R-4 To prevent routing loops, the relay SHOULD implement a configurable = policy to drop packets received on a DHCP-PD client facing interface with a destination address = in a prefix delegated to a client connected to that interface, as follows: For point-to-point = links, when the packet=E2=80=99s ingress and egress interfaces match. For multi-access links, when the = packet=E2=80=99s ingress and egress interface match, and the source MAC and next-hop MAC addresses = match. An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route to = destination) error message MAY be sent as per [RFC4443], section 3.1. The ICMP policy SHOULD be = configurable. Thanks, Ian > On 15. Oct 2020, at 03:51, Jen Linkova wrote: >=20 > On Wed, Oct 14, 2020 at 12:44 AM Bernie Volz (volz) = wrote: >> If not, perhaps we just say: >>=20 >> R-4 >> To prevent routing loops, the relay SHOULD implement a configurable = policy to drop traffic received from an uplink interface as follows: >=20 > I'm not sure 'from an uplink interface' makes sense. In the case of a > routing loop caused by an amnesiac DHCP-PD client it would be a > downstream interface. > The scenario when such traffic arrives from an uplink interface is > 'the uplink router believes the prefix is delegated to the client but > the relay does not have a route pointing to the client so it sends > traffic back' - so more likely 'an amnesiac relay' case. >=20 >> For point-to-point links, when the packet's ingress and egress = interfaces match. For multi-access links, when the packet's ingress and = egress interface match, and the source MAC and next-hop MAC addresses = match. An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route = to >> destination) error message MAY be sent as per [RFC4443], section 3.1. = The ICMP policy SHOULD be configurable. >>=20 >> - Bernie >>=20 >> -----Original Message----- >> From: ianfarrer@gmx.com >> Sent: Tuesday, October 13, 2020 9:16 AM >> To: Michael Richardson ; Jen Linkova = >> Cc: Bernie Volz (volz) ; dhcwg ; 6man = ; v6ops list >> Subject: Re: [dhcwg] [v6ops] [EXTERNAL] Re: Question to DHCPv6 Relay = Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-requirements >>=20 >> Hi, >>=20 >> Thanks for all of the discussion on this. We=E2=80=99ve reworked the = requirement as follows: >>=20 >> R-4 >> To prevent routing loops, the relay SHOULD implement a configurable = policy to drop client traffic as follows: For point-to-point links, = when the packet's ingress and egress interfaces match. For multi-access = links, when the packet's ingress and egress interface match, and the = source MAC and next-hop MAC addresses match. An ICMPv6 Type 1, Code 6 = (Destination Unreachable, reject route to >> destination) error message MAY be sent back to the client. The ICMP = policy SHOULD be configurable. >>=20 >> Thanks, >> Ian >>=20 >>> On 9. Oct 2020, at 17:41, Michael Richardson = wrote: >>>=20 >>>=20 >>> Jen Linkova wrote: >>>> I think there is confusion re: the scenario we are talking about. >>>> I've attached the diagram for the case which concerns me. >>>> So: >>>> - The Relay R has an interface eth0 connected to a switch S. >>>> - Devices A and B are connected to the same switch and using R as a >>>> default gateway. >>>> - The prefix 2001:db8::/56 was delegated to a client A via the = relay R. >>>=20 >>> a friendly amendment to your example to aid in human comprehension: >>> } - The prefix 2001:db8:0000:0123:/64 was delegated to a client A = via the relay R. >>> } - R installs a route for 2001:db8:0000:0123:/64 towards A via = eth0. >>>=20 >>>> - The device B (which has an address NOT from the delegated prefix, >>>> but from another /64 assigned to that common link, let's sat >>>> 2001:db8:cafe::/64) sends a packet to an address from the delegated >>>=20 >>> now, my brain can more clearly see that 2001:db8:cafe::/64 is not >>> within 2001:db8:0000:0123:/64, while I had to use a few extra brain >>> cells to see that it wasn't in that ::/56 :-) >>>=20 >>>> What I'd expect to happen (with DHCP-PD or without - e.g. if R has = a >>>> static route towards A, not a dynamic route produced by PD): >>>> - the packet is sent to A. Well, if A does not have a route to >>>> 2001:db8::42 then indeed a routing loop might happen. But if A does >>>> have a route, the packet will be delivered. >>>=20 >>>> What seems to be required by R4: >>>> - R detects that the packet is received via eth0 and needs to be = sent >>>> back to eth0. R4 seems to require such packets to be dropped. >>>> So if B would never be able to communicate to any address in the >>>> delegated prefix, right? >>>=20 >>>> Am I missing anything? >>>=20 >>> I think that you got it right. >>>=20 >>>>> Perhaps the missing piece of the rule is don=E2=80=99t send it = back to where it came from, based on link layer addresses (or link if = point-to-point). >>>=20 >>>> Yes. If R4 was saying 'drop the packet if it comes from the same >>>> link-layer address you are going to send it back' - it would make >>>> total sense. But I don't think routers do *that*. >>>=20 >>> Yes, if we made the check on L2 address, then it would work. >>> And I agree that routers are exactly doing that. >>>=20 >>> I think that it also works if B is a router with additional = interfaces >>> downstream, unless there are multiple paths. >>>=20 >>> -- >>> Michael Richardson . o O ( IPv6 I=C3=B8T = consulting ) >>> Sandelman Software Works Inc, Ottawa and Worldwide >>>=20 >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >=20 >=20 > --=20 > SY, Jen Linkova aka Furry --Apple-Mail=_18A64C07-EA05-4998-A2EF-BD9727C302FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi,

Sorry for the delay in reply, I=E2=80=99ve = been out of the office for the last few weeks for various = reasons.

Here=E2=80= =99s a new wording proposal incorporating Jen & = Bernie=E2=80=99s suggestions:

R-4
To prevent routing loops, the relay SHOULD implement a = configurable policy to drop packets
received on a DHCP-PD = client facing interface with a destination address in a prefix = delegated
to a client connected to that interface, as = follows:  For point-to-point links, when the = packet=E2=80=99s
ingress and egress interfaces = match. For multi-access links, when the packet=E2=80=99s ingress = and
egress interface match, and the source MAC and = next-hop MAC addresses match. An
ICMPv6 Type 1, Code 6 = (Destination Unreachable, reject route to destination) error message = MAY
be sent as per [RFC4443], section 3.1.  The ICMP = policy SHOULD be configurable.

Thanks,
Ian

On = 15. Oct 2020, at 03:51, Jen Linkova <furry13@gmail.com> = wrote:

On Wed, Oct 14, 2020 at 12:44 AM Bernie Volz (volz) <volz@cisco.com> = wrote:
If not, = perhaps we just say:

R-4
To = prevent routing loops, the relay SHOULD implement a configurable policy = to drop traffic received from an uplink interface as follows:

I'm not sure 'from an uplink = interface' makes sense. In the case of a
routing loop = caused by an amnesiac DHCP-PD client it would be a
downstream interface.
The scenario when such = traffic arrives from an uplink interface is
'the uplink = router believes the prefix is delegated to the client but
the relay does not have a route pointing to the client so it = sends
traffic back' - so more likely 'an amnesiac relay' = case.

For point-to-point links, when the packet's ingress and = egress interfaces match. For multi-access links, when the packet's = ingress and egress interface match, and the source MAC and next-hop MAC = addresses match. An ICMPv6 Type 1, Code 6 (Destination Unreachable, = reject route to
destination) error message MAY be sent as = per [RFC4443], section 3.1.  The ICMP policy SHOULD be = configurable.

- Bernie

-----Original Message-----
From: ianfarrer@gmx.com = <ianfarrer@gmx.com>
Sent: Tuesday, = October 13, 2020 9:16 AM
To: Michael Richardson <mcr+ietf@sandelman.ca>; Jen Linkova <furry13@gmail.com>
Cc: Bernie Volz (volz) <volz@cisco.com>; dhcwg <dhcwg@ietf.org>; 6man = <ipv6@ietf.org>; = v6ops list <v6ops@ietf.org>
Subject: Re: [dhcwg] = [v6ops] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding = draft-ietf-dhc-dhcpv6-pd-relay-requirements

Hi,

Thanks for all of the = discussion on this. We=E2=80=99ve reworked the requirement as = follows:

R-4
To prevent = routing loops, the relay SHOULD implement a configurable policy to drop = client traffic as follows:  For point-to-point links, when the = packet's ingress and egress interfaces match. For multi-access links, = when the packet's ingress and egress interface match, and the source MAC = and next-hop MAC addresses match. An ICMPv6 Type 1, Code 6 (Destination = Unreachable, reject route to
destination) error message = MAY be sent back to the client.  The ICMP policy SHOULD be = configurable.

Thanks,
Ian

On 9. Oct = 2020, at 17:41, Michael Richardson <mcr+ietf@sandelman.ca> wrote:


Jen Linkova <furry13@gmail.com> = wrote:
I think there = is confusion re: the scenario we are talking about.
I've = attached the diagram for the case which concerns me.
So:
- The Relay R has an interface eth0 connected to a switch = S.
- Devices A and B are connected to the same switch and = using R as a
default gateway.
- The prefix = 2001:db8::/56 was delegated to a client A via the relay R.

a friendly amendment to your = example to aid in human comprehension:
=    } - The prefix 2001:db8:0000:0123:/64 was delegated to = a client A via the relay R.
   }  - R = installs a route for 2001:db8:0000:0123:/64 towards A via eth0.

- The = device B (which has an address NOT from the delegated prefix,
but from another /64 assigned to that common link, let's = sat
2001:db8:cafe::/64) sends a packet to an address from = the delegated

now, my brain = can more clearly see that 2001:db8:cafe::/64 is not
within = 2001:db8:0000:0123:/64, while I had to use a few extra brain
cells to see that it wasn't in that ::/56 :-)
What I'd expect to = happen (with DHCP-PD or without - e.g. if R has a
static = route towards A, not a dynamic route produced by PD):
- = the packet is sent to A. Well, if A does not have a route to
2001:db8::42 then indeed a routing loop might happen. But if = A does
have a route, the packet will be delivered.

What seems to be required by R4:
- R detects = that the packet is received via eth0 and needs to be sent
back to eth0. R4 seems to require such packets to be = dropped.
So if B would never be able to communicate to any = address in the
delegated prefix, right?

Am I missing anything?

I think that you got it right.

Perhaps the missing piece of the rule is don=E2=80=99t send = it back to where it came from, based on link layer addresses (or link if = point-to-point).

Yes. If R4 was saying = 'drop the packet if it comes from the same
link-layer = address you are going to send it back' - it would make
total= sense. But I don't think routers do *that*.

Yes, if we made the check on L2 = address, then it would work.
And I agree that routers are = exactly doing that.

I think that it also = works if B is a router with additional interfaces
downstream, unless there are multiple paths.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 I=C3=B8T= consulting )
=          Sandelman Software = Works Inc, Ottawa and Worldwide

---------------------------------------------------------------= -----
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: = https://www.ietf.org/mailman/listinfo/ipv6
---------------------------------------------------------------= -----



--
SY, Jen Linkova aka Furry

= --Apple-Mail=_18A64C07-EA05-4998-A2EF-BD9727C302FF-- From nobody Thu Oct 29 15:17:17 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 C53683A099F; Thu, 29 Oct 2020 15:17:16 -0700 (PDT) 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 8SK01F9IiyLE; Thu, 29 Oct 2020 15:17:15 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26CF03A07C4; Thu, 29 Oct 2020 15:17:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 17ED5389BB; Thu, 29 Oct 2020 18:23:53 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1wKURg9MDZoU; Thu, 29 Oct 2020 18:23:52 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A11BE3898B; Thu, 29 Oct 2020 18:23:52 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6A67D59A; Thu, 29 Oct 2020 18:17:05 -0400 (EDT) From: Michael Richardson To: ianfarrer@gmx.com, dhcwg , v6ops list In-Reply-To: References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <19432.1602258078@localhost> <644565BC-5818-4244-A34A-1B39C3FC9175@gmx.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [v6ops] [dhcwg] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Thu, 29 Oct 2020 22:17:17 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ianfarrer@gmx.com wrote: > Sorry for the delay in reply, I=E2=80=99ve been out of the office for= the last few weeks for various reasons. > Here=E2=80=99s a new wording proposal incorporating Jen & Bernie=E2= =80=99s suggestions: > R-4 > To prevent routing loops, the relay SHOULD implement a configurable p= olicy to drop packets > received on a DHCP-PD client facing interface with a destination addr= ess in a prefix delegated > to a client connected to that interface, as follows: For point-to-po= int links, when the packet=E2=80=99s > ingress and egress interfaces match. For multi-access links, when the= packet=E2=80=99s ingress and > egress interface match, and the source MAC and next-hop MAC addresses= match. An > ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route to desti= nation) error message MAY > be sent as per [RFC4443], section 3.1. The ICMP policy SHOULD be con= figurable. I'm okay with the new concept. I think that the sentence lengths and punctuation could use some work. I suggest: R-4 To prevent routing loops, the relay SHOULD implement a configurable policy to drop potential looping packets received on any DHCP-PD client facing interfaces. The policy SHOULD^WMAY? be configurable on a per-client or per-destinat= ion basis. Looping packets are those with a destination address in a prefix delegated to a client connected to that interface, as follows: 1) For point-to-point links (e.g., PPPoE), when the packet=E2=80= =99s ingress and egress interfaces match. 2) For multi-access links (e.g., ethernet), when the packet=E2=80= =99s ingress and egress interface match, and the source MAC and next= -hop MAC addresses match. An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route to dest= ination) error message MAY e sent as per [RFC4443], section 3.1. The ICMP policy SHOULD be config= urable. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+bP2EACgkQgItw+93Q 3WVN+gf/dxBwDIA/4Lj5T5l3K+igv8Sd76L2s1tdCry8483LdD0R2FII30QlBLz8 PJjOWaJLjI/qSZd3W2l3bxpuJ2pICXzXmse0lj49rnAIOhhhV9okqH9eY4EyYKh1 2EHJn9y7mSeF6Ebr+bMwjC7yNChC0opGfYDCzFqeAeWAWFx6LaFmbgUwqF65euJn i0/r4tXCJxLQTQg52nbBXeQPCnRYR6WOjOZ5KfJrw8x/ZfYI1ra+JQPcgAo8H9g6 S6Vx4XJgDHYsQuiKGRYOZnE0rmUgFzan0UraXkZWUfTOPP7RoYPeaiOkCTXw+Ovh Dmi6rU2kMVqj/fhT8sgIHOjukF+UBw== =VHH3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Oct 30 08:54: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 138C83A0CEC; Fri, 30 Oct 2020 08:54:26 -0700 (PDT) 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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-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 (1024-bit key) header.d=gmx.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 IzvzuZPy9SYq; Fri, 30 Oct 2020 08:54:24 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 56D6B3A0CC1; Fri, 30 Oct 2020 08:54:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1604073256; bh=5i31iW6mZC3abSV5RP5OqW5PjTZmjAPCEa/ULecppRQ=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=PL+EFgnVvjzJpEzOSImlIcqyItw1IBk6Mi+iL7asagDqZa+jGGJdy3l14UBxonxAw 0lwUS495PxoWfVRteb1AEmlvTBmF5Ni/mejb29ARRq8ltsq1I0O9RTfwuLnx9m/yG0 FFHd/U2Hj8MNFct7FyF8hbxRHfOywnQZIKwdtPP0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.128.43] ([89.1.62.143]) by mail.gmx.com (mrgmx104 [212.227.17.174]) with ESMTPSA (Nemesis) id 1MVNB1-1kyg2y3kmd-00SQxp; Fri, 30 Oct 2020 16:54:15 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: ianfarrer@gmx.com In-Reply-To: <5878.1604009825@localhost> Date: Fri, 30 Oct 2020 16:54:14 +0100 Cc: dhcwg , v6ops list Content-Transfer-Encoding: quoted-printable Message-Id: References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <19432.1602258078@localhost> <644565BC-5818-4244-A34A-1B39C3FC9175@gmx.com> <5878.1604009825@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.104.11) X-Provags-ID: V03:K1:UT3cL6tHZ9XGB3G0eo3d27npXtxCJrqNQVsiI478WzFGZ90hmEo dhhcFE/fvfHS1aDfxOXTzzfoFclhH4bvbomBi+XFr7D6ylEethvwHOJP9gYg8dt0ruXuTzB yOiEchJE1WffTQnbLOgsa01ca7snSO3+zo4QBx3EAba1OQbXhrB4m9k5zhATp5Hwn1hb8V/ SSclusSBGkSm2ns32rBbQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:ldPl9kp0rAA=:0uTOz+/fQ/57T/dF6YViTY fR1w6G03lxvXmr3LKwjl5Z4kqVEdPdQNwHhtW5bk0JslsNxeQxDJdIVmZyZnsiiw8HwPrprBB kCoEvVqxqhVbt0lRp23scTGixQU9vZWH+m66P3HrZtYwOmkvgn5iKIzpNCpBClovFijNJrEQG JkMCNT9lSGhqQEhFWi+2rXP7Eq1YueWh3QpbYsZ35LSQcPbogcsboIK2fVQDwLwRFkKSke0yo d8CTFx6Q9JkoUS7idpn0QYiwjac0GFcbsaIpEZz7+QKjL7ep07mXDsyU3bxlvXv3gKrVJjEsd nKicWyeLfnkQmAo0VSYIIa/JgvykC/rMbg5ZH+evYLvQvk6zXyeI+OEjk8H7VeAwSqJ9VgSQb EC7mMpUUvBBZumGm+3yOcBCEUGdysXzD/67FwUqhYgM5sk/NWuvl2YIhyG6lGbtqKfr2vV6LU ADs1TTRH8NWvIABXj4X9YTFRzTfhXlM45DLonp2D+pYBUpOZAlWXIL3rDpmzw1Ne0ZhP1Ff6I P/ttLtqbumIbD4xDZaKrcQI40+w86qkDJdulPMuXw54jPE90Oh63mG96Y8laO9S7cCemKNcRG n7fmKsL0VVoJqlucwMM/FS0HqTMouakLLh6ISzzpkHH1/eM+Y/3vzVPqwVehILCW3AXWgL+u3 5UJ+9U9ztkiRv/7L+SnmdQ64b8hxVWP6fRb0eNv19bSKkbseUMrHJZpvQl9Ty2E6W8xDM9jqB D3aFdU0izx3jWEUikyxyImvDtXg8Fi+XqmnoMnuAfVFPRqdFcFtL9V8Zreh2WwQR1thcvdPWZ tvfvC1FKj8zqRtgWgkYKT+AcDJ81E8uDOCCLPKMW98/F0HGaXuynFKHOblQMvilZwa9jbdsdI hw6XG+KU6EGgiJDwMzww== Archived-At: Subject: Re: [v6ops] [dhcwg] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Fri, 30 Oct 2020 15:54:26 -0000 Hi Michael, Thanks for the suggestion. It reads better than my version. One = question: "The policy SHOULD^WMAY?=E2=80=9D - I guess this was meant to = be MAY? Thanks, Ian > On 29. Oct 2020, at 23:17, Michael Richardson = wrote: >=20 >=20 > ianfarrer@gmx.com wrote: >> Sorry for the delay in reply, I=E2=80=99ve been out of the office for = the last few weeks for various reasons. >=20 >> Here=E2=80=99s a new wording proposal incorporating Jen & Bernie=E2=80=99= s suggestions: >=20 >> R-4 >> To prevent routing loops, the relay SHOULD implement a configurable = policy to drop packets >> received on a DHCP-PD client facing interface with a destination = address in a prefix delegated >> to a client connected to that interface, as follows: For = point-to-point links, when the packet=E2=80=99s >> ingress and egress interfaces match. For multi-access links, when the = packet=E2=80=99s ingress and >> egress interface match, and the source MAC and next-hop MAC addresses = match. An >> ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route to = destination) error message MAY >> be sent as per [RFC4443], section 3.1. The ICMP policy SHOULD be = configurable. >=20 > I'm okay with the new concept. >=20 > I think that the sentence lengths and punctuation could use some work. > I suggest: >=20 > R-4 > To prevent routing loops, the relay SHOULD implement a configurable > policy to drop potential looping packets received on any DHCP-PD = client > facing interfaces. > The policy SHOULD^WMAY? be configurable on a per-client or = per-destination basis. >=20 > Looping packets are those with a destination address in a prefix > delegated to a client connected to that interface, as follows: >=20 > 1) For point-to-point links (e.g., PPPoE), when the packet=E2=80= =99s ingress and egress > interfaces match. >=20 > 2) For multi-access links (e.g., ethernet), when the = packet=E2=80=99s > ingress and egress interface match, and the source MAC and = next-hop MAC > addresses match. >=20 > An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route to = destination) error message MAY > e sent as per [RFC4443], section 3.1. The ICMP policy SHOULD be = configurable. >=20 > -- > Michael Richardson . o O ( IPv6 I=C3=B8T = consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide From nobody Fri Oct 30 10:15: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 78EFA3A104B; Fri, 30 Oct 2020 10:15:46 -0700 (PDT) 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 w6ag_uZ0r7Uw; Fri, 30 Oct 2020 10:15:44 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 834D33A1048; Fri, 30 Oct 2020 10:15:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 74677389BB; Fri, 30 Oct 2020 13:22:33 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qnx27Duocy7g; Fri, 30 Oct 2020 13:22:30 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8B8E5389BA; Fri, 30 Oct 2020 13:22:30 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 56DBB362; Fri, 30 Oct 2020 13:15:40 -0400 (EDT) From: Michael Richardson To: ianfarrer@gmx.com cc: dhcwg , v6ops list In-Reply-To: References: <5F6947F2-F7DF-4907-8DD5-28C2B20A91DE@gmx.com> <19432.1602258078@localhost> <644565BC-5818-4244-A34A-1B39C3FC9175@gmx.com> <5878.1604009825@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [v6ops] [dhcwg] [EXTERNAL] Re: Question to DHCPv6 Relay Implementors regarding draft-ietf-dhc-dhcpv6-pd-relay-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: Fri, 30 Oct 2020 17:15:47 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ianfarrer@gmx.com wrote: > Thanks for the suggestion. It reads better than my version. One > question: "The policy SHOULD^WMAY?=E2=80=9D - I guess this was meant= to be > MAY? ^W is word delete in the ancient Unix tty. So I'm saying: "SHOULD" . Wait. Should it? MAY? I'd like to say SHOULD, but someone will tell us that their hardware can't = be configured that way... quality of implementation issue. >> R-4 >> To prevent routing loops, the relay SHOULD implement a configurable >> policy to drop potential looping packets received on any DHCP-PD cli= ent >> facing interfaces. >> The policy SHOULD^WMAY? be configurable on a per-client or per-desti= nation basis. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+cSjwACgkQgItw+93Q 3WVTFAgAlfB2cP/GZRwDQH/K2MJNBgIlnqatHukg8sOKRJrz/sh85S0cp0QdHv5e KJdP2lV+vI7gDq5Ar6z45nXc2+DXEC7zDeTRO1IbvWMpPvii/X10melJifmKLiO+ Ira0+g5B/26iytFDVVbx0xi+7D8mWlIIEVA8S/T6tUvOUBOTIbKK5wWDVZsYKBqD yKrAbV+JjBdeoeih8XYm1ZY4b1MmXl1wVRlI4Wfj0ncjrFKcbhet+LSAMJ3oF/so mpOPj3RKGGZj0Oq9igFGO+5xcfTobe4cuDw+2YgBDjFq/dBVZoy0GGSiMlVoYV/9 2A3nTLgJztIAjuqCUxWak/fyNbJMlQ== =pDH8 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Oct 31 23:01: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 6C72C3A0E95 for ; Sat, 31 Oct 2020 23:01:37 -0700 (PDT) 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 i0pvS6aMvSX2 for ; Sat, 31 Oct 2020 23:01:33 -0700 (PDT) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0: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 5B76C3A0810 for ; Sat, 31 Oct 2020 23:01:22 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id h6so8197064pgk.4 for ; Sat, 31 Oct 2020 23:01:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:cc:to:message-id; bh=VAadasFj25SHZCrCFBiUkF/fgnuLtLwYGZzKW2p9L7w=; b=PQkL7AGbU+5KqGTpC0wb/usyLkuCcbdLlgXxN+b4NraXeLrpeMsNctQXwmblFPFOfr hbDp8pDdq1j0W/xxKEF2exKDKp9gW0Fog55MswZe6FZWcyZA9dDx+j5HaHRiw2uXaT1f G+rV8yPvfTp8m0LtnM9sJlXgxuZ4RZuvrD1l1yucNmHctRPCrRZCYUa2KCUsQ6AhWZ2+ vVD0Ci0vbTVCSbDn38Le69fs2PYZqs5RYKNla3G0WIgkY82a75HA2+FTJWBmbtYIaCuz RX2MrNs3wr48fAf/+LK+HvgWxgCpAa7SnaxWzG+JgyaVrmrFjeGHjBK2IxeZAe6a6jlQ LcgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:cc:to :message-id; bh=VAadasFj25SHZCrCFBiUkF/fgnuLtLwYGZzKW2p9L7w=; b=tnl2+j9PWniuuDIHjCLHycRDhSO+tlTMTFWCC1fRCaQ9ctfclpoMn6e+IDIHbAI6vU ly+//QSI2ZHRWzs0GmJT319Qle9KMEcnk46UsgA/XsnnBTUquutrUmAxYQYjlkW240Iq /p4BtXOvNrwVq7Dt7/z29IO/ooM0nrebk0hdYggrqL+HngNjP/KfOA2MwEue0Pi9GVg6 Gal89LhyPv2J2OiZ5eGIO8uEfbFOnur1d5XIY7u+GCu+8pkKOtT77HgFdc0Ta66Lk2n5 nfKD9mQls60XZfpCosG6m9rZFIp6Q+ToY5UHjsframt9E+WiUhR2PawqLGHGd5jobXth IwsA== X-Gm-Message-State: AOAM531E+pGrQjaIlh3VINzce20j3n/Qdc5OWUZewRuJzwRz8u+S8S/V SafC6fuBN3wteLQHzcBVS05cv/ybG5BMBQ== X-Google-Smtp-Source: ABdhPJxLWcUVEejUfrVehjC/Y1JQ7El75ExKC8udRJ7BlmCcaacPsWe5mfCtLaUFG/EpWDY3rAoYnQ== X-Received: by 2002:a62:3746:0:b029:164:4326:1e7a with SMTP id e67-20020a6237460000b029016443261e7amr16775004pfa.33.1604210481547; Sat, 31 Oct 2020 23:01:21 -0700 (PDT) Received: from ?IPv6:2600:8802:5800:1963::1004? ([2600:8802:5800:1963::1004]) by smtp.gmail.com with ESMTPSA id k25sm9976538pfi.42.2020.10.31.23.01.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 31 Oct 2020 23:01:20 -0700 (PDT) From: Fred Baker Content-Type: multipart/mixed; boundary="Apple-Mail=_F0CC0384-FB51-4DF3-9708-B6778CF21A3C" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.1\)) Date: Sat, 31 Oct 2020 23:01:19 -0700 References: Cc: Rajesh A Shinde , Warren Kumari , Ramesh R Chandra , Ron Bonica To: IPv6 Operations Message-Id: <461B659C-FC97-4C1C-A78C-D7C05297D74C@gmail.com> X-Mailer: Apple Mail (2.3654.20.0.2.1) Archived-At: Subject: [v6ops] Developing v6ops agenda 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, 01 Nov 2020 06:01:38 -0000 --Apple-Mail=_F0CC0384-FB51-4DF3-9708-B6778CF21A3C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ron and I are developing the agenda for IETF 109. I'm forwarding you an = edited version of the note I sent him and the authors of current work. = An important file, attached, is what I call the "raw agenda data"; it = all derives from the data tracker, but rearranged in a way that makes = sense to me. One of the important points is drafts that have been = "updated"; that's a time reference, and refers to the end of IETF 108. = It also contains pointers to mailing list commentary, the draft, a diff = against the next older version if any, and the relevant data tracker = page. As I see it, most of our drafts need an update, and I would encourage = the authors to do so. The new HBH draft has next to no IETF commentary, = so my inference is that it's not something the operators are interested = in - at least not yet. draft-vf-v6ops-ipv6-deployment has a few comments = from the list, which I would encourage the authors to review and update = the draft in response to. In the "raw agenda data" file (attached), = you'll find a link to all discussion of the drafts on any IETF list. Ramesh Chandra will give a talk on Reliance JIO's deployment experience. = (For those unfamiliar with Reliance, see = https://stats.labs.apnic.net/ipv6/AS55836?c=3DIN&p=3D1&v=3D1&w=3D30&x=3D1;= there are five Indian ISPs that rank highly in observed IPv6 traffic, = and rather a number that are in the "me too" state.) I have asked him = for "lessons the IETF should learn from operational experience" and "any = suggestions on how to boost enterprise deployment?". Our proposed agenda = is at https://www.ietf.org/proceedings/109/agenda/agenda-109-v6ops-00; = comments solicited. I also noticed = https://www.nojitter.com/enterprise-networking/should-enterprises-avoid-or= -embrace-ipv6, and started to think about dropping the guy a note. Then = I decided not to; he repeats a lot of ages-old marketing hype that = doesn't necessarily correspond to anything I think is real, and never = thought made sense. We have over 1000 root servers worldwide, all of = which respond to IPv6 addresses if the network supports the technology = (sometimes an issue) - so what's the case for an India-specific = IPv6-only root server? India only has 43 IPv6-capable servers (cf = https://root-servers.org)... But it did make me think about enterprise management, how many = misconceptions they have, and how much money they're spending that IPv6 = deployment would free up. I'm not sure what to do with that. I'd like to = believe that we can be part of the solution to whatever we decide the = actual problem is. Your opinions would be helpful - an "IPv6 marketing = hype dispelled" draft, perhaps? Or "Native IPv6 in enterprise = deployment"? An important part of that is to note that upstream ISPs = frequently have IPv6 deployed, but enterprise customers are not using = it, even though actually turning it on is not all that difficult or = time-consuming, and Jen spoke at IETF 108 about turning IPv4 off. So - = how do we encourage enterprise deployment and adoption? I should think = part of that has to do with the public-facing services - mail and web. = Part of that has been figuring out how to use IPv6 to talk with someone = that desperately wants to cling to expensive IPv4 internally, but I want = to promote native deployment. Maybe, and here I take a page out of = Mythic Beast's book, charge more for IPv4 service?=20 --Apple-Mail=_F0CC0384-FB51-4DF3-9708-B6778CF21A3C 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.

RFC Editor: RFC-EDITOR

WG: Updated WG Document

Individual Submission: Unupdated

Individual Submission: Updated

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

Fri Nov 15 08:45:45 2019

--Apple-Mail=_F0CC0384-FB51-4DF3-9708-B6778CF21A3C Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_F0CC0384-FB51-4DF3-9708-B6778CF21A3C--