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

Ted Lemon <mellon@fugue.com> Fri, 01 November 2019 10:11 UTC

Return-Path: <mellon@fugue.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 9B5DF12022E for <v6ops@ietfa.amsl.com>; Fri, 1 Nov 2019 03:11:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 EcvErwqmu6Dm for <v6ops@ietfa.amsl.com>; Fri, 1 Nov 2019 03:11:58 -0700 (PDT)
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C466A120220 for <v6ops@ietf.org>; Fri, 1 Nov 2019 03:11:57 -0700 (PDT)
Received: by mail-qt1-x832.google.com with SMTP id u22so12224654qtq.13 for <v6ops@ietf.org>; Fri, 01 Nov 2019 03:11:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; 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; d=1e100.net; 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 smtp.gmail.com with ESMTPSA id d126sm3571515qkc.93.2019.11.01.03.11.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Nov 2019 03:11:53 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <2A9E3CA6-EF42-4D76-8BE2-3BEC9E117AC2@fugue.com>
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: <7870ab3d-9570-4f79-df5b-3653ab3a6c54@si6networks.com>
Cc: v6ops list <v6ops@ietf.org>
To: Fernando Gont <fgont@si6networks.com>
References: <CAO42Z2yQ_6PT3nQrXGD-mKO1bjsW6V3jZ_2kNGC2x586EMiNZg@mail.gmail.com> <B53CE471-C6E8-4DC1-8A72-C6E23154544F@fugue.com> <325e84aa-1703-e1ce-55a6-8790ceb7aff0@si6networks.com> <4C6471D4-0F5B-49EE-A38A-22AB2B87DA7E@fugue.com> <7007fd81-eae9-c165-c405-162b561f165a@si6networks.com> <69BD70A3-D9BF-48CB-9E68-D242333E9683@fugue.com> <7870ab3d-9570-4f79-df5b-3653ab3a6c54@si6networks.com>
X-Mailer: Apple Mail (2.3600)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/gzqTdfWXitRfkZQtNDzkNLJt34I>
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: Fri, 01 Nov 2019 10:11:59 -0000

On Nov 1, 2019, at 5:45 AM, Fernando Gont <fgont@si6networks.com> 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… :)