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

Fred Baker <> Fri, 01 November 2019 14:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7524712010C for <>; Fri, 1 Nov 2019 07:21:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qntgPB254Nsb for <>; Fri, 1 Nov 2019 07:21:56 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6D80F1200E7 for <>; Fri, 1 Nov 2019 07:21:56 -0700 (PDT)
Received: by with SMTP id 21so7172749pfj.9 for <>; Fri, 01 Nov 2019 07:21:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=A+ViMIU2YoNBHYJf5YXqopm8nn5rZMcj90YEb+cFwSs=; b=T2FBpuhkLM8IvkqqllRAG90B8FqLUt+IOyibkh5NBOLhACkicauSfObMOGIJ3YbzKC aYTQxXLT7lFd9+BnZucNcnwwnzm0G3AsdIS3kcg0qg0U8TG3esESs6+6v3dKeJEBzDx3 gHiYqtg+Ur8DDk6v2wdFaKpK06L0R/addf1aT2Jo5b8mWgF8JEua/2gl+gQqh7+cFhcX 8ogcA1D1FgEslTiqEgfKKEOtGp6p9t3Awn9env609RyBw5JMP9J96+3bpk65j1HCqy+c dN05+vrORmO4KnKvbg6BhRQlsMt5XK/nTFC4R1qUl2DWJTaC7S1UfVdqWosh/sfjydGJ zZ2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=A+ViMIU2YoNBHYJf5YXqopm8nn5rZMcj90YEb+cFwSs=; b=SphuALFPUGK9okW3H3lK7lgKoZo4y5s1vxsunPAI9UW/+5ML1yPQ7gfBFFrvK7jwJl OijeU6k/zBsZws4NfSPVepzwdqgiqZCy5tUL+jHc/3coFyh5cOGYBn7LT+0qiq+X1IkW VveHI5MNbV9dd1pHZg6zpDNAD2LhC7r2HHXaX38irfld33Wxk+9UIeonT7JTCyD9L/1v WltbqS2VGTIrtRF8dgeNvhGcc/s9SOHH+04RTPpXU4FFc6zdw4a4jVGWZd3acf8aXRxk LZDhwp7jOp6/4873xYUpyBJQlfvrPPRLinVxwSqW2but9HLLX83yTFBHUz7sWXWijh/w 6xvA==
X-Gm-Message-State: APjAAAUv0CZ2y507359ZGu+uNrQwqXbskbCnyfbYSuYWDNLG+36VyGui K+KBBKoAPv1RJPPiFXV2snA=
X-Google-Smtp-Source: APXvYqyqd0tPWScj0N3ujS2gTN516lHYOyuCC2ArY3kqIREX7AwVtuHwcucRSwDP0vqDvjARRBw5ZQ==
X-Received: by 2002:a17:90a:268c:: with SMTP id m12mr11462pje.69.1572618115814; Fri, 01 Nov 2019 07:21:55 -0700 (PDT)
Received: from ( []) by with ESMTPSA id v63sm6459919pfb.181.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Nov 2019 07:21:55 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
From: Fred Baker <>
In-Reply-To: <>
Date: Fri, 1 Nov 2019 10:21:53 -0400
Cc: Ted Lemon <>, IPv6 Operations <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Ole Troan <>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds
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, 01 Nov 2019 14:21:59 -0000

> On Oct 30, 2019, at 10:07 AM, Ole Troan <> wrote:
> 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,

On a customer-facing interface (e.g., someone you don't exchange BGP with and is therefore the only source of the prefix), yes. In an ISP, you want to be looking at the RIB, not the FIB; any BGP neighbor that is advertising a prefix to you might send you a packet with a source address in that prefix.

> 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
> _______________________________________________
> v6ops mailing list