Re: [v6ops] Flash renumbering

Vasilenko Eduard <vasilenko.eduard@huawei.com> Mon, 21 September 2020 15:24 UTC

Return-Path: <vasilenko.eduard@huawei.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 02A023A08C6 for <v6ops@ietfa.amsl.com>; Mon, 21 Sep 2020 08:24:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 dpveekIWmUrZ for <v6ops@ietfa.amsl.com>; Mon, 21 Sep 2020 08:24:11 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA7B3A08BB for <v6ops@ietf.org>; Mon, 21 Sep 2020 08:24:11 -0700 (PDT)
Received: from lhreml701-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id A7B438318B72145D0B52; Mon, 21 Sep 2020 16:24:09 +0100 (IST)
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 21 Sep 2020 16:24:09 +0100
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml703-chm.china.huawei.com (10.219.141.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 21 Sep 2020 18:24:08 +0300
Received: from msceml703-chm.china.huawei.com ([10.219.141.161]) by msceml703-chm.china.huawei.com ([10.219.141.161]) with mapi id 15.01.1913.007; Mon, 21 Sep 2020 18:24:08 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: Richard Patterson <richard@helix.net.nz>
CC: "v6ops@ietf.org" <v6ops@ietf.org>
Thread-Topic: [v6ops] Flash renumbering
Thread-Index: AdaLlIyewLCjExjqRk+nNQVH29wmCwAzUPGAABOUmgAAGqqFAAAbuXfAAAxRMoAADNTJAP//1BmA///IPECAAEoYgP/7tcFAgAiApID//6SnYA==
Date: Mon, 21 Sep 2020 15:24:08 +0000
Message-ID: <6f5fabd632fb4954adc13ea805be3c0b@huawei.com>
References: <8f964b8650cd4b619ff47aed5b07bc67@huawei.com> <7ef6cbcc-164f-383c-658b-b3c0df859535@go6.si> <1af87e24-1410-8f89-b50d-9c61694e4644@foobar.org> <f97b7ac2-0b36-2fae-58fd-eddee6f8b408@gmail.com> <76f10fa7030044c4a0b71443fde92f24@huawei.com> <CAHL_VyC7u7bNJD9pUzbFTrBtifbCVmQtPn4YHHs5g7T6omKwLQ@mail.gmail.com> <2e11a0315196499c81b72c171e014650@huawei.com> <EB3611C3-8849-4670-AFAD-4924AC79E26A@fugue.com> <93e01391b78b4c19be87f58f68281cbf@huawei.com> <CAHL_VyDhUO9mMTXEB1Z53-sA4KtHMu4-vdB0zb-oukanmEdARw@mail.gmail.com> <5b2f71a95a7944f0bcda368c11c6d7a2@huawei.com> <CAHL_VyDP-w9LzQTCkQM-tyjVo+T982aazFJTWeNPvGqHSHRtgQ@mail.gmail.com>
In-Reply-To: <CAHL_VyDP-w9LzQTCkQM-tyjVo+T982aazFJTWeNPvGqHSHRtgQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.197.29]
Content-Type: multipart/alternative; boundary="_000_6f5fabd632fb4954adc13ea805be3c0bhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/mPACpi3lvgS3UAQ7uY_5iRjB5iY>
Subject: Re: [v6ops] Flash renumbering
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: Mon, 21 Sep 2020 15:24:15 -0000

Hi Richard,
Thanks. You have pointed to interesting case. I have investigated.
Unfortunately, RFC 8028 (1st hop router selection) has not considered what to do when router is up, but all uplinks are down.

I have not found anywhere else the similar instructions for router (as discussed below for CPE requirements: router life 0, prefixes advertised). It is fully legal by ND, just not recommended anywhere as a general case.

But I have found that host should be ready:
RFC 6724 Default Address Selection for Internet Protocol Version 6 (IPv6)
5<https://tools.ietf.org/html/rfc6724#section-5>.  Source Address Selection
Rule 5: Prefer outgoing interface.
   If SA is assigned to the interface that will be used to send to D and SB is assigned to a different interface, then prefer SA.

Ed/
From: Richard Patterson [mailto:richard@helix.net.nz]
Sent: 21 сентября 2020 г. 15:51
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Flash renumbering

That is actually still just option a), and could result in packets being sourced from the wrong prefix in a multi-homed, multi-prefixed environment.

On Mon, 21 Sep 2020 at 12:05, Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>> wrote:
Hi Richard,
I have sent in reply to Fernando details: RFC 7084 has chosen different option:
d) continue sending old PIO, but inform hosts that this router is not default anymore
IMHO: it is right!


RFC 7084 Basic Requirements for IPv6 Customer Edge Routers

L-3:   An IPv6 CE router MUST advertise itself as a router for the  delegated prefix(es) (and ULA prefix if configured to provide ULA addressing) using the "Route Information Option" specified in Section 2.3 of [RFC4191].

This advertisement is independent of having or not having IPv6 connectivity on the WAN interface.

L-4:   An IPv6 CE router MUST NOT advertise itself as a default router with a Router Lifetime [RFC4861] greater than zero if it has no prefixes configured or delegated to it.
Eduard
From: Richard Patterson [mailto:richard@helix.net.nz<mailto:richard@helix.net.nz>]
Sent: 18 сентября 2020 г. 23:31
To: Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>>
Cc: v6ops@ietf.org<mailto:v6ops@ietf.org>
Subject: Re: [v6ops] Flash renumbering

On Fri, 18 Sep 2020 at 20:47, Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>> wrote:
From standard point of view
local traffic should not stop after CPE would lose uplink,
Because internal CPE switch should still switch traffic
After internal CPE router would stop promoting itself a router for this link


In this scenario, when the WAN interface (native Ethernet or PPP) goes down, would you expect the CPE router to:
a) continue sending RAs with the old prefix PIO as if nothing has happened.
b) send an RA with PIO prefered lifetime of 0
c) simply stop sending RAs with the PIO


a. messes up multihoming, and is a bit disingenuous of the CPE to continue advertising
b. Helps deprecate the stale GUA prefix but means we lose local IPv6 connectivity
c. Prevents new devices from attaching and getting local IPv6 connectivity

ULA would help retain local IPv6 connectivity behind CPEs that implement b & c.
I'm kinda wishing we included a recommendation for the use of ULA in draft-ietf-v6ops-cpe-slaac-renum.  But I imagine that would be rather contentious