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

"Bernie Volz (volz)" <volz@cisco.com> Wed, 30 October 2019 22:16 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 5327B120829; Wed, 30 Oct 2019 15:16:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 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_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=eTI3Mv8f; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Xqp7uOtE
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 497IpJ4Z3guR; Wed, 30 Oct 2019 15:16:23 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB9AF12080C; Wed, 30 Oct 2019 15:16:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6894; q=dns/txt; s=iport; t=1572473782; x=1573683382; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=9X5dibBYs7cx54z46ziQ5JWqpm3N2qHZqIw7FLD87vA=; b=eTI3Mv8fh0LcAA+LdIgw6JF3PSBT1hvoF+8FTwQuxabSnVqWOkEbj6Lp +RIDlrlv2U9wb0VEJ5ng9dXkHBz85YpeVjhiurP1ExxLqZJTdSDiPk+M2 e9k/4g6WfMaZGYsstyWIFUX7oCVl6HS8Df3ilGxRtEqfXVCu4pfGU1QFj 0=;
IronPort-PHdr: =?us-ascii?q?9a23=3A0EcIfhIqxbI4023kEtmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeCuKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZubDknpBPXrdCc9Ws9FUQwt8g=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C/AADnCrpd/4sNJK1lGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYF9gUspJwVsUAggBAsqCoQeg0YDinOCXpdrglI?= =?us-ascii?q?DVAkBAQEMAQEYDQgCAQGEQAIXg08kOBMCAwkBAQQBAQECAQUEbYU3DIVRAQE?= =?us-ascii?q?BAQIBAQEQEREMAQEsCwEECwIBCBgCAiYCAgIlCxUQAQEEDgUbB4MAAYJGAw4?= =?us-ascii?q?gAQ6oBgKBOIhgdYEygn4BAQWBNAGBFIJPGIIXAwaBDiiFGIZ5GIF/gRAoH4J?= =?us-ascii?q?MPoJiAQECAYFCBgIUgxAygiyMcxgIGoJQh3WWAAqCJIcQjiEbgjyMCIsahFe?= =?us-ascii?q?GE4wCjCmEeQIEAgQFAg4BAQWBaSKBWHAVOyoBgg0BM1AQFIMGDBeBBAEJgkK?= =?us-ascii?q?FFIU/dAGBJ4sGgTABL14BAQ?=
X-IronPort-AV: E=Sophos;i="5.68,248,1569283200"; d="scan'208";a="656704178"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Oct 2019 22:16:21 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x9UMGLtq004834 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 30 Oct 2019 22:16:21 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 30 Oct 2019 17:16:21 -0500
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 30 Oct 2019 17:16:20 -0500
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 30 Oct 2019 17:16:20 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TSjXa+FSrHG+iXNGr4TxQd9CNXc4gOtabyyzslPw8uDfIFgA1mSV0E9bnOzlmIBNIn9ZFT29lrXFnMzCI96Ix33Z4y2VKQi3P2ZRMAlRYxiy3ToxIN4ne67Z1l0Tjb2L1FAnrrhJi3pzM2wTQqj6cPqjklBZXUw2TMa5POiOTRcCaCngHxdDSSxAKvb+uLUJWaEu1maN5RfotLX886jGkJQjczeS9dd2atCdqE2+AcdZns7Jk4fkHEHx3eGwCvb3ORI75DAvclc0VQGoUsb/1R3ixjURce/N9rf2ICK5yIiMJLjjTBitlxQijudIjG1gynciuZI0o2nmvQOV14EU8w==
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=9X5dibBYs7cx54z46ziQ5JWqpm3N2qHZqIw7FLD87vA=; b=M2dE5UL/ZM2/cNj5m4AJS5lHYw9Wn0xeU+DLKcRikWXqeV4VfXYsp+k/rBYHSsyhg4dInMpva1LgTdu+Dnj8NkdhT+ZEAmTKr5qd2/1lGfoC5Co2L/dxsvWECHLonrbbCDj6FG6omYR9CqjcoD2HcSmdrrBxyRVBfQPl+RigUzL3+MEbTglhRV5i08KZ/iZzJzD38zjCypYtajMnxtTOqfFxJBv7hIolnGBDvygsU3JATfNI11yUGUJKi/XNSarnpPxewoyfFBF9mDRF0N1a4mU2FtlhAztpTfy/tjTMRRqrecjdHNa+z306smrtN9Kj3eic467OHB8A5g1G5sPerA==
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=9X5dibBYs7cx54z46ziQ5JWqpm3N2qHZqIw7FLD87vA=; b=Xqp7uOtEZZV4FFzlc43SLjgiP+nTSnd4WyFikU3/egdObWoPhryLYQT/6s6kB0yJlpXmSuZWzxY0k5529xr7SfnHVPJ6oN1Crora5VUwj29+X2T1Y6oKmEr9eqCN2H7FFFfsFfV9qZkucsko430GH7VGMlEXB5OP1azJyybntGc=
Received: from MWHPR1101MB2288.namprd11.prod.outlook.com (10.174.97.139) by MWHPR1101MB2287.namprd11.prod.outlook.com (10.174.255.19) 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 22:16:18 +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 22:16:17 +0000
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Bud Millwood <budm@weird-solutions.com>
CC: "dhcwg@ietf.org" <dhcwg@ietf.org>, IPv6 Operations <v6ops@ietf.org>
Thread-Topic: [dhcwg] [v6ops] SLAAC renum: Problem Statement & Operational workarounds
Thread-Index: AdWPYMgWrzinXIUuTM2kZJk2AWui+gAC5zaAAADQaAY=
Date: Wed, 30 Oct 2019 22:16:17 +0000
Message-ID: <C0A66DA1-29DE-456A-934D-7ECC07575336@cisco.com>
References: <MWHPR1101MB2288616D545F3DAD1D1734A1CF600@MWHPR1101MB2288.namprd11.prod.outlook.com>, <CAOpJ=k06SRAHR7S+UmvFu=zvyk8j_uica2gdbBij+5pr+Jykww@mail.gmail.com>
In-Reply-To: <CAOpJ=k06SRAHR7S+UmvFu=zvyk8j_uica2gdbBij+5pr+Jykww@mail.gmail.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: [24.233.121.124]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c5c2c836-7ff6-480d-ed06-08d75d86c944
x-ms-traffictypediagnostic: MWHPR1101MB2287:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <MWHPR1101MB2287FFD5604EFBC1E4364A2ACF600@MWHPR1101MB2287.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02065A9E77
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(199004)(54094003)(189003)(54906003)(6116002)(33656002)(498600001)(99286004)(6436002)(71190400001)(71200400001)(229853002)(2906002)(14454004)(91956017)(3846002)(76116006)(66446008)(66946007)(6486002)(64756008)(66556008)(66476007)(966005)(6916009)(26005)(446003)(81156014)(6246003)(102836004)(2616005)(186003)(66066001)(81166006)(8676002)(256004)(25786009)(7736002)(305945005)(14444005)(76176011)(476003)(8936002)(486006)(6512007)(5660300002)(86362001)(6306002)(4326008)(53546011)(36756003)(11346002)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR1101MB2287; 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: oc5db4MNfqXc21qCOSQd5qnW6CPRZmJxqHA7bYY+atYWB+Wl5AgxpblLwTRVXhgPYd7JEUx8DqfPPrfImTaXw94V77xhS56VmzoWfk6Nl+yV38okLDzFNea7Mscei6T7+kzJu1y27+3Fq7idp0Dy4xvIsowawm0y4IJi5S3JZp0OFwfLA6FScA3rOPh7A7rVoupv4HolpKF1F9zkI7jDpMeF0KTmavlYfSS8saBvx3y7uQ7/FEgjRguRJkP3JnV+37oTa1Hb1Z6tzIfbcRHXMI4NQEzurwEevGeZYSvz+Q9CQxRqgZ+Zhr/4f0rn7a23HEvV+AUMupqNXLUWbLHRXtxFZpf3YMAKaO+VZmRLck8Uj4aJDYjASYiMwkFw8pyhAmjOpbCGP/rOcGPoF1XxwsQZ6rzxfeQjiZhvGrXbX5/mzO+XlVL9CSuk/aZ0Rk6pP05mAvK4h6y7fY7wLwjvTlH5WmHwjA8SeqHyvNm7ZFM=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: c5c2c836-7ff6-480d-ed06-08d75d86c944
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2019 22:16:17.8033 (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: CsiLxMDDh+SLeBBqoyGOzXfpidYlrP4GVZqDaNI6Q/zyCqrmJSjVicme5W8zF5on
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2287
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/MScaG-uej-LHzfdGlIXOudwOiBM>
Subject: Re: [v6ops] [dhcwg] 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: Wed, 30 Oct 2019 22:16:25 -0000

See Ted’s message ...

Regarding (3), I was thinking that you might configure it server wide to do this, but if you had specific broken clients, those could be excluded (perhaps based on a class, such as from a specific manufacturer, or by explicit duid). There’s probably never an issuing in providing configuration knobs ... most likely it is just the default behavior that is important.

I’m less inclined to break what is working, so I’d be a bit more cautious than Ted. Also, the “now” broken CPE will cause a customer service call and could be expensive to the SP. SP support teams also would likely need to know that they might see an increase in customer issues, which probably isn’t easy to know (how many people read release notes carefully)?

- Bernie

> On Oct 30, 2019, at 5:53 PM, Bud Millwood <budm@weird-solutions.com> wrote:
> 
> Hi Bernie:
> 
> If suggestion (1) or (2), an older CPE that borks over two delegated
> prefixes would stay borked until the old prefix expired. And it seems
> like suggestion (3) still runs the risk of catching that older CPE.
> Configuring that knob at the client level seems like a lot of
> management overhead.
> 
> I wonder if introducing suggestions (1) or (2) aren't pushing existing
> clients to expose new bugs they may have? Suggestion (4) seems
> reasonable to me.
> 
> - Bud
> 
> 
> 
> 
> 
> 
>> On Wed, Oct 30, 2019 at 10:02 PM Bernie Volz (volz) <volz@cisco.com> wrote:
>> 
>> 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):
>> 
>> Always have the server do this (sending 0 lifetimes) for a Reply to a Request for this condition.
>> (1) but only for Relayed messages.
>> Have a server configuration knob (at whatever granularities desired – global, prefix, client, …).
>> 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
>> 
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/dhcwg