Re: [v6ops] Flash renumbering

Richard Patterson <richard@helix.net.nz> Mon, 21 September 2020 12:51 UTC

Return-Path: <richard@helix.net.nz>
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 2378E3A0E2E for <v6ops@ietfa.amsl.com>; Mon, 21 Sep 2020 05:51:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.099
X-Spam-Level:
X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, THIS_AD=0.799, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=helix-net-nz.20150623.gappssmtp.com
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 d3FlH1C3z7YB for <v6ops@ietfa.amsl.com>; Mon, 21 Sep 2020 05:51:11 -0700 (PDT)
Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB3493A0E1B for <v6ops@ietf.org>; Mon, 21 Sep 2020 05:51:11 -0700 (PDT)
Received: by mail-io1-xd2b.google.com with SMTP id q4so5837193iop.5 for <v6ops@ietf.org>; Mon, 21 Sep 2020 05:51:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=helix-net-nz.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ytuOAIKKmy7cQbAGqdnqwh3QrDUPDaI9RvUZyGauAJU=; b=T8QqQJenvgusfSctID9htMEV9cEx5QL9B+2y6r3qBTeXWcSc2Rj2mT/orvT3yzaVNT DmC40YonZY4La5C6OPT+GByNKM2yjJFt73/OHcEkCo5dg51OMH4yth586zeHor8Edbi1 VacrcWpJt6NtsBwq4aT6fFIFN9EKG0ECPoBGelda1gEZ1WQcOMLW5d46FCDKS4JnFK7r 4gh9SDdaqijaFeaPhiSNWA0zzGibznhnMtjNhQgCE3XyKL4wjYT7PHK/k4X7nhyNMlAO j7VAoPgTNB82zV+QrAGNAudeC4Q35nzGB6IsONPzlxw1YugX2xuOPUEDaxLWLzyuA1gB 5srQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ytuOAIKKmy7cQbAGqdnqwh3QrDUPDaI9RvUZyGauAJU=; b=b7XAfYRmOJWC++2A3vet2oXnaY4YD5ZCimY22E3B974v1qbP4Z0wPlCq1g2A0HGETw JUATyxc0iGgE9UDUmwNFbkx6dtNqq8jhCVjhQSVyI9PxC9qCRDPI3mvDiH4SvhQOjcgD khCaTP4XtRnB3Lxie5Sp5CFFIf7RtGd+T6luphEZJ+w5HCFecmuGSK4YqH57sNzdrL1s YXcOjB3ZvhtxR+KY1s06eDuZbcWyWGMjN5ziu/sl8y7AntuhQyG8khoK1xJ01y1nXC2T z76q/TR1l41ggeCJn+CD7a4PE4H19fzCj2t03pq145CWoEw/RVx/lGbTG+RvGwIcyCK/ ftXw==
X-Gm-Message-State: AOAM53125MQwYtHVW5hpOGXQt/jL/sTU4hZBOfdRkekgLW7b+H8PVLDH brxWLwb/spw6yln/+LCQ1V6fKb6J0eFwAA==
X-Google-Smtp-Source: ABdhPJxFSCZHUlczuYM/ipMnglkGQXm4CykM0l6OrjUsZT0NmLMXGQch9Et6I03LRdZCkjqU1I0fcQ==
X-Received: by 2002:a05:6638:1616:: with SMTP id x22mr42011824jas.110.1600692670516; Mon, 21 Sep 2020 05:51:10 -0700 (PDT)
Received: from mail-il1-f178.google.com (mail-il1-f178.google.com. [209.85.166.178]) by smtp.gmail.com with ESMTPSA id l12sm5821783ioq.50.2020.09.21.05.51.09 for <v6ops@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Sep 2020 05:51:09 -0700 (PDT)
Received: by mail-il1-f178.google.com with SMTP id y2so2865922ila.0 for <v6ops@ietf.org>; Mon, 21 Sep 2020 05:51:09 -0700 (PDT)
X-Received: by 2002:a92:79d2:: with SMTP id u201mr30514615ilc.83.1600692669475; Mon, 21 Sep 2020 05:51:09 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <5b2f71a95a7944f0bcda368c11c6d7a2@huawei.com>
From: Richard Patterson <richard@helix.net.nz>
Date: Mon, 21 Sep 2020 13:50:57 +0100
X-Gmail-Original-Message-ID: <CAHL_VyDP-w9LzQTCkQM-tyjVo+T982aazFJTWeNPvGqHSHRtgQ@mail.gmail.com>
Message-ID: <CAHL_VyDP-w9LzQTCkQM-tyjVo+T982aazFJTWeNPvGqHSHRtgQ@mail.gmail.com>
To: Vasilenko Eduard <vasilenko.eduard@huawei.com>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f5730a05afd24d6e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/JT9m31PM4xsN6m1JLByUfufaesc>
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 12:51:14 -0000

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>
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]
> *Sent:* 18 сентября 2020 г. 23:31
> *To:* Vasilenko Eduard <vasilenko.eduard@huawei.com>
> *Cc:* v6ops@ietf.org
> *Subject:* Re: [v6ops] Flash renumbering
>
>
>
> On Fri, 18 Sep 2020 at 20:47, Vasilenko Eduard <
> 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
>