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

"Bernie Volz (volz)" <volz@cisco.com> Wed, 30 October 2019 21:01 UTC

Return-Path: <volz@cisco.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBBC6120924; Wed, 30 Oct 2019 14:01:54 -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=QKbPAFhB; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=cmL076Xe
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 OUjKbfh_4m36; Wed, 30 Oct 2019 14:01:51 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9006120AA9; Wed, 30 Oct 2019 14:01:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14152; q=dns/txt; s=iport; t=1572469310; x=1573678910; h=from:to:cc:subject:date:message-id:mime-version; bh=6Fx5o1rkgKrvfNEdNeg90d2cBV6nOQOHbeiyQmgt29s=; b=QKbPAFhBgSKgfcDyg89MJD6mmd/741HGicGxOB+PfbDqBzcl7VqxZ8ER 7mNT53gpw2SfayRMoBChUNju4W2jCMUEKOn1cTlNbOrRtwVez8/4E+LNO rJRDqgi8pfrJWW1QtSFuu/NWXecBZ+oBYSQPPhHFRtC+bchfu262jRsqL k=;
IronPort-PHdr: 9a23:smpUcRFEeQnRi2udAKIP7Z1GYnJ96bzpIg4Y7IYmgLtSc6Oluo7vJ1Hb+e4w0Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0ETBoZkYMTlg0kDtSCDBjlK/r4Ryc7B89FElRi+iLzPA==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CoAQCF+bld/5ldJa1lHAEBAQEBBwEBEQEEBAEBgWwEAQELAYEbLyknBWxYIAQLKgqHZAOKc5VohGGCUgNUCQEBAQwBASUIAgEBhEACg2YkNwYOAgMJAQEEAQEBAgEFBG2FNwELhVQWGxMBASwLAREBgQAmAQQODRqDAYF5TQMuAQ6oEQKBOIhggieCfgEBBYE0AYNhGIIXAwaBNgGFF4Z5GIF/gRBHgwqCYgEBAgGBQgYCFiuDFYIsjHMYCA2IGYI5lgAKgiSGLGSOPJlehFeGE4NWiCyMKYR5AgQCBAUCDgEBBYFoI4FYcBU7gjgBM1AQFIMGgScBCYJChRSFP3QBgSeLBoEwAS9eAQE
X-IronPort-AV: E=Sophos;i="5.68,248,1569283200"; d="scan'208,217";a="649800280"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Oct 2019 21:01:49 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x9UL1nhl001811 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 30 Oct 2019 21:01:49 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 30 Oct 2019 16:01:49 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 30 Oct 2019 16:01:48 -0500
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 30 Oct 2019 16:01:48 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J5zrUeZKLtthddbh00k4u8dFO8HHrcwrLtj2GshYp4J/qNAy3aunOpjYT4TyjJibGKmUvFIQ0q/UQlZ9etrvuK2wcYNbc/IGrOSGf3qpeLV6PV9+2ZAPADLqOoWJnKP23ULmJb2pLhHclhjmjYF8TMchzDp/fC7KIHbYwlGeN9UudSWZnzkUUm53HMlkLS0HeTlVevgq/X0gjH4Uzw2Zqgu2ALDUmu6cityPferD1Tk20jlgqKTm9duM3Wn5pvX8FLMJYO2a1oulJWFgzD2lLCWSwaK6GdgreoeKlkTEzT9Wi+bYW5yMT/a6ddIGjOewTshtszyKCJZj/wlK++Sm8g==
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=rJWnB6v6t3gj3B/qSC+h55SNs448PlyR7taZdwQqngU=; b=ku83MK4ln6aT8LfoQS/GcypHkRkHQ3Jykk2/D6MbrwZrerftneSyQzc8/SnxQPj5bGFnb8tWkk9msyZvPRe7QVz18Qv+1X3Ww2uzAFbUS6QOnQSgPgd9Ecvcyg/+RJPAvWQOrlpOZOt9uhWV45fBpmZ5RzQP5jNUj4vYcOsalld5gsrP6sHzJKyI76dC2KcjJpMerdmk0tyKSAw5wboESAzKUFKDJROwS/XEtO6Tt0fCG4UsSkzyW9YcjTAPBFAjgiFwPxN220LPxrIIilirrG1hiShh213NwkZFONnFS8qaFDyQbIKWvHyAz82Eo5Pcx9PbZNf5Z+diSeAE/Fpv3w==
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=rJWnB6v6t3gj3B/qSC+h55SNs448PlyR7taZdwQqngU=; b=cmL076XeXs2875dv0i6infuV7p+SgaqdjFE8nV3WwsO5PbxMpHyHk9aCucM1TNsoto2vdxLev+WEWih7zNIkQVU21ZFxvrAJQqIRX9/RFBenyWqFf6rpnd9A0L+8t1mH+9fwa5apxu+XSaMLl5RtJpcR3UBhpgmGfYAPzN76aWI=
Received: from MWHPR1101MB2288.namprd11.prod.outlook.com (10.174.97.139) by MWHPR1101MB2093.namprd11.prod.outlook.com (10.174.96.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.24; Wed, 30 Oct 2019 21:01:47 +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.028; Wed, 30 Oct 2019 21:01:47 +0000
From: "Bernie Volz (volz)" <volz@cisco.com>
To: "dhcwg@ietf.org" <dhcwg@ietf.org>
CC: IPv6 Operations <v6ops@ietf.org>
Thread-Topic: [v6ops] SLAAC renum: Problem Statement & Operational workarounds
Thread-Index: AdWPYMgWrzinXIUuTM2kZJk2AWui+g==
Date: Wed, 30 Oct 2019 21:01:47 +0000
Message-ID: <MWHPR1101MB2288616D545F3DAD1D1734A1CF600@MWHPR1101MB2288.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=volz@cisco.com;
x-originating-ip: [173.38.117.77]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 32b7b826-2cbc-41ec-ff27-08d75d7c60b2
x-ms-traffictypediagnostic: MWHPR1101MB2093:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <MWHPR1101MB20935E592CE21D392B0BA57ACF600@MWHPR1101MB2093.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02065A9E77
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(136003)(366004)(396003)(39860400002)(189003)(199004)(606006)(450100002)(71190400001)(71200400001)(2501003)(256004)(102836004)(14444005)(476003)(25786009)(33656002)(2351001)(486006)(14454004)(186003)(26005)(6436002)(2906002)(76116006)(66556008)(66476007)(66946007)(52536014)(316002)(74316002)(5660300002)(4326008)(66066001)(5640700003)(478600001)(64756008)(966005)(9686003)(6306002)(55016002)(236005)(54896002)(8676002)(86362001)(6116002)(6916009)(81156014)(7696005)(81166006)(3846002)(99286004)(790700001)(1730700003)(6506007)(66446008)(8936002)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR1101MB2093; H:MWHPR1101MB2288.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: 2OD8DBY5Fq6gK9aCzEAo/mNClgY2Hts82ROyligLjtvEHLxya7ag0P7yoeAmIlkPwPeGVaeFPOPJxl5om3gEb9S9VEzTfBvpVqDmDex/rHO7lN/r0ya+tBX7ORv01QNOR3rA0yoElu8mPSr1J+TAAp107jV6PemvS08aggOCDiQ3+bWsW+pNYanjBVt6rsQh8eyg+B83CBbDmELhb9QqwMx/m3Q6Gl6hQK/+bATuSYoQQVKs9l/0T5N/miR1XN20i1cRxt9Og0EdGALABDWUwD2jz/whRwJmXrK1iGOt+MEXVgl3/YNZK2TZBRzz26kOAvVMnN0h1qsJeo4dCgz3SIYIXv9qT4L+joL30EhnLSnwjmhDKHp7a5pd2/xrpZT5xcehO4prqZPloKzmjupFUNxWV3zbYgbtoox15gM3NENZG2x/XouUjO7nWEKj+1Iy98vdyNE6UkpOe4I+lp0LOkSaT1/ZTvYO0p/l0pdMPtE=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MWHPR1101MB2288616D545F3DAD1D1734A1CF600MWHPR1101MB2288_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 32b7b826-2cbc-41ec-ff27-08d75d7c60b2
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2019 21:01:47.4696 (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: 8+nP9l6iUwWj7RjIzsz079lxcUEjdzdADWFrfdLlE/nQlu4zJsSyfA1ejEv8xDwY
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2093
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/C3KYvuEztUCzqaNGoTlSZBd01Nw>
Subject: [dhcwg] [v6ops] SLAAC renum: Problem Statement & Operational workarounds
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Oct 2019 21:01:55 -0000

Hello:

DHC folks may want to check out the recent discussion on the v6ops mailing list (https://mailarchive.ietf.org/arch/browse/v6ops/) with the "SLAAC renum: Problem Statement & Operational workarounds" subject.

Basically, one issue that appears to happen in networks where CPEs receive delegated prefixes and are renumbered when a CPE cycles power - why the renumbering occurs is not material. The issue is that some of the devices serviced by the CPE may still have configuration (i.e., from Prefix Information Options received via RAs or perhaps even DHCP) based on the original delegated prefix and if the CPE does not have stable storage (into which it stored the old delegated prefix), nothing initiates deprecating this information. This is because everyone is honoring the lifetimes, but the renumbering caused the SP DHCP server to provide a totally new delegated prefix and there's no record in the CPE of the old.

For a CPE that has stable storage, it could initiate steps to deprecate the old delegated prefix.

Note that this issue is discussed in https://tools.ietf.org/html/draft-fkhp-dhc-dhcpv6-pd-relay-requirements-00#section-3.2 and also in section 4.3 (S-1) of that draft.

One idea that I suggested is that the SP DHCP server can provide this information to the CPE. The DHCP server should still have a record of the previous delegated prefix (as it has not yet expired for the binding) and it could therefore send this, with 0 lifetimes, in the Reply to the Request (as it would do in a Renew). This would avoid the need for the CPE to keep this information in stable storage.

There isn't any direct mention of sending IA_PD (or IA_NA) with 0 lifetimes in the processing of Requests, but it isn't a stretch to consider this. And, without something, it isn't obvious that servers should (or would) do this?

Some possibilities are (from least conservative to most):

  1.  Always have the server do this (sending 0 lifetimes) for a Reply to a Request for this condition.
  2.  (1) but only for Relayed messages.
  3.  Have a server configuration knob (at whatever granularities desired - global, prefix, client, ...).
  4.  Define a new option that a client would include in (Solicit/)Request to request this behavior. Note that (3) could always override.

Hopefully existing clients would handle this correctly, though they likely would not take the action to deprecate the old delegated prefix. But we don't know (and at least early in the DHCPv6 days, clients weren't always happy when they received multiple delegated prefixes). Hence, how conservative should we be?

Perhaps we can discuss as part of draft-fkhp-dhc-dhcpv6-pd-relay-requirements (which is on the agenda for IETF-106), or I could request a separate slot for it - if we need a higher bandwidth discussion.

We can also just discuss here on the mailing list as it may be possible to resolve fairly quickly.

It will require a short draft as it is something that would need to be folded into a RFC8415 bis or continue on it own. Probably adding it to draft-fkhp-dhc-dhcpv6-pd-relay-requirements is not best since these are the delegating relay, not server, requirements.


  *   Bernie