Re: [v6ops] Flash renumbering

Vasilenko Eduard <vasilenko.eduard@huawei.com> Tue, 22 September 2020 10:17 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 53B013A0B95 for <v6ops@ietfa.amsl.com>; Tue, 22 Sep 2020 03:17:19 -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 vDfmnEcY_daX for <v6ops@ietfa.amsl.com>; Tue, 22 Sep 2020 03:17:16 -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 38A1D3A0B25 for <v6ops@ietf.org>; Tue, 22 Sep 2020 03:17:16 -0700 (PDT)
Received: from lhreml744-chm.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 0E4DB2E7B84801E515E9; Tue, 22 Sep 2020 11:17:14 +0100 (IST)
Received: from msceml705-chm.china.huawei.com (10.219.141.144) by lhreml744-chm.china.huawei.com (10.201.108.194) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 22 Sep 2020 11:17:13 +0100
Received: from msceml703-chm.china.huawei.com (10.219.141.161) by msceml705-chm.china.huawei.com (10.219.141.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 22 Sep 2020 13:17:12 +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; Tue, 22 Sep 2020 13:17:12 +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//6SnYAA3P8+A///L4qA=
Date: Tue, 22 Sep 2020 10:17:12 +0000
Message-ID: <b18832ca2efb44d59d2186863f56481b@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> <6f5fabd632fb4954adc13ea805be3c0b@huawei.com> <CAHL_VyDO_DTtE2Uj-T2f=a4wdJ2QtNrtO8YwMS88rZtcit5MrQ@mail.gmail.com>
In-Reply-To: <CAHL_VyDO_DTtE2Uj-T2f=a4wdJ2QtNrtO8YwMS88rZtcit5MrQ@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.92]
Content-Type: multipart/alternative; boundary="_000_b18832ca2efb44d59d2186863f56481bhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Bhl_FnPfBXU4PwQQQuJqk_IwyLU>
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: Tue, 22 Sep 2020 10:17:20 -0000

Hi Richard,
I have not understood you.
We are talking about the situation of uplink lost, then Router could continue sending old PIOs, but inform hosts that this router is not default anymore (router lifetime 0).

If it is the single router, then hosts could continue to use PIO for local communication. Nothing could be done for global connectivity (redundancy needed).

If it is multi-home on single link, then rule 5 of RFC 6724 would give the hint to all hosts to use PIO of other router.

Hence, problem of lost uplinks is resolved – just support of RFC 6724 is needed on hosts (rule 5) and RFC 7084 on routers (G-4 and L-3 requirements).
Why you claim that it should be separate links to separate routers?

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

That presumes the end-host is multihomed with different interfaces to different networks, rather than attached to a single network that is multihomed.

On Mon, 21 Sep 2020 at 16:24, Vasilenko Eduard <vasilenko.eduard@huawei.com<mailto:vasilenko.eduard@huawei.com>> wrote:
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<mailto:richard@helix.net.nz>]
Sent: 21 сентября 2020 г. 15:51
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

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