Re: [v6ops] Clarification/addition on the cpe-slaac doc.
Fernando Gont <fgont@si6networks.com> Wed, 10 February 2021 17:44 UTC
Return-Path: <fgont@si6networks.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2773A110C for <v6ops@ietfa.amsl.com>; Wed, 10 Feb 2021 09:44:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 RMDcN77VOd6U for <v6ops@ietfa.amsl.com>; Wed, 10 Feb 2021 09:44:35 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A14A03A110A for <v6ops@ietf.org>; Wed, 10 Feb 2021 09:44:31 -0800 (PST)
Received: from [IPv6:2800:810:464:2b9:8956:4518:7147:354b] (unknown [IPv6:2800:810:464:2b9:8956:4518:7147:354b]) (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 B9B2D283C40; Wed, 10 Feb 2021 17:44:27 +0000 (UTC)
From: Fernando Gont <fgont@si6networks.com>
To: "Bernie Volz (volz)" <volz=40cisco.com@dmarc.ietf.org>, Warren Kumari <warren@kumari.net>, Ole Troan <otroan@employees.org>
Cc: IPv6 Operations <v6ops@ietf.org>
References: <CAHw9_i+uALQiarCRs=m7rBNJ25R62PmRev2zHm+vZ=2VJw9yHw@mail.gmail.com> <888118D6-1F56-4ED3-9F3E-745DA9F590D8@employees.org> <CAHw9_iLxeJJ2nSki0mB6kc+VMP5j4RDtUnGd87KWC-20XzwtQg@mail.gmail.com> <BN7PR11MB25471C02FB6F8540DEB0C942CF8D9@BN7PR11MB2547.namprd11.prod.outlook.com>
Message-ID: <1d9fc7dd-7814-9826-07f9-8407ab7d953b@si6networks.com>
Date: Wed, 10 Feb 2021 14:11:31 -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: <BN7PR11MB25471C02FB6F8540DEB0C942CF8D9@BN7PR11MB2547.namprd11.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/p7spEHWpZ8giyHUBEHgP1V6v_go>
Subject: Re: [v6ops] Clarification/addition on the cpe-slaac doc.
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Feb 2021 17:44:39 -0000
Hi, Bernie, On 10/2/21 12:37, Bernie Volz (volz) wrote: > It seems odd to me to be cherry picking things for RFC-8415 to reiterate > as requirements? > > Doesn’t that open up the possibility that someone skips other things > because “well it wasn’t in the CPE-SLAAC” requirements? This was motivated by the default behavior of some popular CE Routers, which end up triggering the use of dynamic prefixes, because they simply randomize the IAID in such cases. So this is relevant here. (One may wonder whether they are doing so by extrapolating RFC7844, or simply because they don't store the IAID on stable storage and also don't use an algorithm that always computes the same value...) I think one could add this note to the corresponding subsection that explains the requirement: [RFC8415] requires that IAID for an IA MUST be consistent across restarts of the DHCP client. However, some popular CE Routers are known to select a new random IAIDs e.g. everytime the underlying PPP session is established. This could be the result of extrapolating the behavior described in [RFC7844], or simply a consequence of not storing the IAID on stable storage and failing to employ an algorithm that consistently generates the same IAID upon reboots. Thus, this requirement prevents CE Routers from inadvertently triggering a flash-renumbering event on the local network. ... or the like. Thoughts? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
- [v6ops] Clarification/addition on the cpe-slaac d… Warren Kumari
- Re: [v6ops] Clarification/addition on the cpe-sla… otroan
- Re: [v6ops] Clarification/addition on the cpe-sla… Warren Kumari
- Re: [v6ops] Clarification/addition on the cpe-sla… Bernie Volz (volz)
- Re: [v6ops] Clarification/addition on the cpe-sla… Richard Patterson
- Re: [v6ops] Clarification/addition on the cpe-sla… Fernando Gont
- Re: [v6ops] Clarification/addition on the cpe-sla… Warren Kumari
- Re: [v6ops] Clarification/addition on the cpe-sla… Bernie Volz (volz)
- Re: [v6ops] Clarification/addition on the cpe-sla… Fernando Gont
- Re: [v6ops] Clarification/addition on the cpe-sla… Warren Kumari