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

Ted Lemon <> Fri, 01 November 2019 10:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B5DF12022E for <>; Fri, 1 Nov 2019 03:11:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
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, 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 EcvErwqmu6Dm for <>; Fri, 1 Nov 2019 03:11:58 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C466A120220 for <>; Fri, 1 Nov 2019 03:11:57 -0700 (PDT)
Received: by with SMTP id u22so12224654qtq.13 for <>; Fri, 01 Nov 2019 03:11:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=E+4xWjj1E9rFFsHAHe++oIhW5yAf04szckv9/YzvX7k=; b=JUnmVGzvgBys+kdNJq5zfxhjix8+4GvlqQlQGfhDP4IgqbKIgMsnXhMj8/UqiXSpbG MuDsdkllc2f95kkwII8sFuE5zwsOsrcF8iVVb+Mvfg1/yEcaTsdbdb6W8qZL7Zz58NB3 Zkh62rPIoAdV66v1e5voiPvUnWLUMZ6Vsr3LTEoFcSY8t+9GQrG9DqUPC5NNmosnSrkp VYMse+3YlKTnXwEXFtLs7NN/IDZ+nlnn3SnF7FKx0L8cxuv+gi2YNhHXGE5Jik1XJAk/ Bx6FN0qm/RmE9Ub5QlfeJkdL0KFeLusYoA/XNuA6ow/JMhG81TnwFj+caFkU4o1vhIY8 IG4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=E+4xWjj1E9rFFsHAHe++oIhW5yAf04szckv9/YzvX7k=; b=JGsp1H2kuSLORmrX1I2x9ho0O1s4f5IEajcpKW/lw7/q68X1w4ljrh5UX9OKfNhdlH 8E62saOw6+43sSUMOwiv+wZjXnze/aLLYVas8gCbV5piGLAUXdmmH89wgERFtkfkJIZA 3wKFPr6ekJ9RMy7I5Li8oZbmZILSe25Zwc5T/TSEp3Nl/yFrwmfSP3N3a8yFOIWk76Hz WTuaQTe9a3uYUJLH5SmsmbKnBg874QArHa3ghFF540RlfG7i1pbe/QEJoYeo8oqx2rjj t15vGidKd2DGQhlzT6y2kOrD3WPowkB3xuHQZSDWi7dvPHTlRpr7tWTbZoUqdIKC69NP AN5g==
X-Gm-Message-State: APjAAAV4GwR9pxR1IkRHH7FnnwShs3sXkPYzxdIRx4DeZB3++uHCvonk qii5Mv6VL1zN9m5dKTmeNdb2LOheZ06FvA==
X-Google-Smtp-Source: APXvYqyYvpRY2JriHdS7Vemx365U3W/LGgtlY883lyBjZiYRCyTHdgkh32rrO5X51TXvdBUS/f4Bzw==
X-Received: by 2002:a0c:a222:: with SMTP id f31mr8951265qva.192.1572603114559; Fri, 01 Nov 2019 03:11:54 -0700 (PDT)
Received: from ?IPv6:2601:18b:300:36ee:bdc1:1d6d:228a:c9c1? ([2601:18b:300:36ee:bdc1:1d6d:228a:c9c1]) by with ESMTPSA id d126sm3571515qkc.93.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Nov 2019 03:11:53 -0700 (PDT)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0B214466-6CE8-4D4C-8DFD-C53B1BE1BF97"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3600\))
Date: Fri, 1 Nov 2019 06:11:52 -0400
In-Reply-To: <>
Cc: v6ops list <>
To: Fernando Gont <>
References: <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3600)
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 10:11:59 -0000

On Nov 1, 2019, at 5:45 AM, Fernando Gont <> wrote:
>> So why aren’t they doing that?   What’s the obstacle?
> Are you referring to the CPE case, or to the rest?

I’m specifically referring to the ISP case, although I think referring to it as “the CPE case” is limiting your options! :)

> If you assume all routers employ the same values for the valid/preferred
> lifetimes, then what you propose is the equivalent to "prefer the last
> advertised prefix". In which case, in the presence of multiple RAs the
> src address of new sessions will deterministically flap. That doesn't
> seem nice from a troubleshooting perspective.

No, I’m saying that if you have two prefixes, one with a preferred lifetime of zero, and another with a preferred lifetime that is not zero, you should choose the second one.   Can you explain in a little more detail when this would cause a “deterministic flap”?

>> As for previous comments about source address selection, I think that if
>> you have two prefixes that are otherwise equivalent (a tie), and one has
>> a preferred lifetime of zero, while the other has a preferred lifetime
>> of not-zero, it would be dysfunctional to choose the one with the
>> preferred lifetime of zero.  What on earth is the purpose of preferred
>> and valid lifetimes if SAS isn’t taking them into account?
> The timers are only supposed to be of use if they go off. Given the
> default values the use (one month, and one week), they never go off.
> The valid lifetime would trigger garbage collection for stale prefixes.
> The preferred lifetime would keep a fresh and working address as the
> preferred address for new flows. -- if only they went of in a timelier
> manner.
> So, I'd rather ask the question: what on earth is the purpose of setting
> a timer that will never go off in a meaningful situation and period of time?

Possibly we are talking past each other.   A prefix with a preferred lifetime of zero always has a preferred lifetime of zero.   There’s no timer to go off.   How the preferred lifetime got to be zero is of course an important question, and there I think that what you are getting at is important: a 30 day expiry time is way too long.

What if the user does want to release the prefix, e.g. for privacy reasons?

> Not that I oppose to that. But I just note that there's no reason for ot
> trusting a router that advertises PIO,VL=0, because your trust model is
> that you do trust the router (if not your whole local network).
>> If I get an RA that’s not signed by the same key as a route in my
>> routing table that’s working, I don’t let it override what is currently
>> in my routing table and working.
> But that's not the current deployed reality. IN current deployments, RAs
> are not signed. So why wuld you be skeptical to PIO, VL=0?

Right, we have a problem there.   SEND didn’t solve it.   I don’t think RA Guard solves it for the home case.   So, there is work to do… :)