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

Owen DeLong <owen@delong.com> Thu, 31 October 2019 19:27 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 0789A1209D9 for <v6ops@ietfa.amsl.com>; Thu, 31 Oct 2019 12:27:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 Sy5sxzQi4Lcg for <v6ops@ietfa.amsl.com>; Thu, 31 Oct 2019 12:27:36 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE0912097C for <v6ops@ietf.org>; Thu, 31 Oct 2019 12:27:32 -0700 (PDT)
Received: from [199.187.216.130] ([199.187.216.130]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id x9VJRVkF021473 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 31 Oct 2019 12:27:31 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com x9VJRVkF021473
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1572550052; bh=tQeKh/rNwYgT1e/jvMxMIfJ7B4MZ3KOjy0yhN1GiZXg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=GtELwLZd2GcNvox5/EVKjE4oU79XsmXa9EOrbDPS83G0aWpyVoGHZeMuY9yQ1LmT3 PXZhLCEWpXkFWorNc89+L+r/qJCM6idzFtfvJj6BnXRD9itIm7KTCsLrP8Og5fT2qy T1uuYgoevR8LtVrFOLIf/ztXvZgkUDeXOB2OmQrw=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Owen DeLong <owen@delong.com>
In-Reply-To: <8dbfb1b6-5efa-019f-313b-e8045ee277ee@si6networks.com>
Date: Thu, 31 Oct 2019 12:27:30 -0700
Cc: v6ops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <A97CB183-B7D0-42F3-A6C5-0224049936F1@delong.com>
References: <m1iNIFE-0000IwC@stereo.hq.phicoh.net> <d1b6855d-bde9-7b53-4809-0846bb9772e4@si6networks.com> <7C913CC2-938F-449C-9750-85C36EC05E38@delong.com> <48c864c7-589d-23cf-417e-6f4ec012a76a@si6networks.com> <7C142F1F-04C6-48A2-A65A-7CADD3691ECF@delong.com> <8dbfb1b6-5efa-019f-313b-e8045ee277ee@si6networks.com>
To: Fernando Gont <fgont@si6networks.com>
X-Mailer: Apple Mail (2.3445.104.8)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [192.159.10.2]); Thu, 31 Oct 2019 12:27:32 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/OLDSvPmV3N0oaeorR_FhJzDbNQE>
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: Thu, 31 Oct 2019 19:27:45 -0000


> On Oct 31, 2019, at 12:13 PM, Fernando Gont <fgont@si6networks.com> wrote:
> 
> On 27/10/19 01:48, Owen DeLong wrote:
>>>> It is worth noting that these values are tunable by the administrator
>>>> and the
>>>> RFC suggested defaults should never be a hard-coded value.
>>>> 
>>>> With the following exception, I don’t advocate modifying this on the
>>>> client
>>>> side:
>>>> +Section 5.5.3 of RFC4862 should be amended to specifically
>>>> allow the immediate deprecation of a prefix by sending a valid
>>>> lifetime of 0 seconds. Hosts should be required to honor
>>>> this as a signal that the prefix is no longer valid.
>>> 
>>> Could you please elaborate on this one?
>> 
>> I’m not sure what I could do to elaborate. The addition of a specific
>> call-out that
>> even if the current behavior of ≤2 hours = 2 hours is to be preserved,
>> there should
>> be a special case for “0 seconds” which causes the prefix to be immediately
>> deprecated with extreme prejudice.
>> 
>> Hosts should be required to treat an RA containing a prefix with a 0 second
>> valid lifetime as an invalid prefix and immediately deprecate it from
>> the interface
>> if it is in use.
> 
> OK, so you do agree with the proposed change? (in
> draft-gont-6man-slaac-renum, not in *this* document)

From the context of my thinking at the time of writing the original reply,
“this document” referred to draft-gont-6man-slaac-renum. Apolgies
for my lack of clarity as you have apparently interpreted it differently.

> 
> 
> 
> 
>>>> I do think that generally speaking, your proposed modifications to
>>>> CPE and
>>>> router behavior should be standardized and implemented.
>>>> 
>>>>> A better mitigation is to affect the preferred and possibly the valid
>>>>> lifetimes in response to consecutive RAs from the same router that lack
>>>>> the original (stale) prefix. e.g., after two consecutive RAs that do not
>>>>> contain the existing prefix, reduce the preferred lifetime. After two
>>>>> additional RAs, reduce the valid lifetime.
>>>> 
>>>> In the crash scenarios you describe, you’re assuming a single router on
>>>> the network or
>>>> at least only one router announcing the prefix(es) in question with no
>>>> persistent
>>>> memory of the prefixes it was announcing across a reboot. In such a
>>>> scenario,
>>>> it seems to me that the following are also likely valid assumptions:
>>>> 
>>>> +The network has significant excess bandwidth compared to demand.
>>>> +The small overhead of frequent RAs and short lifetimes is probably
>>>> an acceptable tradeoff in this environment.
>>>> 
>>>> However, there are lots of other scenarios in the world where those
>>>> assumptions
>>>> won’t hold true and we should not seek to solve this problem (which is
>>>> generally
>>>> applicable to residential and SMB environments) at the expense of all of
>>>> those
>>>> other professionally administered environments.
>>> 
>>> Even with the default RA frequency, if you were to unprefer a prefix
>>> upon, say, second RA that doesn't advertise it, and say, remove the
>>> prefix after many other RAs are received, that would be a *big*
>>> improvement to what we have now.
>> 
>> I don’t like this idea because I can think of some scenarios where you
>> may receive multiple RAs from router A not containing the prefix in the
>> same time frame that router B has not sent an additional RA containing
>> the prefix, but it will do so in its next RA.
> 
> Maybe it wasn't clear in the I-D, but the basic idea is:
> If you receive multiple RAs from router A that do not advertise the
> prefix, then you disassociate such prefix with router A. If nobody else
> is advertising the prefix, you'd deprecate it. If other routers are
> advertising it, this would not change the status quo of the prefix wrt
> such other routers.

That’s definitely not how I interpreted the I-D and I would strongly encourage
you to review and update the I-D for clarity in this area. I’m actually still not
100% convinced that this is correct behavior. It also places additional burdens
on hosts to track all routers associated with a given prefix rather than merely
tracking candidate default gateways, RIO data, and one set of prefix timers
utilizing the most recently received timer refreshes.

>> There is no requirement for all routers on the same link to provide the
>> same set of PIOs, nor are they required to use the same advertisement
>> timers.
> 
> Agreed. Please see above.

With the above clarification, I think it can be done and is less likely to break
things. However, it does place a significant additional tracking burden on the
host which I’m not entirely convinced is a desirable situation. Especially in the
case of a resource-constrained host which is using SLAAC to avoid the overhead
of DHCP.

> 
> 
> 
> 
> 
> 
>>>> In section 3.2.1, you advocate setting the A and L bits to their
>>>> previous values
>>>> for prefixes which are being deprecated. IMHO, this is incorrect and the
>>>> announcements calling for immediate deprecation should also indicate that
>>>> the prefix should no longer be auto-configured and should no longer be
>>>> considered on-link.
>>> 
>>> Not sure I follow. Could you please elaborate?
>> 
>> Sure… In section 3.2.1 of your document, you advocate that if the previously
>> valid PIOs were set A=1 and/or L=1, then those values of the A and L bits
>> should be preserved in the RAs sent to deprecate them.
>> 
>> My argument is that since you are attempting to make this a prefix that
>> hosts
>> will no longer autoconfigure (A) and will no longer consider on-link
>> (L), that
>> in reality, regardless of the previous state of the A and L bits in the RAs
>> announcing the prefix in a valid PIO, the new RAs since the prefix has been
>> deprecated should be sent with A=0, L=0 in order to signal the host
>> that this prefix should not be auto configured and should no longer be
>> considered on-link.
> 
> You really make a good point. I will go through RFC4861 and see what's
> the current expected behaviour in such case.

Thanks!

Owen