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

"Bernie Volz (volz)" <volz@cisco.com> Sun, 27 October 2019 22:04 UTC

Return-Path: <volz@cisco.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 9F8E71200DE for <v6ops@ietfa.amsl.com>; Sun, 27 Oct 2019 15:04:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=J/5htI57; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=0NxbeSYq
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 i-PXNgUWB3pt for <v6ops@ietfa.amsl.com>; Sun, 27 Oct 2019 15:03:58 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB139120046 for <v6ops@ietf.org>; Sun, 27 Oct 2019 15:03:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22161; q=dns/txt; s=iport; t=1572213838; x=1573423438; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TWH/Z9Sg3on3cw/jsTDYdgV7v90vhIEnVGBkbz2OvA8=; b=J/5htI57fqA3Y/Q7Pa0uFwrdHVpMCutG2DuS5HQC/iKpuytgefO/Hf99 Pknhi+bqKLcw/iew/FgusYfsjO1VJ6zgCZQAcK8YSlYlM0SsmVngjU/4k 2F76iX6sq+IXFaARcW1DZXCV/sVb5xAZiElgwC9SQ/cHvdNOOsGQ6kzHb 4=;
IronPort-PHdr: =?us-ascii?q?9a23=3A/+/UcRNQathqC7Sq2cYl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEuKg/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQF0r/PtbhbjcxG4JJU1o2t3w=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALAAACE7Zd/5FdJa1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBEQEBAQEBAQEBAQEBgWgDAQEBAQELAYEbLyQFJwVsVyAECyo?= =?us-ascii?q?KhB6DRwOKbYJef5ILhGGBLoEkA1QJAQEBDAEBLQIBAYRAAheDKCQ1CA4CAwk?= =?us-ascii?q?BAQQBAQECAQUEbYU3DIVQAQEBAQMSER0BATcBDwIBCBEDAQIoAwICAjAUCQg?= =?us-ascii?q?CBAENBSKDAAGBeU0DLgGkGAKBOIhhdYEygn4BAQWCSYJDGIIXCYE2AYwOGIF?= =?us-ascii?q?/gREnH4IXNT6EHgsGAjQWglqCXo0QMoI3hTyJNI8DCoIklS4bmVqEVoYTg1a?= =?us-ascii?q?ZTgIEAgQFAg4BAQWBUwE3gVhwFWUBgkFQEBSDBoEnAQKCSYpTdIEpjFYBJYE?= =?us-ascii?q?LAYEpAQE?=
X-IronPort-AV: E=Sophos;i="5.68,237,1569283200"; d="scan'208,217";a="366506637"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Oct 2019 22:03:57 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x9RM3voB008030 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 27 Oct 2019 22:03:57 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 27 Oct 2019 17:03:56 -0500
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 27 Oct 2019 18:03:55 -0400
Received: from NAM02-CY1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 27 Oct 2019 18:03:55 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=F4NPn7B+KLepZckJnQq+F0mz0sbBXOgb6Ujf8GjYvNfoZAdroHQV/mrjSYoYBJEw7w7tAwOaWV6fHx8nsH50e95jA2VM81jgS5R3IYLTMRMlN7emTCZWT5ESet8v+bsW/ccxbFF8bw44veEwDv9VO/oNt6gp2Ldi302vUA3KNUp4UbQXfKlm5aIW0zoIGj0x34p0Bf01quOqVqe8IASkwJeZae8zXL3S1LT4hst/1Raq5RfeRUZRb3hTJ//4CJmcHvtQt3msMilNmVeGBrZBtGtvKfqY5ZqGop9/LpT0pqiIXVOvzvNvTxBeMo0Zn/XfoDaF9oBGaBa7qQStMecTZg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TWH/Z9Sg3on3cw/jsTDYdgV7v90vhIEnVGBkbz2OvA8=; b=g0kASYl5VH5/H7f/EMOguy8aQQlpobHMx2FNa0/U0Lb/qLcail7VVGrjCUQzLSeZE6lsC1LdcZEFUPWwZwnizxnEyC2nxy/5Qh+3UMxbtV+z1Ji7l53AOaUN0PSOiSITCLMCAF81jUw6UBog30BELSpKFS91CcTtKtANvY3dKPe+GWB9PPFBFqHU48st/yRm9wqGlBlOH3sdnXSXNEGAHtMtJdLHbhvYjthu1g1xdWZ+CXAIpKzgJcFSjndZsLkp6GlDB0ol/0VpJj8evE64ogxhkSE6ytJsDDUplhg/P1aTZyfelAmlqgjYffE3NOSIF5bgmcWyRTmGCsoR253jXw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TWH/Z9Sg3on3cw/jsTDYdgV7v90vhIEnVGBkbz2OvA8=; b=0NxbeSYqz2B8jM+HMaHbbIHKYzIoXvMlEJVjvbcDHx7N5fP16Sf+XkxpOEI9ahN/1CHX/huV+f7s7iW4V7IZnXxVetaMxv0hvjnpwfYKWZ2/nLTuk02XrwCxqD2fvD+eDRLz+EXsIJZyffP0JMnxWcf1wkFOS/UcF2rOP3aPZYI=
Received: from MWHPR1101MB2288.namprd11.prod.outlook.com (10.174.97.139) by MWHPR1101MB2319.namprd11.prod.outlook.com (10.174.97.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.24; Sun, 27 Oct 2019 22:03:53 +0000
Received: from MWHPR1101MB2288.namprd11.prod.outlook.com ([fe80::808:4d44:a5d1:c7f6]) by MWHPR1101MB2288.namprd11.prod.outlook.com ([fe80::808:4d44:a5d1:c7f6%11]) with mapi id 15.20.2387.025; Sun, 27 Oct 2019 22:03:53 +0000
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Owen DeLong <owen@delong.com>, Ted Lemon <mellon@fugue.com>
CC: "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: [v6ops] SLAAC renum: Problem Statement & Operational workarounds
Thread-Index: AQHVibwc6PRwlsH+ZUmOeFzp+XKiI6dt8FJugAA0sICAAERiAIAACLmAgAATKlOAAANjAIAAXboA///n6oA=
Date: Sun, 27 Oct 2019 22:03:53 +0000
Message-ID: <74875D36-6A96-4FB2-853F-86875833470D@cisco.com>
References: <CAO42Z2yQ_6PT3nQrXGD-mKO1bjsW6V3jZ_2kNGC2x586EMiNZg@mail.gmail.com> <B53CE471-C6E8-4DC1-8A72-C6E23154544F@fugue.com> <e67f597d-93a7-3882-3a12-69519178893d@foobar.org> <m1iOinq-0000J3C@stereo.hq.phicoh.net> <DC2F31E2-8CA4-483A-B1A1-6730A904BA32@fugue.com> <A96A5C76-93AE-40E4-BA52-776F9277C382@delong.com>
In-Reply-To: <A96A5C76-93AE-40E4-BA52-776F9277C382@delong.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1e.0.191013
authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com;
x-originating-ip: [173.38.117.91]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0a3224ee-dd43-47b8-86a0-08d75b298e50
x-ms-traffictypediagnostic: MWHPR1101MB2319:
x-microsoft-antispam-prvs: <MWHPR1101MB2319A3E95D5F381ECAF730D9CF670@MWHPR1101MB2319.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0203C93D51
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(39860400002)(376002)(396003)(136003)(346002)(199004)(189003)(51444003)(316002)(26005)(3846002)(6116002)(71200400001)(71190400001)(7736002)(14454004)(86362001)(36756003)(66574012)(4326008)(6306002)(486006)(446003)(76176011)(6512007)(561944003)(236005)(54896002)(11346002)(2616005)(99286004)(91956017)(186003)(2906002)(6246003)(58126008)(110136005)(66946007)(64756008)(66446008)(66476007)(66556008)(81166006)(8936002)(476003)(8676002)(81156014)(478600001)(256004)(14444005)(5024004)(25786009)(229853002)(6486002)(76116006)(33656002)(102836004)(5660300002)(66066001)(6506007)(53546011)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR1101MB2319; H:MWHPR1101MB2288.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: QTTk1xRASqYC9am/+iZHYzL+sVebikBrcqYY7cK0YEQIPuYkhZTmH+J5mkj71LbQlFTdWfem3PjaGsebc+yX3mwP946C81ug3MmQjb1I66bupeXWh/nJCsblbmhfmu+RQ2EFjL+0GhtRRWvhRHgXpueS9dU6bAvBIHBnsa8pGy6pL5xiMvfWQeq0BOKWSZ8fpV77BE4Uo6wwyjNJYQ7psO4GhzDmcweO6CfZaaFJSofOM8JZx/BRic7L39BmTwF+pd4s3nJYdcF6n7Xqcdfw+lJu7klqGP03c6DpbWsFZY8gqgEfYp2Y6Aub3j5v6HGIBniOrYuJJpRrLPBDpBiULSafidiS+JRAr3fr54dfaOJ+SXq1mCu8eelkn0SGK7XUtCIUy2AVZKvTNalbpVD4dNFhU+7Hbg88mJVQCDwVeIZi6+kn1LiCvdTdM/yB6+NG
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_74875D366A964FB2853F86875833470Dciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0a3224ee-dd43-47b8-86a0-08d75b298e50
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2019 22:03:53.4453 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: bHCZ30WiiyxVK1P4x4nBKbjPKHCEnnNTQPPlpvteH/x1yB8/fHpfgfjw7Z0HYbcX
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2319
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: rcdn-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/7VGE_-S1ZV5WU9rVd3nUADQK2hs>
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: Sun, 27 Oct 2019 22:04:02 -0000

>I don’t know of a single DHCPv6 server which operates that way currently. Can you point to a working example?

That is actually the RFC8415 specified behavior … the DHCP server I work on (Cisco Prime Network Registrar) will do this if steps are taken to “invalidate” a lease.

See RFC 8415, Section 18.3.4:

   If the server finds that any of the addresses in the IA are not
   appropriate for the link to which the client is attached, the server
   returns the address to the client with lifetimes of 0.

   If the server finds that any of the delegated prefixes in the IA are
   not appropriate for the link to which the client is attached, the
   server returns the delegated prefix to the client with lifetimes
   of 0.


  *   Bernie

From: v6ops <v6ops-bounces@ietf.org> on behalf of Owen DeLong <owen@delong.com>
Date: Sunday, October 27, 2019 at 4:18 PM
To: Ted Lemon <mellon@fugue.com>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds




On Oct 27, 2019, at 06:54 , Ted Lemon <mellon@fugue.com<mailto:mellon@fugue.com>> wrote:

On Oct 27, 2019, at 9:41 AM, Philip Homburg <pch-v6ops-9@u-1.phicoh.com<mailto:pch-v6ops-9@u-1.phicoh.com>> wrote:
The little bit missing is that the CPE should write prefixes advertised using
SLAAC to persistent storage which allows the CPE to invalidate stale prefixes
after a reboot.

Actually I do not believe this is correct behavior.   Let us assume prefix delegation.   If we have prefix delegation, then when the CPE comes back from a power cycle, it should reconfirm the prefix it had previously; the assumption is that that prefix is still valid.  This can be handled in infrastructure—the ISP edge router should know whether the prefix is still valid, because if it is it should be advertising a route for it.   If it is not still valid, then the CPE router should attempt to renew it, which would go to the DHCP server (possibly both messages would).  If the lease on the address is still valid, the ISP should renew the lease and not issue a new one.   It is a misconfiguration for some other thing to happen in this case.   This would then re-establish the route in the ISP edge router.

So this still requires that the CPE has written the lease to persistent storage. Currently many CPE do not do this.

I agree that the CPE should attempt to reconfirm/renew the existing prefix lease. However, if that fails for some reason (and there are multiple scenarios which present valid reasons this could fail without misconfiguration on either side), I think that the behavior described is preferable to simply removing the old prefix from RAs and waiting for them to time out on the unsuspecting hosts. Especially in the case of 1 week preferred and 1 month valid lifetime timers.

If the ISP wants to deprecate the old prefix, the thing to do is not to fail to renew it, but rather to renew it with a preferred lifetime of zero and offer another prefix with a preferred lifetime that is not zero.   The CPE router should in this case advertise both prefixes, with the applicable lifetimes.  Using my limited SEND proposal, the advertisement with a preferred lifetime of zero would be immediately seen by all hosts that implement limited SEND, and they would start using the new preferred prefix.  Hosts that don’t implement limited SEND would still behave correctly, but might take longer to stop using the old prefix.  This should be okay because the old valid lifetime is still valid.

Can you point to any authoritative document which supports this particular mechanism?

I don’t know of a single DHCPv6 server which operates that way currently. Can you point to a working example?

That’s the way things should go when everything is working correctly.   If however the ISP’s DHCP server loses its cookies and can’t renew the old prefix, then we’d see the new behavior where hosts that implement limited SEND could immediately see that the old prefix was no longer usable, and would stop using it in preference to the new prefix.   Hosts that don’t implement limited SEND would behave as they behave today.

While there may be advantages to limited SEND, I don’t see that as a reason not to implement this particular fix across the board since it would benefit both hosts implementing limited SEND as well as hosts not implementing it.

Owen