Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

Ole Troan <otroan@employees.org> Wed, 30 October 2019 14:07 UTC

Return-Path: <otroan@employees.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414E91200F3 for <v6ops@ietfa.amsl.com>; Wed, 30 Oct 2019 07:07:17 -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, 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 r5JY_x0O1hYe for <v6ops@ietfa.amsl.com>; Wed, 30 Oct 2019 07:07:16 -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 301E4120112 for <v6ops@ietf.org>; Wed, 30 Oct 2019 07:07:16 -0700 (PDT)
Received: from astfgl.hanazo.no (dhcp217197164246.blix.com [217.197.164.246]) (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 267C64E11B4E; Wed, 30 Oct 2019 14:07:15 +0000 (UTC)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id 2D87620903EC; Wed, 30 Oct 2019 15:07:12 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <96344740-2F4B-4BCE-A881-EB1A5933AFA2@fugue.com>
Date: Wed, 30 Oct 2019 15:07:11 +0100
Cc: Timothy Winters <twinters@iol.unh.edu>, IPv6 Operations <v6ops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A24614F4-03F1-42A2-A7C3-525CC261C97E@employees.org>
References: <CAOSSMjVhK_V4HpMzprOyo9pj=ysFef+uZUs=twd_zfPaBdPu3Q@mail.gmail.com> <0F0B6068-CA62-449B-B56E-78E9EF8D998E@fugue.com> <CAOSSMjVLP4dx0Z1OKgXBgmuUCmR_C35J87fgkX7V=e7E3iQY3w@mail.gmail.com> <96344740-2F4B-4BCE-A881-EB1A5933AFA2@fugue.com>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: Apple Mail (2.3594.4.19)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/ftD3Rv5RI4cvzTBZlONBa8kXnJ4>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds
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, 30 Oct 2019 14:07:17 -0000

Ted,

>> We check both, the handling of the IA_PD and the error message.
> 
> And to be clear, you mean that if the CPE asks for a prefix delegation and doesn’t get the prefix it previously had, it deprecates it as described in L-14?  When this deprecation happens, what ways are being tested for it to happen?
> 
> E.g., is it the case that the client sends an IA PD containing an IA Prefix option, is the server returning the IA Prefix option containing the same prefix, with a status code encapsulated in it?   What status code?   Or is it returning an IA Prefix option with a different prefix?   Or is it doing both?

You are thinking about this wrong.
The simple implementation of uRPF/BCP38 is: on LAN ingress to do a lookup in the FIB of the SA, if the resulting adjacency/interface matches the ingress interface allow packet otherwise drop packet and send ICMP message. This behaviour is required regardless of renumbering or not.
The ISP is required to do this on their ingress interfaces too.

Cheers,
Ole