IETF Logo Mail Archive

Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

Tim Chown <Tim.Chown@jisc.ac.uk> Tue, 26 February 2019 09:17 UTC

Return-Path: <tim.chown@jisc.ac.uk>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8B2130EAA for <ipv6@ietfa.amsl.com>; Tue, 26 Feb 2019 01:17:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk
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 TQ0VqE3tY4uW for <ipv6@ietfa.amsl.com>; Tue, 26 Feb 2019 01:17:12 -0800 (PST)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE415130EE1 for <6man@ietf.org>; Tue, 26 Feb 2019 01:17:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1551172629; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rdvDtTu3hdfsz/CNtklVp/m/snSIbyWZ5McOxIjQ7Vw=; b=Nj75tG4aaMMLCx5Mq+FCfPqI7ENuiGUqq/fteeKYwStM8hHqHv3D/UjsH5tqki0m6IUrjyNz0a4XFrHuOl4VR1Jb/451QZf3YPNVZLNHfzpVlDjyYJDiVMcu+YOMElG9yt7Qv03XCr73fa0oawwqCXGEBxy5tbkzMzNKy+o/K6U=
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03lp2057.outbound.protection.outlook.com [104.47.8.57]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-51-FKS8RVzXMMqj9vQ_7XIlLg-2; Tue, 26 Feb 2019 09:17:06 +0000
Received: from AM0PR07MB4177.eurprd07.prod.outlook.com (52.133.54.140) by AM0PR07MB5473.eurprd07.prod.outlook.com (20.178.22.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.12; Tue, 26 Feb 2019 09:17:03 +0000
Received: from AM0PR07MB4177.eurprd07.prod.outlook.com ([fe80::617a:4c8b:34ae:efcb]) by AM0PR07MB4177.eurprd07.prod.outlook.com ([fe80::617a:4c8b:34ae:efcb%4]) with mapi id 15.20.1665.012; Tue, 26 Feb 2019 09:17:03 +0000
From: Tim Chown <Tim.Chown@jisc.ac.uk>
To: Fernando Gont <fgont@si6networks.com>
CC: Richard Patterson <richard@helix.net.nz>, Fernando Gont <fernando@gont.com.ar>, IPv6 Operations <v6ops@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Subject: Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios
Thread-Topic: [v6ops] A common problem with SLAAC in "renumbering" scenarios
Thread-Index: AQHUzTkBQuNentVJFkebkUvTotpgtqXxzZ4A
Date: Tue, 26 Feb 2019 09:17:03 +0000
Message-ID: <FB8B77EE-CC16-4418-BB5E-D44EE66D6B72@jisc.ac.uk>
References: <6D78F4B2-A30D-4562-AC21-E4D3DE019D90@consulintel.es> <B6E2EC33-EEAF-40D0-AFCC-BDAFA9134ACD@consulintel.es> <20190220113603.GK71606@Space.Net> <28fbc2c305c640c9afb3704050f6e8d7@boeing.com> <20190220213107.GS71606@Space.Net> <019c552eb1624d348641d6930829fd1f@boeing.com> <CAKD1Yr0HBG+rhyFWg9zh0t3mW486Mjx9umjn+CRqAZg4z9r0dg@mail.gmail.com> <20190221073530.GT71606@Space.Net> <CAO42Z2wmB2W52b4MZ2h9sW5E9cQKm-HRjyf--q8C26jezS7LXQ@mail.gmail.com> <a73818d31db7422b99a524bc431b00ed@boeing.com> <CAO42Z2z9-48Gbb_Exf+oWUqDO=axSLpZBtqeDcxkAoFq5OziGw@mail.gmail.com> <CALx6S3624hnGauG1HaSWPMvQw0t2Q5R3gb8W4R8w3kuK7dcrWQ@mail.gmail.com> <1F07F2BB-2F37-4D12-9731-7892DF4E3D88@consulintel.es> <0a582916-af14-bd82-a4cd-002a36f8830b@huitema.net> <67515a73-26a5-3ed0-da88-1a4ce64550d3@foobar.org> <360afa02-cf23-375c-4876-780d3c2aa5ac@gont.com.ar> <CAHL_VyD34V=TRcsCp0DOO9HJNHyy5xkiMQ_cZoBa7zTE4fe5OA@mail.gmail.com> <ead01e0a-9211-7944-88d6-ae8d037c03a8@si6networks.com>
In-Reply-To: <ead01e0a-9211-7944-88d6-ae8d037c03a8@si6networks.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3445.102.3)
x-originating-ip: [141.85.248.9]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5e007613-c746-4eb5-6598-08d69bcb2baf
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:AM0PR07MB5473;
x-ms-traffictypediagnostic: AM0PR07MB5473:
x-ms-exchange-purlcount: 1
x-microsoft-exchange-diagnostics: 1; AM0PR07MB5473; 20:018UKT0mtrIvMNvFBAkN1R/GP/aoVQZDzdKVBNjlhkRjJhtx0W6O2cN4G5UP1mIreyGbztVS6mjq1xDxcg1v44wjLY3RnPLjVlSXsDaYTS/tK3/Nq8h9marCETqj5+zKQJT3ruNWLjhFPN1eCmmZQ68pYC+jGYlwx2YiiWDkV90=
x-microsoft-antispam-prvs: <AM0PR07MB54731A2B14F549D43EA4AEACD67B0@AM0PR07MB5473.eurprd07.prod.outlook.com>
x-forefront-prvs: 096029FF66
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39850400004)(346002)(396003)(366004)(376002)(189003)(199004)(25786009)(4326008)(36756003)(446003)(6246003)(786003)(11346002)(2616005)(476003)(74482002)(93886005)(6916009)(81166006)(81156014)(8676002)(86362001)(316002)(97736004)(3846002)(6116002)(486006)(106356001)(53936002)(6512007)(105586002)(6306002)(256004)(14444005)(229853002)(66066001)(14454004)(478600001)(6436002)(5660300002)(57306001)(53546011)(33656002)(76176011)(186003)(26005)(6506007)(102836004)(8936002)(54906003)(50226002)(2906002)(7736002)(71200400001)(71190400001)(83716004)(82746002)(68736007)(305945005)(99286004)(72206003)(6486002)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB5473; H:AM0PR07MB4177.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: PoNx3OrwXAg2c7pCYeiXQgbTkOh7Rno6R1XeUFdTcx1eB8RG/68Erz479hjPUxfNQqkpAdkJcV+oqnii8KdQGyyDIoSjXFVLluPIVWayAZUaxXmiBtfD1xjJn0w+ZGwNN20YNF/gs8Pft5Ap/mKD0cIwWqJ8wIVVMAlPCyzQm2WnbdDVpesCzcBB327g3/szjynbzVUe3IB/NYbLIgMTqhZ/BStKAqFj3O4KtiHrQUZSOkLZuK3pjaqrbD+FTlmFk0wKVa/uRVeMROSFrcyB7xx0sGxy+CpFWyJze8zasF54S1Ukk+mqx5H3/c9A4N54TDNepj6VYw7ogBezgt/d1eIe1PmbwfYfY9dUWWfLJVB+qpv6AEPp11nZYFDWZIzmcU6UaE4toGl+D8FAxTfAYcJWlwduOBi42sPk74k4GQs=
Content-ID: <1AEDECB4A05F584483A830FCEEC1F755@eurprd07.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: 5e007613-c746-4eb5-6598-08d69bcb2baf
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2019 09:17:03.1574 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5473
X-MC-Unique: FKS8RVzXMMqj9vQ_7XIlLg-2
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset="WINDOWS-1252"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/wHOrqzEWeTcipmE6-1TfJIKaDmw>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Feb 2019 09:17:15 -0000

> On 25 Feb 2019, at 18:36, Fernando Gont <fgont@si6networks.com> wrote:
> 
> On 25/2/19 07:32, Richard Patterson wrote:
>> On Sat, 23 Feb 2019 at 05:22, Fernando Gont <fernando@gont.com.ar> wrote:
>> 
>>> * As per RFC4862, it turns out that you cannot remove a stale prefix vy
>>> sending an RA wiht a "Prefix Lifetime" of 0. SO, with current standards,
>>> not even the CPEs can (even if they wanted to) do something to fix the
>>> problem.
>> 
>> The Valid Lifetime cannot be zeroed or shortened below 2 hours, but
>> the Preferred Lifetime can.  So we can't invalidate the prefix, but we
>> can deprecate it so it's not used for new outbound sessions.   This is
>> what we've implemented in our CPEs, after an unavoidable change in
>> prefix, and it seems to have mitigated (or reduced the impact of) the
>> issue.
> 
> Agreed. That said, with the current default lifetime values, things
> become tricky:
> At least in theory, you should be sending such RAs for "Valid Lifetime"
> seconds. With a default of one month, that means that, in theory, you
> should be sending such RAs for a month. And if there are multiple
> crash-and-reboot events, you should advertise each of the stale
> prefixes. (I assume the CPE just records the last one)

When / where was the default Valid Lifetime chosen to be one month?

Tim

> -- 
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

v2.23.0 | Report a Bug | By Email