IETF Logo Mail Archive

Re: [v6ops] draft-ietf-v6ops-slaac-renum and draft-ietf-v6ops-cpe-slaac-renum

Owen DeLong <owen@delong.com> Tue, 26 May 2020 03:20 UTC

Return-Path: <owen@delong.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611DC3A0BAF for <v6ops@ietfa.amsl.com>; Mon, 25 May 2020 20:20:05 -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=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 RlzxyKNgSl9p for <v6ops@ietfa.amsl.com>; Mon, 25 May 2020 20:20:02 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 618A23A0BB0 for <v6ops@ietf.org>; Mon, 25 May 2020 20:20:01 -0700 (PDT)
Received: from [IPv6:2620::930:0:2980:c8bf:9bea:da9f] ([IPv6:2620:0:930:0:2980:c8bf:9bea:da9f]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 04Q3Jvnu627851 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 25 May 2020 20:19:59 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 04Q3Jvnu627851
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1590463199; bh=mTlYn42SC0FU8AO4YBqx4j1XYHNuIBrO6tDVA/swxTI=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=m/2ZIBAV1e/VVoz/ZHGMZtnlMJjfWAd6FK/8p16oH/rZfOiYhmbwi1wl4ajBvKV/T Kwsfmj+TFMsoN6zeXaFL/nsaSHz3JZHj5Vn0VVCw7aPnS/adJ7fWMqxOSx/Okh8Bix HXhAFR5weBgzOYbC9OweQZTm8LySrukQV3jiXZwE=
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <m1jdESc-0000H0C@stereo.hq.phicoh.net>
Date: Mon, 25 May 2020 20:19:57 -0700
Cc: IPv6 Operations <v6ops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6546385B-2BBD-41C9-B8A1-2E11C9EC34F5@delong.com>
References: <m1jb1gz-0000MZC@stereo.hq.phicoh.net> <8aa3102e-22b1-60ed-2d99-838f3fdf1736@si6networks.com> <m1jbKVd-0000L7C@stereo.hq.phicoh.net> <CAHL_VyDWYz=hUTZ+RDZ0JuF-KCsh5HBsM1pFFy3FqtL6pC_hCw@mail.gmail.com> <m1jbRI7-0000LCC@stereo.hq.phicoh.net> <CAHL_VyA23QJzgTy_nauxmjPM4PJT00YC451QL+s6d3dMomkX5Q@mail.gmail.com> <m1jc9R0-0000I4C@stereo.hq.phicoh.net> <B45A0FFE-5AE4-42BF-A8C7-B33F60B1BCAD@delong.com> <m1jdESc-0000H0C@stereo.hq.phicoh.net>
To: Philip Homburg <pch-v6ops-9@u-1.phicoh.com>
X-Mailer: Apple Mail (2.3445.104.11)
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]); Mon, 25 May 2020 20:19:59 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/bumTpY2zg1-N_rLMX-yd6wESsqw>
Subject: Re: [v6ops] draft-ietf-v6ops-slaac-renum and draft-ietf-v6ops-cpe-slaac-renum
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: Tue, 26 May 2020 03:20:06 -0000


> On May 25, 2020, at 07:52 , Philip Homburg <pch-v6ops-9@u-1.phicoh.com> wrote:
> 
> [note, I'm replying here to multiple messages]
> 
>> Why wouldnt the operator in such a case simply configure the RA
>> side as static?
> 
> Yes, but it introduces extra complexity. In particular, the CPE has to
> continue to request a prefix using DHCPv6. Then a naive implementation may
> end up with two entries for the same prefix in a single RA. Finally, the
> implementor may realize that filtering out the prefix from DHCPv6 may
> actually cause the CPE to violate a MUST NOT, so a strict interpretation of
> the CPE may cause the CPE to remove the user supplied prefix.

We are saying that the CE router MUST NOT do this BY DEFAULT.

If the CE router vendor wishes to provide a mechanism whereby the user can
misconfigure their network to misbehave in the way you describe, then they are
free to do so without being in violation of this draft.

Owen

v2.23.0 | Report a Bug | By Email