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

"Bernie Volz (volz)" <volz@cisco.com> Fri, 01 November 2019 20:46 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 5C765120013 for <v6ops@ietfa.amsl.com>; Fri, 1 Nov 2019 13:46:03 -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=AJwewRPM; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=NT3Noa/C
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 tNoXy-RpR3Mh for <v6ops@ietfa.amsl.com>; Fri, 1 Nov 2019 13:45:58 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A04212000F for <v6ops@ietf.org>; Fri, 1 Nov 2019 13:44:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7402; q=dns/txt; s=iport; t=1572641082; x=1573850682; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=w44YPXcdDSuTRBwRmUjRH3yW4ItvWGJSWtnZP2JT28U=; b=AJwewRPM/7MI2UWjKwtZh/pseMdsVRdY2cSIySIeH6osb5Iz8sVu0myK xa3tZ1BkBFFPsSs+0W3Kt96aDFqZtIvvPukRUKbloJVxnzUbhm/cAORui kLN9TtCTcYQ+RvAK+qpixc+5DFo1/zF57Q4LJqxozCyyXqRbAYATyC2op M=;
IronPort-PHdr: =?us-ascii?q?9a23=3AIqPq+B3/9kg4rx1fsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxGCt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8TgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdCCDV/TJ//xZCt8F8NHBxdo?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAADWl7xd/4ENJK1lGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYFsAgEBAQELAYFKJAUnBWxYIAQLKgqEHoNGA4p?= =?us-ascii?q?1gl5/ln2CUgNUCQEBAQwBARgLCgIBAYRAAheDZCQ3Bg4CAwsBAQQBAQECAQU?= =?us-ascii?q?EbYU3DIVRAQEBAQIBAQEQEREMAQEsCwEEBwQCAQgRBAEBAQICIwMCAgIlCxQ?= =?us-ascii?q?BCAgCBA4FCBqDAYJGAw4gAQ6oBgKBOIhgdYEygn4BAQWBNAGDYxiCFwMGgQ4?= =?us-ascii?q?oAYwQGIF/gRFGghc1PoJiAQECAYFCBgIWFRWCZDKCLI0LCYJph3eWAgqCJIc?= =?us-ascii?q?RhR6JIZllhFeGE4wEkSYCBAIEBQIOAQEFgWgjgVhwFTuCbFARFIMGDBeBBAE?= =?us-ascii?q?CgkmFFIU/dAEBgSaLBoEwAS9eAQE?=
X-IronPort-AV: E=Sophos;i="5.68,256,1569283200"; d="scan'208";a="363419201"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Nov 2019 20:44:41 +0000
Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id xA1KifDb008634 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Nov 2019 20:44:41 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 1 Nov 2019 15:44:40 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 1 Nov 2019 16:44:40 -0400
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 1 Nov 2019 15:44:39 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VZ9VFtmFSgM5jJ7viwTo6R1bJa38Kch6OxAKW+4LFfJ5CLtTqXR+OObl+fruTWKjwDGQSVxU4S40grWE6A5IuHPyAUfWj2ymCA/SwocAp+fgDCQtNCwg6QWOwyvKthhMtOYPMQn17qv5GAQp121zQ37fvmBpKISyMgTwJ2dW5UBVNbhUqCnX3B2UGhZz6j5Yo/kKtcFKzMURVIn7uYIJ/9bEcpnHIHaDp0Fy11T6MqryG9kkrzzbQ4t1YkktdOnWL3zQCcMQ6SA7iJfpOqe6UENqZop6KeF/FrozWKFPoSIvDPCRtltV4CvkJgxikWvY6M6ht3zySZJkGfU4n1NIPQ==
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=w44YPXcdDSuTRBwRmUjRH3yW4ItvWGJSWtnZP2JT28U=; b=OLtKUom8IPXjTPxYTyn933PpsDFAEBQ3f+HKDbDWNMAXrJ/5ksYzUq+8K8mY75Sw1REF1JNaGuth1zzK2Omq4/qAEjvdgY3tPgcpV2hGegSjxIMNuVuFutp34Ogx40cWyqh3FQex5iwO5a2IusryWF65bFvk4pKX5OQHq2WVVQi4FcZRigtGV5UBOC7M3p0lYzyf5TA9vhQY+HyqC1ACaJxT8SoaYqni/OImag8bk/uv4aJVxKihiBbJ8NK/roEXTKzFmOvCbm4Asx2qh68zId/DY9E8KJMFdbt5YM/Z283YD41kXUfxDB2XWOuhjEnKDK2yGBRF7kEOOjAtoqUDxg==
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=w44YPXcdDSuTRBwRmUjRH3yW4ItvWGJSWtnZP2JT28U=; b=NT3Noa/C9DjjNDVfBrDj7d1R0FCVCWoWngOVupxI/EuT1VmmSpy1BMY+iOAtYMWg/Sb9A1N3CEIL7UC2mXFEfy/pWsSfScX+yCDQQQrvoJyh1Ol7qps/Polfy6UzpQuw4cazdw6AbdBqbgqduTn/gV6Cy9P2J40cQX/yAwURvCo=
Received: from CY4PR1101MB2279.namprd11.prod.outlook.com (10.172.75.137) by CY4PR1101MB2328.namprd11.prod.outlook.com (10.173.191.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.22; Fri, 1 Nov 2019 20:44:38 +0000
Received: from CY4PR1101MB2279.namprd11.prod.outlook.com ([fe80::81f5:2724:385e:dbab]) by CY4PR1101MB2279.namprd11.prod.outlook.com ([fe80::81f5:2724:385e:dbab%10]) with mapi id 15.20.2387.030; Fri, 1 Nov 2019 20:44:38 +0000
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Owen DeLong <owen@delong.com>
CC: Fernando Gont <fgont@si6networks.com>, "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: [v6ops] SLAAC renum: Problem Statement & Operational workarounds
Thread-Index: AQHVibwc6PRwlsH+ZUmOeFzp+XKiI6dt8FJugAA0sICAAERiAIAACLmAgAATKlOAAANjAIAGpb+AgAAD94CAAHz9AIAA0laA///HGgCAAGQlAIAAKLqw
Date: Fri, 1 Nov 2019 20:44:37 +0000
Message-ID: <CY4PR1101MB2279A17EC40534E2AABBF9B0CF620@CY4PR1101MB2279.namprd11.prod.outlook.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> <c06adfb0-1bab-d177-96e4-d1263e618000@si6networks.com> <E9C816FC-57A7-49A9-A4E3-90A3E2F38D5D@delong.com> <8f46bb68-1713-8c68-96b1-c46cf2003325@si6networks.com> <071E7287-74DD-44B9-9917-5231652F9E3D@delong.com> <B1BF35FC-852E-43C7-847D-7C62C7418E6E@cisco.com> <020501A3-CF94-474A-8763-1DC9E111B865@delong.com>
In-Reply-To: <020501A3-CF94-474A-8763-1DC9E111B865@delong.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.85]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 54ac4ef0-3a57-46dc-ae6a-08d75f0c4ffc
x-ms-traffictypediagnostic: CY4PR1101MB2328:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <CY4PR1101MB23286399C4AD92D9333BF7F9CF620@CY4PR1101MB2328.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 020877E0CB
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(39860400002)(396003)(376002)(366004)(189003)(13464003)(199004)(6436002)(2906002)(66574012)(66446008)(5660300002)(14454004)(71200400001)(25786009)(66556008)(6116002)(86362001)(64756008)(71190400001)(6916009)(3846002)(6246003)(26005)(7696005)(4326008)(66476007)(102836004)(33656002)(76176011)(316002)(446003)(256004)(6306002)(7736002)(11346002)(186003)(74316002)(53546011)(476003)(305945005)(6506007)(229853002)(55016002)(9686003)(478600001)(966005)(5024004)(76116006)(54906003)(81156014)(8676002)(486006)(66066001)(8936002)(66946007)(52536014)(14444005)(99286004)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1101MB2328; H:CY4PR1101MB2279.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: lhpYVnQ9VO6k4V179LGT7fcWHb5KoTq2i4ShTx8Nyh2fDFd8OFDIJHLqy9xzBSXHoV7E5Kdo/Bmgf1dcZ97j4x82ziGNx7SG2OtZ1Pn5oFBERFzr97lk4HhhUVFLsLYpOf+zyvc4oUEpKdsn5T0q9q/q7Zm2UZjf66hXUYz+acoDe8OQQ51lXE3S1murRBLdAga6p36I+3MRcMar4N5H0bYRDCjYbujdvhU02BUzwJRyIy/fnCqWTAvc4mczvsIQxqNtaCbbjI6tMvd6Wns7c79j5geJJKV4H52Ai9zNEu9qSuyP9tp+a7QyBRGZdleUwIt1DOJtzdVbQHUk7njdJiGebw/azoyFeDIkzgcpQ3uI8qVpE6QnLzNqwspZG9PKgbIeAZB9xiHtKVxAEW5s9tgskqrl70ylLqXgieSaZJTvJAvgQ5l0yuTy1hWanWZDHKeq3+u2S4DAUST2ExkoAHkPYJ0aOyl+Me0wJkDAqlE=
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: 54ac4ef0-3a57-46dc-ae6a-08d75f0c4ffc
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2019 20:44:38.0471 (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: A3Nb9593EwdQtPqhusig93WA8QdTWKqKa+BEgUVKMA8Mc1Vrnfkk8A4/ZpEy7zVt
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1101MB2328
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.28, xch-rcd-018.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/tZmmbDxMEZ4FQ7-z5141uG-ZdXw>
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: Fri, 01 Nov 2019 20:46:04 -0000

Owen .. this is IF the device remembers (i.e., writes the information to persistent storage).

> A rebind is not going to get useful timer data in response.

Yes, it should. This is because the CPE will include its existing (remembered) prefixes in the Rebind and the server that receives this can immediately respond with lifetimes of 0 if the PDs are no longer valid for where the CPE is "now" connected. Which is exactly what you wanted the device to know.

Here's text from https://tools.ietf.org/html/rfc8415#section-18.3.5:

   If the server finds that the client entry for the IA and any of the
   addresses or delegated prefixes are no longer appropriate for the
   link to which the client's interface is attached according to the
   server's explicit configuration information, the server returns those
   addresses or delegated prefixes to the client with lifetimes of 0.

- Bernie

-----Original Message-----
From: Owen DeLong <owen@delong.com> 
Sent: Friday, November 1, 2019 2:15 PM
To: Bernie Volz (volz) <volz@cisco.com>
Cc: Fernando Gont <fgont@si6networks.com>om>; v6ops@ietf.org
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

Rebind isn’t the same as remembering.

Consider the situation where a cable provider rehouse the customer to an entirely different CMTS which may utilize an entirely different DHCP server. A rebind is not going to get useful timer data in response.

Owen


> On Nov 1, 2019, at 9:16 AM, Bernie Volz (volz) <volz@cisco.com> wrote:
> 
>>   Where is the mention of storing the expiration times?
> 
> Also, based on RFC8415 this means that the client should use a DHCPv6 Rebind when it powers back on as now it has the information to ask whether it is still valid (assuming it hasn't expired)?
> 
> See Section 18.2.18 of RFC8415:
> 
>   Whenever a client may have moved to a new link, the
>   prefixes/addresses assigned to the interfaces on that link may no
>   longer be appropriate for the link to which the client is attached.
>   Examples of times when a client may have moved to a new link include
>   the following:
> 
>   -  The client reboots (and has stable storage and persistent DHCP
>      state).
> 
>   -  The client is reconnected to a link on which it has obtained
>      leases.
> 
>   -  The client returns from sleep mode.
> 
>   -  The client changes access points (e.g., if using Wi-Fi
>      technology).
> ...
> 
>   If the client has any valid delegated prefixes obtained from the DHCP
>   server, the client MUST initiate a Rebind/Reply message exchange as 
> ...
> 
> 
> - Bernie
> 
> On 11/1/19, 11:41 AM, "v6ops on behalf of Owen DeLong" <v6ops-bounces@ietf.org on behalf of owen@delong.com> wrote:
> 
> 
> 
>> On Oct 31, 2019, at 8:06 PM, Fernando Gont <fgont@si6networks.com> wrote:
>> 
>> On 31/10/19 16:39, Owen DeLong wrote:
>>> 
>>> 
>>>> On Oct 31, 2019, at 12:25 PM, Fernando Gont <fgont@si6networks.com> wrote:
>>>> 
>>>> On 27/10/19 10:54, Ted Lemon 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).
>>>> 
>>>> That assues the CPE has stored the previously-leased prefix on 
>>>> stable storage -- which does not need to be the case. Hence the 
>>>> related text in our I-D.
>>> 
>>> IMHO, the CPE requirements should be increased and the CPE should be 
>>> required to store the prefix and it’s expected valid and preferred 
>>> expiration times in persistent storage. I would like to see the text in the I-D updated accordingly.
>> 
>> It's already there (draft-gont-v6ops-slaac-renum-00):
>> 
>> 3.2.1.  Signaling Stale Configuration Information
>> 
>>  In order to phase-out stale configuration information:
>> 
>>  o  A CPE router sending RAs that advertise dynamically-learned
>>     prefixes (e.g. via DHCPv6-PD) on an interface MUST record, on
>>     stable storage, the list of prefixes being advertised on each
>>     network segment.
> 
>    Where is the mention of storing the expiration times?
> 
>    Did I miss it, or did you miss that part of my comment?
> 
>    Owen
> 
>> 
>> 
>> Thanks!
>> 
>> Cheers,
>> --
>> Fernando Gont
>> SI6 Networks
>> e-mail: fgont@si6networks.com
>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>> 
>> 
>> 
> 
>    _______________________________________________
>    v6ops mailing list
>    v6ops@ietf.org
>    https://www.ietf.org/mailman/listinfo/v6ops
> 
>